Users/Developers Threatening Fork Of Debian GNU/Linux

[jrch2k8]

This is such BS.

The kernel does not distinguish between applications' own memory and IO operations, thus, and it constantly happens under heavy IO when you copy large amounts of data, applications get swapped out, thus when you switch back to them your system more or less freezes, because the kernel prioritizes reading memory pages from swap back to RAM. swap is almost always detrimental to the performance of the system, unless you use various swap implementations using compressed RAM.

God, people are so much full of BS. Like those segfaults in SysVinit which no one can show me (meanwhile I can easily find several hundred real bug reports about segfaults, crashes and freezes in systemd). When you're telling them that SysVinit basically has no way of segfaulting they say that _real_ _multiple_ bug reports about crashes in systemd are a figment of my imagination. Wow.

And I owe you nothing. If it's so difficult for you to repeat your previous messages, then so be it.

Huh, you've just told me that swap is required for hibernation. Well, f*ck me, but if some kernel developer had a hangover when he was designing this feature, then it's not my problem - it's a bad ugly implementation. People often increase their RAM which means in Linux you must resize your swap partition (of course some crazy guys create a swap partition which is several times their physical RAM but that's not exactly an ordinary practice). I'm sorry but that's utterly f*cked up; that's not a thing to be proud of, or an argument for using swap.

well this is very dependant of you hardware configuration, i for once barely have issues with swap but is true with certain chipsets you can get crazy long pauses when moving big data(non-intel chipsets tend to have this effects) and swap but for example my archlinux(in a mac mini 2012) move huge 4k videos(40g+) files(hobby im try to get good at) with 0 issues even when im editing other huge video in kdenlive but my AMD 990fx chipset board hate those big files and sometimes freezes even the mouse for 1+ min and this happens too with certain RAID card, fiberchannels, etc. so my point is don't assume that if you have 1 problem is an absolute truth for absolutely everyone else.

i agree with you about swap and hibernation, i understand why was done this way originally but even so is not an elegant solution but i'm confident it will be replaced eventually.

about swap resize is an unspoken rule but not a rule, swap was not designed to be an alternate big on-disk RAM, it was designed to handle non-critical data structures that weren't used often enough to justify the horribly expensive space in RAM(talking back to the 80's) or as a way to win some more time for the kernel to start aggressively cleaning pages in case the main expensive RAM became saturated, so in that age have certain fixed % of swap depending of the total ram was a good practice but today this concept is idiotic, if you have more than 1g in your swap you either need to spare few bucks and get more RAM or have a crappy software doing something very stupid.

Please note that you don't need to remove SWAP infrastructure from the kernel(this is very very unusual, i guess that is why you triggered that bug), just don't create a swap partition in your disk or reformat those partitions to ext2 or simply enable zswap, in my case i have maybe 3 years without creating swap partitions on my server or workstations or whatever because this day and age is a lot cheaper to get more RAM than buy a new harddrive(or SSD) damaged for constant swapping(is backwards now)

well about your rant about segfaults bug reports this have a simple explanation systemd is more dependant on kernel infrastructure while sysvinit is totally dependant in userspace and basically see nothing new since ages ago so the bugreports tend to be quite old and that executable itself is quite stable but problem with is that is actually quite easy to crash the boot process(again not the executable file sysvinit itself) by simply messing with its userspace dependencies(bash, ls, touch, awk, grep, etc.) or messing with early init scripts(forcing them to loop, wait for never happening events, bad syntax, etc.) while systemd can be crashed if you mess with the kernel infrastructure(the executable itself) but is very hard to mess the boot process if the kernel infrastructure starts fine(exactly backwards).

for testing you just need to modify the permissions/attributes of lets say awk and boom or look for an init script in rc2.d that contains a loop or a poll and add ;; somewhere near and enjoy, of course this won't happen often if you don't mess with the package init script or start having fun with /usr/bin and chmod but is also true systemd won't either if you don't mess with your kernel config options(without taking into consideration the dependencies of it of course).

again don't assume if in your specific scenario you managed to crash either one is the absolute same for everyone else on earth

[ceage]

Well, in any case, about systemd etc. I do find it very difficult sometimes to figure out why a particular systemd service gets started, and when I tried putting together a battery target which would automatically shut down various daemons that I don't need when I want to save power, it apparently somehow caused the brightness keys (fn-F5 and fn-F6) to mysteriously stop working, and as I expected, it was impossible to debug. So instead of using a systemd target, I'll just hack together a shell script that runs the necessary "service <foo> stop" instead of using a systemd target. If things start breaking horribly, I'll file debian bugs, and try to find ways to work around the brain damage. The fact that I won't be able to edit shell scripts to work around brain damage is still a little anxiety-producing, and the fact it's much more difficult to create a runlevel which is "just like runlevel 3 but without certain services running" is unfortunate.

Not sure whether I've grasped what the issue is, but in case you were trying to use `systemctl isolate ...' for this: don't. This is likely not what you want and will almost certainly kill processes that belong to your desktop session. It *should* be enough to add something like `Conflict=pesky-power-hogging.service' to your custom battery target and then tell your ACPI handler to run something like ``/bin/systemctl start my-battery.target''.

[V10lator]

This is such BS.

The kernel does not distinguish between applications' own memory and IO operations, thus, and it constantly happens under heavy IO when you copy large amounts of data, applications get swapped out, thus when you switch back to them your system more or less freezes, because the kernel prioritizes reading memory pages from swap back to RAM. swap is almost always detrimental to the performance of the system, unless you use various swap implementations using compressed RAM.

Proove? Cause I just did heavy I/O with copying a lot of data:
before:

$ free
             total       used       free     shared    buffers     cached
Mem:       8163016    1993952    6169064      37872       3332     117256
-/+ buffers/cache:    1873364    6289652
Swap:      2088412         88    2088324

After:

$ free
             total       used       free     shared    buffers     cached
Mem:       8163016    7922728     240288      37872       2612    5877152
-/+ buffers/cache:    2042964    6120052
Swap:      2088412         88    2088324

So... why did it not swap out anything?
Also: If you know that good how the kernel handles memory/swap, why in hell do you want the kswapd to stop running? Again a question I have to repeat cause of your ignorance.

God, people are so much full of BS.

Maybe you should say that while looking into a mirror.

Like those segfaults in SysVinit which no one can show me

Did I talk about SysVinit crashes? No, so what's your point?

And I owe you nothing. If it's so difficult for you to repeat your previous messages, then so be it.

Why should I repeat myself over and over again? You're trolling and it gets really boring.

Huh, you've just told me that swap is required for hibernation. Well, f*ck me, but if some kernel developer had a hangover when he was designing this feature, then it's not my problem - it's a bad ugly implementation.

No, it's the only possible implementation. Where when not to swap do you want to save the data so the kernel is able to find it easily when exiting hybernation?

People often increase their RAM which means in Linux you must resize your swap partition (of course some crazy guys create a swap partition which is several times their physical RAM but that's not exactly an ordinary practice). I'm sorry but that's utterly f*cked up; that's not a thing to be proud of, or an argument for using swap.

So why not use swap files instead of swap partitions? And if you don't even care about hybernation, who's forcing you to resize the partition? Also: yes, it is an argument for swap. If you like (the linux implementation) of hybernation or not doesn't change the fact that hybernation is not usable at all without it. You know, that's the difference between opinions and facts...

[movieman]

Proove? Cause I just did heavy I/O with copying a lot of data:

I can only presume he's confusing Linux with Windows, which used to swap out my web browser when I copied a 2GB file from one disk to another so it could try to cache the file in RAM. Linux doesn't do anything that silly.

[erendorn]

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).

Humor us, the journald format is key/value, append based, and log content value is plain text. So what are the differences? Just that you need to pass it to "strings" first?

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 ...

journald stores more metadata that you cannot get back, and text logs tend to have no unified format, or even place. So you need multiple, uncomplete tools.

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 ?

Worse case is, you still cannot provide what you couldn't provide before, but at least you have the journald logs.

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.

Put systemd on the rescue media? Use any live session of a distribution with systemd? Use any other system that has systemd, as you probably don't have only a single one? Use strings, and then, grep/cap/sed/awk?

[alcalde]

If I hadn't experienced all of this firsthand, I wouldn't have posted these links here. I tried Fedora 20 just recently and I saw with my own eyes how systemd segfaulted. OK, that was a bug, yum update fixed it. Then it froze on boot trying to run two bad services over and over again - not even trying to realize that they cannot be launched.

Systemd is an abomination. An init system must be rock f*cking solid and equally simple. Systemd is anything but. There was a proposal to create a very simple, very basic init 1 process which spawns all other crazy systemd features as sub-processes so the whole system has no chance of crashing but no, Lennart doesn't think it's worth it.

You're using Fedora, a bleeding-edge distro whose stability has been the butt of jokes in places like the Linux Action Show (e.g. the immortal diatribe on two menu options, "System Update" and "System Updates") and blaming SystemD? SystemD runs nice and smooth on OpenSUSE and has done so for a long time; I'm writing this from a test install of OpenSUSE 13.2 RC1, also with no SystemD problems.

All the technical luminaries in the Linux universe has declared SystemD awesome, not "an abomination". That's exactly akin to Windows users who say "I don't run Linux because I don't want to have to compile all my software". The SystemD as exists in your mind isn't the same thing as the SystemD that exists in objective, external reality. At some point in time people have to notice that all the maintainers of all the major distros are adopting it and realize it's them, not the entire Linux universe, and that they're fooling themselves... their real objection is just a resistance to change. There's no other explanation.

It's also starting to get embarrassing and fights like this will be held up as examples of why no sane Windows user should want to adopt Linux. These blood-soaked battles over ideological minutiae make us look like obsessive, shrieking nerds and the community like a terrible place to be. Didn't that one Debian developer have to take some "time off" and practically end up in a mental institution over his opposition to SystemD? This is LITERALLY madness. It's time we just accept that SystemD improved on SysV and move on... or come up with something better. Forks are supposed to be avoided at all costs. All this fighting over imaginary things is just going to hurt Linux.

[finalzone]

You're using Fedora, a bleeding-edge distro whose stability has been the butt of jokes in places like the Linux Action Show (e.g. the immortal diatribe on two menu options, "System Update" and "System Updates") and blaming SystemD? SystemD runs nice and smooth on OpenSUSE and has done so for a long time; I'm writing this from a test install of OpenSUSE 13.2 RC1, also with no SystemD problems.

As one of Fedora Spin maintainers, the 20 release is rock solid and stable. I don't know how the previous post got systemd segfault as it is hard to find the specification of his system and what exactly caused the segfault to begin. Maybe he was unlucky and hit the case of "You Mileage May Vary".

[scjet]

I honestly hope they do fork Debian, there's way too much PhoronHat here anyway.

[CTown]

I can understand where these experienced IT guys are coming from. Their workflow is based around many of the tools systemd is trying to replace; we're talking about decades of this workflow.

Still, systemd solves problems people care about. Even the problems most of these IT guys never recognized (and still might not); which is the goal of engineering. This will continue to make systemd more popular; a nearly mandatory component in Desktop Linux. systemd was just released default on RHEL7/CentOS7 and is the default on yet to be released versions of Ubuntu and Debian. By a few years, the IT guys will develop a workflow and solutions around systemd. Then, the anger around systemd will fade.

At that point and only at that point will we look for a new cause to have troll fests over... probably, the next creation of Lennart Poettering!