Linux has a standardized API called Advanced Linux Sound Architecture (ALSA). Another layer above ALSA, a sound server, should handle interactions with userspace applications. Initially, that layer was Pulseaudio and Jack, but it was recently replaced by Pipewire.

“Initially?” Pulseaudio was released in 2004. By then, Linux had been around for 13 years, and ALSA had been around for 6 years. And it took some years before Pulse became common.

Pulseaudio was first adopted by a major distribution in Fedora version 8, in 2008 - when ALSA was already 10 years old - and even later by Debian, Ubuntu, and so on.

“Initially” is entirely inappropriate here. Pulseaudio is Poetteringware and has no relationship to any original or early Linux audio subsystems.

I don’t know that I can answer your question, sorry, but something you said confuses me.

• file storage/syncing from a central server (so Syncthing is out) … While working absolutely fine for sync between different devices (have it in use in a different scenario), the peer-to-peer nature is unsuitable for what I’m looking for

Why? I think you missed describing a requirement, because there’s no reason SyncThing can’t do “for syncing from a central server.” Do you mean one-way, or one-to-many, or what? What, exactly, doesn’t SyncThing do that you need?

I believe SyncThing is not the right tool in many scenarios, but I don’t understand these bullet points.

For one thing, SyncThing is only peer-to-peer if you set it up that way. You can absolutely define a “master” simply by only connecting the “clients” to the master. It’s an utterly arbitrary distinction, but the clients won’t know about or communicate with each other unless you explicitly pair them with each other. This is how I have our phones set up: each one is paired to the central server, but neither is an introducer nor knows about each other. We have one directory that the server has shared with both phones, and several directories that the server shares only with one or the other phone. I even have the server connected and sharing all of the directories with a second, backup server that neither phone knows about.

Again, I’m not pimping SyncThing; it has weaknesses, the biggest one being any lack of sophisticated merge ability. I wish it had a plugin system where, for each for type, in case of conflicts it would call out to some external merge program; rather than just throwing up it’s hands and going, “well shucks, guess I’ll just spam a bunch of sync conflict files”. And it can be annoyingly slow recognizing changes and syncing; it would be a terrible choice for any sort of pair programming file sharing.

But what problems have you encountered with it, for your case?

will, hopefully, push app developers to target Wayland properly.

IME, having to force people to do something in OSS is a very bad smell, and cause for reflection.

Excel. Before it got subsumed and was infected with the ribbon. The Excel team were truly talented developers.

I think much of that was part and parcel out Microsoft acquiring them when they bought Excel, and it’s obviously degraded in the interim, but for a while they were all island of programming excellence in the Sargasso Sea of usual Microsoft incompetence. The only thing Microsoft is really good at has ever been marketing and sales, and they weren’t even good at staying on the ethical, legal side of business operations.

I think we’re mostly on the same page.

Years ago, after over a decade making fistfuls of money as a Java developer and yet becoming almost physically nauseous at the idea of having to look at more Java code, I did a survey of possible ships to jump to. I was on the management track by that point - still more level enough to have my hand in - but salaries weren’t a huge factor. So I wrote a series of projects in three upcoming languages at the time: Vala, Rust, and Go.

I don’t remember now why Vala dropped out so quickly; I think it was some unsavory dependency or relationship with Gnome libraries, but honestly I don’t recall.

But I hated Rust. It felt like a language I was constantly fighting with, and simple, common things were just hard. And it’s not like I didn’t have experience with other paradigms; I cut my teeth on C and Pascal, did a fair amount of Scheme in college, actually implemented a project in Haskell that went into production at one company (and, for that, I sincerely apologize to every developer who worked there after me), and was part of a team that built an ETL engine for what qualifies as “big data” in Erlang at another.

Rust was the worst developer experience of them all, including Erlang, and that’s saying something.

Go was stupid easy to write, and more importantly, to understand other people’s code, and relatively hard to write bad code in. It’s gotten worse over time (Go generics are practically useless compared to the amount of cognitive complexity they add) but that’s the hubris of language developers: they can’t resist adding new crap that’s just enshittifies the language. Although, in the case of generics, there was a solid decade of pressure, mostly new converts who hadn’t yet learned they are entirely unnecessary, to add generics, so I don’t really blame the Go team for that one. And, for the most part, they’ve avoided making large, bad additions.

In any case, I was roasting Rust, not Go.

I love the binaries from Rust projects: they’re small (smaller than Go, without the runtime overhead), they’re fast, and they’re usually statically linked. But the language itself is a nightmare, and the compile times are absurd, so it someone wants to give me a binary, fine. Otherwise, no thanks. Rust may be a “memory safe” language, but that doesn’t mean shit if the code isn’t auditable and people are just passing around binaries.

Re auditability: sure, a Rust programmer could audit a code base. But I’d argue that a non-Go developer with any experience with any C-ish language could audit a Go project and confirm that it’s not doing any sketchy things like calling out to a botnet. I doubt many people would claim the same for Rust.

Oh, that changes things. Founding a company and being an executive when Microsoft acquires you - well, it doesn’t necessarily make you technically competent, but it does make you a certain kind of smart.

You mean, curl as in the link library projects link in, or curl as in the executable front-end that most people think of when they think of curl?

There are countless (Ok, a little hyperbole there) downloaders and http request CLI tools already, implemented in just about any language you like. But curl as a linkable library - I am skeptical any Rust library will replaced libcurl anything soon except in Rust projects.

Anyway, the new hotness language everyone is rewriting their Rust projects in is Nim. Rust is passé now.

I’m really enamored of UEFI. Although, TBH I’m not clear anymore on the various layers of the boot cycle from BIOS to init.

I, too, spent many hours deciphering which grub mapping represented my boot partition, and which commands I needed to get a successful boot. And then distros made it worse by adding layers of convoy based grub config generators, and each one did it differently, and I completely lost the thread of how to configure grub - sure, I could get it to boot from the grub shell, but it was nearly impossible for any distro to figure out how to persist a grub configuration, without spending a day tracing down that the grub menu was aktually generated by some distro-specific package that put some of the configuration in /etc, and some in /usr/lib, and to regenerate the initrd and menu you had to run different commands that did stuff that eventually just ran mkinitrd.

I am not a distro-hopper per se, but this was infuriating enough that I was happy to see UEFI come along, and I think I’m getting to the point where I’m starting to almost be on the verge of understanding it. And the use of blkids to identify partitions is a beautiful thing. And it seems to work better - more reliably. I noticed that when I got a little micro computer recently for a project and when I went to install from the boot USB and it said “no UEFI support detected” I actually groaned. And after installing using grub, I couldn’t get it to boot past the BIOS. Fortunately, something I did in the BIOS allowed UEFI to be detected on my next install try, and everything went smoothly thereafter.

I don’t think there’s anything wrong with grub itself, but all these distros add so much “convenience” crap on top I think it’s just made using grub fragile again.

Rust is dead. Haven’t you heard? We’re rewriting everything in Zig now.

Rust should be deprecated.

On a more serious note, having a CTO at Microsoft, of all places, jump in on your side is kind of embarrassing. With one exception, code written at Microsoft has been some of the worst, most insecure, in the world.

Twitter is pro-religion? What kind? Satanism? Muslim? Hindu? Oh! Buddhist! Elon’s clearly a Buddhist.

Every time I see one of these posts about an OSS project finally moving off Twitter, I have this same baffled reaction: why the fuck were they still using it‽

There are dozens of projects to share storage; what’s needed are systems that share compute. Crypto currency controversy aside, things like Etherium with smart contracts, or the more venerable - but centrally controlled - seti@home, are more what’s needed. I suppose having the ability to support some mechanism of micro payments isn’t unreasonable, but I think it it were something like “I’ll donate X% of my unused C/GPU cycles to any processing request signed by the public key from this project,” I’d feel more comfortable about it. Micro payments for selling unused cycles to arbitrary projects is just another capitalist market I’m not interested in participating in.

Caveat: I’d be comfortable selling spare compute to for-profit projects: companies, etc. But that’s a side-note. What I’d like to see is a general-purpose way to donate spare cycles to specific projects. Definitely supporting whitelists, but optionally supporting blacklists. I think PK would be the foundation, as it would allow a True Believer to donate cycles to any project in the GNU Foundation, or specific projects from self-hosters.

Such compute would probably be horrendously slow, and figuring out how to parcel out and distribute e.g. compiling a project in an arbitrary language sounds like quite a challenge. I can see cases where the CI speed isn’t especially critical, such as building assets for a release, but the technical challenges seem difficult.

Oh, yeah; I’m fine with a GUI boot USB, and a GUI installer… but if possible, having a target use is nice. Having a “server” target often means they skip installing X/Wayland, window managers, DE, and a bunch of applications - which means a far shorter installation and fewer post-install clean-up hoops of removing crap that’s not going to get used.

I like the convenience of the GUI installers; I just like the option of saying “don’t install a desktop GUI.”

That sounds pretty neat.

I looked into it; it looks like they’ve got placeholders for server-oriented installs, but no ISOs yet; only for desktop and mobile at the moment. But it’s a cool project, and I’m keeping my eye on it - thanks!

This is why centralization is bad.

Maybe this will encourage more engagement in projects like i2p and ipfs. I’d be happy to donate some compute and bandwidth to these projects.

Maybe there isn’t a good solution, but throwing money at it doesn’t address the underlying issue that these important OSS projects are at the mercy of Big Hosting.

I just made up a new boogey-man!

Huh. I wonder who gave you a downvote for this. It looks like good advice, and TBH in all the years I’ve been using Linux, since I stopped building the kernels myself I haven’t messed with targeted builds or any of the newer power saving options.

Good advice, thanks

I think you have an X/Y problem.

Rootless podman requires no special firewall management. Like docker, you mearly expose you want in the container, and if you want those ports accessible outside the machine, the firewall has to allow access - just like any other program.

How is your podman configured? To use pasta, or slirp4netns? I often have trouble with pasta - I merely haven’t spent the time to figure out the details of using it - so I always just switch (back) to slirp4netns, which was the original network tool. Do this in /etc/containers/containers.conf, or dig into pasta and see if there’s something in there. The pasta package is actually called “passt.”

Did you set up subuid and subgid correctly?

Did you confirm you can access your services locally?

If you are using slirp4netns and have your account configured in subuid and subgid, then rootless podman should function as any other networking program, and you shouldn’t have any firewall issues.

As an aside, and just my humble opinion, I really hate firewalld. It makes firewall configurations complex and byzantine, and almost impossible to work with with other tools like nft. I’m sure it is great for some people, but anytime you add more complexity to a configuration, you add more opportunity for something to be incorrectly configured. I hate fighting with it, and have had times where I struggled to get it to open a port: I was in the wrong “zone”, or was in persistent mode rather than runtime mode, or whatever. It’s just unnecessary added complexity, and lately if the distro installs it I just uninstall it first thing and use nft.

If you followed the rootless podman wiki and everything else looks good, I’d look suspiciously at firewalld.

I just got a new, cheap, fanless micro computer that advertises itself as running Linux, and I spent today looking at Arch-based distros; Cachy made my short list, although I’ve never run it.

Is it suitable for running a headless, fanless mini-PC that’s raspy just going to be a snapclient host?

Is there a “Server” option in the installer? Once I get this set up, it’s going to be running entirely headless and without any peripherals (except the AUX out), and I’d like to strip out all of the unneeded software.

I’ve installed bare Arch before, and it’s a PITA I’d rather avoid; it’s easier to just install Garuda or Endeavor and then uninstall X and Wayland, and everything that depends on them. I’m wondering how Cachy fares in this situation.

Before anyone suggest I use a different, non-Arch distro for this: no. I understand pacman and yay, and I know where Arch puts files that every distro has a different opinion on locating. I’ll play with other distributions and switch when I find one I like more, but this is a device I just want to set up and forget about except for periodic upgrades.

Anyway, what are your opinions on CachyOS? I’ve been pretty happy with Endeavor for desktops, but I wouldn’t put it on a headless server.

It should; screen is older, and tmux was a new alternative to try to address screen’s deficiencies. It’s still more correct to say “tmux is like screen.”

There’s also dvtm, also newer than screen.

I was a longtime screen user before switching to tmux, which is IMHO categorically better. I tried dvtm for a few months, but you have to pair it with something else to get close to tmux, and I found it fussy and difficult.

Then there are a bunch of terminals with built in multiplexors, which baffles me: it binds you to a specific terminal, loses all of the benefits of persistent sessions, and can’t be used remotely over ssh. It’s not clear to me why people build or use those.

If you can boot from USB, I’d look at Ventoy, which will let you put multiple distro ISOs on a single USB stick and then pick one of them to boot from when you boot up. I linked to a tutorial rather than the project page for a quick review.

It could be that OpenSUSE is contributing to your boot issues, and that one of the other distros may have a kernel and configuration that plays more nicely; Ventoy will help you determine this. It’ll also let you play with several distros without having to install all of them, and see if you like one more than another.

If your boot problem is hardware related - either an issue with the hardware itself, or just Linux compatability, then you should stay away from rolling release distros like Arch; while you can configure them to minimize reboots, they’re managed in such a way as to expect people to upgrade frequently, including the kernel, which requires reboots. For example, I run Arch and I love it, but I also tend to not upgrade it very often and the longer between upgrades, the greater the chance of something going wrong during an update. It’s absolutely the least dependency-hellish distro I’ve used if you update frequently, but something like Debian is better if you’re looking for long uptimes.

TL;DR: use Ventoy and try several distros. If you find that your boot problems persist through several distros, ignore rolling-release distros like Arch, Alpine, and Void, and focus on Debian-derived distros like Debian, Ubuntu, or Mint. Or you can try a Redhat derivative, but I hate RPM with the fire of a thousand suns so I’d recommend that last - still, some obviously insane people like it, and it’s an option.