Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What Next After Ubuntu?

news.ycombinator.com

Post reply on HN
Print view View original

321–330 of 345 posts

Re: Ask HN: What Next After Ubuntu?

#321

Post by warrenm »

GoblinSlayer wrote: post #310
ThenAsNow wrote: post #296

Earlier quoted context omitted.

I want to like systemd, especially since it is the default and has all the mindshare in Linux. I'm also not particularly in love with the historic shell scripts approach, as some are. Some systemd elements, such as its journal, are convenient. My issues with it are: - If you setup an atypical configuration, particularly involving luks volumes, it is not hard to break systemd and dracut's assumptions, and then you wil…

I wonder if surface area of bash is even quantifiable, I never managed to read its man page to the end.

it's only 3400 lines!

:P

Re: Ask HN: What Next After Ubuntu?

#323

Post by warrenm »

loxias wrote: post #153
bleuuuu wrote: post #121

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…

I have to think ... you don't actually know what you're talking about

I fought against systemd for a while, too

I was wrong

The "if it ain't broke, why fix it" approach with 'classic' init scripts led to a far far messier place than systemd

My only complaint about systemd is that I haven't found a way to push the journal to text simply ...and that's most likely my poor google-fu or not having enough to time to fully dive into it, rather than "systemd's journal sucks"

Systemd does use "text files or symlinks for configuration"

It's very well designed - though you may happen to have a preference for a different architecture (...but the one you described is pretty much systemd, my friend :))

Re: Ask HN: What Next After Ubuntu?

#326

Post by kaba0 »

loxias wrote: post #153
bleuuuu wrote: post #121

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…

Did you consider in your opinion that booting and service management is an insanely hard problem?

Would you write an optimizing compiler in multiple small tools as well? Essential complexity can’t be reduced, IPC will blow up your accidental complexity budget. Many times a monolith is indeed the best design choice.

Re: Ask HN: What Next After Ubuntu?

#327

Post by 2devnull »

2 options: 1) gentoo 2) FreeBSD

Which of those you choose depends on your needs. I’d try FreeBSD first, and if you find it lacking then I’d go for gentoo. BSD seems like a well kept secret, but it won’t work for everyone. They do have stellar docs and a friendly community, buts it’s not ubuntu.

Re: Ask HN: What Next After Ubuntu?

#328

Post by bayindirh »

UK-AL wrote: post #314
asdfkjhasdfhuh wrote: post #277

Earlier quoted context omitted.

systemd is "easier" for people used to cisco/microsoft/etc. The huge list of services with not-for-human names so your job can look complicated and essential.

Eh? systemd unit files are tiny compared to the huge massive scripts that came before it. Often those scripts we're only understood by a few people as well. I think this why a lot of people really hate systemd. Suddenly a bunch of arcane knowledge used to maintain specific scripts got made redundant.

I have a thousand gripes about systemd, but “it made my knowledge obsolete” doesn’t make that list.

Also, I have only seen two or so massive scripts about services. Most of them were slight variations of a standard boilerplate code.

Re: Ask HN: What Next After Ubuntu?

#329

Post by kaba0 »

8jy89hui wrote: post #166
gaganyaan wrote: post #137

I'm liking NixOS thus far. I've got it installed on my personal laptop. It's got some rough edges, but the benefits for me outweigh the downsides. I really like affordances like "nix-shell -p foo" to just run a shell with the "foo" command in it for one-off usages, instead of slowly accumulating installed apt packages that I forgot why I installed them. Similarly, having any custom configuration inside of "configurat…

> It's got some rough edges I've recently been looking really hard at NixOS as a possible next-step. (I use Manjaro and am particularly interested in ways to keep my Laptop and Desktop in sync) I've heard that the documentation can be pretty lackluster at times. Are there any other rough edges I should know about?

For development, not all languages have the same “support”, tooling. This is sometimes inherent in the given language’s dependency management or popularity.

Re: Ask HN: What Next After Ubuntu?

#330

Post by amluto »

yjftsjthsd-h wrote: post #262
amluto wrote: post #205

Earlier quoted context omitted.

In my copious free time, I have a vague idea of designing and implementing a mechanism called kpid1. 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 in…

What benefit are you seeing in putting it in the kernel?

Several:

Zombie reaping could have a reasonable API. (Signals are miserable.)

PID 1 is magic in problematic ways. In particular, if PID 1 crashes, the whole system goes down with it. And having PID 1 be a normal program running from a normal ELF file means that that ELF file is pinned for the life of the system or at least until it execs something else. So handoff from initramfs to a real fs either involves PID 1 calling execve() or involves leaving the init process around. Upgrading the package containing PID 1 requires execve(). Running PID 1 from a network filesystem or an unreliable device risks a kernel panic for no good reason.

With PID 1 moved to the kernel, the actual service management job is no longer coupled to PID 1’s legacy. A service manager could hand off to another one by saving its state to disk and exiting, by running the new one and moving its state after the new one starts, or by any other ordinary means. And if it crashes, you can ssh in, read logs, save work, and then restart it or the whole system as appropriate.

As a minor additional benefit, having PID 1 in the kernel could enable some optimizations. Right now, a process must enter the zombie state when it exits, and it must stay in that state until its parent wakes up and reaps it. So a service exiting fundamentally involves some complex bookkeeping and a context switch to a single, unrelated process. If the kernel knew that kpid1 was in use and that nothing in the system actually needs to be notified of exiting children of pid 1, then a child of pid 1 that exits could simply go away, as it would on a sensible system like Windows.

(Yes, it's okay to admit that, in some respects, Windows is substantially better than Linux/Unix.)

Post reply on HN