Removing Libsystemd0 From a Live-running Debian System
lkcl writes The introduction of systemd has unilaterally created a polarization of the GNU/Linux community that is remarkably similar to the monopolistic power position wielded by Microsoft in the late 1990s. Choices were stark: use Windows (with SMB/CIFS Services), or use UNIX (with NFS and NIS). Only the introduction of fully-compatible reverse-engineered NT Domains services corrected the situation. Instructions on how to remove systemd include dire warnings that "all dependent packages will be removed", rendering a normal Debian Desktop system flat-out impossible to achieve. It was therefore necessary to demonstrate that it is actually possible to run a Debian Desktop GUI system (albeit an unusual one: fvwm) with libsystemd0 removed. The reason for doing so: it doesn't matter how good systemd is believed to be or in fact actually is: the reason for removing it is, apart from the alarm at how extensive systemd is becoming (including interfering with firewall rules), it's the way that it's been introduced in a blatantly cavalier fashion as a polarized all-or-nothing option, forcing people to consider abandoning the GNU/Linux of their choice and to seriously consider using FreeBSD or any other distro that properly respects the Software Freedom principle of the right to choose what software to run. We aren't all "good at coding", or paid to work on Software Libre: that means that those people who are need to be much more responsible, and to start — finally — to listen to what people are saying. Developing a thick skin is a good way to abdicate responsibility and, as a result, place people into untenable positions.
slackware users are saying "what's all this then?"
lose != loose
I think it is rather obvious that there should be a way to have more options. Competition is good, choice is good. Can't someone fork a version without systemd? Also, note that other distribution, like Slackware, don't depend on systemd, but the pressure is mounting.
While it all sounds nice, you do realize 99.99% of the population just sort of wants their computer to work. We don't strictly care too much about your love/despise of some piece of software you didn't pay a dime for, didn't invest any time in writing, and then whine about being used/write love stories to. This sort of behaviour is exactly why projects like a Linux distro, or god forbid GNU/Hurd, never make it to mainstream software. I've said this before, and I'll say it again. If you want the Linux eco-system to be accepted start by getting rid of Stallman, write some damned drivers, make an easy to use system that doesn't require 5 hours of Googling on how to get a laptop soundcard to work. If you invested half the energy you folks use for whining about systemd into actually making an alternative available you might actually get something done.
every so often, I try out the various 'desktops' that linux distros offer.
every time, I give up, dislike all the procs running, mem wasted, cpu cycles wasted and all the crap that comes with the desktop. feels like bloat that should not be there, not for a 'simple' linux install.
I always laugh when people look at my display. I use a red/orange color to highlight the active window and grey for the inactive ones. there is no trash icon, no iconbox, no drag/drop. a short menu appears when you click into space (no clients under) and then pick which foreground rxvt opens up (all with black bg's).
I keep things simple. but I've been using this layout for literally over 25 yrs (starting with twm and using mwm for a short while, when motif was still popular).
not having a desktop is great. in all that time, I just have not been limited (at all) in what I can do, and things seem to be fast when I just run a term window, type what I want and it instantly runs.
unix was supposed to be simple. systemd is an abortion and one that most of us do not want.
good to see this protest post with a hand-tweaked system; but the fact is, we should NOT have to flip over backwards to remove a stupid should-not-be-there-anyway daemon and its evil libs.
--
"It is now safe to switch off your computer."
Man, can we just give this a rest? My gawd, I can't believe people have the energy for this. Just go back to an earlier distro before all this stuff and enjoy.
I did just that. It took a few weeks to figure out how to work around all the kinks (as FreeBSD is primarily targeted at the server space), but I'm really glad I did. I have a full Xfce desktop with all of the programs I was using on Wheezy before. Rock solid stability. Might be a bit easier to try PC-BSD to get one's feet wet.
I've also really grown to like all of the new features: ZFS for easy multi-disk mirroring, encryption, and snapshots; pf for firewall rules; etc. There's also DTrace, jails, etc. The integration with the base utils is wonderful, and the documentation is top notch. I've also found the new package system to work as good as apt-get (pkg install {program-name} and you're done.) I liked it enough that I've even started using it for my servers as well.
Definitely give it a try if systemd bothers you as well.
All or nothing? Nearly every part of systemd beyond the minimal PID 1 functionality can be switched out with replacement components. Linux users are supposed to be more intelligent, though if that's the case why is it that so many of them seem to have shoved their head up their ass in regards to systemd? Almost every piece of information in the original post is 100% inaccurate and yet nobody is calling the author out on it.
I love idealists not because I am one, but because they make life bearable for pragmatists such as myself.
Can't someone fork a version without systemd?
There's a fork of Debian without systemd, and there's a project to strip systemd down to the essential parts.
I thought something was off, feels like it's been a week since the last time I saw an article about systemd (not to be confused with all the other Linus articles that are turned into systemd discussions by commenters).
>>>
The introduction of systemd has unilaterally created a polarization of the GNU/Linux community
>>>
Please allow me to correct a little oversight: The introduction of systemd has BILATERALLY created a polarization of the GNU/Linux community...
Good luck trying to fix something when it breaks. You'll find little or no documentation, scripts that call scripts that lead to more scripts, and logs that don't give you any meaningful information. People did fork a systemd free version of Debian and Slackware is still chugging along without it.
Only the State obtains its revenue by coercion. - Murray Rothbard
... In 3,2,1
http://saveie6.com/
The fact that is possible to run debian or any other distro without systemd is enough for me to stay cool. Let's put that effort somewhere else.
We all knew this would happen. Alas, we did it anyway.
We aren't all "good at coding", or paid to work on Software Libre: that means that those people who are need to be much more responsible, and to start — finally — to listen to what people are saying.
When was the open source or free software spirit EVER "Have it your way", like some kind of unpaid Burger King?
You can't vote with your wallet with free software. Unless you pay for it, and my wild guess is most people don't.
If you can code, you can vote. Maybe. If someone accepts your patches. Not everyone wants to make money either.
If you can't code, can't pay, and have a problem with what you get - get a job and/or learn to code.
I agree, but I am having a hell of a time getting over the initd martyrs. Everything I see about this is written like some kind of revolutionary maniphesto.
And this is the IMPROVEMENT, before it was just endless vitriol towards Lennart Poettering whose crime was "writing a software package for free", even though he's not the one with the end-say on what packages go in the distribution.
If they all move to devaun the debian community is going to be getting rid of some of its most vitriolic and insufferable members. I imagine concentrating all those people in one place is going to be disaster down the line but at least they're going to be gone from the forums of the systemd-based distros
If I wanted one program to perform every single imaginable task on my computer, I'd install Firefox.
Here is what I think will happen:
At some point Poettering will piss off Linux enough to get him banned from submitting to the mainstream kernel.
To deal with the problems of no active maintainer of systemd contributing to the kernel, Linus will write his own boot system.
This system will work better then the sysinit system, but not be anywhere near as onerous as systemd.
Peace will return to the linux landscape.
http://imgur.com/gallery/VWUgs...
Sums up how I feel about yet another systemd flame war.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Really, someone should get a dictionary for their birthday and read the definition for "unilateral" lol.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Back in those days, you could remove IE (the browser) without breaking things just fine.
You couldn't remove mshtml.dll, aka IE (the rendering engine) without breaking a lot of applications that used it to display HTML, including other Windows components.
So in that case, what both Microsoft and opponents were saying was true, depending on what you mean by "IE".
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Normally when there are experimental changes made to a software system, a branch of some sort is created, the experimental work is done in isolation there, and if the changes are working well then the branch is folded back into the mainline version of the software.
I'm confused as to why this was not done when integrating systemd into Debian.
Why did something as experimental and potentially disruptive as systemd go into mainline Debian so quickly?
Why wasn't a separate fork created of Debian, like was done for Debian/kFreeBSD, with all systemd integration happening there? If, a few years down the road, this fork was doing well and users liked it, it would become part of mainline Debian.
I find it really odd that people keep saying that there should be a fork of Debian without systemd. But that makes no sense. It should be the other way around. Debian was well established years before systemd was even conceived. So Debian should have been left as it was, with a fork of Debian being created with systemd.
It got me to put FreeBSD on my to do list for 2015.
All the criticism of systemd is not strictly from a luddite perspective. There is a population that appreciates meaningful advances (Wayland, btrfs, even some facets of systemd), but doesn't like some of the compromises systemd has employed to achieve their goals. Getting stuck in a point of time before systemd is not a desirable result, and in fact systemd might be able to win over some detractors if they recognize criticism and make sensible technical solutions to those rather than continuing to say 'oh everyone loves it except some impossible to please luddites'. For example, journald could embrace native text logging with external binary metadata and deliver all the goodies they provide and quell all the (justified) bitching that human readable logging is a second class citizen in their model.
They may not be able to accommodate all the objections (e.g. the amount of complexity they *must* do in pid 1 to have guaranteed comprehensive service management without blindly applying namespace isolation everywhere that would make a system look even weirder/risk breaking some services), but they could come a long way.
The issue for many of us is that things are being implemented that go beyond what systems administrators can follow along without understanding how to be a more robust software developer (and even then, there's some loss of convenience in analyzing things compared to an interpreted language). Systemd design shifts focus on specialized tools that are better at their specific task, but less reusable in similar contexts. If I started with syslog and learned 'tail -f' will let me watch logs, then I have acquired knowledge that can be used the next time I encounter logging output. If I learn 'journalctl -f', then that knowledge does not transfer to the huge number of other applications that do logging. It's a small example of things that in aggregate pose a significant challenge.
An administrator faced with a 'classic' design won't know everything about the system, but can get far with 'set -x', 'find', and 'grep' because the configuration, logging, and much of the 'glue' code is in clear text, and communication between programs usually hits the filesystem in fairly specific ways. Now with things like systemd and dbus, 'invisible' things happen (well, overly generic communication channels and compiled code). When the kernel implements new awesome stuff, it frequently manifests in sysfs, which is nice and discoverable. Advanced functionality that adheres to the 'everything is a file' and generally presents and accepts simple utf-8/ascii data. Not everything in the kernel does that, sometimes it creates obscure devnodes with ioctls instead, but it's a common and good practice in kernel land.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components. While certain concepts can be specifically be done better (e.g. journald does better than windows event framework), the emergent behavior of Windows that becomes impossible to overcome by administrators isn't really due to those specific things.
XML is like violence. If it doesn't solve the problem, use more.
TRIOS is based on Debian Jessie, systemd removed https://foss.rs/threads/trios-... DL link: http://mirror.org.rs/image/TRI...
I can't understand why people are asking developers to stop working on systemd or even abusing them. Anybody can develop software, useful or not, system-d or system-that. Why not putting some effort into convincing distributors, especially server distributors, to use more administrator friendly init-frameworks.
I don't believe lkcl wrote this. It has capital letters and punctuation, plus some of the words are spelled correctly.
Not his style at all. I call a fake !
Choices were stark: use Windows (with SMB/CIFS Services), or use UNIX (with NFS and NIS).
Novell Netware was still a player back then.
I didn't like (and never used) Pulseaudio either. If I wanted to play sound over a network I'd share my media directory.
Networked sound playing is just an incident of pulseaudio being a sound router. It's a nice feature, but that's not what pulseaudio was basically written for.
There are lots of situations where sound is routed to something which isn't the usual ALSA driver:
- lots of headphones/microphones now are USB. They are not another channel on the same soundcard, they are a completely different sound driver. Switching when pluging a headset is not something which is trivially done in ALSA without special support of software.
- bluetooth, which is VERY common on portable devices (but also might be usefull on dekstops) isn't even a kernel driver. Sound is handled by a deamon communicating with the bluetooth stack. It has much more in common with networked sound than with ALSA.
- recording the output of another program becomes much more trivial if there's a sound router handling the redirection, instead of needing some special support in software.
What I wouldn't do is run an unnecessary audio layer requiring application support - and that can do nothing else - in the form of a sound daemon I never wanted and didn't ask for.
Pulseaudio doesn't require any special support. It can present an ALSA target to any ALSA-enabled software. Most current software don't even have a pulseaudio plugin, they just open the default ALSA device which happens to be one pulseaudio listends to and that just works.
Software mixing you say? It's called dmix.
Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ?
I prefer to run unnecessary things like sound as daemons in userspace. Thank you very much.
I moved away from Windows and towards open source years ago in order to have choice.
And you're still free to disable pulseaudio and use dmix instead, if you want.
Now indeed, for an init system, it's a bit more complicated to leave complete choice to the end user. Some specialist distro like Gentoo are able to offer you to switch between their default OpenRC and whatever you want.
But the amount of work and risk of bugs in untested paths is rather high. So don't expect other distros to offer instant switch between systemd and upstart.
I will have that choice whether or not most major distributions gargle the Poettering cock.
Instead of being vulgar, maybe you should ask yourself why so many distributions are switching to systemd.
Maybe, part of the reason would be that systemd solves actual real world problems that these distributions need fixed.
Maybe that's because systemd people and Lennart Poettering actually ship code, instead of just sitting the whole day bitching and cursing on internet forums.
Maybe if you didn't spent all your energy on whinning about systemd, and actually tried to *DO* something, to *FIX* the problems, and write an actual good solution, maybe your solution would be the one picked up by distros.
Also please try to avoid making confusion between the actual piece of code that runs as PID 1 (which is indeed confusingly called "systemd") and all the other pieces of code that add the functionnality mentionned in all systemd articles (these pieces of code are all members of a project which is also called by the same name "systemd", but all pieces of code are completely different deamons like "networkd", "journald", etc.). In other words, it's not the PID 1 that get stuffed with innapropriate functionnality. It's the people who wrote the PID1 that are also writing other daemons for extra functionnality, all different parts of the same project.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The other day I found out that it's impossible to use yum on a Red Hat machine with an expired RHN subscription. It proved quite unpleasant to work my way around it, as wget was not installed.
Pretty soon we'll need a valid subscription to start daemons, something made possible by "improvements" like systemd.
This subscription model is becoming quite the rage (Microsoft, Adobe, Red Hat, etc) and this is leading real fast to absurd situations like in the novel from Philip K. Dick (Ubik) where the guy has to pay a few dimes each time he wants to use the door of his apartment.
lucm, indeed.
I was in a meeting last week with some representatives of a large defense contractor and Microsoft. The two of them don't get along well. The defense contractor people (not the MS people) brought up the whole systemd thing as an equalizer between Windows and Linux, and not in a positive way.
The bottom line is that I have a hard time believing it, but Microsoft is actually making inroads in the server market again. Linux adoption where I work is pretty much stalled, and the things it is used for are mostly virtualization hosts, rather than stuff that actually performs a function. While the systemd thing is just a tiny blip compared to the other reasons this is happening, this shit does not help.
I'm also not going to waste my own capital evangelizing the OS if significant engineering effort is going into something that is, at least in the short term, reducing the reliability of the operating system. That's a stupid idea and pissing off your evangelists is, too. Everyone forgets where the market share came from...and figures that it is fungible with whatever stupid follow-on idea they have, once they have said share.
Red Hat is about to learn this the hard way.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
RedHat.
And the design of systemd which means systemic and wideranging changes in many packages making "not systemd" a large change in programming. If systemd were not being pushed by RedHat but by, for example, a bit player like Gentoo, then the widespread changes would stop it working. See upstart for another example of a wideranging change that wasn't pushed by a big enough player. But once it starts being done, either others have to backport or fork or conditionally code in systemd use or they have to use systemd.
And at that point, it's not "choose systemd", it's "choose not to maintain a fork".
A very different kettle of mackerel.
"with libsystemd0 removed"
It's clearly about libsystemd.
Perhaps there is an underlying secret purpose in implementing SystemD, similar to the hidden purpose in saying TrueCrypt is insecure and trying to get people to use Microsoft encryption software.
We don't want it. Get over it.
That's what it comes down to for me: Does it work?
I honestly don't care about all the bleating and bitching about systemd vs. traditional startups vs. makefile startups vs. whatever-the-flavour-of-the-week is. What I care about is whether it will run the software I use, which is essentially Java, Eclipse, Ant, and as many databases as will install on the system (if it won't install on Linux, I can run it on my Windows laptop, and do.)
While I consider myself a "developer" because I do a lot of hobby programming, I am not and never have been responsible for system administration. My system never boots unattended as is the case with virtual machines in a cluster, so the issues people have raised about logging and such just flat out don't matter to me.
If I'm concerned about anything, it's about issues like the instability of the latest NVidia drivers that Debian pushed for Squeeze. While my system used to stay up for weeks at a time, the display drivers now crap on the system more than once a week. That's just flat-out shameful when you consider that I only have to reboot my Windows box once a month to apply patches nowadays.
Systemd? Couldn't care less.
I do not fail; I succeed at finding out what does not work.
Meh. Those who know don't talk and those who talk don't know. Sometimes it's coordinated evil, sometimes it's just a single idiot who manages to gain influence by a combination of dumb luck and people being to disgusted to argue.
We aren't all "good at coding," but we know what init system we want.
We aren't all "doctors," but we know we don't want vaccines.
We aren't all "scientists," but we know global warming is a hoax.
I cannot be the only one sick of seeing this crap posted over and over. systemd is being implemented in distributions because a) it is good and b) the people making that decision are the ones qualified to do so.
It's possible, but it seems a bit conspiracy-theorist to me.
One good thing about a startup daemon that controls everything is it's much easier to compromise than a hodgepodge of manually configured and custom tailored systems. With systemd it's target once, compromise everywhere.
look at the title of the summary for the answer. the rest of the so called "summary" is just a list of flamebait links and commentary, its not even a summary of an article
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Six whole people voted and the tie had to be broken by the chair. Not exactly a powerful mandate.
Why the fuck do you want to round a *sound mixer* inside your *kernel space* ?! Do you run your video decoder and webbrowser there too ?
Because musicians also use computers, and latency -- which is higher if you're going through user space -- is a big no-no. While some latency is acceptable, any trained musician will easily hear 5 ms latency if he's recording, especially with voice. Since FIR filters and the hardware audio chain already add latency, there's really no room for the mixer to add much. Pro audio is actually a major application for real-time Linux kernels: https://wiki.archlinux.org/ind... And saying "but only musicians need this" would totally miss the point that almost everyone starts as hobbyists and amateurs, and the capability should be there already, especially because it's not a big problem to have it -- in-kernel mixing has been available for a long time and works fine.
"Politicians and diapers must be changed often, and for the same reason."
Really, someone should get a dictionary for their birthday and read the definition for "unilateral" lol.
that's in.... *counts on fingers*... 9? days? :)
ok so let's look it up... a random google search shows these:
1. Of, on, relating to, involving, or affecting only one side: "a unilateral advantage in defense" (New Republic).
2. Performed or undertaken by only one side: unilateral disarmament.
3. Obligating only one of two or more parties, nations, or persons, as a contract or an agreement.
4. Emphasizing or recognizing only one side of a subject.
5. Having only one side.
6. Tracing the lineage of one parent only: a unilateral genealogy.
7. Botany Having leaves, flowers, or other parts on one side only.
yep. definitions 1 through 5 are perfectly relevant. unilateral. meaning that pottering made the decision and (2) did not consult any of us. he claims to be "listening to users" yet (4) in fact ignores everything they tell him and carries on regardless. he has therefore violated the implicit software freedom contract (3) between users and developers who choose to be of service to others.
so yeah. it would appear that yes i really do know english, if only by accident.
You nailed it and it's perfect; there's nothing to add. GG
"Politicians and diapers must be changed often, and for the same reason."
"Posting anonymously (and behind seven proxies) for obvious reasons." - yes, because your post is highly embarrassing for you. not a fact or citation in view to back up your post
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Ran an update, a bunch of packages are now in a weird dependency loop with systemd fingered as the culprit.
I could solve it, but I'm not paid to give a shit about systemd, so when I get some time I'm just going to replace the instance with CentOS-derived (but systemd lacking) Amazon Linux -- it's the first time I've ever chosen to move a machine off Debian. A decision I'll be making... about as many times as I have Debian machines left. Failure has consequences; better luck next distro, I guess.
Yahoo! Pipes are awesome. How awesome? http://pipes.yahoo.com/jesdynf/slashdot
https://lists.dyne.org/lurker/...
re all,
Here is a pre-alpha sneak preview of Devuan at the current state of
affairs. It is my valentine to Franco: despite we probably never met in
person, I love him. He is really dedicated to this project and putting
hard work in it. I also fell in love with another VUA, whose name I
won't tell, but he is the one hosting the gitlab, running very well.
http://mirror.debianfork.org/d...
http://mirror.debianfork.org/d...
http://mirror.debianfork.org/d...
do not use this in production, this is an internal preview (not even an
alpha) for the Devuan enthusiastic community and for those wondering if
we'll really make it: yes we will.
Journalists and DWN editors reading: please do not link this. We will :^) Let it be a private valentine
have another more public release soon
Also please note that this is not yet rebranded, so it says Debian
almost everywhere. Didn't find the time for that yet.
default user is 'devuan'
password is always 'devuan', also for root
sources are those of Debian 8 RC1 jessie
plus the mods here: https://git.devuan.org/groups/...
and packed with the SDK https://git.devuan.org/devuan/...
happy hacking
--
Jaromil, Dyne.org Free Software Foundry (est. 2000)
We are free to share code and we code to share freedom
Web: https://j.dyne.org/ Contact: https://j.dyne.org/c.vcf
GPG: 6113 D89C A825 C5CE DD02 C872 73B3 5DA5 4ACB 7D10
Confidential communications: https://keybase.io/jaromil
---
Pretty fucking boss.
Systemd is as worrying to me as the next user, especially since there are *still* stupid PulseAudio bugs that have persisted for years since Lennart got his hands on the audio system. But since I don't have the time or inclination to write a better alternative, I'm just sitting back and watching the show, and therefore I guess I need to be OK with the outcome.
(Boilerplate warning - this info is as of 2015-02-16 only, this info may be incomplete or incorrect, this may not work for you, or your environment)
For wheezy -> jessie users who do not want to manually compile packages AND keep systemd out of the system.
First, go to "options->preferences" menu on the aptitude and uncheck "Install recommended packages automatically" checkbox(or do equivalent on synaptic). This will also make your system more managable(stops installing unwanted packages).
Then HOLD OR DOWNGRADE POLICYKIT-1 PACKAGE TO 0.105-4 - this is the last version that don't depend on systemd related library. If you don't have this version, get this version manually from net and install it using dpkg.
I think all bad things starts from this package. - if you hold this(and be careful), you'll still be able to enjoy many of the improvements of jessie without installing most of the systemd crap(even systemd-shim). After this, there will be 2 problems left to your general desktop user experiences.
One is about login environment -> this relates to the fact that not long ago most of the display managers(gdm3,kdm,lightdm) became dependent on logind included in systemd(again corrected in kdm,lightdm so these 2 are safe again) - if you're paranoid, just use slim or wdm or xdm(since these 3 are ugly, you'll need some additional tweaking) instead and DON'T FSCKING USE GNOME3(gone are the days when one can install gtk/part of gnome2 libs only freely to use standalone(not gnome related) gtk2 programs. Gnome3 become more intermingled like windows) or XFCE4(core functions of xfce depends on libpam-systemd). If you are using LXDE, don't install lxde task since this depends on several packages which again depends on systemd. Install lxde-core task instead and invidual packages you want to use on LXDE(oh, and get/tweak pygtk-shutdown from net instead of existing shutdown button of LXDE to enable shutdown/reboot). Other simple WMs don't need to worry(just worry about DMs).
The other is printing. CUPS on jessie depends on colord which depends on libsystemd0 and policykit-1 so unless you use CUPS on wheezy version there is no simple way to prevent libsystemd0 from being installed on your system, but you can still prevent other systemd crap if you hold polcykit-1(systemd, libpam-systemd, etc.)
Packages to avoid like plague - policykit-1(0.105.5 or later) - Unlike others who are helpful about reducing unnecessary systemd dependency, the maintainer of this package is vehement about keeping libpam-systemd(and dropping seemingly still working consolekit) dependency to this nearly essential package for desktop(see bugreport #747105 yourself), libpam-systemd - this package depends on systemd directly even with systemd-shim present on system.
"Your stuff is a f*cked up as Windows, so we might as well use Windows."
At least FreeBSD does not puke over POSIX, or the UNIX philosophy.
At least FreeBSD is not a hostile take-over by a $10 billion corporation trying to enforce vendor lock-in.
I think all the systemd advocates should do the same. Either OSX, or Windows.
If you want proprietary, go proprietary. Let a big corporation make your computer decisions for you - it's not worth the bother. Screw log files and the other crap, let the sysadmins deal with that.
If you hate POSIX, and the UNIX philosophy, then please go away, and leave us real UNIX/Linux people alone.
and hardware audio acceleration
Yup, Amiga had hardware sound mixing (4 channels in this case. that's where 4-channel MOD where born from).
PC from back then had some form too. (High-end sound cards like Gravis UltraSound were basically multi-channel, like souped up version of Amiga. Creative Sound Blaster AWE could mix samples as part of their wave table synthesis or even stream "instruments" from the main RAM, i.e.: actually stream a second audio track and mix it - that's what most player back then used to do to avoid grabbing and locking the "waveout". Starting from Creative Sound Blaster Live! each software sending its own separate stream and the card mixing them was the norm, ...)
Hardware sound mixing was the norm on most high-end gaming machines. It's only recently that "only a glorified DAC" that were common on laptops and office box started to become the norm in high-end stations, once the CPU had enough omph that sound processing become an insignificant burden.
Hence the need of sound mixing daemons, hence the rise of pulse audio in linux world and hence the equivalent whose name I've forgotten in Windows.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
... Because I need less than 125 microseconds mixing processing latency (12 samples at 96 kHz) so that in-ear monitor mixing for live performance can be useful - requires a total latency from microphone to wireless receiver to CPU to processing to wireless transmitter to in-ear monitor of less than 5 ms.
If low latency in professionnal audio setting is your target, then there's already specialized software for that: JACK.
It's specially designed for what you want, and as widespread usage in the field.
Or might as well go for a hardware solution.
Use the right tool for the right job. Otherwise you end up trying to cram extra requirement into a tool which wasn't designed for it.
There are even special distribution which are geared toward pro needs and are tuned with this kind of tools.
(Dynebolic as an example)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Is SystemD and these related libraries going to actually be more secure? It seems like init scripts were not a source of disaster earlier. The kludgy if-then scripts, while somewhat embarassing, seem predictable enough in their effects. I wonder if the converting of this idiosyncratic system into one big spaghetti monster will create more vulnerabilities.
Is the logging too verbose like a firehose to follow what's important? And would this help them charge money for DevOps? Where has the center of this conversation been? Without digging around Slashdot seems to be the only venue this gets any attention. Is it a result of centralization in the open source world, wherein relatively few people decide the fate of upstream distros?
Even if it works fine and solves some major problems, still: what can be done to decentralize the open source world? Can maybe SystemD get a kind of POSIX like clearly defined set of functions, and truly be made hot swappable for something less bulky and possibly devious? What would it take to unplug or supplant SystemD's role in GNOME?
--hongpong.com
It's always sad when these things happen. Personally, I'm not fanatical about this issue, but I hate it when I am dictated what to do and think, and how to work - this was my main reason for getting off Windows ASAP, and then later GNOME.
What makes it so sad is that it used to be fun - I loved playing around with DOS and later Windows, and even enjoyed programming for Windows 3, but I stopped enjoying what I was doing when they got imperialistic. The same thing with GNOME - when they started on 'simplifying' things on the desktop by taking away options and dumbing down the interface (a better way would have been to allow a form of expert mode - those of us with that ambition would be happy with vi and a config file).
And now this? I honestly don't mind, unless it forces me to use other things that I don't want, or gets in the way of what I do for a living. One of the things that annoy me at the moment is the drive towards turning Debian into a laptop/tablet OS, with lots of automatic crap going on as you log on to the desktop: network manager and the whole 'semantic desktop' or whatever it is called. It may make sense if you live your whole life on a portable device with wifi and USB, but I work on servers and I want my desktop PC to be a server with a desktop for convenience; I have no liking for tablety fashion statements.
Ironically, I chose Debian because it tends to be conservative, focused on SW freedom, but it worries me that they've recently looked like they're getting into bed with the GNOME crowd and now also systemd, if I understand things correctly. The fun - not to mention my ability to be productive - is under pressure.
>>... destroying my business by losing access to all data on a critical business laptop ...
You should backup.
And also do experiments on a test computer.
aaaaaaa
I'm pretty sure some of the "pro-systemd" stuff from AC's is actually trolls. (You know, the crazy "stderr is for losers" rubbish).
I bet a lot the the "Fuck Lennart" stuff is trolls too.
Watch this Heartland Institute video
It clearly is about systemd. Here's another hint: what is libsystemd about? That's right: systemd.
No. libsystemd0 is about interfacing to systemd if systemd is pid 1. If systemd is not pid 1 then libsystemd0 is a no-op.
Luke has put himself to a lot of hard work to remove a no-op.
Watch this Heartland Institute video
Systemd is decidedly far less secure against a competent attacker. It has its fingers in so many places, local privilege elevation will be easy. It has network connectivity, which is about the most stupid thing security-wise you can do for an init-system. It has excessive feature-creep, and that means it is in active development all the time, with new vulnerabilities added constantly.
You are right, SYSV-init does not actually have any real security problems, and that is due to its simplicity and age.
My personal take at this time is that this is possibly intentional. Linux may have gotten to hard to break into for the surveillance-creeps and systemd may be an attempt to fix that. Sure, it will take a few months, or maybe even years for the catastrophe to become obvious.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Here's a little hint.
If you don't want systemd on your Debian servers then install sysvinit.
That was hard, wasn't it?
Watch this Heartland Institute video
Distrowatch keeps tabs and gives links to almost 300 distros. If you still can't find something you like, you can build your own Linux with only what you want, and nothing else.Rolling your own is surprisingly not all that difficult.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
So... you're seriously saying that system's *optional*, pure-C dhcp client is somehow less secure than ISC dhcpc, which relies on *shell scripts* to actually do anything to the running system -- and has been the subject of numerous vulnerabilities to date?
You are right, sysv-init does not have any real security problems, because it doesn't actually do anything. sysv-init, it relies on a hodpodge of other utilities and shell scripts nested like Russian dolls, and those are *still* turning up problems, with more being introduced all the time as new features and requirements are shoehorned into the bloated, creaking mess.
I swear.. you're objecting to a system that *might* have vulnerabilities, and advocating in favor of sticking with one that has had many, and whose very design (or lack thereof) virtually guarantees there will always be more to be found.
Every single technical objection I've seen to systemd (even the valid ones based on facts, not conjecture) apply even more so to what systemd is trying to replace.
And people wonder why we're moving to FreeBSD instead of making our "reasoned arguments" to get systemd's flaws fixed...
Systemd does not mess with the firewall.
Sure, people are working on that,
Systemd does not mess with the firewall... yet
Look, this is another one of those cases where how something is done and who does it are just important. In theory, we should have all that stuff unified somehow. In practice, this is not the person to do it. Also, this is probably not the way to do it. More message passing, less taking over everything. Enhancement of existing projects, not replacement of them with hastily-developed and poorly thought out replacements. That's a step backwards.
I'm not even in theory against adopting systemd one day, when it's mature. If that ever happens. It's not time to implement it everywhere. The right place for it to be right now is Fedora, which is where Red Hat tests new stuff before it goes into RHEL. It doesn't belong anywhere else yet, save for other Fedora-based distributions. Why you'd want to be Fedora-based when you could be CentOS-based I have no idea, but I guess that's a separate rant.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"If I wanted one program to perform every single imaginable task on my computer, I'd install EMACS" - FIFY
Your thin skin doesn't make me a troll
That is like saying "don't like OOXML use something else."
The dominate players have a lot of influence. Red Hat is connecting everything to systemd. Why is udev now part of systemd? Why does Gnome3 require systemd?
What is going to be next? Once Debian goes systemd, Red Hat will have much more control over everything in Linux.
I expect Debian to gone completely.
Soon enough, Red Hat will decide that Linux should be standardized on one package management system. Systemd will only work with RPM.
Red Hat will say this was done because of user demand, and that only luddite grey beards are complaining. Red Hat will say that Linux package management was broken, because of two many choices, and this had to be done.
When this happens, there will not be much unique about Debian, so who needs it?
If that actually works at all, it won't for long.
Once Debian switches over to systemd, Red Hat will have total control. And Red Hat is determined to have systemd everywhere, and to have everything dependent on systemd.
Enjoy those little tricks while they last, they won't last long.
You must not know many admins.
Every admin I have ever known, including myself, must adjust to constant change, it's part of the job.
Systemd is not just a change. Systemd is an obvious embrace-extend-extinguish strategy. Systemd is all about Red Hat monopolizing Linux, and forcing vendor lock-in on Linux users.
The introduction of systemd has unilaterally created a polarization of the GNU/Linux community
Citation needed. It seems to me the polarization has been created in the Debian community by the anti-systemd crowd. Instead of fixing the problems that resulted in systemd acquiring more of the Linux user-space functionality, or work actively towards supporting multiple init systems, they continually claim that there are divisions in the community created by the systemd developers.
This doesn't seem to be an issue in other distributions.
Redhat employs Lennart. Just email them to complain. Also mail the people of your $distro to reconsider.
I have been testing FreeBSD lately. For servers, FreeBSD is awesome, beats systemd-linux up and down.
For desktops, sadly, FreeBSD seems to have hardware compatibility issues. They tend to be smaller issues, but annoying none-the-less.
What is so hard to lock down?
HTTPd: Only run it on 80 or 443 on the system.
FTPd: only use port 21.
SSHd: only use port 22.
SMTPd: Only use port 25.
BIND: Only use port 53.
Close off every other port on the server that you don't need. If the ISP blocks the above ports, use port forwarding on the router to get around it and leave your daemons running on the standard port. There's still a good majority of us that use Linux for servers. These are the people who do not need or want systemd. These are also the people that the big distros are not listening to and making systemd a one size fits all. Keeping systemd on a desktop distro is fine by me. Keep it off my servers.
Why? What will stop it working?
"Once Debian switches over to systemd" -- It already has for Jessie, and that command does work in Jessie.
Watch this Heartland Institute video
... so I took a blow-torch to my car to remove the hardpoint to which one can attach a towing hook.
Clearly the presence of the hardpoint is all part of the caravan club's conspiracy.
Having removed the hardpoint I can rest easy that I won't find myself suddenly towing a caravan.
OK, so the structural integrity of the chasis is somewhat compromised, and I'll probably end up losing control of the vehicle at some point as a result of that, but the risk is totally worth it to avoid the risk of caravan infection.
I really don't know what the designers were thinking. How could they inflict this creeping caravanism on me by making the structure at the back of my car confom to caravan-club standards?
=-=-=-
As for libsystemd0, for a sane view read:
https://lists.debian.org/debia...
Debian: GNU/Linux done the Linux way
systemd is not just an init system. systemd is a GNU replacement. Run systemd/Linux or GNU/Linux, but don't pretend that the two operating systems are one and the same. They are not.
systemd is not an init system. It's a GNU replacement.
No, you cannot 'unilaterally' create a condition between two groups of people. You can DO something unilaterally, "The introduction of systemd has unilaterally created a polarization..." is a misuse of the word. The EFFECT of what systemd did was a polarization, in which BOTH PARTIES moved further away from one another "towards opposite extremes." Polarization cannot, definitionaly, be unilateral. Its crappy writing. I suppose complaining about crappy writing on /. is like complaining about the smell of sewage on a particular day, but so be it.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Because that's exactly where it should be. {...} Stupid, but initially the whole whole rationale behind PulseAudio according to Poettering was to make mixing work and no software mixing code would be accepted in the kernel, which is odd, because no one had ever tried.
Hey, while you're at it, why not including also a JPEG decompression in kernel? That's useful for Webcams! And throw H264 while you're at it! That's gonna be great! except... not.
Such a hackish idea was actually done with some newer USB webcam drivers in V4L. Once resolution increased to 640x480 and above, USB webcam, in order to circumvent the limited bandwitdh on USB 1x, started compressing frame as JPEG in hardware and streaming the compressed stream to the PC.
Back then, the only way to get useful output out of V4L (designed to provide raw images like on older cams) was to embed a whole fricking JPEG decompressor inside the kernel driver (that's what the spca5xx driver did back then).
The thing wasn't the most stable thing ever. The jpeg decompressor wasn't very resilient and fault tolerant. If USB transmission got corrupted, the decompressor could barf. That barfing happenned while in kernel space.
Luckily, V4L2 was later introduced, which also handle compressed stream, and nowadays all the peculiarities are hidden behind a user-land framework like gstreamer (which handles the dirty low-level interraction behind the scene. Including compressed streams, including non-USB webcams like firewire, etc.)
Same goes for sound:
mixing is a rather high-level task which should be kept out of the kernel into a separate userland daemon, because that's the sane solution.
You DON'T try implementing rsync in kernel space. Only block devies and filesystem. Higher level stuff goes into userland software.
You ONLY implement in-kernel webserver as a proof of concept or for some corner cases. Apache and the like remain separate stacks.
Thus:
You keep video decompression and sound mixing out of the kernel too.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Why you'd want to be Fedora-based when you could be CentOS-based I have no idea,
Um, I don't think this is hard to understand. CentOS is just a rebranded version of RHEL. RHEL is basically like Debian Stable: it's slower and more conservative. Fedora, as you just said, is where Red Hat tests new stuff before putting it into RHEL (much like Debian Testing or Debian Unstable). So if you want your distro to be a little more cutting-edge, you'd base it on Fedora, not on CentOS. If you want your distro to be more conservative, you'd base it on CentOS, not Fedora.
You don't even need a test computer, all you need is another laptop hard drive. Laptop HDs are usually brain-dead-easy to replace, usually just with one or two screws. On my Dell Latitude, there's two little screws holding it in, plus a plastic bezel part that screws to one side (and replacements are available for a few dollars on Ebay). It's simple: just pop out the regular HD, and put in your testing HD, and use that for your experiments while your critical data sits safely in a drawer.
Of course, not having any kind of backups is still pretty stupid. At the least, just get a portable USB hard drive and back up to it periodically using rsync.
Um, I don't think this is hard to understand. CentOS is just a rebranded version of RHEL.
It's slightly more than that, but yes, that's the idea.
So if you want your distro to be a little more cutting-edge, you'd base it on Fedora, not on CentOS. If you want your distro to be more conservative, you'd base it on CentOS, not Fedora.
If you want your distribution to be on the bleeding edge, etc etc. CentOS may be stodgy, but at least it's a stable base. I don't care for rpm, so I use Debian anyway. And so far, Ubuntu, but I'm planning to change that up here in a bit when I just decide which way to jump. Maybe gentoo since I have all these amd64 hosts now.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
BeOS. Well I say major in terms of technical achievement, not market share sadly.
BeOS was able to play an MP3 while browsing the web and chatting on IRC and still burn a CD without making a coaster
Which was, by the way, the motivation for Palm buying BeOS: for their technology, to use it as a way - for exemple - to play MP3 in the background of very low-power machines that were not even designed for multitasking.
And thus some of the multimedia component made it into PalmOS 5.x
Saddly, Palm themselve didn't manage to stay successful.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]