Announcement

Collapse
No announcement yet.

New Group Calls For Boycotting Systemd

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Um... No one is trying to force you to do anything. If anything, those "boycotting" are the ones attempting to force it out!

    Am I the only one who thinks "organizing" a boycott is a little... unnecessary? I mean, anyone who cares that much will likely switch distros anyway, correct? That, or implement something else themselves...

    It seems like a sad waste of time and energy that could be better spent on developing a viable, modern alternative. If we don't like it, then we make something better. Crying doesn't solve anything.


    Originally posted by phred14 View Post
    I don't mind that. Feel free to use systemd, I really don't mind that either.

    But I don't want to use systemd, and it need go no farther than that. You need not know or understand my reasons - they may matter to me, but they don't have to do you. When someone comes out and says, "systemd has won" as was posted earlier in this thread, it's not far to imagine some glee in the idea that I too will be forced to run systemd soon.

    Why do you care! Is your life that boring that you have to try to control my computer, too? Get a life!

    (The next thing someone else on this thread will do, besides schooling me on how stupid, backward, and retarded I am, will be to tell me to "get a life" and just go ahead and use systemd, already.)
    Last edited by bmourit; 20 September 2014, 05:16 AM.

    Comment


    • So someone (apparently affiliated with the group that inspired this) went ahead and forked systemd 208 as "uselessd" (they suggest parsing it as "use less" or "useless", whichever you prefer).


      It can compile and run on musl, uClibc, and FreeBSD systems; the last-mentioned is as a service manager started by init, requires a bit of mucking around to use, and is missing a lot of functionality/barely partly working.

      Most of the systemd features other than the process supervisor have been removed.
      I found out about this when I updated aports.

      Still not interested.
      The init I'm really interested in weighs 492 lines right now, and may be less by the time it's done.
      And if you say "But gnome depends on systemd", I'll say "Good riddance!" I've hated it since I first tried it (Dapper Drake, on a Thinkpad 600x with 64 megs of RAM and a 500 MHz CPU ). And I'm barely more interested in KDE and Xfce. The only desktop a computer should have is the one it sits on.

      Well, OK, I use CDE sometimes; but it's the only DE I'd consider.

      I've written sysv-style init scripts several times, including a networking service because there aren't enough of them already (or at least enough that work right ). I've hacked together a couple rc scripts to start built-from-scratch systems.
      And guess what? I liked it, and I want to do it again.

      But I might try writing a dependency-based init in make first, just because make is a dependency-based language.

      Comment


      • Originally posted by Ibidem View Post
        ... I'm barely more interested in KDE and Xfce. ...
        LXDE/LXQt?
        Enlightenment?
        ?toil??

        Comment


        • Why you cannot trust Lennart Poettering / systemd

          I stayed out of the debate before, but now I've stumbled across a concrete reason to avoid all of this stuff.

          Comment


          • Originally posted by highlandsun View Post
            I stayed out of the debate before, but now I've stumbled across a concrete reason to avoid all of this stuff.

            https://www.linkedin.com/pulse/artic...tering-systemd
            So in other words, a developer is greatly offended that they chose to use their own solution rather than the solution he developed and that his company offers paid support for. I am sure he is a totally unbiased source on that.

            Comment


            • This story cannot be read by those of us who don't want LinkedIn Accounts

              Originally posted by highlandsun View Post
              I stayed out of the debate before, but now I've stumbled across a concrete reason to avoid all of this stuff.

              https://www.linkedin.com/pulse/artic...tering-systemd
              An attempt to read this gets a redirect to their login page if JS is enabled, and an almost blank page if JS is disabled-at least in Torbrowser.
              I don't trust social networking sites, and as a user of systemd on a sensitive system I do need to know if any of this relates to potential
              for back doors. Could someone post a summary of arguments made in this?

              My own examination of the systemd "cryptsetup" module's source hasn't found anything obvious, but this kind of discussion
              should take place in the open and not in locked forums.

              We need to keep many eyes on the kernel, on crypto libraries, on browsers, and on systemd. In all cases this is so nobody is tempted to try
              a little "underhanded C" and so that accidently introduced security bugs are found by us before they are found by the NSA or other hostile
              exploiters. There must never be another "heartbleed," at least with FOSS software it's possible to audit this stuff.

              Comment


              • Originally posted by Luke View Post
                Could someone post a summary of arguments made in this?
                I've no problem reading it without an account even with noscript on, so:
                Lennart said he can't use existing DBMS for journald because of his requirements and the post says that he wasn't/isn't right and LMDB meets all the requirements he had.
                The post then argues, that this is clearly NIH and in the last paragraph that systemd is not in the sense of "the unix philosophy" therefore Lennart and the systemd team can not be trusted.

                Note that this is a summery of the post, not my view on this subject.

                Comment


                • Originally posted by droste View Post
                  I've no problem reading it without an account even with noscript on, so:
                  Lennart said he can't use existing DBMS for journald because of his requirements and the post says that he wasn't/isn't right and LMDB meets all the requirements he had.
                  The post then argues, that this is clearly NIH and in the last paragraph that systemd is not in the sense of "the unix philosophy" therefore Lennart and the systemd team can not be trusted.

                  Note that this is a summery of the post, not my view on this subject.
                  More importantly, their NIH led them to create a solution (journald) that is broken by design - it is inherently vulnerable to crash corruption, and as the linked bug report shows, the corruptions are well known by the developers and they have no idea how to fix them. The key point is that no single team can possibly have expertise in every aspect of a complex system, and the systemd developers' all-in-one philosophy will inevitably lead them to make more such unfixable design mistakes.

                  Comment


                  • Originally posted by TheBlackCat View Post
                    So in other words, a developer is greatly offended that they chose to use their own solution rather than the solution he developed and that his company offers paid support for. I am sure he is a totally unbiased source on that.
                    Way to utterly miss the point.

                    Comment


                    • Originally posted by Luke View Post
                      An attempt to read this gets a redirect to their login page if JS is enabled, and an almost blank page if JS is disabled-at least in Torbrowser.
                      I don't trust social networking sites, and as a user of systemd on a sensitive system I do need to know if any of this relates to potential
                      for back doors. Could someone post a summary of arguments made in this?
                      Here is the full text
                      Originally posted by Howard Chu
                      I've been watching the systemd drama with a skeptical eye, from a distance. But tonight I read something that crystallized it all for me, so now I'm compelled to point out why Lennart Poettering and systemd cannot be trusted.

                      The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.s...922/focus=6950 where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness.

                      Going thru the rationale point by point
                      - small, embeddable, in pure C - LMDB is the smallest transactional DB engine in the world, written in pure C.
                      - stable API, sanely managed, free software - the LMDB API is modeled after the BDB API so it was mature from day 1 and has had no incompatible changes since LMDB's introduction. It is professionally managed by software veterans and released under the OpenLDAP Public license - totally free.
                      - OOM safe - LMDB does practically no memory allocations of its own - readers require zero mallocs, writers seldom require more than 1. It can never use enough memory to drive a system into swapping; it can never cause an OOM (out of memory) condition.
                      - typeless - LMDB is typeless, as a key/value store it doesn't care what types of values you store.
                      - efficient with large and binary data - LMDB is particularly efficient with large data, nothing else comes anywhere close. http://symas.com/mdb/microbench/#sec4
                      - does not require file locks; readers don't block writers, and writers don't block readers.
                      - robust against failures - LMDB is crash-proof by design, and proven in the real world. https://symas.com/carrier-grade-stab...d-performance/
                      - needed in-line compression - this is a red herring. LMDB uses 1/3rd as much space as DBs that offer compression. Compressors need to average 3-4x compression ratios to match LMDB's space efficiency, but few can guarantee more than 2x compression on average. http://symas.com/mdb/inmem/scaling.html (By the way, I've got nothing against compression in general. In fact I was one of the pioneers of open source lossless data compression, nearly 30 years ago. https://sourceforge.net/p/arc/ It serves a purpose and I know, better than most, where it's useful and appropriate.)

                      Leaving aside the blatant ignorance and NIH-ism, this thread shines a bright light on the whole hazy question of "Unix design philosophy" that has shrouded the systemd debate. The Unix philosophy is to write small, single-purpose tools that can be composed together (in pipelines, via scripts, etc.) to build larger solutions. The systemd folks are quick to point out that systemd is not monolithic; it in fact currently is comprised of 69 individual binaries. http://0pointer.de/blog/projects/the-biggest-myths.html

                      This rebuttal from the systemd camp utterly misses the point though. Having 69 binaries that are all intimately tied together, interdependent, and written by the same person is just playing a shell game. The point in writing dedicated tools is to have dedicated authors, subject-matter experts, responsible for each tool. Unless you're an extremely gifted and brilliant individual, you cannot acquire and maintain expertise in all of the subject areas that a complex system requires for its operation. The systemd team has clearly demonstrated that they're incompetent at designing robust multi-process data storage systems. What else in their all-in-one kitchen sink project have they also failed to design competently, leaving implementation issues aside? Which other viable technologies have they ignored, in their quest for in-house homegrown purity?

                      Comment

                      Working...
                      X