Yes.

That makes about as much sense as saying that pip, gem, npm, cargo, or nix should called be the default package manager on Mac OS…

The default package manager is the default because it manages the system’s software. RPM, Deb/apt, pacman, etc. Homebrew is like pip or docker or cargo or snap or whatever else. You can set it up if you’d like but it’s certainly not a default. (Though I’m not trying to dispute that it’s good 😊)

Mac OS doesn’t have a good default package management solution (though they would if they just opened up the app store and added a CLI). It’s ok to admit it, and say that third party folks (who Apple does not support unless I’m missing something) are powering a pretty good third party experience. If only Apple cared about people who wanted a truly free an customizable computer, they could make a great OS :)

What’s wrong with homebrew?

Crappy default package management.

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.

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.

If you can’t remember or don’t know the syntax well you can still understand a systemd timer, but that is much hard for the crontab.

I will agree that it is easier to read a timer than a Cron entry, especially if you’ve seen neither of them before.

Granted, crontab uses fewer characters, but if you only set up either once in a blue moon you’ll need the docs to write either for a long time.

This is where I disagree. I very rarely setup a Cron job, but when I do, I don’t need to look anywhere for docs. I run crontab -e and the first line of the editor contains a comment which annotates each column of the Cron entry (minute, hour, dom, mon, dow). All that’s left is to put in the matching expressions, and paste my command.

Compare that to creating a new timer, where I need to Google a template .service and .timer file, and then figure out what to put in what fields from the docs. That’s probably available in the manual pages, but I don’t know which one. It’s just not worth it unless I need the extra power from systemd.

This is from somebody who has several systemd timers and also a few Cron jobs. I’m not a hater, just a person choosing the best and easiest choice for the job.

Cron may be old but I don’t think it’s “legacy” or invalid. There’s plenty of perfectly good, modern implementations. The interface is well established, and it’s quite simple to schedule something and check it. What’s more, Cron works on new Linux systems, older non-systemd ones, and BSD and others. If all you need is a command run on a schedule, then Cron is a great tool for the job.

Systemd services and timers require you to read quite a bit more documentation to understand what you’re doing. But of course you get more power and flexibility as a result.