Hacker News Reader

I think the future is probably something more NixOS-like. Now, personally, I've tried it and found it a bit wanting UX-wise (and for really niche stuff), but for providing cutting edge and the ability to roll back safely I don't think it can be beaten. If you have databases, etc. that might need to be rolled back things get more complicated, ofc.

Right now, I'm running Arch Linux with a small smattering of self-compiled stuff. Arch seems to actually be pretty stable, unless you're using their 'testing' repos... and it's very close to bleeding edge. Their secret, I think, is staying as-close-as-possible to upstream -- the trouble usually starts when distros start to add large patches. This has been a huge issue for me with Debian/Ubuntu.

With zfs and boot environments the whole rollback issue is solved. No need for nixos for that.

Definitely for most cases, yes... but 'data' is still an issue (if you care about the data). NixOS has an interesting mechnanism for separating "package" upgrades from "data" upgrades, tho, so that's a slight advantage. (They basically keep around old binaries to be able to run and back up an old database and restore it on a newer version. Straightforward file system snapshots don't really do that.)

EDIT: Sorry, I feel I didn't explain this very well. The main point is: You can have multiple versions of all the software on your system, including stuff like PostgreSQL. That's actually very powerful.

Another potential problem is the licensing and root-on-ZFS.

Personally, I'm really looking forward to an in-upstream-kernel FS like bcachefs. (I'm actually a fan of ZFS, we use it on our servers, etc. I still feel a bit uneasy about the licensing issues and the fact that it's not in-kernel.)

AFAIK, nixos isn't about just rollbacks...Things like ability to declare the state of your system (with all your apps) in a single file and possibility of having two different build of the same program in the system seems very futuristic and productive to me...I mean, this thing frees us from docker/vbox.

I think even the Linux kernel would be a component of NixOS and could be substituted with something else.

The whole idea is just an enterprise-proposal away from getting polished around the edges.

seems like zfs would be a low-level solution and nix would be a high-level solution.

I’ve been using Linuxbrew with Ubuntu (actually Pop!_OS). Linuxbrew is macOS’s Homebrew but for Linux, maintained by the same organization and using the same codebase.

If something needs to be installed system-wide, like dev headers for ncurses or something, I’ll install it through apt. But for nearly everything else (git, Neovim, fzf, tmux, htop, ripgrep, ...) I install it though Linuxbrew.

Linuxbrew formulas are up to date, not ancient. I have yet to run into a problem where a formula only worked on macOS and not Linux. Also for homebrew core packages they publish pre-built bottles so that I don’t have to build everything from source.

It’s pretty great. Pop!_OS is pretty much zero-upkeep, and Linuxbrew has everything I need.

I’ve said it before but the only thing really missing to keep me from using Linux as my main OS with this combo is better desktop mouse sensitivity and keybindings that mimic macOS system-wide (Cmd-C, Cmd-V, ...)

> Their secret, I think, is staying as-close-as-possible to upstream

I've wondered about this. This would depend on upstream being sane about how it does things or puts things.

Is this always the case?

Usually, yes, it appears. Maintainers of projects are generally pretty invested in getting their software into popular distros... and so they tend to follow the patterns that would allow that. (I mean, stuff like 'where do I put the binaries' is still often configured in Arch and other distros, so we're talking about stuff outside of that kind of thing. Most packages aren't complicated enough to require anything outside of simple configure flags.)

I wish there were more standards & conventions here. It seems silly that every package needs to be manually packaged for Debian/red hat/arch/etc, FreeBSD, homebrew, and maybe Cygwin/whatever people use now. That’s a whole lot of work, often for every new version of the program! And all that work could vanish if there was a standard bundler.

I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)

> And all that work could vanish if there was a standard bundler.

The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding.

You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented.

There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization.

What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...

Personally I feel like in many ways OSS got its shit together here over the past decade or so, especially when it comes to default directories and naming conventions etc., so maybe traditional distros might want to reconsider adding so many patches for everything. Its especially bad if it's security patches for unmaintained software, as they are often incomplete, different distros all come up with their own patches whenever someone stumbles upon the bug, because why talk to others and try to prevent duplicate work...

It doesn't have to be one or the other.

I've been very happily using Guix as a package manager inside my Debian, thereby having a Debian with up-to-date versions of packages and access to all the other benefits of using a next-generation package manager (specifying release candidates, docker-like portable builds, plus emacs integration).

Just have to be slightly careful not to install packages via Guix that might cause conflicts, especially with Gnome. But if you do you can always just hop into a tty and `guix package --roll-back` to get back to a working build.

Maybe one day I'll migrate to Guix as a distro in itself rather than just a package manager within a foreign distro (Debian), but for now the setup works well, and it's also a nice way to get experience with Guix before diving into the deep end.

I have done this as well (with Nix rather than Guix, but it doesn't matter). You do run into some friction sometimes, e.g. the UI themes from your main distro not applying properly (because paths are all wrong).

It does basically work, but it can be a bit jarring, depending on exactly what you're trying to do.

After using Ubuntu for over a decade, I switched to Arch Linux.

If you exclude the duplicated architecture packages in the Ubuntu repos and include the community-maintained packages, Arch has more packages new packages seem to commonly available within 24 hours of an upstream release.

For example, I use some utilities based on "rofi". A search for Ubuntu packages containing "rofi-" contains just no results, but a search for Arch packages returns about 50 results.

https://packages.ubuntu.com/search?suite=groovy&section=all&...

https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdat...

AUR packages look easier to maintain than PPAs, so I'm more likely to get get involved with packaging something on Arch then I was on Ubuntu.

> After using Ubuntu for over a decade, I switched to Arch Linux.

Hah! Very similar experience; see my sibling reply :)

Yes. However, Arch Linux means you need to spend time, probably several times per year, to fix stuff that worked yesterday but doesn't work anymore.

Arch Linux is just an entirely different thing compared to Ubuntu. I'd like someone who isn't me to make sure stuff works. Only very rarely will I be bothered to do actual work to upgrade to a new breaking version on my daily driver. Randomly breaking my shit on a Tuesday will make me install something more stable. On the rare occasion that I'd like to try something unstable, I can usually find a PPA or something. I don't like edges that make me bleed on my base OS.

There’s a continuum between something like Arch or Gentoo and CentOS on the other side - the amount of “pain” is roughly similar but when you encounter it changes - it’s usually easy to figure out WHAT broke on Gentoo as it was probably the last thing you installed - whereas a move from CentOS six to seven can be a huge undertaking (even more of you jump straight to 8).

But there definitely is something nice about general stability (until you have to install something on an old OS that requires a new package and you enter a whole new hell).

> Yes. However, Arch Linux means you need to spend time, probably several times per year, to fix stuff that worked yesterday but doesn't work anymore.

Largely a myth and config-dependent. I used to have this issue 10 years ago but now most of my troubles are self-inflicted. Things are as stable as they come when using software from the official repos.

I feel like a fairly competent Linux user and within 2 months had my Arch install broken to a point where I didn't want to invest the time to go down that "why is right click broken along with all these dependencies" rabbit hole. I went back to my mint/debian/Ubuntu safe space.

I installed Arch Linux on a ThinkPad in 2011 and it's literally running the same OS today, nearly 10 years later. I won't say I've never had anything break, but never anything major like audio or video or wifi.

In my experience, Arch is one of the most stable OS's I've seen. But I suspect a lot of it has to do with what you're doing with it. First, ThinkPads are generally well supported in Linux. Also, I've never seen any reason to use GNOME as a desktop. I used to run XFCE on Compiz, then i3 as Compiz stopped being updated. More recently, I've switched to sway, and I've finally started using PulseAudio because it's required for Zoom. Obviously, i3 and sway aren't for everyone. YMMV.

I've been thinking about leaving Fedora and your comment intrigues me. Does Zoom work well with i3? Can you share your screen? Regarding PulseAudio, I didn't realize Linux users had a choice about whether to use it - is there an alternate audio subsystem available?

Alsa and JACK are major forces aside from PulseAudio.

> Does Zoom work well with i3? Can you share your screen?

Yes and yes. Source: I run Zoom with i3.

Do you happen to know if Zoom is available on FreeBSD?

You've already been told about ALSA (which Pulse uses and organizes, for its the low-level audio subsystem the kernel offers) and Jack, which specializes in low-latency audio. There's also sndio ported from OpenBSD.

But the one you might want to consider instead is called PipeWire. It implements the ALSA, Pulse and Jack APIs with a single implementation and it's pretty much the future of audio (and video casting) on Linux.

If you're using Wayland, you're already using PipeWire, but likely not for audio. On Fedora you can follow the instructions here https://fedoraproject.org/wiki/Changes/DefaultPipeWire which basically boil down as "uninstall pulse and install these packages" and you'll be using PipeWire for your audio.

I had tried several times to switch to it and it was not ready, but about a week ago I've been able to make the move with no loss in functionality and even got a fix to an old bug that affected my sound card, so at least with version 0.3.22 I can recommend giving it a go. Switching back to Pulse if bugs arise is trivial anyway.

I never had any problem with Zoom on i3, but I never tried to share my screen.

Zoom on sway works, but since sway runs on top of Wayland and Zoom doesn't have the bindings to communicate with Wayland, I'm fairly positive screen sharing would not work. At least, not out of the box ... it might be possible to connect it to some other screen capture process if you're adventurous.

PulseAudio runs on top of ALSA. Traditionally, Linux desktop applications connect with ALSA and you can still manage ALSA directly. More recent applications, such as Zoom, expect to connect with Pulse and don't support connecting directly to ALSA.

From a user perspective, Pulse offers some advantages like being able to manage audio levels for different applications independently. In early releases, Pulse was unstable and difficult to troubleshoot, so it was easier just to use ALSA directly. Pulse has gotten a lot better in recent versions.

I used to believe that a properly configured Arch Linux setup is super stable, until one day when I upgraded the Linux kernel and there was multiple GPU hangs and graphics glitches. It's fixed upstream now, but it does make me think again about running close to the bleeding edge.

On the same line, I don't realize that my Bluetooth driver was broken until I checked dmesg. This one wasn't fixed upstream yet, but I don't need Bluetooth on my laptop anyway.

Upgrading Arch Linux can be a mess... But Ubuntu is no picnic, either. I've seen plenty of glitches during Ubuntu 20.04 "LTS" upgrades. The most recent is it dropping the network in the middle of the 20.04.2 upgrade. Before that, it lost the default route (there was a bug with multiple interfaces.) There have been others.

If we're going anecdotal, Ubuntu has been nothing but great for me. I have left laptops off for months and then turned them on and update/upgrade them no problem, as well as computers that I use daily. I think the crux of the update issue is really how well package managers handle interdependencies between packages vs how many/what packages you have on your system.

These are servers with multiple Ethernet and bridge interfaces, primarily used for VM hosting. This requires no third party packages and is not anything non-standard or terribly exotic. I often wonder if Ubuntu tests configurations with anything beyond a single NIC.

Debian is more reliable than Ubuntu about upgrades between and within major versions and in configurations that aren't the most typical.

Still consult the release notes before upgrading between major versions in case there are relevant release-specific gotchas before/after/during, and for generally helpful precautionary advice, but quite often there aren't.

I think arch is better for desktop sorts of things. remember:

- desktop users want the latest thing, immediately.

- server users want nothing to change, ever.

As a desktop user, not so much, no.

I want things to work. I don’t want to spend my time arguing with my tools, just for the sake of having the latest and greatest. I might go through and upgrade everything every couple of years, at most.

Beyond that, I just want security upgrades to happen without me having to think about them.

> More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient.

I understand your comment but Hugo is the wrong example, this package is actively maintained and is up to date in Debian unstable.

https://tracker.debian.org/pkg/hugo

Packaging Eclipse is something that _any_ distro will have a hard time with, and for good reasons, given the number of jars involved here.

This might just be evolution. For development, at least for me, the experience was never install a distro and some packages from the distro and start coding. There was always something that would require a bunch of bespoke installations. Libthis or libthat out of date. Files in the wrong place in the distro (or upstream developer's config). Old version of the database server.

Now, I think there's a pretty nice balance going on. Seems like the distros do a good job of getting you to a working GUI and command line, and we've had all kinds of new tools show up for getting to the latest/greatest for development. That said, I think the distros could do a much better job helping devops and admins understand how to use tools like apt and yum. Then there's the whole container thing, which really does give us a more universal way to distribute software (ok, maybe not snaps).

> things seem to have devolved into grabbing things from random github repos

Devolved from what? I believe from software not having any dependencies unless they absolutely must because adding dependencies is such a royal pain. Software written in C and C++ has long been used to the system package manager being language package manager, and the (UNIX) OS being its IDE.

Debian successfully packages a ton of Python software, notorious for its complicated dependency graphs. Has been for decades.

Debian packages a noticeable amount of C-based software which is just old. Emacs, for example. I suppose that skipping major versions (25 to 27) is considered unacceptable, and packaging and maintaining several versions is just proportionally harder.

(This is why my laptop now runs Void, and I get a fresh Firefox next day after the release.)

> Debian successfully packages a ton of Python software, notorious for its complicated dependency graphs. Has been for decades.

But that's what I'm talking about. Suppose there is no software in Debian that uses a Python dependency that you need, hence no one packaged it. Now instead of adding a line to your setup.py (or whatever Python devs use), you have to go through the entire adventure of cooking a Debian package if you want to follow the Debian way. And them submitting it to the main repo which is an adventure and commitment of its own which most people are not ready to make.

Sure, that works to the benefit of everybody, not only your app. And that's the whole point of Debian distribution. Debian developers work on improving Debian. Not on publishing their software. This is the main difference between “app stores” and “package repositories” and “distribution”. Debian is a distribution, and a package repo is only a part of that.

But it kinda saddens me that every language ecosystem has their own package repository, and every distribution ends up having to do effectively busywork of adapting those packages to their distribution and its rules.

> Debian successfully packages a ton of Python software, notorious for its complicated dependency graphs.

I guess this depends on your definition of success, but from my perspective as a Python developer, it doesn't really. Most Python software I'm aware of encourages users to get it by other means (e.g. pip, Anaconda, containers), and anecdotally, the majority of users seem to do so. The occasional people who use apt cause frustration 'upstream' when they report bugs in a version that's 2 years out of date.

One package which I help maintain upstream had a security flaw with a CVE, left open in the Debian package for many months after we fixed it. No-one upstream is a Debian developer, and no-one in Debian was updating the package.

Python started out with a traditional model of applications sharing libraries, and is now moving in the direction of self-contained applications with separate dependencies. Languages like Javascript and Rust went straight for the latter model, so are probably even less amenable to Debian packaging.

IMO, this moved forward with Linux at the OS level 20 years ago with apt and rpm.

Seems like now that hyper scale cloud vendors are displacing distros as gatekeeper, we’re going down a road towards niche packaging for languages, frameworks, etc.

Because for those languages, their runtimes are the platform, the underlying OS is irrelevant, as long as the runtime and associated libraries provide the required abstractions to deliver what is being asked for.

UNIX is C's platform, hence POSIX and its influence on C and C++ based OSes.

A clear example why platform languages always win.

C was born to make UNIX portable, and C++ was born a couple of years later on the same office rooms where UNIX came to life.

Any guest language introduces additional hurdles, debugging tools, binding libraries, editor support, and naturally OS package managers.

Maybe FreeBSD is an option?

Their packages repo has a “latest” which is very up to date. One can also use ports for more control and custom options etc

I have the same problem. While setting up home stuff recently. I was doing everything through ansible on LXC containers and found myself doing a lot of building from source. I still continue to use it but will explore other distros in the future.

Homebrew is meant to be language agnostic.