You could make the same kind of articles for the old coreutils if you really wanted to. Just creatively “rewording” the bugfixes from the recent 9.8 release:

• GNU Core Utilities Are Causing Failures [when copying between NFS and non-NFS filesystems with ACLs]
• GNU Core Utilities May Cause Data Corruption [with copy ranges larger than 2 GiB]
• Correctness Bugs Found in GNU Core Utilities [tail --pid may race with reused PIDs]

I feel like the reactions regarding uutils are a bit… off in general. There seem to be a lot of people who are pathologically negative towards open source projects for, frankly, bullshit reasons, like vague complaints about “Rust evangelism” (what?) or how permissive licensing is against the spirit of open source (WTF).

Phoronix isn’t helping with these clickbait articles which border on content farming and their failure to moderate their comments of course, but these negative attitudes seems to cut across sites, also including Lemmy, Reddit and even Hackernews.

The uutils team seems to be doing well but it makes me sad to think about any aspiring open source devs without corporate backing reading such drivel.

You could always swap out crons, syslog, init systems, and it would not affect Gnome.

That just isn’t true. Both GNOME and KDE already have hard dependencies on systemd-logind. GNOME hasn’t supported non-systemd Unixes since 2015! The only reason it works is that the elogind project provides a systemd-logind implementation decoupled from the rest of systemd. The GNOME team has elected to give users of elogind (despite not being officially supported) advance warning that they’ll have to do some amount of extra work in the future if they want to ship GNOME 50. Honestly I think that’s quite fair of them.

There are more GNOME features that don’t work without systemd even if it launches, like application isolation using systemd scopes. Fundamentally this is about not having to reinvent the world. Why should every DE have bespoke implementations of user, login and service managers instead of just using the ones that 99% of user systems already have?

Nu’s find builtin isn’t a GNU find repacement. I think what you actually want is ls piped into where:

ls **/* | where type == file

I do question the choice to alias a well-known program with a builtin that does something entirely different. You can also use ^find to avoid calling the builtin. I would’ve expected \find (bash-like) or command find (fish-like) to work as well, but alas…

That’s not entirely true, unless you choose to nixify everything. You can just have a basic Nix configuration that installs whatever programs you need, then use stow (or whatever symlink manager you prefer) to manage the rest of your config.

You can’t entirely forget that you’re on NixOS because of FHS noncompliance but even then getting nix-ld to work doesn’t require a lot of effort.

No C program is written to satisfy a borrow checker and most wouldn’t compile with one, so adding it would require rewriting the world anyways. At that point why not choose a language that, in addition to being memory safe, also drastically cuts down on other kinds of UB, has sum types, sane error handling, a (mostly) thread safe standard library, etc.?

The mentioned performance governor runs the CPU permanently at maximum frequency, which is obviously bad on battery powered devices and on devices with lacking thermal headroom. I think it might cause problems in virtualized environments as well but I’m not sure about that.

To be fair showing the overview on startup makes perfect sense on vanilla gnome, it’s only dumb if you install one of the two specific extensions that partly replace it.

Running poweroff is one of the correct ways on anything Systemd (details). If that doesn’t work then something is broken.

If you haven’t done so already try looking into the journal. sudo journalctl -b -1 -e will take you to the end of the log for the last boot.

I am very sorry to remind everyone about the existence of Visual Basic, but it has:

• VbCrLf
• VbNewLine
• ControlChars.CrLf
• ControlChars.NewLine
• Environment.NewLine
• Chr(13) & Chr(10)

And I know what you’re asking: Yes, of course all of them have subtly different behavior, and some of them only work in VB.NET and not in classic VB or VBA.

The only thing you can rely on is that “\r\n” doesn’t work.

GUIs do have advantages in things like discoverability. Honestly the 1983s Apple Lisa nailed this with the idea of having clickable menus annotated with keyboard shortcuts, so users could do the same thing faster next time. For some reason we stopped doing this (especially in web apps), but that’s a reason to make better GUIs, not to RETVRN to the feature set of a VT100.

I don’t know why we have to go on nonsensical diatribes about “UNIX wizards” though when we’re fundamentally talking about a handful of minor UI improvements to things that already exist.

To be fair that’s not the entire story, since you need to actually resolve the conflicts first, which is slightly scary since your worktree will be broken while you do it and your Linter will be shouting at you.

You may also want a dedicated merge tool that warns you before accidentally commiting a conflict and creating a broken commit.

Oh and non trivial resolutions may or may not create an evil merge which may or may not be desirable depending on which subset of git automation features you use.

Using git status often is definitely good advice though.

I agree.

You could say that about any kind of autocomplete. Why would people install snippet plugins into their vim/emacs? Sure you can just type everything by hand but it’s just more convenient.

Personally I find these kinds of inline AI suggestions make a more convincing use case than trying to prompt engineer a Chat based LLM and diverting your attention to phrasing specifics instead of the actual problem space.

If your build fails because you can’t track down the literal ≠ in the code I would recommend just looking at the compiler error. I understand the concerns about == vs = more but the vast majority of LSPs (and some compilers) will catch that too.

I have also yet to see any IDE enable ligatures by default, at least VS Code and the JetBrains suite both require opting into them even though their default fonts support them.

The GDPR conversation is hilarious. Sure they’re a US based company, but after 5 years of operation I would’ve expected them to have consulted a lawyer about this at some point. Forgetting (assuming it’s not “forgetting”) about the required documentation is not the worst thing in the world morally but it doesn’t exactly make them look competent either.

While unfortunate, not shipping these standard Google apps is not really an option for any Android manufacturer due to Google requirements. Including them is required if you want to use anything from the GSM, which includes things like the Play Store and everything it touches. You can technically ship a different Android distribution like Lineage or /e/, but that’s not really what most people will be expecting of an “Android” phone and will narrow the viable target demographic even more than the value proposition already does.