Slackware, Crux, Pisi, Manjaro, Devuan… Freedom-Fighters Or Luddites?

I’m not alone in disliking systemd. It’s not because systemd is an innovation. I like change and improvements of all kinds, but systemd is a power grab and I don’t like those.“Systemd is a power grab. It puts more or less the entire community into the hands of one Corporation. The rug has not been pulled from beneath our feet yet, but now almost everyone is standing on the same rug, so to speak, and as such are now vulnerable. A license change is all it would take. Or perhaps Red Hat might declare that systemd will be free for home use but must be paid for in commercial settings. Whether they intend this or not is beside the point. They are in a position to do so. This is a colossal weakness for every distro.” I chose FLOSS and GNU/Linux because they were different than dealing with the monolith of that other OS. They worked for me. It’s wrong to make all of FLOSS dependent on a single piece of software besides init or Linux or the basic libraries but that’s what’s happening.

Recent projects of mine have included migrating back to Wheezy (Debian’s “stable” release) from Jessie (their “testing” branch) because it’s too buggy and most of my problems were tied into systemd and pulseaudio, both designed by the same guy, Poettering. Systemd wants to take over the world making all kinds of stuff dependent and pulseaudio is a weird mix of X and an audio-server. Both break the UNIX philosophy of doing one thing well. Both convolve two or more things in a way that makes systems difficult to handle. I’ve set up hundreds of thin clients and never had any problem with esound and X, both doing what they do and leaving the other alone. Debian is supposed to serve users and one package is supposed to leave the others alone. Debian is going astray. Unless they wake up, many loyal devotees of Debian will move to other distros that do IT the right way. I’m a little old to be distro-hopping but even I can see the necessity of escaping the entanglement, the single point of failure, and the loss of control that systemd represents.

See A Devuan and A-two….

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , , , , , . Bookmark the permalink.

14 Responses to Slackware, Crux, Pisi, Manjaro, Devuan… Freedom-Fighters Or Luddites?

  1. oiaohm says:

    ram there are a few pro audio distributions based on debian jessie.

    There are a huge stack of issues that Window users put up with. Where X application will not work with Y application with audio. This is not behavior you find on Linux or OS X. Ok you find this behavior on Linux when you are running pure Alsa.

    And Apple don’t use PulseAudio.
    Apple paid for developers make Pulseaudio work on OS X for network transferring of Audio. Coreaudio Apples core stack is great for local audio completely worthless for network transport.

    The reality here your two choice on Mac is pulseaudio or jackaudio when you require network transport.

    Because it’s an unmitigated bit of FLOSS festering failure. That’s why.
    This is DrLoser being his normal moron who has not done any research. All the commercial options todo these particular things are dead. FOSS has killed out there competition here. Closed source has been a complete festering failure at doing particular things.

    Does every use need all the features Pulseaudio provides the answer is most likely no. Pulseaudio and Jackaudio are your two solutions for when you need more feature in audio than your OS provides. Unless of course you are a Linux Desktop user who has those features already.

  2. ram says:

    Curiously, Debian Squeeze, seems to be the last Linux distribution that is stable enough for professional media creation. I’m glad Debian has forked — it was long overdue.

  3. DrLoser says:

    When it works, of course. I had Miley Cyrus going full-bore on the thin client briefly. That’s the only problem I have with it.

    Not sure which of the following you regard as “the only problem,” Robert:

    a) Miley Cyrus
    b) Miley Cyrus full bore
    c) Miley Cyrus on a thin client (no sniggering at the back there)
    d) Miley Cyrus, “briefly.”

    No doubt you heard all the best bits anyway. We’re talking Miley Cyrus here — not Charles de Gaulle, Richard Feynmann, or even the Collected Wisdom of Daffy Duck.

    … or …

    e) “When it works, of course.”

    This is audio we’re talking about here, Robert. It’s not a ram-jet. I can see how fluctuations in the environment will take down a ram-jet. I fail to see how fluctuations in the environment should, in any acceptable way, take down an audio stack.

    Unless said audio stack is an unmitigated bit of FLOSS festering failure. Which pulseaudio evidently is.

    Fun fact: The original name for it was “polypaudio.” As off-putting names go, this one has to take the cake.

    ‘Scuse me, I’m off to put my Gimp mask on … or perhaps not.

  4. DrLoser says:

    .The sad reality is Windows users having failing audio output is about the same percentage as those who have failing pulseaudio in upto date distributions today.

    And naturally you have a cite for that, oiaohm.

    Look, in some instances, there is a good case to be made for what Robert calls “monoculture,” which is a fancy way of describing a single entity in charge of a particular bit of architecture.

    You don’t even have to look to Microsoft on that point. How about Apple? Apple is equally a monoculture, particularly when it comes to parts of the system that generate huge profits.

    And Apple don’t use PulseAudio.

    Because it’s an unmitigated bit of FLOSS festering failure. That’s why.

  5. oiaohm says:

    It’s an awful piece of FLOSS dreck, isn’t it?
    Same was said about OpenOffice and may other things.

    Reality here is when Pulseaudio works is great. When it crashes its not. The cause of Pulseaudio issues is nothing more than lack of proper QA processes. Easy to spot.

    The sad reality is Windows users having failing audio output is about the same percentage as those who have failing pulseaudio in upto date distributions today.

    Interfacing with thinclients is a undertested area.

    Robert Pogson does insist on using X11. pulseaudio over network is know to be trouble in many ways. Worst is the amount of bandwidth it consumes. X11 over network is also known for being a bandwidth hog. X11+pulseaudio eqauls either X11 server crashing or pulseaudio crashing due to lack of network traffic. Newer versions of pulseaudio are getting less likely crash when network transmission is not possible but it also results in outputting crackling.

    Please note the Pulseaudio crash rate is lower than Windows audio issues. Its a case of being in a glass house don’t throw stones. Robert Pogson can throw some stones over Pulseaudio but you as a Windows user DrLoser really cannot because even allowing for how much Pulseaudio suxs it better quality than the Windows solution in the latest versions.

    The pig miss of incompatible and confliting audio API/ABIs that Windows has results in some very bad things. Like play a game under Windows switch out desktop switch back game no longer has sound. This does not happen with pulseaudio under Linux or any Unix sound server going back to before the birth of Linux. Adobe made out that Linux had a audio mess. Reality windows has 8 different interface paths to audio driver under Windows also the driver has to be able to process correctly the differences each of those paths expects. I am really serous-ally surprised that Windows managed to put out sound as well as it does but Windows has audio glitches all over the place that would see Linux users ready harm someone over them.

    OS X users could throw some brick bats at Linux over its audio mess. The do in fact have something that does look a little saner than Linux.

    Linux world expects perfection. So people will be complaining about stuff even when it exceeds the competition. Also you have to be aware people like Robert will take a crash worse than bad latency.

    Avoid X11 use NX or RDP and pulseaudio would have behaved self since pulseaudio would have been talking to pretend local drivers and those drivers compress for network transport.

    Jessie Pulseaudio is quite good. Rarely malfunctions except for when you start using it for conner cases.

    This is the problem. Linux in a lot of areas is not that bad. Some areas Linux needs major work. Area 1 X11 has to die since its insecure and cannot be fixed. Area 2 Pulseaudio need a serous code audit. Area 3 we need a Init system that truly and properly works and I don’t really care who it comes from as long as it works.

    Interesting point is Pulseaudio design is not bad. Pulseaudio is in fact one of the best no kernel designs for audio ever. Quality of code in Pulseaudio is an issue.

  6. oiaohm says:

    DrLoser Ok you want to know where Pulseaudio is good.

    I will agree with Robert Pogson that in Wheezy Pulseaudio suxed. Suxed so bad I forced system back to pure Alsa. Note due to removal of graphical environment sound servers I was able to force back to pure Alsa due to KDE and Gnome making it possible to disable sound server completely and fall back to kernel.

    1) what is good about Pulseaudio is reduction in sound servers and the agreement that graphical environments should be able to function without a sound server. Second part is annoying that some have gone back on it.

    Next is quite major. Since I have been around the wine project for a long time. Remember the wine project refuses to accept a Pulseaudio driver mainline. Instead wine uses its Alsa driver to interface with Pulseaudio. turns out in the most recent version of pulseaudio the only major issue is default-fragment-size-msec issue. Interesting enough this is not a pulseaudio problem. Wine use to have a huge stack of users complain that X program output sound on computer 1 and did not put out sound on computer 2 even that they were using Alsa. Yes different alsa sound drivers were behaving differently. Not due to hardware issues but due to coding in driver defects. Linux has less non conforming sound drivers today and it due to the developers behind pulseaudio being willing to go into the Alsa and kernel code bases and fix stuff.

    2 What is good about Pulseaudio is major fixes to the ALSA drivers it has caused.

    On Pulseaudio size issue. I really don’t give much grounds as that as a cause of problems. 245,145 yes this is about 10 times the size esound was. Esound did not have a suitable test-suite. But remember Libreoffice is 6,956,827 and its able to get a defect density per 1000 lines of code of 0.002 or less percent chance. Libreoffice has scan run against it at least every month preferred every week. Pulseaudio scanned once per year if lucky. You can go to the coverity projects and monitor when a project got scanned last and from watching this you can see how active a project security team on taking on preventing issues.

    Reality is 245,145 line of code is not unmaintainable size. Pulseaudio is getting better with age. Pulseaudio is a case of a project under resourced. I was around using Linux when esound was new. Early esound had most of the teething issues Pulseaudio has had. If you want a truly unmaintainable size you are talking something around 100 million lines of code. Anything less than that is quality of test-suite and procedures using automated tools to prevent issues that is normally lacking.

    Libreoffice removed over 10000 flaws that OpenOffice had by checking the errors the automated tools could find and removing where possible. Remember esound was before coverity. Pulseaudio and esound should be able to achive the same level of defect if the project leads of Pulseaudio takes QA serous-ally. Please note SUN and Orcale did not sign up to perform coverity scans on the code base of OpenOffice regularly either.

    Poettering has a flaw he pushes stuff out door without suitable testsuites and worse not setting up processes to have regular usage items like coverity that are provided free of charge to open source projects.

    To thinclient with sound is a major problem. RDP does include in protocol sound problem not all thinclients implement it. X11 does not include sound in X11 protocol in any sane way. With or without Pulseaudio doing audio in thinclients is hell. This is one reason why I don’t care if X11 disappears.

    Next problem you will run into with thin is audio and video getting out of sync if you are using X11 over network. Basically the video and audio protocol has to be one to work correctly over network. NX RDP and others meet this requirement.

    A lot of people have rose colored glasses about esound over network. People forget that even when esound was not over network it has latency problems. Pulseaudio has a lot lower latency esound. Yes some of pulseaudios expanded size is a more complex audio processing solution that does deliver lower latency than esound ever could. Pulseaudio and jack-audio audio engines are both able to achieve fairly low latency.

    Lack of complexity is not always a good thing. Lack of running tools to find code defects is alway a bad thing.

  7. DrLoser wrote, “when, precisely, is Pulseaudio “good”?”

    When it works, of course. I had Miley Cyrus going full-bore on the thin client briefly. That’s the only problem I have with it. The X-authentication is easily configured away and the GUI tools for pulseaudio are fine, but the server itself crashes under load. That’s terrible, something I haven’t seen in GNU/Linux for ages. Poettering is taking us backwards, not forwards. The fact that pulseaudio has that problem in Wheezy, and Jessie is very troubling. There are millions of users. What fun are they having?

  8. Agent_Smith wrote, “PA is the crappyest thing ever to go out from Poettering’s mind”.

    I like networked sound just as I like networked video but I would like pulseaudio a bit better if it worked out the box. The package in Wheezy would not even start without piddling around with config files and then the documentation and the facts seemed at odds. It’s just way too complex to be reliable. pulseaudio is a bit like CUPS if you compare speakers with printers, so it’s not complete trash but it’s infested systems and programmes are depending on it but it fails bringing everything down with it. esound, which was uber-simple and reliable is no longer in Wheezy, it’s just a compatibility element in pulseaudio. I’m looking at streaming, say with vlc from Beast to the thin client. I fought with that documentation for a bit today. You’d think what I need would be Exhibit A in all the docs, but no, there are 15 ways of doing everything and I have to sort through the matrix to find what works. At least we know vlc works.

  9. Agent_Smith says:

    PA is the crappyest thing ever to go out from Poettering’s mind… Oh, wait, there’s systemd…

  10. DrLoser says:

    Oh joy, another oiaohm “I can explain this stuff to you, except that I can’t.”

    Pulseaudio is kinda bad but is kinda good.

    And when, precisely, is Pulseaudio “good”?

    It’s an awful piece of FLOSS dreck, isn’t it?

  11. DrLoser says:

    I’m a little old to be distro-hopping but even I can see the necessity of escaping the entanglement, the single point of failure, and the loss of control that systemd represents.

    I have some sympathy with that, not least because I regard pulseaudio as an abomination. However. Let’s take those three points one at a time.

    1) “Entanglement?” Show me a single apt-get package that doesn’t feature “entanglement.” I’ll even give you the basic interfaces to the kernel (such as glibc for free.

    The packaging system, inherently, is chock-full of “entanglement.” Just to take one small personal example: when I installed iconv on Cygwin, it took me fully two or three hours to acquire and build the dependencies.

    Now, obviously, I noticed these dependencies because I was building on top of Cygwin. If for some reason you need to build on top of Debian, those dependencies are already there.

    As entanglements. Just because you don’t notice them, it doesn’t mean that they don’t exist, Robert.

    2) Single points of failure … an interesting topic. Normally, I should point out, referenced in terms of hardware. Or disaster recovery. Or quite possibly when you are dealing with a DNS (say) or other locator that can drop a server farm without recourse.

    Not, I submit, relevant to systemd. Systemd is precisely the same “single point of failure” as the Linux Kernel is. No more, no less. Although I would submit that system is considerably less bloated than the Linux Kernel.

    Naturally it will acquire “bloat” as it grows. That is the way with these things.

    3) “Loss of control?”

    You didn’t possess control in the first place, Robert. If you can’t map a bunch of independent procedural scripts onto a declarative model — and this model does not even have to be systemd — then you were just fooling yourself.

    Any other minor little local difficulties you want me to resolve?

  12. I made this comment from The Little Woman’s new/old thin client.
    Snappy… ;_)
    pasted:Recent projects of mine have included migrating back to Wheezy (Debian’s “stable” release) from Jessie (their “testing” branch) because it’s too buggy and most of my problems were tied into systemd and pulseaudio, both

  13. oiaohm says:

    Pulseaudio is kinda bad but is kinda good.

    I’ve set up hundreds of thin clients and never had any problem with esound and X, both doing what they do and leaving the other alone.
    Really remember I am a KDE user who has always used a lot of QT based applications. I had the hell battle between artsd and esound. Pulseaudio was the first unified sound server shared between most graphical environments on X11. Every historic Linux/Unix sound server bar jack-audio was a strange mix of X11 and audio this include esound.

    Like it or not Devuan is not the way forwards. Ok systemd might not be the way forwards but the issues are major with sysvinit.

    I like the gentoo guys they are facing the facts by creating openrc.

    Linux kernel has never been a true Posix kernel. Only reason Posix applications work on Linux is the fact the libc libraries emulate a hell load so Posix designed init systems will always be broken due to particular Posix expected facts not being true.

    The realities of sysv.
    1) Sysv init cannot start services dependly. rc directories generation depends on extra data LSB standard have added as metadata to init scripts so the generate starts everything in the correct order. If user decides not to start services on start on startup and start them manually heaven help you with sysvinit not to screw it up.
    2) Sysv init base solutions cannot stop services perfectly.
    A) Sysv init allows services to be stopped in the wrong order with no warning that you are about to set off hell on oneself.
    B) Sysv init will fail to stop all parts of the application.
    3) Sysv init fails to restart services correctly due to 1 and 2.
    4) Sysv init service status reporting is pot luck on how correct or if a service will even provide a status.

    Those 4 points are what a init system should pull off. Start, Stop, Restart and Status. are 4 really simple requirements.

    UNIX philosophy of doing one thing well.
    True but what is the one thing sysvinit related init solutions is really doing well? Answer is there is not 1 thing its more good luck and hacks that sysvinit even starts without more errors than you can dream.

    Sysvinit has been a single point causing many failures.

    There is 1 annoying fact under Linux about the only way to be able to get correct status of services is use cgroups. If you are working on solaris the only correct way to be able to be sure to get correct status of services is use zones. If you are working on Freebsd and other BSD based OS’s PPID works as Freebsd does not allow breakaways.

    Even so BSD init system supports running inside jails natively or the freebsd equal to a major configured cgroup namespace.

    The big thing to be aware is the world has also changed since sysvinit was designed as well.

    Systemd is really trying to design itself to meet the init requirements for the next 20 years. Sysvinit was design in the golden ages where a computer hacker was a coder not someone who was breaking into computers. We live in a age were we need protections around applications.

    Truly its one thing to hate systemd. Its another it sit down and serous-ally understand the problem. DMD from GNU and Openrc are both serous-ally studing the problem.

    Something to also serous-ally take into account logind idea OpenBSD audit team agrees with. logind is about allowing per application permissions instead of just per user permissions. The world we live in today we need per application permission.

    So sections of systemd are really good ideas we need. Old saying don’t throw the baby out with the bath water. Yes sections of systemd could be the bath water but not all of it is.

  14. Modular sunfish says:

    An intermediate step would be to try Debian GNU/kFreeBSD. It has a little less hardware support. But on the plus side it has no systemd and does provide PF instead of iptables. Aside from those points, the experience for users, tinkerer, power users, devops and most (non-Debian) devs would be the same as for the late Debian GNU/Linux. Maybe Debian 9 or 10 will be clean again after the pain in 8, but who knows. The push to systemd does not seem motivated by technical considerations beyond a few points that are better met in other ways. Had the discussion been limited to init systems, it never would have been inconsideration since it is not an init system. Instead we would have been looking at Upstart and the others, some of which are quite nice. The main pressure seems to come from the false dilemma of “OMG we have to have all of systemd all right now at this moment, hurry, hurry” or “if you wait, it will be SysV init forever”. However, even those holding back from the trainwreck that is systemd know that it could be about time to phase out SysV for another init system, but the operative terms there are phase out and init system.

Leave a Reply