Maybe.

Linux won because it worked. Hurd was stuck in research and development hell. They never were able to catch up.

However, Linus’s kernel was more elaborate than GNU Hurd, so it was incorporated.

Quite the opposite.

GNU Hurd was a microkernel, using lots of cutting edge research, and necessitating a lot of additional complexity in userspace. This complexity also made it very difficult to get good performance.

Linux, on the other hand, was just a bog standard Unix monolithic kernel. Once they got a libc working on it, most existing Unix userspace, including the GNU userspace, was easy to port.

Linux won because it was simple, not elaborate.

Zsh

No plugin manager. Zsh has a builtin plugin system (autoload) and ships with most things you want (like Git integration).

My config: http://github.com/cbarrick/dotfiles

Exactly.

My take is that the issue isn’t with tmpfiles.d, but rather the decision to use it for creating home directories.

Yeah, but I want both GPU compute and Wayland for my desktop.

Long term, I expect Vulkan to be the replacement to CUDA. ROCm isn’t going anywhere…

We just need fundamental Vulkan libraries to be developed that can replace the CUDA equivalents.

• cuFFT -> vkFFT (this definitely exists)
• cuBLAS -> vkBLAS (is anyone working on this?)
• cuDNN -> vkDNN (this definitely doesn’t exist)

At that point, adding Vulkan support to XLA (Jax and TensorFlow) or ATen (PyTorch) wouldn’t be that difficult.

Unfortunately, those of us doing scientific compute don’t have a real alternative.

ROCm just isn’t as widely supported as CUDA, and neither is Vulkan for GPGPU use cases.

AMD dropped the ball on GPGPU, and Nvidia is eating their lunch. Linux desktop users be damned.

There’s a Wikipedia article on multiple encryption that talks about this, but the arguments are not that compelling to me.

The main thing is mostly about protecting your data from flawed implementations. Like, AES has not been broken theoretically, but a particular implementation may be broken. By stacking implementations from multiple vendors, you reduce the chance of being exposed by a vulnerability in one of them.

That’s way overkill for most businesses. That’s like nation state level paranoia.

No, you don’t split the file. You split the master decryption key.

Each user just needs to remember their own password, and SSS can reconstruct the master key when enough users enter their passwords.

multiple people to agree on decrypting a file

For that, you would use Shamir’s Secret Sharing algorithm rather than multiple encryption.

https://en.wikipedia.org/wiki/Shamir's_secret_sharing

AES has been accelerated on all Intel CPUs since Broadwell, was common as far back as Sandy Bridge, and has been available since Westmere.

AMD has had AES acceleration since Bulldozer.

But the commenter is right that adding a second layer of encryption is useless in everything except very specific circumstances.

Does Hyperland support scrolling tiling?

That seems to be the new hotness in tiling WMs.

(Also, you can change the default editor visudo uses, but I don’t remember the command because I won’t be changing it until I get a grip on vim and can make a decision about which editor I want to use.)

It just uses your preferred editor, which you set with the EDITOR environment variable. In fact, any program that opens an editor should use this to determine the user’s preference.

I set mine to VS Code:

export EDITOR="code -nw"

Examples of programs that use this variable include visudo, crontab -e, and git commit.

After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today.

From https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq

Yeah, if you’re not up to the challenge of maintaining your own system, Arch isn’t for you.

Nothing. They’re mostly the same thing.

The Ubuntu version will sometimes print “ads” to your terminal :P.

For a prod server, I’d choose Debian over Ubuntu if I didn’t have paid support, because I’m not a fan of Canonical. If I needed paid support, I’d choose Ubuntu, because Debian is strictly a community distro. (That community happens to include major companies, like Google.)

See the other thread.

TL;DR: Useful abstractions and a hell of a dependency solver.

Sure, but the interface is probably just as important as the actual logic behind it, isn’t it?

The logic is why I love Apt. Most robust dependency resolution algorithms I’ve used.

But also, I don’t have any issues with the CLI. Having a distinction between apt-get and apt-cache and apt-mark doesn’t feel weird to me. You’re practically just separating the top-level sub commands by a dash instead of a space. The apt command is really just a convenience thing, and there are specialized tools for the more advanced things. Which is fine by me.

Also, the top level apt command doesn’t guarantee a stable CLI, so for scripting you’re supposed to use apt-get and friends anyway.

Honestly I would consider that one of the fundamental things a package manager must do.

You’d be surprised. Homebrew (the de facto standard package manager for macOS) doesn’t do this. Though, you can at least lookup the “leaf” packages which are not dependencies of any other package.

And, most language-specific package managers can’t do this. E.g. if you install software with pip or cargo.

you have to remember the extra step after it’s finished installing

If the package is in use, it shouldn’t be an orphan.

For example, what if you race with a cleanup job that is removing orphans? (Debian is hyper stable, so I often enable unattended upgrades with autoremove. I’m not so comfortable doing that on Arch ;)

What you’ve described is just an apt-get install when you start and and apt-get remove when you’re done. Or more properly setting it as a build dependency in your source package, to let Apt handle it.

But also, why uninstall build tools?

This, at least version constraints, is another one I’d consider essential tbh. The rest are great though, I agree.

Yeah, version constraints are common. But most other package managers bail with an error when they encounter a conflict. Apt is really good about solving conflicts and proposing solutions. Often it will propose multiple solutions to your conflict for you to choose from.

Again, it’s the solver part of Apt that makes it the best IMO.

Packages often enable the services they install right away.

That’s a problem of the package, not the package manager.

Generally this fits with Debian’s philosophy. But regardless I think it’s out-of-scope for why Apt is good. You could make a distro with Apt and not have your packages do this.

To temporarily install a package […]

I’m not talking about apt the CLI tool, but the actual package manager. The plain apt tool is only designed to be a convenience wrapper for common workflows implemented in other tools.

As you correctly pointed out, Apt has the distinction between packages installed as a dependency (“auto installed”) versus packages installed directly (“manually installed”). This is precisely one of the reasons why I consider Apt the best package manager. (Yes, I know other package managers can do this, not all though.)

If you want to install a package as manual, then later mark it as auto, you can do that with apt-mark.

dpkg-scanpackages is eternally slow.

Are you maintaining a PPA for others?

Frankly, I’ve never run into this problem.

The standard packaging tools […] are insane.

dh_make helps you create a package that adheres to Debian policy, and there is good reason for Debian to have those policies. But if you’re just packaging something yourself, you don’t have to use it. It’s just a template for new packages.

At the end of the day, all you really need to create a deb is to create two files debian/control and debian/rules. These are the equivalent to a PKGBUILD. The control file specifies all of the dependency metadata, and the rules file contains the install script.

The difference in packaging philosophy is that PKGBUILDs are external and they download the upstream sources. On the other hand, in Debian, they rehost the upstream package and add the debian directory. This means that building Debian packages is mostly hermetic: you don’t need access to the network.

What do you like about it?

Mostly that it makes super useful distinctions between concepts. But there are other goodies.

• Manually installed versus auto installed.
• Uninstalled versus purged.
• Upgrade versus Dist Upgrade.
• Dependency versus suggestion versus recommendation.
• The alternatives system.
• Pinning, and relatedly that packages can include version constraints in their dependencies.
• Interactive configuration at install time.
• Support for both source and binary packages.

I also do appreciate that Debian pre-configures packages to work together with the same set of conventions out of the box. But again, that’s a property of the packages, not of Apt.

By starting the switch to Gentoo, they either learn Linux well enough to never want to go back, or they fubar their system so bad that they can’t go back.