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

Linux From Scratch ends SysVinit support

lists.linuxfromscratch.org

Post reply on HN
Print view View original

391–400 of 416 posts

Re: Linux From Scratch ends SysVinit support

#391

Post by theamk »

its_magic wrote: post #357
theamk wrote: post #347

Earlier quoted context omitted.

"BSD init", "much simpler"... So does this mean you still expect applications to manage their own logs, daemonization and security setup themselves? If yes, that's yet another init system not made for application writers.

Manage their own logs, daemonization, and security? The humanity! How will they ever manage all of that? Come on man. It's been done for decades. It doesn't take a giant bloated infrastructure to manage most people's needs, which are quite basic in most cases.

.. and that opinion is a great explanation of why systemd won.

Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet.

It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people dismissed the sysvinit early on because it had no features (example [0]), which means the choices were either upstart and systemd. And between two of those, systemd is a clear win.

Read the thread and look at how many highly technical people with no relation to Fedora or Poettering is ready to choose _anything else_ just to get away from "it's been done for decades".

[0] https://lists.debian.org/debian-ctte/2013/12/msg00234.html

Re: Linux From Scratch ends SysVinit support

#392

Post by xerxes901 »

simoncion wrote: post #390
xerxes901 wrote: post #388

Earlier quoted context omitted.

Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations etc is… not a great idea in my opinion. But of course in this particular case, because systemd makes the /dev/log journal/syslog socket a dependency of every unit by default, there is no need to encode this dependency at all. Anyway if you really wanted to you could write this script as a generator and…

Okay, I'll rephrase the question a bit and ask it again. Imagine that you have a service that has a configuration-dependent dependency on rsyslog. For whatever reason, journald's not an option... maybe it's simply not installed, or this service depends on rsyslog-specific behaviors that journald simply doesn't replicate. It doesn't matter why this configuration-dependent dependency exists, it simply exists and there'…

Put a script in /etc/systemd/system-generators/ that does something like

  if grep "logging = syslog" /etc/stupid-service/stupid-service.conf >/dev/null; then
    printf "[Unit]\nAfter=rsyslogd.service\n" > "$1/stupid-service.d/10-syslog-dep.conf";
  fi;
> It's pretty basic and straightforward

Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; it could potentially match a file just because some other option contained a multi-line value that had the string "log_destination = syslog" in it.

The whole philosophy of systemd is to move away from these kinds of "simple" and "mostly working" pile-of-shell-script systems to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.

Re: Linux From Scratch ends SysVinit support

#393

Post by simoncion »

xerxes901 wrote: post #392
simoncion wrote: post #390

Earlier quoted context omitted.

Okay, I'll rephrase the question a bit and ask it again. Imagine that you have a service that has a configuration-dependent dependency on rsyslog. For whatever reason, journald's not an option... maybe it's simply not installed, or this service depends on rsyslog-specific behaviors that journald simply doesn't replicate. It doesn't matter why this configuration-dependent dependency exists, it simply exists and there'…

Put a script in /etc/systemd/system-generators/ that does something like if grep "logging = syslog" /etc/stupid-service/stupid-service.conf >/dev/null; then printf "[Unit]\nAfter=rsyslogd.service\n" > "$1/stupid-service.d/10-syslog-dep.conf"; fi; > It's pretty basic and straightforward Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; it could potentially match a file just b…

> Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; ...

Where's that documented?

I tried the obvious things followed by a config reload. Here are the results (the 'log_destination' parameter is on line 482 of the config file):

  log_destination = \
   'stderr'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "\"
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'stderr'"
  LOG:  configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
  

  log_destination = 'std
  err'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
  LOG:  configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied

  log_destination = 'std\
  err'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
  LOG:  syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
  LOG:  configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied

  log_destination = 'stderr'
  
  LOG:  received SIGHUP, reloading configuration files
  
  
  #log_destination = 'stderr'
  
  LOG:  received SIGHUP, reloading configuration files
  LOG:  parameter "log_destination" removed from configuration file, reset to default
What's the line continuation character for 'postgresql.conf'? Are you certain that you're not getting 'postgresql.conf' confused with 'pg_hba.conf'? That file is documented to support line continuations: [0]

  The general format of the pg_hba.conf file is a set of records, one per line. Blank lines are ignored, as is any text after the # comment character. A record can be continued onto the next line by ending the line with a backslash. (Backslashes are not special except at the end of a line.)
> The whole philosophy of systemd is to move ... to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.

That's truly a lovely and laudable goal. In this system, how does you propose one processes a flat text config file with a mix of 'K = V' and 'K V' settings without doing ordinary, boring text processing? Do you propose that one waits until "systemd-configd" gets created and every daemon of any importance is updated to put its config in there instead of in flat files? If so, has there been any notable progress on this in the last ~fifteen years?

> Put a script in /etc/systemd/system-generators/...

Thanks for finally answering my question. Is the way to conditionally update service dependencies really to dump text files in magic locations? Is there no 'systemctl' (or similar) command that allows one to manipulate dependencies for a specific service that one can call from a generator?

[0] https://www.postgresql.org/docs/17/auth-pg-hba-conf.html>

Re: Linux From Scratch ends SysVinit support

#394

Post by tapoxi »

lelanthran wrote: post #349
tapoxi wrote: post #24

Earlier quoted context omitted.

I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)

> but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg) It's been 17 years and Wayland has yet to reach feature parity with X11/Xorg. There is doubt that it ever will. Regardless of what you think the Unix "philosophy" is, actual features matter.

But Wayland is a protocol suite, you're comparing it against Xorg, an implementation that shipped 16 years after X was created.

Re: Linux From Scratch ends SysVinit support

#395

Post by jcotton42 »

JCattheATM wrote: post #301
tuetuopay wrote: post #207

Earlier quoted context omitted.

Pedantic but systemd is inspired by MacOS launchd, not by Windows services. It has nothing akin to the registry, which even microsoft admits is a pain on windows. Oh, and usually people shit on windows for many reasons, but some of the very core features of the OS are robust and the Linux crowd could take a hint. Like, you know, the notion of service at the OS-level and not some random bash script that nohup'd a bina…

I didn't say it was inspired by the registry, I just drew a comparison. In both cases you have a huge binary thing that you have to interact with through secondhand tools rather than directly.

systend units are plain text.

Re: Linux From Scratch ends SysVinit support

#396

Post by donkeybeer »

its_magic wrote: post #382
donkeybeer wrote: post #380

Earlier quoted context omitted.

>...or they just decide to develop their own version from scratch instead, keep it closed source from day one, and you get nothing at all. Happens all the time. You again seem very confused. Its exactly the same as they closing up a bsd fork. So how is the outcome or incentive any different? With bsd they can do that without any effort, with gpl at least they have the friction and may deem it too much of a friction.…

You seem to be unaware of the basic fact that government--laws and legal systems--is men with guns . "Government is not reason, it is not eloquence, it is force! Like fire, it is a dangerous servant and a fearful master." - George Washington It's difficult to have a conversation with someone so profoundly ignorant of reality. Do some research and stop wasting our time with your angry rantings.

I had a feeling you'd be too fucking stupid to be able to respond to any of the points and duly vanish just as I expected from your sackless kind.

Re: Linux From Scratch ends SysVinit support

#397

Post by its_magic »

theamk wrote: post #391
its_magic wrote: post #357

Earlier quoted context omitted.

Manage their own logs, daemonization, and security? The humanity! How will they ever manage all of that? Come on man. It's been done for decades. It doesn't take a giant bloated infrastructure to manage most people's needs, which are quite basic in most cases.

.. and that opinion is a great explanation of why systemd won. Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet. It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people…

> .. and that opinion is a great explanation of why systemd won.

Completely wrong and ignorant.

> Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better.

And then they got systemd. LOL

Like Dr. Phil said, "How's that workin out for ya?" LOL

> And so when something new came up, they jumped on it with both feet.

You just did what your type always does: whatever you're told.

> It's instructive to read Debian CTTE discussion on init systems

No, it really isn't. lol

> the choices were either upstart and systemd. And between two of those, systemd is a clear win.

Well, it's too bad none of the other good options were considered, isn't it? When your only "options" are a giant douche or a turd sandwich, the outcome can't possibly be good.

See U.S. presidential elections for one of the best examples of this dynamic. Two complete fucking losers are presented every time, and 40% of the population are mesmerized by the spectacle and think there can be no other possible options at all. That's you.

The fact is, many of you noobs don't even know how to write a shell script, yet somehow feel qualified to comment on this subject, as if your opinion is worth anything at all.

How many daemons have you personally written? Hmm? Do you even know how to write any C at all? Daemonizing a process isn't rocket science. It's a double fork. So simple even you could do it, I bet.

The problem is you're too technically ignorant to understand that none of your "technical" arguments hold any water at all. It's just you repeating the bullshit you were told, as usual.

Every Big Lie being told relies on Useful Idiots like you to help support it.

Logging is not difficult. Double forking is not difficult. If you find any of that to be a challenge, you're not qualified to write a daemon. If you can't successfully set up and run something like runit or any of the many other good sysvinit alternatives, you're not qualified to administer a Linux system. Period.

You make all these appeals to authority ("highly technical people" saying this or that) like that means something. You forget that you're speaking to the guy who built his own operating system. I don't need any guidance from "highly technical people" on what init system to pick. Apparently you're the type who does.

That's what your entire argument basically boils down to--one giant appeal to authority.

If everyone else was jumping off a bridge, would you do it too? Of course you would, without a moment's hesitation. Because you're a God damned lemming.

Now get off my lawn.

Re: Linux From Scratch ends SysVinit support

#398

Post by raggi »

adastra22 wrote: post #98
ktm5j wrote: post #75

Earlier quoted context omitted.

Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now. To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.

The whole point of LFS is to understand how the thing works.

nothing is actually stopping people from understanding systemd-init except a constant poorly justified flame war. it's better documented than pretty much everything that came before it.

Re: Linux From Scratch ends SysVinit support

#399

Post by rfmoz »

ahartmetz wrote: post #251
pjmlp wrote: post #177

Earlier quoted context omitted.

I love how people worship UNIX design in Linux circles, especially when complaining about decisions where Linux is catching up with commercial UNIXes, as in the init systems replacements. UNIX design was so great that its authors did two other operating systems trying to make UNIX done right. One of the few times I agree with Rob Pike, > We really are using a 1970s era operating system well past its sell-by date. We…

I think the main problem of Unix today is that it's not Unix-style enough . Too many namespaces with too many non-composable separate APIs on them instead of "everything is a file". Plan9 is more Unix than Unix and that's indeed better. Redox OS, too. The Unix security model is mostly useless today, but it seems like something better is possible as an incremental change, and there are projects that do that, like RSBA…

Yes, "everything is a file" but the mouse on Rio is written in stone.

Aside of that, plan9 wins on the theoretical side, it was a research OS, but in the practical one... it's opinionated.

Re: Linux From Scratch ends SysVinit support

#400

Post by fragmede »

bryanlarsen wrote: post #117
fragmede wrote: post #88

Earlier quoted context omitted.

It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?

Nobody complains about a very wide variety of only vaguely related utilities being in the Gnu coreutils tree.

Because they're not all called coreutils. They've got names like sed, awk, and grep, not systemd-named, systemd-analyze, systemd-networkd, systemd-resolved, systemd-timesyncd. I guess that's a good thing though?
Post reply on HN