Users/Developers Threatening Fork Of Debian GNU/Linux

[Luke_Wolf]

Your entire reply was literally perfect and I thank you for that.

I just don't get this argument of "UNIX Philosophy". I mean, I get it on a very, very simple level. But there are many easy arguments against it. For example, UNIX wasn't developed at a time when computer hardware was nearly as advanced as it is today. Back in the day I don't think there was even a fraction of the dependency on binary blobs and the like to make graphics and wireless cards work. Would the fathers of UNIX hate that we absolutely require this today? Probably. But that doesn't mean that's a bad thing.

I just think it's important to note that if people are so anti-systemd, they don't have to use it. Pissed off at Debian for adopting it? Cool -- don't use Debian anymore. Or with 0 manpower fork a project of over 10,000 packages and expect it to parallel main line Debian.

Perhaps my definition of being realistic and pragmatic is different than systemd's opposition but it really comes down to a bunch of people getting bent out of shape over something that they don't have to use. Linux isn't Windows or Apple where you're stuck with what the vendor decides. The great thing about Open Source is choice and I think most who are against systemd are completely missing that point.

At the risk of a No True Scottsman... the real problem with the "UNIX Philosophy" is no true programmer blabs on about it. The same principles expressed by the UNIX philosophy have been modernized (and the plaintext requirement dropped altogether) and are used today under very different terms by programmers.

For example instead of "Do one thing and do it well" we talk about separation of concerns, modularity, and code reuse, and instead of a collection of separate processes we decompose programs into systems which allows parts of the system to be taken out and reused in other systems (and hence we talk about tight vs loose coupling).

as far as text vs binary, text is good for most things but whenever you care about security or speed binary is preferred. Logs care about security and having it in text let's an attacker modify them with ease, sure they could just delete the log but that'll be a clue in and of itself.

The problem is that a bunch of users and sysadmins have latched onto this development methodology which they are then misapplying against any software that they don't like regardless of whether or not it's actually following it.

[gens]

At the risk of a No True Scottsman... the real problem with the "UNIX Philosophy" is no true programmer blabs on about it. The same principles expressed by the UNIX philosophy have been modernized (and the plaintext requirement dropped altogether) and are used today under very different terms by programmers.

For example instead of "Do one thing and do it well" we talk about separation of concerns, modularity, and code reuse, and instead of a collection of separate processes we decompose programs into systems which allows parts of the system to be taken out and reused in other systems (and hence we talk about tight vs loose coupling).

as far as text vs binary, text is good for most things but whenever you care about security or speed binary is preferred. Logs care about security and having it in text let's an attacker modify them with ease, sure they could just delete the log but that'll be a clue in and of itself.

The problem is that a bunch of users and sysadmins have latched onto this development methodology which they are then misapplying against any software that they don't like regardless of whether or not it's actually following it.

yes, the "Do one thing and do it well" is just a general guideline for making a "good" big system out of smaller parts


but i have to disagree on a binary format being more secure
it's easy to change anything in any format that you know the specification of (even ELF/x86), if you have write access to the file ofc

unless the file is encrypted
but in that case a corruption of just one byte would render the whole file undecriptable

[V10lator]

Now of course I shouldn't have compiled my own kernel but I f*cking did, because RHEL has an absolutely outdated kernel which doesn't include many fixes from upstream, and new hardware is not properly supported.

Right man, use a enterprise distibution in a none-enterprise environment, try to tune it to your needs while not knowing what you're really doing and as a result break the kernel. Wait, no, it can't be your fault, it must be systemds cause you're a poweruser (what is a poweruser btw? Is it a user on drugs or something like that?).

don't tell me it has f*ck to do with Fedora. I had it on RHEL 7.

Uhm... But... It really has to do with Fedora: The bug you linked is for Fedora 20, RHEL 7 is forked from Fedora 19, so how can you expect a backport before a fix?
Not to mention that there was a fix available around 2 hours after the bug has been reported but let me guess: A poweruser isn't able to use a patch (or to wait around 10 days which was the timeframe Fedore needed to release the fix officialy).

I have also incorrectly compiled kernels before that failed to boot due to missing features, even when using SysVinit no less.

Me too. But wait, that was before systemd existed! So it must have been SysVinits fault! Good we have systemd now!

Disabling SWAP support in the kernel is not incorrect in any way.

You used a enterprise distro, so go ask the guys from Red-Hat if it's supported to compile swap support off the kernel, then come back and tell again it wasn't incorrect.

In fact most sane people disable SWAP because SWAP is rarely if ever helpful, but it's more than often harmful.

But you know that SWAP is a hard requirement for hibernation? Sure only insane people want hibernation... Also go monitor your RAM, you'll see that it's (almost) 100% filled (well, maybe you just bootet cause of no hibernation so you won't see it right now, just wait a bit) ... that's cause of the I/O cache. Linux needs SWAP to do some I/O magic (keep these caches when needed instead of drop them cause of no more RAM) but I guess fast I/O isn't important for sane people, too.

In fact SWAP must be disabled in many situations because bug 12309 (closed != fixed, I observe this bug on many Android phones) is still unresolved and SWAP makes it 1000 worse.

#12309 is because of said I/O magic and has been fixed 4 years ago! But surely you're using mechanical harddrives in combination with a 4 years old kernel and systemd on your android phones... and that's systemds fault. Comeon, talking to you stops being funny here.

[gens]

well, once you get used to it and learn/apply the advanced features you will see sysadmins crying of happiness, just the DDOS protections and the advanced security is enough to drop anything else and never look back. <-- have a bit of a learning curve(or de learning curve).

if you are a developer once you discover the API side of systemd and realise how many hacks and white hairs you will save yourself you will run naked crying in the highway and start hugging and kissing people(is that much better).

interesting
i never cried configuring anything on my system, for some... 9-10 years now
from bash through vsftpd, apache, irssi to the X server, all more or less sane
(openbox-es XML config was one of the worst, because its XML and i don't want/know how to use an XML editor)
alsa is one of the more confusing ones
it's more of a programming language then a config
but even alsa makes sense

then i read the .service spec
it's horrible if you ask me
ExecReload stuck to mind, just the name makes no sense considering what it does
and why does everything have to have Caps ?
why are there a "[Unit]" and "[Install]" sections ?
why are there sections at all if all declaration names are unique ?
(if they are unique, i didn't check)
if a .service is "A unit configuration file" why is there also a .unit file that the documentation says it is "A unit configuration file" ?

and what if i want to do something advanced, like a beowolf cluster without hard drives on nodes... i have no f-in idea how to do it
if that is even possible

i fkin made a self modifying program and it was more straightforward to do then this


then again i'm no professional admin and i didn't put much time beyond writing a basic .service file
i did however ask a professional admin that tried it and he said something like "that is not going on my servers"
reading around the net there seems to be more admins that don't quite like that way of doing things
although to be fair most sysadmins probably wont care as long as it runs a program as it's supposed to


i still say a sysadmin should know how to write a shell script...

[gens]

...

bdw
systemd protecting from DDoS ?
advanced security ?
you do know it uses dbus as it's IPC and that it is easy to flood
not to mention the whole namespace thing

[haplo602]

1,2,3 unixes had binary gzipped logs for eternity and somehow nobody cared
4. please name one unix which proved indexed databases in text files
0. JOURNALD CAN EXPORT TO SYSLOG FFS

compressing text logs and writing in binary format are two different things. if you can't understand the difficulties and differencies then there's no need for a discussion (and since you listed it as a counter argument, it seems you do not understand).

and why is the indexed text db so important ? if I want that, I can import to suitable database via an import interface/conversion script/daemon ...

export to syslog is nice, but somebody earlier mentioned that the existence of journald is justified by it logging the boot process before syslog is running, how do you export to syslog if none is running ?

You only need logs when something goes wrong (most common case). And if something goes wrong in the stage where journald has its reason for existence (very early boot) you usually cannot boot up the system. This in turn means, anything special needed to read the log files SLOWs you down or prohibits any reasonable troubleshooting (you have to have a system where you can read journald files). grep/cat/sed/awk are standard utilities available everywhere so you can boot up the failing system from rescue media, mount the filesystems and go hunting for the issue. in case of a binary log, you are screwed unless you have the correct utility to read it.

[CanalGuada]

then i read the .service spec
it's horrible if you ask me
ExecReload stuck to mind, just the name makes no sense considering what it does
and why does everything have to have Caps ?
why are there a "[Unit]" and "[Install]" sections ?
why are there sections at all if all declaration names are unique ?
(if they are unique, i didn't check)
if a .service is "A unit configuration file" why is there also a .unit file that the documentation says it is "A unit configuration file" ?

[root@laptop ~]# find {/usr,/etc} -name *.unit
[root@laptop ~]#

There is neither .unit file on my laptop gracefully booted with systemd, nor mention of such a file in that man page.

A unit configuration file whose name ends in .service encodes information about a process controlled and supervised by systemd.
This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files.

Not my native language but here I clearly understand that there are many types of unit configuration files and that this systemd.unit(5) link redirects to a parent man page, that explains what that files are, this one being specific for .service units.

Before going further in implementation details, everybody is prompted to read systemd.unit(5). Because that helps..

Regarding sections, unit file format follows more or less a well known specification in order to be parsed, or read by humans, whether there are (at this moment) common option names (some are shared between different types of unit files) or not.
Moreover, unit configuration files can also be modified or extended under /etc/systemd/system/[email protected]/ directory with one (or many) but .conf files : using sections also improves readability here.
No need to mention that unit configuration file format is yet a mandatory stable interface for compatibility, but that reading options per section could in the future quickly turn to be a requirement in order to easily implement extensions that may happen.

What benefit do we draw not to use them right now?

In XDG Desktop Entry specification, the one which inspired unit file format, the Exec key contains a command line with executable program and arguments. Using Exec prefix for StartPre/Start/StartPost/Stop/StopPost/Reload commands within .service files looks very convenient, don't you think ?

Now, if what stucks to mind is only about reloading, I'm sorry but we have to disagree

[Unit]
Description=Postfix Mail Transport Agent
After=network.target

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
[B]ExecStart=/usr/bin/postfix start
ExecStop=/usr/bin/postfix stop
ExecReload=/usr/bin/postfix reload[/B]
Restart=always

[Install]
WantedBy=multi-user.target

[CanalGuada]

and why is the indexed text db so important ? if I want that, I can import to suitable database via an import interface/conversion script/daemon ...

export to syslog is nice, but somebody earlier mentioned that the existence of journald is justified by it logging the boot process before syslog is running, how do you export to syslog if none is running ?

Why should anybody need to import logs to suitable database via whatever it may be needed, after installing (r)syslog in order to get... what journald provides with no hassle ?

You only need logs when something goes wrong (most common case). And if something goes wrong in the stage where journald has its reason for existence (very early boot) you usually cannot boot up the system. This in turn means, anything special needed to read the log files SLOWs you down or prohibits any reasonable troubleshooting (you have to have a system where you can read journald files).

Recent systemd versions provides debug shell access. It is available very early in the startup process to fall back on and diagnose systemd related boot up issues. It provides all you need in order to read logs and can be easily set up from a different booted system since cd, mkdir and ln are standard utilities too.

grep/cat/sed/awk are standard utilities available everywhere so you can boot up the failing system from rescue media, mount the filesystems and go hunting for the issue. in case of a binary log, you are screwed unless you have the correct utility to read it.

See above. If you can mount the filesystem, you have the correct utility to read logs. If not, where will you read logs from ?

[birdie]

You realise that removing the swap line from your /etc/fstab has the effect of disabling swap right?

Swap is in fact very useful and usually speeds up a lot of operations, especially on systems with RAM constraints.

You strike me as the kind of person that wants to find something wrong with a new project just so you can argue with people.
If you don't like systemd that's fine but please stop spreading FUD.

Nah, it's not that simple, the code is still there and it's used (don't ask me why and how, just run `ps ax | grep kswapd` on a system where you don't have swap enabled in fstab).

This is quite damning btw https://bbs.archlinux.org/viewtopic.php?id=144702

[V10lator]

Nah, it's not that simple, the code is still there

Sure, what do you want the kernel to do, recompile itself at boot time and recompile itself again when you use swapon?

and it's used (don't ask me why and how, just run `ps ax | grep kswapd` on a system where you don't have swap enabled in fstab).

Seriously, you want to disable something while you don't even know why and how it's working? Are you... sorry... I can't find words for that... Anyway:
"The name swap daemon is a bit of a misnomer as the daemon does more than just swap modified pages out to the swap file. Its task is to keep the memory management system operating efficiently."
"the swap daemon tries three ways to reduce the number of physical pages being used by the system:

Reducing the size of the buffer and page caches,
Swapping out shared pages,
Swapping out or discarding pages."
(Source: http://www.science.unitn.it/~fiorell...lk/node39.html )

So... Did you ever run `ps ax | grep kswapd` on a system with SWAP support disabled in the kernel, cause it should still be there, else your memory mamagement would be horrible (no way of reducing buffers and page caches). Also:
"With no swap, the system will compress the cache of clean (unmodified) pages to near zero, because those are the only pages it can evict from physical memory." - "It requires no swap space to swap clean pages"
This is what kswapd does, too, so if there's no kswapd running you have even less RAM to use!

This is quite damning btw https://bbs.archlinux.org/viewtopic.php?id=144702

And also years old! From the link itself: "Seeing as this hasn't been solved for quite a long time, maybe one of you guys should make a bug report upstream." ... Did you do that or are you waiting till the devs read your mind? Also: Use swap (activate a swap partition or file, hell even ramzswap works) - problem solved!
Another quote for you: "This is a special case of a very important principle: For a well-designed system, you can't make it run better by reducing its choices. Linux is a well-designed system. Removing swap just gives it fewer choices, so it's not surprising that it behaves worse."

So you lession learned should be: Stop calling yourself a poweruser and stop doing stupid actions without even informing yourself, then blaming others for it! But my guess is you're going to ignore this post, just as you did with my last.