Hello, tone-policing genocide-defender and/or carnist 👋
Instead of being mad about words, maybe you should think about why the words bother you more than the injustice they describe.
Have a day!
This probably has a lot to do with the new DOA XServer fork being “anti-DEI” (pro-discrimination). When these slimy shitweasels go out and vice signal about how bigoted they are, they congregate around it and form a new harassment campagin because they have no life.
Sorry you’re getting harassed. I hope you can take solace in the fact that these little pissbabies lead miserable lives.
Linux on Apple Silicon is a totally different story than it was for Intel Macs because of the work put in by the Asahi team. It’s actually one of my favorite pieces of hardware to run Linux on. The trackpad works great too, btw.
It’s not for no viable reason. Rust is just safer than C. There absolutely are bugs with GNU coreutils, so it’s not even a hypothetical like you implied. But beyond safety, some of the Rust equivalents are more performant than their C counterparts.
And uutils is already heavily tested against the GNU coreutils. It’s not some fly-by-night rewrite that people aren’t serious about. I don’t know if it’s been formally audited yet, but it absolutely will be when companies like Canonical (and hopefully SUSE and Red Hat, one day) want to start shipping them.
Just adding to this for other people that don’t know: you can also install most* standard Linux applications and tools on SteamOS, as long as it’s available as a Flatpak, or you can install it to your user directory. Technically, you can even bypass that last caveat and install whatever you want, but you’re going to have a bad time if you don’t know what you’re doing.
Alternatively, you can install any Linux distro on your Steam Deck if game dev isn’t a good experience for you on SteamOS. In fact, Bazzite is working on a GDX (Game Developer eXperience) edition, and will likely be a solid choice once it’s ready.
I don’t dislike GNOME (except for their insistence on shirking and breaking standards that everyone else uses), but I’m curious about why you prefer KDE on your laptop, but GNOME on your desktop. If anything, I’d think that GNOME’s larger UI might be easier to use with a less precise pointing device than default KDE.
internationalization
Interesting point. I don’t actually know about that. What can the GNU coreutils do with regard to internationalization? Just the output of commands, or can they also internationalize stuff like command args?
I fully agree with you on the accessibility front. It’s not even good on X11, but it’s unusable on Wayland, from what I understand :( Accessibility on Linux needs a massive funding and development initiative, and it needed to be done a long time ago.
But uutils is pretty solid. I’ve swapped out my GNU coreutils entirely (on Arch, not Ubuntu, because I value my time too much to be troubleshooting broken snaps) and haven’t run into any issues. I think people are underestimating how close the compatibility already is. I’m sure something I use at some point will try to invoke an option that doesn’t exist in the uutils version, but it’s been solid for me so far.
That’s not what I mean. Yeah, getting the environment variables are simple enough, but if you simply exec something as the root user, whatever you exec will naturally be looking for configs in /root/.config and not your ~/.config dir, so any configurations to things like your text editor won’t be read.
I don’t think it’s that simple. The challenge is that you need to still behave as if it’s invoked as the user so that the editor uses their configurations instead of simply execing it as root.
I could be wrong though ¯\_(ツ)_/¯
Rare Canonical W. The only thing I miss from the original sudo is sudoedit, but I’m pretty sure that’s on the Rust implementation’s TODO list.
The people complaining that Apple copied a good thing are missing the point. If Apple includes containerization on macOS by default (even if you have to enable it manually), more developers can just target Linux instead of Linux and macOS for certain types of applications (real bash scripts with GNU coreutils instead of the trash that Apple ships, servers, etc.).
Because google doesn’t want you doing anything that they can’t control fun on the host Android system. They did the same thing with crostini on ChromeOS for “security”.
TIL blahaj.zone has a Peertube instance. Nice!
Agree. Currently, single-file Rust source projects are very un-fun to work with.
They seem to cite getting better rust-analyzer support as an important part of getting cargo-script stabilized, so I’m hopeful.
I cannot wait for cargo-script to stabilize.
GPL is more freedom for users and developers. MIT is less freedom for users because it grants more “freedom” for some company to exploit the developer’s labor by taking it to make something proprietary with it.
If you want to use GPL code, pushover licenses are incorrect because they protect the user and developer from this nonsense.
If the other projects are licensed with a GPL, there is no issue doing any of these things (except using them for proprietary purposes later), which is the point. If you licensed your project incorrectly, that isn’t the GPL-licensed project’s fault.
Precisely. The Rust community should stop using pushover licenses.
Other than the example uses provided in the article, does anyone have any interesting ideas for how this could be used? The RUST_LOG=debug one looks like it’ll be particularly useful as an easy way to see what network requests a given binary might be making.
The grown-ups that run Fedora and the community are overwhelmingly against this very bad proposal, so I don’t think the reich-wing creep’s toy project is going to replace the official XServer implementation any time soon.