Anyways, both AMD and Nvidia drivers work fine on Slackware.
Anyways, both AMD and Nvidia drivers work fine on Slackware.
I just looked at the deps for systemd on an OpenSuSE 12.2 box. It requires a lot of stuff I would not expect of init - PAM, libkmod, selinux, libaudit. It does seem like a lot of responsibility for the tool that kicks off run level changes.
I wonder, does it's author have any ties to the American NSA?
Myth: systemd is monolithic.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries are separated out so nicely, that they are very useful outside of systemd, too.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.It never mentioned systemd-logind. Then how about the handy portability chart? For example, systemd-detect-virt, systemd-tmpfiles, systemd-udevd are.
Covered by Interface Stability Promise: Yes
Fully documented: Yes
Reimplementable Independently: No
**systemd Implementation portable to other OSes or non-systemd distributions: No
Well one thing Vim_User was right about that systemd is not just an init system so why do you think it's just something that kicks of run level changes? It's a systemd and session manager, it's not called initd, it's systemd because it's a deamon that manages the system. Now the package includes quite a bit of other stuff like systemd-udev that you would probably have installed anyway that has its own depdencies, systemd-logind that replaces ConsoleKit that you would probably have installed otherwise, systemd-journald that can replace syslog that also has its dependencies among various other things. These are separate binaries and therefore separate processes. They however are not usually packaged separately and most of the can't be used independently (see the portability chart).Originally Posted by hoohoo
Seriously, what the fuck? systemd has been completely open source from the start and it has a large developer community behind it. The author is also a long time open source developer and he works for the most prevalent open source company there is, Red Hat.Originally Posted by hoohoo
Back to Slackware, requiring PAM is certainly one of the reasons systemd is still out of Slackware. PAM has been forbidden to enter Slackware long before I start using it for some reason. But Volkerding seems quite adamant about keeping it out.
I must admit I don't know much on systemd. It seems quite intrusive and I haven't found anything yet that shows it fixes anything worthwhile, though I must admit I didn't look hard. My systems obviously run quite well without it and I don't feel I miss any particularly important features. Any infos would be appreciated.
Advantages from user perspective
1.) lots easier to write init files[20 lines for real badass service] very rock solid and less error prone
2.) habilty to start/stop service ondemand[nginx start only when someone try to access your webpage and goes down after it for example]
3.) resouce jailing and nice level for service [for example, my nginx should have 512mb ram max, nice 20 and X% of cpu use]
4.) start service by specific timeframes [nginx is only available each friday from 3am to 5pm] aka no more need for cron
5.) journald is alot faster than grep[since is indexed] and provide more information than syslog + it can integrate with r/syslog too
6.) freaking fast boot speed and no more init levels
7.) don't require VT but it emulate the needed info to start X very cleanly
8.) easy integration with any session system [ldap,afs,kerberos,radius,unix,AD,etc]
Advantages from security perspective
1.) every process or subprocess is tracked correctly from the origin process and are ended properly after main process is gone, aka no more zombie/abandoned processes
2.) polkit integration allow secure privileges policies per process
3.) process sandboxing through cgroups
4.) secure logs per process in journals with the specific privileges used and timestamps
5.) virtualization aware, yes systemd can tell your an in a virtualized enviroment or not[awesome for devs]
6.) logind finally a proper and secure session system with a very badass API for devs
Advantages from developers perspective
1.) superB API
2.) finally proper and fast child process tracking, yes no more cat/grep/hacksish PID files/dealing with wild child sisegvs/querying half kernel sys tree to be sure all your child die properly/no more bash-perl hacks
3.) proper secure subprocess spawn with feedback control and always under your main PID, bye bye exec() [just with this you can nuke the entire startkde/startx/kdm(the process spawn code) code and replace it with 20 dbus calls]
4.) dealing with services programatically in runtime, aka i can keep a service file in and std::stringlist modify it at will and pass it through dbus to systemd to spawn my processes/services with all the goodies mentioned
5.) finally proper user session way to acess privileges information and proper policy usage with polkit+logind, aka no more querying ENV vars/pid/xsession info to find out the current user and no more su/sudo hacks
6.) Runtime log per process id query, awesome for bug reports and is a lot faster than using rsyslog with sql or grep
7.) secure sub/process de/attach thanks to logind+polkit+cgroups, aka i can from c++ attach gdb to X process and capture the output with 2 or 3 simple dbus calls and in case you need more permission polkit query the user for autorization if needed for you
8.) hardware info tracking in realtime thanks to udev DBUS api
9.) easy to query your process information and all childs using DBUS
there are more features, but so far those are the more meaningful to me, systemd site have more interesting info
Reading about this on the wider web I learn that the guy who wrote systemd also wrote pulse audio. Pulse was a bit of a stillbirth in the end, it seems he needs glory, so ginned up systemd.
There's a lot of passive/agressive posts from him in forums where this thing was discussed - anyone not liking it subtly cast as somehow wrongheaded, or primitive, or otherwise subhuman, or merely incapable of understanding systemd's greatness.
And then here I find teho & jrch2k8 posting omnibus expositions of systemd's advantages. Curiously no disadvantages noted. I am forced to consider the possibility that teho & jrch2k8 are merely cat's paws in a game of propaganda.
Much like I dislike Ubuntu's use on "one runlevel to rule them all", I don't like the gutting of the system mgmt level of the OS and replacing it with brand new code.
It's not that init is good because it's old, it's that init is good because there is nothing particularly wrong with it. Nor was there anything wrong with the old session management stuff.
This is kind of like M$, changing the system middleware in every new release of a server version of Windows. Nothing is really gained by it, and it just means I have to learn a new way of doing the same stuff. I like BASH, I like shell scripts, I like that the UNIX way is text files for config and logging.
i think the base problem is systemd attack a problem that most regular can't perceive because most distros have very dedicated packagers, Desktop Enviroments are really good at hidding the problem and ISV have tackled the issue with very bastardic hacks to make things works in most distros.
Current issues invisible to users:
1.) bash init file are really complex beast in sysv like systems and for most packages maintainers have to heavily modified them to work well in your specific init system for your distro, aka an openrc init file probably won't work unmodified in upstart and won't work in sysV either without a maintainer wasting hours adapting it.
2.) startX/startkde+kdm[the thing that start your kde desktop after you log in] scripts are probably the most barbaric example of extreme branching i ever seen to support every init/session system out there "automatically" but still most kde start issues are related to this mammut of script
3.) KDM well basically every operation check for every possible distro variant in existance, needless to say is damn ugly and slow[gdm ain't pretty either and don't make me talk about xdm]
4.) most developers out there avoid like the plague any linux specific session code to the point is just easier to make a new session system inside your app than suffer through the nightmare of sysV/VT/ENVs/ConsoleKit, thats why most linux apps that require root access for even a small operation have to run under sudo or spawn separated specific processes as root <-- not exactly secure
5.) no sane linux developer will ever try to track spawned subprocess, is just impossible to make it work right in every distro. just make a huge monoprocess statically compiled blob and duplicate the subprocesses you need inside your code or avoid to death spawn subprocesses at all<-- not exactly efficient
6.) make sane installers on linux is impossible, every freaking distro finds amusing have different path for everything important. that is the reason most commercial apps just pick a distro and send everyone else to fly
7.) syslog is a royal pain in the ass to use from C/C++ without a bunch of layers[mostly DE's] since every distro out there find entertaining to modify default socket path/log paths and to put the sweet caramel touch you have like 4 types of syslog servers + stderr that not always points to the distro log path but to the default <-- in the end many devs just make their own log files and dump them somewhere in /var
so this make everyone's life in the backstage a living hell but when it reach you[the user] it almost kinda works all togheter in an kinda good enough way, systemd most important and killer features are for those in the backstage and ISV than the users, ofc users get some sweets too but most is going for backstage ppl and devs that at some will allow all that wasted time to go for more useful things for the user
Last edited by jrch2k8; 09-19-2013 at 09:57 PM.