LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   The mass exodus if Slackware uses Systemd (https://www.linuxquestions.org/questions/slackware-14/the-mass-exodus-if-slackware-uses-systemd-4175523380/)

philanc 02-15-2015 09:08 PM

Quote:

Originally Posted by gezley (Post 5317699)
At the end of the day, however, my opposition to systemd is visceral and intuitive, not very well-defined and enumerated. I don't have to know the specific reasons systemd is flawed to know at least one of its lead developers has been arrogant, dismissive and contemptuous. His obnoxious attitude to other people, other Linux distributions and other open-source projects like the BSDs is more than enough for me to go on. [...]

Opposition to systemd for intuitive reasons like this is unlikely to satisfy those of you for whom systemd is nothing more than a technical affair, but it's a legitimate reason for me to avoid it completely. [...] I really don't care if systemd is perfect; I still won't use it, and that is a decision based purely on the obnoxious, condescending, rude, unmannerly and bullying behaviour of its main dev.

This is a good and honest answer. I think that many of the most vocal systemd opponents, whatever their apparent rationalizations, do feel that way. I have the same knee-jerk reaction about systemd, when it comes to _my_ machines - the ones I manage, use and want to control and understand. And I also had the same reaction about udev, HAL, dbus, all the *kit, and more generally all the Desktop Environment things.

Now, when it comes to providing a comfortable environment to regular end-users, especially in a corporate environment, it is another story. Most end-users do want a desktop environment, with all the bells and whistles. It obviously can be done without systemd, but my understanding is that systemd is becoming a better, more consistent platform to build a robust desktop (see the KDE developer blog post cited above).

Whatever we may think of the big DE (KDE, Gnome) developers and of the large distros technical leaders, these guys are smart and knowledgeable, and have spend lots of time and effort understanding systemd before adopting it.

We may just not be the right target for their stuff.

a4z 02-16-2015 12:53 AM

Quote:

Originally Posted by genss (Post 5317730)
just because OSX does it, doesn't mean it's any good

it has nothing to do with me, it has with oldschool UNIX neckbeards
today it's just copy pasta "features" marketing

you where talking about something is proven to be better,
but there is no prove, there is just your opinion, and all the system that have implemented you prove faild in solving the problems Apple or Red Hat or Google tried to solve.

so instead of just telling stories, why do you not make a prove?
check some of the problems that are targeted and come with a solution, make it testable for others, write a report why it is better, and than there is something more concrete as 'oldschool UNIX neckbeards' blabla


Quote:

Originally Posted by genss (Post 5317730)
for the Red Queen !
the queen of queens
may she abolish all that are different

I do not know this, but that you dam everything that is different seems to be obvious

travis82 02-16-2015 01:40 AM

well, from a beginner point of view, I don't care about what techniques and tools used by slackware unless they affects it's configurability. I like slackware philosophy and it's KISS procedure which make it a great and stable platform for learning linux. I tried several distros which try to be Windows but still they lag behind Windows in many aspects. so if someday slackware want to kiss off its philosophy maybe I return to Windows or try BSD.

ReaperX7 02-16-2015 02:20 AM

I just thought of this after doing some work today with some other systems, but since things like SMF, launchd, etc. all are init and daemon control systems of UNIX branded distributions, I think I read one of Lennart's blogs where he said systemd was very much aimed at being very UNIX-like or UNIX-derived in design.

However, the old moniker of "GNU is Not UNIX" triggered a thought. Is systemd aiming to make GNU/Linux a true UNIX like Solaris, Illumos, and Darwin/OSX. But to do so wouldn't they need to effectively replace the GNU userland with the systemd userland? It's just a passing thought I had so I figured I'd share.

kevison 02-16-2015 05:50 AM

An interesting article on systemd http://news.slashdot.org/story/15/02...-debian-system

TobiSGD 02-16-2015 06:09 AM

Quote:

Originally Posted by saulgoode (Post 5317603)
So what entitles you to tell people what they are entitled to tell people?

Common sense.

TobiSGD 02-16-2015 06:34 AM

Quote:

Originally Posted by ReaperX7 (Post 5317641)
Issue 1: Faster boot times than bsdinit and sysvinit.

Proven false. Sysvinit and bsdinit can safely boot the system core without starting the service daemons and execve() into a service supervisor like perpetrator to initialize daemons in parallel using tree based dependency startup path load and check, often at nearly the same exact speed, but without running into a journal bug if a shutdown/reboot ends with an improperly dismounted root file system.

This again? Faster boot times were never a goal, but simply a byproduct. You know that very well, so I have to ask why you even bring it up.
Quote:


Issue 2: Cgroups management.

Proven limited. Only a small majority of users and system admins actually will utilize containers and these can be handled by libcgroups and standard init.
I don't quite get were you are going at here. Cgroups management is done for each and every service, not just containers. But even then, when you say "Proven limited" you admit that there at least partially were problems with that which now are solved.
Quote:


Issue 3: UNIX Socket Activation

Proven a bad design. Sockets require a higher degree of shared memory which increases the resource usage footprint by allocating preset socket at boot rather than using named pipes for interservice communication in the system. Traditionally sockets were created only as needed which lowered the amount of resource usage.
Really? How do you start a SSH server using named pipes on the first attempt of a connection?
Quote:

Issue 4: systemd is modular.

Falsified terribly. Modular means that each piece and part of the whole can work seperate and independent of the next. This is proven anything but. Libsystemd is a shared object meaning it has to exist in the system. The init system, journal, and udev must be present for the bare minimum. Udev I understand, but why the mandatory logging system? Plus, you still need the rest of the parts if you add networkd, consoled, logind, and others which only add to the base, but never can be made to function separate all because libsystemd can never be a static library.
And here you completely loose the path. What has this to do with the question at all?
Quote:

Plus add the fact several projects that were only in need of work were abandoned and almost left to rot.
Also not what I asked about, but anyways, this works in both directions, yes, there was a project that was abandoned, namely Consolekit, because it was replaced systemd-logind for systemd users. But how is it the fault of systemd developers that it needed years for someone to step up to actually maintain it again?
Quote:

Add in the fact that systemd is aiming to get kdbus inserted into the Linux kernel to replace netlink in udev which will cripple many non-systemd systems because only systemd has the interface handlers to work with kdbus.
That is funny. I wrote about that also in a previous post, I think even in this thread. The kdbus switch for udev was announced 2014-05-30, and Mr Poettering (admittedly in a not nice fashion) explicitly warned people well in advance that they will have to come up with their own kdbus userspace component if they want to use newer future udev versions. Until now, about 9 months later, there is not a single project that even started with that. How again is this the fault of the systemd developers. Are you seriously blaming them for not writing software for systems they don't support?


All in all, you failed to give a sufficient answer to the question.

TobiSGD 02-16-2015 06:37 AM

Quote:

Originally Posted by gezley (Post 5317650)
I thought it was common knowledge KDE received EU funding. Here's one EU website where you can see they received EU11.5 million.

http://cordis.europa.eu/ist/kct/nepomuk_synopsis.htm

Check out the Administrative Details section. Calling me a liar, were you?

This what the website says:
Quote:

The Linux KDE developer community has shown interest in the NEPOMUK model. A group of developers have started to implement the NEPOMUK interfaces within the Linux KDE and IBM Eclipse environment.
This is what you say:
Quote:

KDE, for example, received massive funding from the European taxpayer
What really happened is that the KDE developers used openly available research data that was indeed funded by the EU, but they have not received massive funding.

brianL 02-16-2015 07:13 AM

Anyway, whatever happens, Slackware with or without systemd will still be my preferred distro.
P.S.
If Jeff Bridges can't do an Oldham accent, try Kevin Spacey.

hitest 02-16-2015 07:47 AM

Quote:

Originally Posted by brianL (Post 5318032)
Anyway, whatever happens, Slackware with or without systemd will still be my preferred distro.
P.S.
If Jeff Bridges can't do an Oldham accent, try Kevin Spacey.

Yep. Slackware is and always will be my main distro.

jens 02-16-2015 08:04 AM

Quote:

Originally Posted by hitest (Post 5318046)
Yep. Slackware is and always will be my main distro.

Even though my "main" distro is (and alwayd will be) Debian, I can't imagine a world without Slackware either.
It's what I'm still(since the very fist alpha releases) running on my most personal desktop/laptop.

For me, Slackware is a full package that never failed to deliver.
Every new release is like a Christmas present that doesn't get boring.

In all fairness, I find those "don't_add_systemd_or_we'll_leave" comments insulting towards the Slackware team.

genss 02-16-2015 08:27 AM

Quote:

Originally Posted by a4z (Post 5317898)
you where talking about something is proven to be better,
but there is no prove, there is just your opinion, and all the system that have implemented you prove faild in solving the problems Apple or Red Hat or Google tried to solve.

so instead of just telling stories, why do you not make a prove?
check some of the problems that are targeted and come with a solution, make it testable for others, write a report why it is better, and than there is something more concrete as 'oldschool UNIX neckbeards' blabla



I do not know this, but that you dam everything that is different seems to be obvious

what problems ?
that not everything goes over dbus namespaces is a problem ?
that some people get confused over run levels is a problem ?
maybe that linux is not enough like OSX is a problem ?
what IS the problem ?

and no, i don't damn everything that's different
that's just a out right lie
i do however damn everything that is different just for the sake of being different
even more i damn everybody that lies to present themselves as being better then others
should be obvious from lennarts blog, especially from hes comparison of systemd to sysv and upstart, that he does
(although "30 biggest myths" has way more blatant lies in it)
in short; i damn everybody who think they are better then everybody else, as people that do are usually morons

hence the red queen, as you see the red queen effect is an observation of the evolutionary arms race
it pits the idea that organisms must evolve not only to survive the environment, but also other organisms
if you still don't get it; it's a snarky remark that systemd's goal is to have features just to kill off everything else
why is that bad ? you ask. It's still evolution, progress ! you say
but it's not
the "features" that distinguish systemd from what slackware is today are not really useful

per process cgroup ? to limit a process to arbitrary cpu/memory/network/io percentage ?
(let me repeat that: per process control group, that is one process group)
niceness, it works fine. even for io and network
nice limits the nicer process when another process wants more resources
a good way to limit something without limiting everything else

another example; i can now compile with -j whatever, that i couldn't do a few years ago
progress in the design of the process scheduler made it possible for me to do whatever without killing interactiveness
(automatic process grouping, if you wanna google)

nice leads to a good explanation of actual progress in linux
(that many overlook when all they are bombarded with are "features")
you know about KDE's nepomuk ? the thing that everybody curses about that it makes their computer unusable ?
let me introduce you to something put in the kernel as of version 2.6.13
put your hands up for ionice ! *clap clap*
ionice is like nice, but for IO ! wooooow
and it gets better !
as of kernel version `cba to find out` nice sets the ionice automatically !
you get two for the price of one ! (if you order within 15min)
(bdw you need to use the CFQ scheduler, deadline does not support ionice)

you see, that is an example of real progress
and it's not intrusive
it does not limit you, nor change your workflow, nor make you learn the .ini format
just benefits with no drawbacks
and it's not even advertised as being this awsome thing that you must have 'cuz it's features and future and progress
(it is progress, although too old of an idea to be "future")

and there are many many things like that, that are not advertized as disingenuously and aggressively as systemd
they are progress, not this hacked together framework


so please don't try and color my name
i hate things that suck* and people that lie
i find that to be a quality of mine, not a flaw
(edit: "things that suck but are presented as being great"*)

edit2:
"you hate it 'cuz it's different" has been used to discredit people that don't like systemd
and it is a red herring, always has been

NeoMetal 02-16-2015 11:33 AM

Quote:

Originally Posted by ReaperX7 (Post 5317802)
I never said it was a bad design all around. People need to stop trying to twist my posts to suit their own agendas. If you read my post, that was NEVER said.

What I said was allocating a system full of sockets for interprocess communications is a bad idea. There's nothing wrong with using sockets, but they should be used dynamically rather than statically to keep the shared memory usage at a minimum, and if sockets aren't required for a process, use named pipes instead to keep the resources used minimal. Sockets themselves aren't bad when used properly, but wasting resources and bloating system requirements by turning the system into an HTML server and overloading the footprint isn't the best of ideas... hence why the system resource requirements from Windows XP to Windows Vista literally exploded. Svchost pulled in more and more functionality using socket activation as well as expanded it's role in the system which not only doubled the CPU and RAM requirements of Windows, but nearly tripled to quadrupled them. Is this something that you would like to see happen across the board for GNU/Linux?



If you look into the idea of socket activation a bit, even just look at the proposed nginx implementation someone linked a few posts back, you can see its not for IPC, unless you are using the term in a meaninglessly literal way. I have some issues with systemD and particularly with the way its being 'marketed', if you will, but taking some technical term associated with it and going out on a tangent with it that isn't really relevant doesn't do anyone any good.

fogpipe 02-16-2015 02:41 PM

This, from the linked slashdot article pretty much sums it up for me:
http://news.slashdot.org/story/15/02...-debian-system
Quote:

At this time I see:
- No technical merits of systemd that are important or critical, just some convenience issues
- Systemd is in hurried development, a stable feature set is nowhere in sight
- The development leads are known incompetents with inflated egos and no communication skills
- There are a number of design decisions that are very, very bad for security and stability

At the same time I see:
- Systemd is pushed strongly with emotional (not factual) arguments
This is a coordinated and targeted propaganda campaign. A campaign focused on technical merits is not even attempted seriously.
- Systemd opponents are ridiculed, insulted and their arguments are not taken seriously
- Systemd is getting very hard to avoid

I can only deduce that there _must_ be one of or a combination of the following going on:
- Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
- Linux did not generate enough support revenue Red Hat and this is intended to fix that by decreasing reliability
- Red Hat wants total control over Linux and systemd is their attempt to establish that

So if it walks like a duck, quacks like a duck, the most probable explanation is that it is a duck and hence I conclude that something nefarious is going on and the last three items are the most likely candidates IMO. I cannot believe that two known incompetent hacks with bad personalities can screw over a whole large tech-savvy community all by themselves. They must have significant, coordinated help, with significant propaganda and manipulation experience. Whether it is military PsyOps or just commercial PR, the effects are the same. And they are massively negative and destructive for Linux and its community if not repelled decisively.
I think we need to look at the the attempt to portray systemd opponents as backward, resistant to change etc in light of the above. The main benefits of systemd are to redhat and its backers who also benefit from a crippled linux.

Didier Spaier 02-16-2015 02:51 PM

@fogpipe:
  • When you quote, at least provide a link to the source.[1]
  • In my opinion, the "retweet" attitude doesn't add any value to a discussion.

[1]EDIT. You did it while I was typing (but not to the comment itself).


All times are GMT -5. The time now is 02:59 AM.