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

Shall we fork Debian?

debianfork.org

Post reply on HN
Print view View original

261–270 of 284 posts

Re: Shall we fork Debian?

#261

Post by rakoo »

simoncion wrote: post #242
rakoo wrote: post #157

Earlier quoted context omitted.

Config test is a human operation; you manually do it after you've edited the configuration, and if you've forgotten to do it then the next start will crash. It makes no sense to automate configtest.

> It makes no sense to automate configtest. Sure it does! It's a belt-and-suspenders approach that ensures that human error won't cause your system services to become unavailable. Why use a computer unless it automates tedious tasks for you and remembers to do things that you might forget? The Gentoo OpenRC BIND 9 init script runs named-checkconf every time you try to start or stop the BIND service or reload its conf…

There's a part of me that believes that on startup, a service must check the config and bail out immediately if it's invalid.

If it doesn't do this automatically, there's still the option of adding the configtest in the ExecStartPre option.

Re: Shall we fork Debian?

#262

Post by csirac2 »

cbsmith wrote: post #258
csirac2 wrote: post #95

Earlier quoted context omitted.

During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?

You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time. You mentioned smart cards... what system would handle when you connect a smart card after boot?

The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup.

By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If there's a LUKS keyslot with a backup passphrase which can be entered by a human operator at the tty, this also serves as a disaster-recovery mechanism so that you can afford to lose the LUKS keyslot associated with the token/smart card.

Re: Shall we fork Debian?

#263

Post by gdamjan1 »

csirac2 wrote: post #255
kolme wrote: post #225

Earlier quoted context omitted.

One of the things that boggles my mind is the "single responsibility principle violation" that they're calling. What? Systemd will only handle the starting and stopping of services. How's that doing more than one thing? This seems to me a technically better solution.

Doesn't it do logging? And cron? And login/console? And configure network interfaces? And a bunch of other stuff... ... systemv sucks enough that I'm in the middle of re-working our firmware at work to use systemd instead (I do like socket activation and supervisor stuff), but of all the systemd features one could like, "do one thing and do it well" isn't one of them.

only the journal is a required additional feature of systemd, and you can set it up to not store anything and just forward to your syslog/rsyslog/...

you don't need to use systemd-networkd, it's a separate program - but it's better than debians /etc/network/intefaces adn RH /etc/sysconfig/network-scripts/if* - so I do welcome the consolidation it'll bring to distros.

you can still run normal cron you don't need to run the kms console daemon either

Re: Shall we fork Debian?

#264

Post by zyx321 »

mverwijs wrote: post #83
pantalaimon wrote: post #56

Earlier quoted context omitted.

Have you ever used it?

I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.

That was 2 years ago, have you given it another try since?

Re: Shall we fork Debian?

#265

Post by adekok »

XorNot wrote: post #174
adekok wrote: post #155

Earlier quoted context omitted.

> I'd really welcome the anti-systemd ranters to just do some work that makes them feel happy, such as making a new distribution that has the exact init system they want. Most people are already working on things that make them happy. The frustration here is that the tools they depend on are changing... in a way that they don't like. They also have limited time for projects. Any time spent fixing other peoples projec…

You know, provided Apple continue to agree with you...it seems more like you're just zenning over the fact that even if you did disagree, you couldn't change anything. Choice is widely regarded as actually making people more unhappy. EDIT: It's also an ironic comment, since a frequent criticism of systemd is that it's trying to be too much like Apple's launchd.

I'm not "zenning over" anything. I need a computer to get work done. I don't need to be mucking with the computer to keep it working.

My choice is to use a (mostly) closed system, because it meets my needs.

Other people don't like systemd because they feel it removes their choices.

There is no contradiction in the two approaches. There's also no irony.

If Unix had started out with something like systemd, fewer people would be complaining about it now. It's the change that people don't like. And the apparent removal of choice.

Re: Shall we fork Debian?

#266

Post by takeda »

mcosta wrote: post #227
takeda wrote: post #223

Earlier quoted context omitted.

And this is FreeBSD's rcNG which combines the best from both worlds: http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/inetd?re...

Nad this is for the power profile: http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/power_pr... so what? Also: Usage: $0 [0x00|0x01]. That is the real unix way these people is proposing.

This is a straw man argument.

The idea is that rcNG makes things simple, but it doesn't stand on your way if you want something more complex or in this case you want to make it harder to use than it needs to be.

Re: Shall we fork Debian?

#267

Post by jude- »

XorNot wrote: post #162
pmontra wrote: post #72

I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default. From my experience what I need on…

Your log files are binary already. What do you think 'cat' is, other then a binary log reader? Binary log files are as easy to read as ASCII with the right translator. Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII. The problem is, people think they'll be able to understand corrupt ASCII logs, but in reality basically never deal with them. They deal with trunca…

> Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII.

The advantage of human-readable logs is that the semantics and rules of the language it's written in serve as a built-in forward error-correction measure. It's easy to see that the string "the qu()&!`8zwn fox jumps over the la" is a corruption and truncation of "the quick brown fox jumps over the lazy old dog", especially if you're already used to seeing the original string under normal operation. By comparison, it's much harder to tell whether or not an arbitrary byte string is corrupt, and journald does not make use of any forward error-correction measures to assist in this.

> Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd.

If I'm using journald in this configuration, then why does journald need to exist at all? It's literally dead weight, and adds another point of failure to my logging facility.

> EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.

When compressed log corruption recovery is a concern, tools like parchive [1] are used instead of gzip/zcat.

[1] https://en.wikipedia.org/wiki/Parchive

Re: Shall we fork Debian?

#268

Post by jude- »

the_mitsuhiko wrote: post #54
mappu wrote: post #34

>SystemD betrays the UNIX Philosophy Not so convinced by this. "Those days are dead and gone and the eulogy was delivered by Perl." -- Rob Pike Systemd in debian would have an easier time making friends if it didn't usurp PID1 for roles that are currently outside PID1, and if it didn't encourage software which is currently init-system agnostic to grow a dependency on a specific init-system implementation.

> Systemd in debian would have an easier time making friends if it didn't usurp PID1 for roles that are currently outside PID1 Like what exactly? This is a non issue. systemd has very little actually running in PID1.

All of systemd's other components require systemd-PID-1. So yes, systemd does usurp PID 1.

Re: Shall we fork Debian?

#269

Post by spb »

Zancarius wrote: post #193
m45t3r wrote: post #138

Earlier quoted context omitted.

Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork". Actually, I find it's funny how anti-systemd people nowadays claim that "systemd is a init for desktop systems" since Gnome adopt something unrelated to the _init_ part…

> Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork". Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some pa…

> Yet the oddly amusing part is how systemd isn't difficult to learn. The only valid complaint against systemd IMO is its departure from Unix philosophy, but for some parts of the \*nix ecosystem, I can't help but think that boat sailed long ago.

This is what I say when people complain that systemd "isn't Unix". Neither are package managers, but I don't see anybody saying we should revert to passing around tarballs that unpack onto root (other than Patrick Volkerding).

> [...] the easiest way to use the distribution isn't to fret over change but to embrace it. Otherwise you'll be implementing fragile workarounds that break every time you update.

I'm thinking about putting together a talk about exactly this, tentatively titled "MacGyver-Driven Development". It's my response to people who respond to any criticism with "Yeah, but then you can just put some tools on top of it": relying on tools only adds another dependency that makes your system more fragile and resistant to change.

The proper way to develop is to keep what you do as small and environment-agnostic as possible. That way, when tides do change, you don't have to fight them or work hard to embrace them; you can just go with the flow, and just change the few parts that touched the changing dependency.

Re: Shall we fork Debian?

#270

Post by spb »

ancarda wrote: post #117

Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.

> Am I the only person who prefers systemd?

No: http://en.wikipedia.org/wiki/Silent_majority

Post reply on HN