Hi TobiSGD,

As you might know both gnome and kde and more DE's are leaning towards making systemd a hard dependecy.
because of this, Dropline Gnome start developing next to their standard gnome release a systemd part.
This is all still in development, and we do not declare it as release for the time being.
That being said, there are some thing to know about systemd on slackware.

1. some packages needs to be reinstalled because systemd ships with udev.so.1, while slackware is still udev.so.0
2. even tho in our systemd package we make a symlink between those 2 libs, rebuilds of the other packages have been made.

https://sourceforge.net/p/dropline-g...s/dlg_current/

at the above link you can browse the code online, please be aware that dropline gnome has been using their own build system, on request I might be able to create a few slackbuilds tho.
below you find the svn checkout command.

svn checkout svn://svn.code.sf.net/p/dropline-gnome/code/dbs/branches/dlg_current dlg_systemd

How to use the build system:

modify file: etc/config
than build your package with ./dbs build <packagename>

Please note that we build dlg with pam support for gdm, but you can offcourse alter the systemd script to not use pam.
currently only login, sessions, polkit and gdm.
so using ssh does not invoke pam for example.

a little howto can be found here:
https://sourceforge.net/apps/trac/dr...me3_10_Systemd

2 members found this post helpful.

I know. Hence the keyword "yet". Neither of them have been released and probably won't be until next year. The big hurdle I see is with supporting legacy or otherwise unchanging applications. Oracle XE doesn't like systemd, so there's probably some more changes to come before most people would consider it stable.
Hopefully that stays that way. I'd hate to see other operating systems lose out because of an init system change.
Yeah, upon further review, it looks like it was a Fedora dependency. My bad.

I'm sorry but technology doesn't work that way. Opinions don't matter unless they are backed by facts. The arguments made by people who think that "systemd is crap" just don't tend to hold up. Also even if there are problems with a technology doesn't mean its "coding" or "formatting" is bad. The reality of the matter is that distribution after distribution is picking up systemd. This doesn't only include the leading enterprise distributions (RHEL and SEL) but also mobile operating systems like Tizen and Sailfish. Community driven distributions like Arch Linux, Mageia, openSUSE, Fedora and Sabayon. Embedded project like Yocto and oragnizations like GENEVI Alliance that works on IVI systems and requires systemd support for compliance. So why do these projects and even competing companies pick up systemd? I mean they have a little more on the line here than some random blogger on the web. So maybe you should do the research, the Debian initsystem debate page is good place to start.

I'm not.

I'm not... the thing is that making claims that aren't true doesn't count as criticism.

It's unfortunate that the level of criticism has gotten so low but it's pretty much the truth. You aren't exactly helping the situation with saying stuff like:

...without once having any sources or analysis how you came to these conclusions or anything of the sort. You gave one link to a site that only showed that all the zero day exploits were fixed. There's also some utterly false claims like, among others...

When in actuality there's a lot of documentation on the project home page at freedesktop.org including technical documentation, reasonings, specifications, man pages (no less than 142 pages) for configuration files and commandline interfaces. Pretty much showing that you didn't do even the most basic research (going to the projects web page) before starting to critize it.


Well it's up to them to maintain the ports to their operating systems. OpenBSD for example worked with Gnome community to port Gnome 3.10 to OpenBSD. There's also the FreeBSD KDE team. In the future there's bit more stuff to maintain but I would think they can manage.

True. SUSE Enterprise Linux is planned for Q3 2014 if I recall correctly. We are probably going to have RHEL 7 beta later this year.

i still dont (and i think i will never) understand, why systemd, upstartd etc. was made/needed.

doesnt the old "never touch a running (aka work) system" count anymore?

sysvinit aka the bsd like init system works find and did since forever. I really like the bashscript approach.

why must humanity allways try to reinvent wheels.. i really dont get it!

greatings.
Stuferus

ps.: maybe we leave this alone, im sure patrick (i hope i may "you" him ) knows it all, maybe feels the same and will stay away from systemd as long as possible. mybe we could port the orginal bsd init, or invent our own wheel - lol - if the time comes?

i was a happy arch user before systemd was incorporated. i did not only leave arch because of systemd, but also because of the fact that the core developer team lied (in a poettering style) to the community to get systemd into arch. so i consider arch not as a "community driven distribution" anymore.

i like the unix aspects of linux, thats the reason i use it. i follow the unix philosophy. systemd is windows software. it runs on linux, but its architecture is windows like.

an example:

polipo wouldnt start, so i start to investigate. i found an error protocoll (forget where) and it told me what to do - it was a command line which i copied and pasted into an xterm.

when i found out what this command actually was, i was shocked, it was a command to read the systemd log file, because the systemd log is *binary*. that was the moment when i realized that systemd and arch linux is nothing for me.

on the other hand - without systemd i would have never returned to slackware. and i feel much better with slackware now.

11 members found this post helpful.

i was a happy arch user before systemd was incorporated. i did not only leave arch because of systemd, but also because of the fact that the core developer team lied (in a poettering style) to the community to get systemd into arch. so i consider arch not as a "community driven distribution" anymore.

i like the unix aspects of linux, thats the reason i use it. i follow the unix philosophy. systemd is windows software. it runs on linux, but its architecture is windows like.

an example:

polipo wouldnt start, so i start to investigate. i found an error protocoll (forget where) and it told me what to do - it was a command line which i copied and pasted into an xterm.

when i found out what this command actually was, i was shocked, it was a command to read the systemd log file, because the systemd log is *binary*. that was the moment when i realized that systemd and arch linux is nothing for me.

on the other hand - without systemd i would have never returned to slackware. and i feel much better with slackware now.

11 members found this post helpful.

Hi,

systemd is a departure from traditional system init software and philosophy of UNIX (what
that means can be found on Wikipedia).

These are the most serious problems of systemd:
- its dependencies
- other software like DEs being dependent on it
- taking over functionality of other software modules and by doing so driving a wedge into
an ecosystem of Linux/UNIX/BSD* OSs/distros
- propagating baseless propaganda about its "parallelism" that does not work because it
does not account for concurrency problems and requirements
- complexity that will become a nightmare for sysadmins and users
- yes, it is a Red Hat product, and based on the above, it is supposed to serve its goals
It is a poisonous system software that should be treated with suspicion it deserves.

There is a counter offensive under way lead by OpenRC devs.
It is a Gentoo sponsored product:
http://wiki.gentoo.org/wiki/OpenRC#CGroups_support
but its implementation is under way in e.g. Arch Linux, by a good dev called artoo:
https://bbs.archlinux.org/viewtopic.php?id=152606&p=10
and is employed by many users of Linux systems with great success.

So, go out and help OpenRC become an advanced sys init software that applies principles
of UNIX, adds even more modern features beyond of what already offers, is compatible with
existing UNIX/Linux/BSD* systems, and by that become an antidote to much of what systemd
offers.

jb

1 members found this post helpful.

taken from: http://en.wikipedia.org/wiki/Init
so you are wrong about that.

- its depends on nothing more than every linux system already needs and has no strange extra dependencies
- there might be some software depending on it, but so far all DE's can run without systemd.
- taking over functionality ? systemd is taking all kernel functions into its program.
kdbus, cgroups just 2 examples.
about your parallelism, that is user/distro configuration.
- Journalctl >>>>> all over logging (IMO) - unit files are very easy when you get used to it
- no comment about the red hat part.

to reply on this: OpenRC implements CGroups like you said.
CGroups is linux-kernel (will not work on BSD)


The reason that people (LP) are developping a new init system, is that current sysvinit is old, outdated, and does not evolve with the rest of the linux world.

Similar story:

http://sporkbox.us/blog/?r=page/95

On very limited embedded systems it could pose a problem. Anywhere else (from mobile to servers) not so much.

That's completely up the developers of the said software to decide. It's hardly systemds fault that other software depend on it.

I think the well integrated and coherent stack to be worth it. If other people want to adhere to different philosophy they should pick up the work to do it.

I don't understand what makes it "propaganda" but it definetly works in practise.

It has been used for couple of years already. I see no nightmare. I'm definetly interested how RHEL 7 will turn out though.

It's a collaboratively developed project that has had commits from 145 people over the past year and from many companies including Red Hat, SUSE, Intel, Pantheon, CENLab, Samsung, Ajax Communications and more. It has sixteen maintainers with commit access including people from Debian, Arch Linux, Ubuntu, Mageia and openSUSE. Arch developers have been particulary active. But sure, Red Hat has invested the most in it.

No disagreement here. It could use some help considering that after over six years of developement it still can't realibly offer parallelized boot, a basic feature for a modern init system.

-OpenRC

@ bartgymnast
regarding that statement:
"systemd is a departure from traditional system init software and philosophy of UNIX (what
that means can be found on Wikipedia)."

I was about to answer you with references to original discussions in Fedora when I noticed
that a poster JWJones included a link to relevant answers. Excellent !

So I do not want to duplicate them - I just ask you to spend some time on these two threads
(display them as threads and follow the posts, keeping in mind that their flows were
interrupted by "well-wishers"):
http://lists.fedoraproject.org/piper...ne/152323.html
etc.

jb

And there could be where "the new "Linux standard base"" shoots itself in the foot and those not happy with the Systemd being forced on them move to the BSD's and suddenly the BSD's *aren't* a thing of the past anymore but are now a direct and possibly equal competitor to Linux.

My take on the impetus behind systemd is that Red Hat decided they needed something like it for datacenter and desktop environments, for the deep hooks it drops into the boot process. With these hooks, it's possible to monitor the internal state of the system via a remote service (for the datacenter) or GUI (for the desktop), and more importantly, make changes to the system's state during the boot process.

Thus, if a datacenter system administrator booted up ten thousand servers, and a hundred of them failed to bring up sshd, the administrator could use a remote connection (akin to IPMI) to rectify the problem without having to roll a crash-cart to each problem server. This would make it more useful than the serial console, occupying a niche between in-band and out-of-band system management.

Alas, no, I'm seeing more and more sysadmins and engineers these days exhibit total lack of clue regarding proper management of production services. This adage may have attained the status of "greybeard esoterica".

Me too. Red Hat's business needs aside, sticking with the simple, tried and true init system makes all matter of sense to me.

Not a needed feature, at least in my use cases. And I'm not eager to get an new stuff that doesn't solve any problem I have but can cause others. If you are not aware of the problem with threads, just read this or even better:PS I apologize, I shouldn't have added one more useless post to that useless thread

wow a post out 2011, we are almost 10k commits, 100k lines and 2.5 years. later

slackware with systemd
1 root 20 0 4928 2920 2076 S 0 0.1 0:01.54 systemd

non-systemd (standard slackware)
1 root 20 0 4352 712 612 S 0 0.0 0:02.21 init

on todays system, I dont call that much of resources.

exclude pam from it, as it is optional.
you have extra: libdl, libattr, libdbus, libcap,
rest is systemd libaries
so libattr = package a/attr
libcap = l/libcap
libdbus = a/dbus
libdl = l/glibc

as glibc is needed for both, there are currently 3 extra packages.
systemd is using libcap, and that depends on libattr
and dbus is being replaced by kdbus (kernel dbus)

so it is the almost same deps as sysvinit+udev

*systemd is init+udev


and memory footprint is low.

Sorry to tell you that, but the majority of these people are in Google's and Canonical's boat. So no, it's not relevant to them, what Red Hat does. Android even avoids udev at all cost, they know why.

You need neither KDE nor GNOME to have a perfectly fine Linux desktop.