Yes.

Lol

Not a “hater” in terms of trying/wanting to be mean, but I do disagree. I think a lot of people downvoting are frustrated because this attitude takes an issue in one application (yay), for one distro, and says “this is why Linux sucks / can’t be used by normies”. Clearly that’s not true of this specific instance, especially given that yay is basically a developer tool. At best, “this is why yay sucks”. (yay is an AUR helper - a tool to help you compile and install software that’s completely unvetted - see the big red banner. Using the AUR is definitely one of those things that puts you well outside the realm of the “common person” already.)

Maybe the more charitable interpretation is “these kinds of issues are what common users face”, and that’s a better argument (setting aside the fact that this specific instance isn’t really part of that group). I think most people agree that there are stumbling blocks, and they want things to be easier for new users. But doom-y language like this, without concrete steps or ideas, doesn’t feel particularly helpful. And it can be frustrating – thus the downvotes.

Yeah, but they require somewhere in the neighborhood of a thousand pounds of batteries to do so. Some of the more egregious ones need multiple thousands, e.g. the electric hummer whose battery alone is heavier than an ICE Honda Civic. Whereas a dozen gallons of gasoline (roughly 72lbs at 6lb/gal) can power that same ICE Civic for a nearly equivalent range, while causing much less wear & tear on the roads, and likely releasing less tire particulates due to the reduced weight. Of course it still releases CO2 and other nasties…

But yeah, the energy density of EVs is still super bad. It’s just “good enough” that we’re making it work.

As I understand it, the big issue is energy density? A tank of gasoline takes you quite far compared to an equivalent tank of hydrogen.

And don’t get me wrong, lithium batteries are super bad at this too, but I do think that has been a limiting factor for H cars.

And then there’s the whole tire dust issue which is definitely a conversation worth having.

People aren’t misunderstanding the issue. Third party cookie support is being dropped by all browsers. Chrome is also dropping them, but replacing them with topics. Sure, topics is less invasive than third party cookies, but it is still more invasive than the obvious user friendly approach of not having an invasive tracker built into your browser. No other major browser vendor is considering supporting topics. So they’re doing an objectively user unfriendly thing here. This is the shit that happens when the world’s largest internet advertising company also controls the browser.

I once heard that argument in a different, yet equally rage inducing context: “outlawing same-sex marriage isn’t discrimination! Everybody has the right to marry someone of the other sex” 🙄🙄🙄

In other news, emacs still didn’t ship my init.el as part of the default configuration! Lol

Sphinx has warnings for these already. They’re just suppressed and ignored :)

I see what you mean. The python ML ecosystem is… not far off from what you describe.

But please consider Python as a language outside the pytorch/numpy/whatever else ecosystem. The vast majority of Python doesn’t need you to setup a conda environment with a bunch of ML dependencies. It’s just some code and a couple of libraries in a virtualenv. And for system stuff, there’s almost never any dependency except the standard library.

You might be even more concerned to find that your Fedora package manager, DNF, is also written in Python: https://github.com/rpm-software-management/dnf

Fact of the matter is that Python is a language that gets used all the time for system level things, and frequently you just don’t know it because there is no “.py” extension.

I’m not sure I understand your concerns about python…

1. Performance is worse than C, yes. But writing performance sensitive code in Python is quite silly, it’s common to put that in a C library and use that within python to get the best of both worlds. DNF does this with libdnf.
2. “It feels like an extension of proprietary hardware planned obsolescence and manipulation.” This is very confusing to me. There has been one historic version change (2->3) which broke compatibility in a major way, and this version change had a literal decade of help and resources and parallel development. The source code for every Python interpreter version is freely available to build and tweak if you’re unhappy with a particular version. Most python scripts are written and used for ages without any changes.
3. “i don’t consider programs written in Python to have permanence or long term value because their toolchains become nearly impossible to track down from scratch.” Again, what? As I said, every Python version is available to download, build, and install, and tweak. It’s pretty much impossible for python code to every become unusable.

Anyway, people like the Fedora folks working on anaconda choose a language that makes sense for their purpose. Python absolutely makes sense for this purpose compared to C. It allows for fast development and flexibility, and there’s not much in an installer program that needs high performance.

That’s not to say C isn’t a very important language too. But it’s important to use the best tool for the job.

Anaconda is just an OS installer program. At least, the Anaconda that you’re referring to. After installation, it’s gone.

There is also Anaconda which is a Python platform/package system/whatever. Maybe you’re confusing the two?

The reason is simple: in order to be a signed piece of secure boot software, the kernel needs to do everything possible to prevent unsigned code from running at the kernel’s privilege level, or risk its signing key getting revoked by Microsoft.

I assume your kernel is from Fedora and is signed. If your kernel, once loaded, allowed the loading of unsigned kernel modules, then any attacker could use it as part of an exploit that allows them to break secure boot. They would simply include a copy of the Fedora kernel, and then write a custom kernel module which takes control of the machine and continues their attack. The resulting exploit could be used on any system to bypass and defeat secure boot. In essence, secure boot is only as secure as the weakest signed implementation out there.

So, Linux distributors need to demonstrate to Microsoft that they don’t allow unsigned kernel code execution. Linux contains a feature called lockdown, which implements this idea. In order to be effective, lockdown must be automatically enabled by the kernel if secure boot is enabled. Interestingly, Linus flat out refuses to include the code to do that, I guess he disagrees with it. So a little discussed reality of secure boot is that, all Linux kernels which are signed have this extra patch included in order to enable lockdown during secure boot.

And that is why you can’t load an unsigned module when secure boot is enabled.