201–210 of 345 posts
I live in a region with a lot of government contracting businesses, so Red Hat Enterprise Linux is something I have to maintain a working familiarity with. However, I use Debian for all of my personal projects and infrastructure. The reason? There's no for-profit corporate interest directly controlling the project. The project's organizational structure resembles a constitutional democracy: https://www.debian.org/int…
I've been running Debian stable on servers for like 8 years now. Up until recently I had a server running Debian Jessie with 1,802 days of uptime. It served a decent amount of traffic. Services on there ran unattended for literally years and it was rock solid. I ended up decommissioning the server because for the same price I could get better hardware specs so I made a new server and put on Debian Bullseye (the lates…
What do you do for kernel updates?
Earlier quoted context omitted.
why the aversion to systemd?
I don't like the design at a fundamental level. It feels brittle, bloated, and not very unixy. I'd rather have my init system be a handful of microscopic executables, using text files or symlinks for configuration and text files for logging. I don't like everything depending on systemd it feels like too much complexity at the wrong part of the stack. It doesn't jive with my sense of architecture, it's not well design…
> text files for logging
...just sucks, on both embedded systems and production servers. (I.e. anywhere where you aren't debugging the machine on the machine, but rather from another machine.)
Either the program just writes to a plain text file forever — and so fills up your disk the first time it goes haywire (so now you have two critical runtime problems!); or it implements its own log rotation and compression (as must every other daemon — not very unixy!); or it must be specifically wired to work with syslog APIs in order to use rsyslog (which, by the way, uses binary wire protocols as well; logging at scale hasn't been text-based in a long time.)
Journald, meanwhile, just sits on the other side of the pipe from any systemd service-unit's stdout + stderr; manages log rotation + compression in a centralized way (which also means you get cross-unit log compression for free); and offers CLI tooling to pipe the multiplexed log stream back into anything that wants to read from it, in whatever format those things want to read from it (i.e. tools that want JSON Lines, get JSON Lines; tools that want plaintext, get plaintext; tools that want a binary record stream, get a binary record stream.)
Is this a Unixy approach? Well, it's pretty much the same one taken by the extremely venerable Unix/Linux line-printer (lp) subsystem — CLI commands, with textual config files, for interacting with a system daemon (lpd) that manages and manipulates binary state files, within daemon-owned directories. Would you complain that the contents of /var/spool/lpd aren't human-readable?
Earlier quoted context omitted.
I've used exclusively Debian on all my servers and laptops for the last 20ish years. Can confirm, it will continue to keep working, however there might be some things that piss one off in a similar manner as Ubuntu's snaps. I hate systemd for example, but grudgingly accept it.
why the aversion to systemd?
For myself, eh. I find it a little annoying but basically tolerable, sort of like a reinvention of SMF from solaris. Linux system config / init has gotten a hell of a lot more complex since I first touched it in the mid-90s, sometimes we get more functionality for that and other times the grognard in me wants to bin it all and retreat to Slackware or something. What was the old joke, Microsoft admins have solitare.exe and Linux admins have "fiddling with text files"? :)
Earlier quoted context omitted.
I don't like the design at a fundamental level. It feels brittle, bloated, and not very unixy. I'd rather have my init system be a handful of microscopic executables, using text files or symlinks for configuration and text files for logging. I don't like everything depending on systemd it feels like too much complexity at the wrong part of the stack. It doesn't jive with my sense of architecture, it's not well design…
Do you think we'll get lucky with a systemd replacement similar to how pulseaudio has been deprecated by a much more reasonable implementation Pipewire?
Basically, a task running as pid 1 (including in a container) could call a new kpid1() syscall, which would cause the kernel to completely take it over. The kernel would take care of all the usual init work, and it would expose the minimal API (presumably using a new kind of fd) to allow a different task to give it instructions and manage zombies as needed. And that’s it.
It’s worth noting that the entire concept of pid 1 is very unixy, but not in a good way. Reasonable modern designs (e.g. all the Windows variants) don’t have any real equivalent.
Red Hat for enterprise use, Fedora for personal desktop use. One of the largest communities you’ll find. If you want Debian based maybe just straight Debian. The centos debacle was poorly handled but I think what red hat was /trying/ to do made sense. The community just wasn’t there to sustain it. Red Hat was paying to give away free RHEL basically lol. CentOS Stream should have just been called RHEL Stream. It’s bas…
I just moved over from Ubuntu to Fedora as I felt I was starting to lose my edge: apt is so easy you forget that the other half of the universe thinks in dnf and I need to keep my skills sharp. Its been a good decision. A bad decision was to use a Fedora mix with KDE. It works very well, but I think its rough edges would simply not be there if I'd chosen the GNOME path. You get the sense that the RH team default to G…
Earlier quoted context omitted.
Isn’t one of the purposes of snaps to allow finer grained permissions? In non-snap systems, how do you prevent that weather app you just installed from accessing your camera and microphone?
It runs as a user without the necessary permissions to access those devices?
I happen to dislike snaps as well. The hard coded install directory is a passion point for me. But at least the permissions issue they are getting right.
I wish that desktop distros would adopt the Android permissions paradigm.
I'm running 20.04, and this is news to me. What is the nature of the breakage?