New Group Calls For Boycotting Systemd

[Karl Napf]

If it did stop, then why do you fight it? This alone shows you in no way competent to lead a discussion nor that you actually know what you are talking, to whom you are talking and then do not get taken serious. Who cares for the spelling? And who cares for a missing link? You know where to find it and so does everyone else. Those who cannot find it have other problems and you should also not come here when you think there is nothing.

See here....

[sdack]

I made no claims based on code size i was simply saying lines of code is the single most ridiculous way to judge a project.

Yes, you did! You first claimed size has no meaning only to claim that your argument would scale onto larger projects. So how do you define what a larger project is when size does not matter? According to your logic can one not make assumptions based on large or small, and yet you did. What you did is known as "proof by contradiction". We do use and need measurements to size up projects and lines of code is a common measurement.

[sdack]

See here....

You did not say much but only posted a link now. So I have to guess ...

You now want to tell me, and by showing me this picture that this is me and in no way represents you, because you are showing the link to me and by the very act of doing so will it, and never can, reflect you?!

Is this about right? Or am I wrong?

[WizardGed]

Yes, you did! You first claimed size has no meaning only to claim that your argument would scale onto larger projects. So how do you define what a larger project is when size does not matter? According to your logic can one not make assumptions based on large or small, and yet you did. What you did is known as "proof by contradiction". We do use and need measurements to size up projects and lines of code is a common measurement.

looking back at my statment I noticed you are right and i retract said statment, though the rest of my point stands. lines of code is a poor metric to use and means nothing if the quality or scope of code is suspect.

[blackiwid]

Rofl... so its ok go to this funny group with 200 other guys woldwide... make your own distro if you want who the hell cares.

In every major distro systemd is default or it becomes u cant change that, even if you would have real arguments against it, nobody cares.

Its the same as the gnome3 haters... something changes or windows 8 haters (even I do not care there to much) something changes and I dont need it, I dont want changes at all, except pretty small changes... blabla...

Nobody cares FOSS Movement is no democracy, its evolution, make something better and your solution will win. Or your distri will win, make after u made a gnome2distro (mint) a sysv-whatever distro. I am shure a few will join, except I guess 100x more people care about their desktop then what happens in some backend stuff.

Its so rediculas... hate hate hate redhat eveil hate hate to big hate blaaaa my gosh.

[Michael_S]

If you're right, then you have nothing to worry about.

Paul Frederick,

If systemd wrecks the mainstream Linux distributions, then Slackware and Gentoo and forks of Debian and Ubuntu and Fedora that abandon systemd will become more popular than the systemd distributions. So why worry?

Systemd can use shell scripts. See: http://www.libregeek.org/2014/02/11/...cript-systemd/ If you can't make the changes you want to your systemd configuration with configuration files and you don't feel like writing C code, you can disable the default systemd services you dislike and replace them with SysV-init-style scripts... or for that matter scripts written in any language you want, or compiled binaries. Maybe this will become so popular in coming years that effectively systemd does almost nothing.

The Unix Way of mixing and matching a bunch of very small programs to get tasks done has a lot of advantages, but it does have limitations. Systemd does a few things it's difficult or impossible to do with SysV init. This has been covered before, but I'll repeat it and ask you what a SysV user should do instead:
1. systemd supports starting some daemons on demand. e.g. you leave a particular service off until it's triggered by a request from the network or even by a request from a local socket.
2. systemd supports cgroups, which offer two nice features. First, you can monitor the resource usage of a service across all threads and processes that service uses. To do that with SysV init, you have to write a program that scrapes 'top' or something similar for the same information. Second, you can restrict the total resource usage of the service across all threads and processes the service has running. How would you do that in SysV init, aside from maybe putting the entire service into a virtual machine and then contraining the VM resources? That works, but it adds a big layer of overhead to work around a limitation in your init process.
3. journalctl is extremely easy to use, it took me ten minutes to get accustomed to it, and in addition to all of the nice database features you get for the system log it also does cryptographic signing of log entries based on previous log entries, so the only way for a hacker to fake a log entry is for him to replace the complete system log from installation. In SysV init if someone removes a remote login entry from your logs and then uses simple date manipulation tricks to change the file timestamp, and they whitespace-pad your log entry to be the same size as it was before, you'll only notice if you make a habit of tracking sha-256 sums of your log files on your own. Do you do that? Are you aware of any SysV-init software that does that?
4. systemd configuration files let you add second and third instances of a service easily with simple configuration overrides. Your second service configuration imports the original and then just overrides the defaults. Want two Postgres databases on your machine? Create the data directory for the second database and add a ten line configuration file to your systemd config. Can you do that with SysV init, for any service that it makes sense to run more than one instance of?
5. A lot of the things that make systemd incompatible with other flavors of Unix involve features that only the Linux kernel has (like cgroups). But that's the whole point - the Linux kernel had these cool features that were not exposed to the init system, you had to write binaries to use those features and then manipulate those binaries from SysV init shells. Instead, systemd gives you direct access. cgroups, umount2 (version of umount that accepts different options), fanotify (permits real time monitoring of filesystem access, useful for among other things on-demand malware scanning), etc...
6. systemd returns true multi-seat to Linux. Of course Linux has always had multi-login, but multi-seat means that if you plugin the right device over USB2 or USB3 with its own keyboard, monitor, and mouse, a second person can login and use the machine simultaneously. Fedora setups with one workstation and ten simultaneous people using it have been done. It's not a killer feature, but it's nice - and it hasn't been implemented in other init systems.

I completely support the Free Software ability to fork anything and make a different version. However, I don't agree with the objection that having systemd everywhere is bad. It's only bad if systemd is bad. Otherwise, uniformity makes a lot of things simpler. Few people are demanding an alternative primary C compiler on Linux on technical grounds, or an alternative primary ssh daemon. And if LLVM displaces GCC in Linux in five years because it's just a flat out better compiler, then people won't be asking for GCC back for technical reasons. In all cases the best product for the task wins, and the technical argument for alternatives only comes up if alternatives are equal or better.

I think this anger that the free software community isn't doing what you want does not make sense. I would get laughed at if I sit around and complain that the O. A.D. guys are disappointing me by putting so much time into their R.T.S. game when I want a free software version of Fallout.

In all parts of open source, if you don't like the direction things are taking your only option is to get involved and make your choice superior.

[profoundWHALE]

I thought that in general, less code is safer, while more code is faster.

This is because with less code, there are less mistakes and usually more interpretation which slows down the execution. With more code, there is less to interpret, and more that can go wrong. What we have here are apples and oranges and the odd pears that are none of the above.

[kpedersen]

Its the same as the gnome3 haters... something changes or windows 8 haters (even I do not care there to much) something changes and I dont need it, I dont want changes at all, except pretty small changes... blabla...

I remember back in the day when Linux was designed by, developed by and (perhaps most importantly) used by... people who could form sentences that made actual sense.

[Michael_S]

I thought that in general, less code is safer, while more code is faster.

This is because with less code, there are less mistakes and usually more interpretation which slows down the execution. With more code, there is less to interpret, and more that can go wrong. What we have here are apples and oranges and the odd pears that are none of the above.

Agreed. I think the concerns that systemd will be difficult to secure are valid. On the other hand, if it's in use in Debian, Fedora, Red Hat, Ubuntu, and OpenSuse then that's a lot of eyes on it for holes.

[gens]

I thought that in general, less code is safer, while more code is faster.

This is because with less code, there are less mistakes and usually more interpretation which slows down the execution. With more code, there is less to interpret, and more that can go wrong. What we have here are apples and oranges and the odd pears that are none of the above.

in general less code is faster, with C at least
C translates fairly direct to machine code so ofc writing more C code will give more machine code

and then come optimizing compilers that use magic (pattern matching and some other evaluations) to "compact" and rearrange things to give less code and be more cpu friendly

some other compiler optimizations like loop unrolling do make more instructions (by repeating them) to avoid the need of the cpu to "settle" after some instructions (notably floating point operations, division and memory access)

there are optimizations that come from the algorithm used, that is mostly related to mathematics (and more complex logical problems, see grep for that)
they can make the code complex or complicated or bout (where complex means bigger and complicated means harder for a human to understand)

then there is over usage of library/system calls
(like calling strlen in a loop even thou the length of the string does not change, that a compiler can not optimize since it does not know what strlen() does)

and ofc there is cache trashing and inefficient memory usage due to poor choices in memory management (data structures, malloc, dynamic libraries and idk)


note that division takes way more time then addition, subtraction and even multiplication
square root takes even more time
syscalls take a fair amount (less on amd64)
branching (notably conditional branching), as written; but not much
and so on and so fort

so ye, simpler programs usually run faster
also load faster as there is less to read of the disk
statically linked programs load and run even faster then that (load, in most cases, in some id expect not)


felt like writing a bit



(won't talk where the thing comes in all this as i really don't want stupid replies)