Slashdot Mirror


Debian Technical Committee Votes For Systemd Over Upstart

sfcrazy writes "Bdale Garbee,chairman of the Debian Technical Committee, called for a ballot from the TC to chose the default init system. The votes are in systemd is the clear winner here. Bdale himself voted for systemd."

379 comments

  1. At least I'm not a Debian user. by Anonymous Coward · · Score: -1

    And now there's no reason to start!

  2. Incorrect summary. by Heraklit · · Score: 3, Informative
    Please. Get your facts straight.

    the default init system for Linux architectures in jessie

    1. Re:Incorrect summary. by Anonymous Coward · · Score: -1, Flamebait

      Please. Get your facts straight.

      the default init system for GNU/Linux architectures in jessie

      FTFY.

    2. Re:Incorrect summary. by beelsebob · · Score: 1

      systemd was not a GNU project, so to suggest this is a GNU/linux distro is as fallacious as claiming that it's Poettering/Sievers/Linux distro.

      What it is, is Linux. This particular project has some parts written by the GNU, and some parts written by Poettering/Sievers, and some other parts written by some other people. Stop trying to imply that the GNU is the be all and end all of user land software on Linux.

    3. Re:Incorrect summary. by Bite+The+Pillow · · Score: 2

      How is that misleading? The next release of debian is codenamed jessie, apparently.

    4. Re:Incorrect summary. by dos1 · · Score: 5, Informative

      Linux architectures, not GNU/Linux. In this context it's not about the whole operating system, it's about the kernel itself. Aside of Linux architectures there are also kFreeBSD architectures in Debian - with "k" added to make it clear that it's about FreeBSD kernel, not OS.

      Don't try to fix other people when you don't know what them (and in turn you as well) are talking about.

    5. Re:Incorrect summary. by dos1 · · Score: 1

      Aside of the comment you're answering to being wrong, the full Debian OS on one of supported Linux architectures is officially called "Debian GNU/Linux" by Debian project itself.

    6. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      Wrong, this is not "linux". This is "Debian".

    7. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      I did not know systemd was used only for the kernel and not the whole operating system.
      You learn something new every day! \o/

    8. Re:Incorrect summary. by Anonymous Coward · · Score: 2, Informative

      How is that misleading? The next release of debian is codenamed jessie, apparently.

      Nether Debian GNU/Hurd or Debian GNU/kFreeBSD are receiving systemd. Just Debian GNU/Linux.

    9. Re:Incorrect summary. by reub2000 · · Score: 1

      I need a term that differentiates things like android or my roku box from systems running glibc and X11 or wayland. I think GNU/Linux works for that.

    10. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      > one of supported Linux architectures is officially called "Debian GNU/Linux" by Debian project itself.

      Did you even read that nonsense? Debian project supports Debian? That's superfluous labeling. GNU/Linux is not an architecture. They can call a horse a giraffe, that's not really relevant.

    11. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      It's Debian's Linux architecture. As opposed to Debian's kFreeBSD architecture.

    12. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      Or Debian's Hurd Architecture.

    13. Re:Incorrect summary. by Anonymous Coward · · Score: 1

      The supported Linux architectures being Linux on i386, Linux on ARM, Linux on PPC etc. Debian has non-Linux architectures as well, such as Hurd and FreeBSD.

    14. Re:Incorrect summary. by tepples · · Score: 1

      Agreed, so long as nobody tries to introduce a mainstream "desktop Linux" or "server Linux" distribution that uses a C library other than the GNU one.

    15. Re:Incorrect summary. by Mitchell314 · · Score: 4, Insightful

      Ignoring stallman and both of debian's BSD fans, that's pretty much Debian's userbase.

      --
      I read TFA and all I got was this lousy cookie
    16. Re:Incorrect summary. by aestrivex · · Score: 2

      I can realistically envision just two types of persons:

      a) The persons who read the article title and immediately assumed "OMG my Debian GNU/Hurd and Debian GNU/kFreeBSD boxen will be getting a new init system!"
      b) The persons who did not do that

      One of these types of persons does not exist in corporeal form.

    17. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      Please. Get your facts straight.

      the default init system for GNU/Linux architectures in jessie

      FTFY.

      It's a joke, silly. It inspires no flames!

    18. Re:Incorrect summary. by Anonymous Coward · · Score: 0

      You're wrong, perhaps try to read more carefully. He didn't say anything about GNU sw being anyhow connected with this. He just mentioned that it is realted only to "Debian GNU/Linux" - that's the official name for Debian with Linux kernel (as opposed to Debian with other kernels).

    19. Re:Incorrect summary. by dos1 · · Score: 1

      Well, in fact, systemd can only be used with the Linux kernel (unless some other kernel mimic all custom Linux interfaces systemd relies on) - that's why it's becoming default for Jessie only on Linux architectures, while others, such as kFreeBSD or Hurd, will still use sysvinit.

  3. Beta by loufoque · · Score: 0, Offtopic

    That's because upstart was BETA software from Canonical.

    1. Re:Beta by arth1 · · Score: 2, Insightful

      But no worse than systemd, which is near universally despised by system administrators.

      Does slashdot have Leonart Poettering on the design team, by any chance? It would sure explain a lot.

    2. Re: Beta by Anonymous Coward · · Score: -1, Offtopic

      beta sucks hedgehog balls (and so does Timmmaay)

    3. Re:Beta by Anonymous Coward · · Score: 1

      FWIW, having worked with all but OpenRC - I very much like the approach of systemd's small interpret-able/generable files.

      I get the flexiblity of external support scripts when I really need them, but 9/10, defining the dependencies well avoids the need for any scripting at all.

      At scale of more than a few dozen machines (and especially when they're coming and going), this is amazingly powerful - one set of tools can write them, another can read them / interact with them via DBUS, all while managing most every aspect of the underlying process in a single well documented way (the manpages are /awesome/)

    4. Re:Beta by gl4ss · · Score: 1

      you mean canonical has something else than alpha builds of some sw??

      --
      world was created 5 seconds before this post as it is.
    5. Re:Beta by Anonymous Coward · · Score: 0

      But no worse than systemd, which is near universally despised by system administrators

      Opinion among sysadmins does seem to run about 10:1 in favor of upstart over systemd. The problem is that systemd is too opaque, much like Windows "you don't get to see" philosophy. It's contrary to the way Unix based OSs have always been.

      The people who are so desperate for a Windows-like OS should just... use Windows! Windows more or less works fine if that's your cup of tea.

    6. Re: Beta by WebCowboy · · Score: 1

      Interesting...I prefer systemd over upstart and I know many others that do as well. So I know it is BS to day systemd is almost universally despised. At worst it is seen as the least of all evils.

      It anything the debate is over retaining init.d scripts and systemd as upstart is somewhat of a single vendor stepchild. The main legitimate concern with systemd is its Linux-only implementation complicating the porting of packages to BSD and HURD based systems. The other might be a matter of taste but still worthy of debate--that systemd does not honour the 'Unix way' sufficiently.

    7. Re:Beta by Anonymous Coward · · Score: 0

      Try openrc it is even faster than systemd nowadays.

    8. Re:Beta by real-modo · · Score: 1

      ...The problem is that systemd is too opaque, much like Windows "you don't get to see" philosophy. It's contrary to the way Unix based OSs have always been.

      The people who are so desperate for a Windows-like OS should just... use Windows! Windows more or less works fine if that's your cup of tea.

      This bears repeating, so I have repeated it. Systemd is philosophically Not The Unix Way. Microsoft has been doing things the systemd way for much longer than Poettering & Sievers, and is better at it.

      I have no desire at all to use an ersatz Windows. Which is probably why I'm using the real thing more than I am using Linux these days. Not happy.

    9. Re:Beta by HiThere · · Score: 1

      When is the last time you hand configured your monitor, putting in desired refresh rate, etc.?

      I'm not convinced that this is a good move, but I'm also not convinced it's a bad one. I don't know. It's beyond my area of expertise.

      FWIW, I don't understand why the init process needs to be changed. My feeling is pretty much "It ain't broke, so don't fix it.", but there may be valid reasons. Two different groups of people seem to think so.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    10. Re:Beta by fnj · · Score: 1

      It is my understanding that the argument of substance in favor of systemd is not that it is a better init system per se, but that it is something fundamentally new: a flexible and powerful asynchronous actor on events.

  4. Right on time by TheloniousToady · · Score: -1, Troll

    It looks like this article was posted exactly one hour after the previous one, which was posted exactly one hour after the one before. I guess the (automatically scheduled) beatings will continue until morale improves.

    1. Re:Right on time by Anonymous Coward · · Score: -1

      timothy is a shell script

    2. Re:Right on time by Anonymous Coward · · Score: -1

      It looks like this article was posted exactly one hour after the previous one, which was posted exactly one hour after the one before. I guess the (automatically scheduled) beatings will continue until morale improves.

      Yes, I think he's also been posting articles for 48hrs non stop. Imagine if he's not a script, but someone incessantly desperately trying to bury the present, desperate, incessant. poor guy no matter how much he posts its not going to magically go away.

      I can't believe Slashdot haven't done something sensible about all this. Make another statement, Say they'll hold off and make links with us to radically improve the situation, Put up a meaningful poll to find out what people here really think about the Beta proposal, and act on it. We are all still here! Respond to the clamour, don't hide away. They say they want to listen? So why stifle our voices with floods of articles?

      A poll about phones really isn't what's needed right now!

    3. Re:Right on time by Anonymous Coward · · Score: -1

      oh, LOL, that's true!

    4. Re:Right on time by arth1 · · Score: 0, Troll

      Yes, I think he's also been posting articles for 48hrs non stop. Imagine if he's not a script, but someone incessantly desperately trying to bury the present, desperate, incessant. poor guy no matter how much he posts its not going to magically go away.

      I can't believe Slashdot haven't done something sensible about all this. Make another statement, Say they'll hold off and make links with us to radically improve the situation, Put up a meaningful poll to find out what people here really think about the Beta proposal, and act on it. We are all still here! Respond to the clamour, don't hide away. They say they want to listen? So why stifle our voices with floods of articles?

      Never attribute to stupidity that which can be adequately explained by CYA.

      They obviously don't believe for a second that they can outdo us at our own game, drowning the protests in articles. Not only would that be a severely pitched battle, but many of the opponents are those who wrote the book on one-to-many communication - they understand the battlefield and weapons a heck of a lot better than the Slashdot employees. They surely know this, and this is just token resistance so they can say that they tried hard to get the site back to regular discussion, so they are not to blame. Save their jobs.

      Meanwhile, the protests obviously continue, and the strike (we posters are workers, not customers - the ad agencies are the customers) starts tomorrow.
      See you all after next weekend.

    5. Re:Right on time by Anonymous Coward · · Score: -1

      Keep modding down and don't respond. It's probably for the best. Since it will drive us all away.

    6. Re:Right on time by TheloniousToady · · Score: 0

      It fascinates me that anything that stimulates discussion here is now a Troll. The term "Troll" is even a bit strange in the Slashdot context since the main purpose of the site is (or used to be) to have a discussion. Isn't that the essence of trolling? We see this in terms of recurring articles about hot-button issues like NSA, free software, bitcoin, etc. It looks to me like trolling is allowed and encourage, even as editorial policy, so long as it's the right kind of trolling.

      Anyway, I thought I'd get in as much of my style of trolling as possible today and then relieve the poor folks (or scripts) who moderate here next week from any further suffering they may experience from my efforts to stimulate the discussion. Fact is, they did just fine without my input during my many years as a lurker here, and they'll do fine without me next week, and maybe beyond.

    7. Re:Right on time by Hognoxious · · Score: 1

      They obviously don't believe for a second that they can outdo us at our own game, drowning the protests in articles. Not only would that be a severely pitched battle, but many of the opponents are those who wrote the book on one-to-many communication - they understand the battlefield and weapons a heck of a lot better than the Slashdot employees.

      For some reason I expected the next sentence to be "We could fight them with conventional weapons, but that could take years and cost millions of lives".

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    8. Re:Right on time by hairyfeet · · Score: 1

      Really? In my head I heard " we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air, we shall defend our island, whatever the cost may be. We shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender"

      Followed of course by the first bars of Iron Maiden's "Aces High".

      --
      ACs don't waste your time replying, your posts are never seen by me.
    9. Re:Right on time by Anonymous Coward · · Score: 0

      "What General Weygand called the Battle of France is over. The Battle of Britain, is about to begin".

      Followed of course by the first bars of Ron Goodwin's "Aces High".

    10. Re:Right on time by goose-incarnated · · Score: 1

      We shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender"

      So, just like my family vacations?

      --
      I'm a minority race. Save your vitriol for white people.
    11. Re:Right on time by Hognoxious · · Score: 1

      WSC would never have used a comma between the subject and its verb. That's the kind of thing Germans do.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  5. Soooo.... by Anonymous Coward · · Score: 2, Informative

    Having been a well behaved, not overly vocal member of the slashdot community for many years (10? more?), today, I found myself banned by ip. and my Karma (which has always been neutral) reduced to "terrible".

    I had posted 10 times over the last 48 hrs, in support of the slashdot boycott. Most sensible debate, some houmour.

    You know once the powers that be need to silence those who gently disapprove, that it's all gone terribly wrong, and those pushing for change that damages everyone are too weak to even make a sensible argument.

    Oh Dear.

    1. Re:Soooo.... by Anonymous Coward · · Score: 2, Interesting

      You are not alone. It's been the same here for me. I had the karma maxed and now it's terrible.
       
      Fuck you, Dice motherfuckers. I'll join the boycott in a few hours.

      FUCK BETA

    2. Re:Soooo.... by Anonymous Coward · · Score: 1

      If you only had neutral karma after 10 years, we're probably not going to miss out on many quality post. Also, you posted offtopic 10 times in 48 hours, what did you expect?

    3. Re: Soooo.... by binarylarry · · Score: 0, Offtopic

      So they banned you for spamming?

      I'm so sad that I'm writing the world's smallest exotic tragedy finfic and sending it to your mta, over and over again.

      --
      Mod me down, my New Earth Global Warmingist friends!
    4. Re:Soooo.... by Bite+The+Pillow · · Score: 0

      3 mod point left. Do I mod you down or suggest it's not a conspiracy? 12 points all to marking people off topic for exceeding the boundaries of common sense. Best not to waste them on whinging I suppose.

    5. Re:Soooo.... by inasity_rules · · Score: 3, Interesting

      Well, I haven't been banned, but my regularly scheduled mod points have not appeared. All I did was mod up some of the more polite and reasoned anti-beta posts... The "Fuck beta" posts are anatomically improbable, and likely less than helpful, but I ignored them and left them where they were.

      I am a late joiner (7 digits), but was an AC for a long time before I registered. I await the outcome of this situation. As far as I can tell, beta isn't being forced on us yet, and if it is, well, perhaps it is time I left /. behind anyway. It has been fun. :)

      --
      I have determined that my sig is indeterminate.
    6. Re:Soooo.... by fast+turtle · · Score: -1, Flamebait

      why in hell don't you fucktards simply boycott now as we've certainly gotten tired of the god damn "boycot beta" beefs. Everyone of them has jacked threads making it impossible to hold a god damn discussion. Maybe I need a god damn shot gun in the crowded room for all you "Fuck Beta" bitches. Better yet, beam you out into vacumn and see how long it takes you to expire.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    7. Re:Soooo.... by Anonymous Coward · · Score: 0

      But that raises a question that is actually related to the story: where else are the smart people?

      Systemd is a good example. It is crap, popular because of good PR and peer pressure. Slashdot is the only website I know of where the commenters have seen through it. Hacker News is broadly pro-systemd, r/linux the same and even LWN comments seem to favor systemd although they're not modded.

      There's a difference in intelligence between website communities and that's what makes Slashdot so special.

    8. Re:Soooo.... by Anonymous Coward · · Score: 0

      Seems you also lost the capability to spell correctly. I suppose you meant you (thought you) had some "humo(u)r"? ;-)

    9. Re:Soooo.... by Anonymous Coward · · Score: 0

      It isn't the 10th of February yet. That is the week of the boycott.

    10. Re:Soooo.... by bug1 · · Score: 2

      If your using this sites comment system to try and destroy this site with a boycott, why do you expect to have good karma on this site ?

    11. Re:Soooo.... by sandertje · · Score: 3, Interesting

      Please, for FUCKS sake, can you guys please stop bitching over Beta? We all don't like it, but I guess /. got the message now.

      Now, back on topic: Good choice Debian. Seeing Canonical ruins all projects it gets its fingers on, implementing Upstart would've been a baaaad idea.

    12. Re:Soooo.... by Hognoxious · · Score: 4, Funny

      Your names going in the book, you quisling running-dog. You'll be first against the wall when the revolution comes.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    13. Re:Soooo.... by bsolar · · Score: 2

      Because he expects the community to agree with him. Karma should reflect what the community thinks of his activity, not what the site's admin thinks, so it should be possible to have positive karma on this site even posting negative comments about it, as long as the community supports them.

      So either the admin tampered with his karma against the community's intentions, or the community is not as impressed with his activity as he thinks.

    14. Re:Soooo.... by ChunderDownunder · · Score: 1

      by Anonymous Coward on Monday February 10, 2014 @07:03AM

      Maybe not in YOUR timezone.

    15. Re:Soooo.... by shutdown+-p+now · · Score: 1

      Don't put too much into the presence or absence of mod points. They can disappear and reappear mysteriously for a very long period of time. From personal experience, I've had a stretch of something close to 3 years where the occasions on which I've got any modpoints I could count on two hands.

    16. Re:Soooo.... by Anonymous Coward · · Score: 0

      I assume you don't write software, or you would already know that your if statement generates a "Code Unreachable" warning. You are confused about who is trying to destroy Slashdot, and who "owns" it. It is true that we do not benefit financially from Slashdot, but that makes it all the worse. Spitting in the face of the people from whom you make a substantial profit, and whom have contributed for more than a decade to make the site what it is before you came along is just plain asinine. People who say "Boycott Slashdot" just don't get it. Why should I not be able to use the site I spent over a decade helping to create just because some asshats can't figure out thatwe are Slashdot, not them? They just profit from our efforts.
       
      * Posting anonymously, since my Karma has also taken a huge hit since the Beta fiasco.

  6. Glad this is over by Anonymous Coward · · Score: 2, Interesting

    It's a shame to see a bunch of Canonical shills on the Debian Technical Committee though. This should have been strictly between OpenRC and systemd, but the Canonical shills were trying to push Upstart even though it's a buggy piece of shit that is inferior to systemd in every way.

    1. Re:Glad this is over by Anonymous Coward · · Score: 1

      So OpenRC loses its possibility to shine and debian will enjoy the problems of systemd being with lots of small and big bugs, some even in the general design (and shared with upstart).

      We'll see if the debian people will fix it before the users will start to get concerned.

    2. Re:Glad this is over by RDW · · Score: 5, Funny

      ...but the Canonical shills were trying to push Upstart even though it's a buggy piece of shit that is inferior to systemd in every way.

      So wait, you're saying that narrow corporate interests were trying to push their own inferior solution in place of a technically superior system strongly preferred by the userbase? There seems to be something vaguely familiar about this scenario, but I can't quite put my finger on it...

    3. Re:Glad this is over by Anonymous Coward · · Score: 0

      The presence of the upstart option in this debate and voting was indeed
      unfortunate whether it was due to political reasons or technical shortsightedness.
      Based on reasonable assessment of technical merits and taking into
      account a need for moving forward the competition should have been
      between OpenRC and systemd only:

              Debian debate - OpenRC
              Debian debate - systemd

      While I admit that right now systemd is more developed and "ready", I
      find the design of OpenRC more compatible with the Unix philosophy.

    4. Re:Glad this is over by Brama · · Score: 1

      strongly preferred by a vocal minority who arrogantly THINK they represent the entire userbase.

      FTFY.

      Luckily they have now thrown in their own windows by acting like total assholes. Good riddance.

    5. Re:Glad this is over by Anonymous Coward · · Score: 1

      It would be much more believable if you actually had real complaints listed here. :)

    6. Re:Glad this is over by ignavus · · Score: 1

      So wait, you're saying that narrow corporate interests were trying to push their own inferior solution in place of a technically superior system strongly preferred by the userbase? There seems to be something vaguely familiar about this scenario, but I can't quite put my finger on it...

      You must be thinking of Windows Metro! :-)

      (He says with a big naive smile)

      --
      I am anarch of all I survey.
    7. Re:Glad this is over by Kjella · · Score: 1

      Well to be the devil's advocate what Canonical wants is to reach the all those that don't use Linux. The community says "Why would you need a GUI for that? All our users are happy with the command line." because the only users you have are those who would be happy with a command line. Of course Canonical could be wrong - often, it seems - but it's not reasonable to think their goals and the community's goals would align perfectly. Canonical wanted to be where Android is now, you know that platform where everything but the kernel like X, Gnome, KDE and so on has been stripped away and replaced and is wildly successful. It's Chromebooks chewing away at Microsoft's market share, not any of the Linux distros that have tried for the last 15 years. Fine, it works for you but stop the navel gazing and see how few of you there are.

      --
      Live today, because you never know what tomorrow brings
  7. More on systemd... by MAXOMENOS · · Score: 4, Informative

    ...here.

    1. Re:More on systemd... by bug1 · · Score: 1

      Apparently this is the most important information, from the front page.

      Spelling

      Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with systemd. On high holidays you may also spell it sÃstÃmd. But then again, SystÃme D is not an acceptable spelling and something completely different (though kinda fitting).

    2. Re:More on systemd... by Anonymous Coward · · Score: 0

      Rather than systemd, they'd be better calling it systemKit. It's got the same kind of bloated, silly crap as the other kits, pol(icy)?kit, consolekit, etc.

    3. Re:More on systemd... by Anonymous Coward · · Score: 0

      System D is a Line troop tradition. The men organize themselves into small units and go into a section of town where they all drink until they can't hold any more. Then they tell the saloon owners they can't pay. If any of them causes trouble, they wreck his place, with the others converging onto the troublesome bar while more units delay the guard.

  8. More information on the topic by cfreeze · · Score: 5, Interesting

    I didn't really know much about systemd being a ubuntu user, but found this giving more background on the story: https://wiki.debian.org/Debate.... The wiki does a good job detailing the technologies. Given the information, the choice of systemd is interesting.

    1. Re:More information on the topic by Anonymous Coward · · Score: 0

      that page sucked, all I got out of it was that Steve Langasek loves upstart and is desperate to find faults with systemd, to the point of ignoring well known problems with upstart such as it leaving you with a dirty filesystem.

    2. Re:More information on the topic by Fubar420 · · Score: 4, Informative

      You're looking at the upstart position document:

      https://wiki.debian.org/Debate... and https://wiki.debian.org/Debate... represent broader parts of the debate.

      --
      -- (appended to the end of comments you post, 120 chars)
    3. Re:More information on the topic by Anonymous Coward · · Score: 2, Interesting

      Which are filled with bad logic. For example:

            Systemd is often said to be too big for the functionality of an init system.

                    However it is much more than init, and if you take into account all the functionality it can provide or replace, you’ll soon find out that it takes less lines of code than the alternatives, in a language (C) that takes less memory to execute.

      This is not the point or benefit of the original UNIX and much of the Linux architecture. By doing small tasks well, a reliable toolchain can be built of those small tasks. *OF COURSE* a monolithic megamonster is going to have fewer lines of code than all the different components shoe-horned into it. And of course *it's going to get details wrong* in those individual components, but the monolithic megamonster may rely on those flaws or make debugging of them unreasonably difficult.

      Been there, done that, have the bug reports. SuSE tried this sort of stunt with YaST for configurations, which blew, and Red Hat has more recently done it with NetworkManager, and Gnome tried it with Gnome 3. They were bad ideas then, they're *still* bad ideas, and I rip them the hell out as fast as I can for stability. Unfortunately, I can't just rip out the init system....

    4. Re:More information on the topic by ustolemyname · · Score: 1, Insightful

      This is not the point or benefit of the original UNIX and much of the Linux architecture. By doing small tasks well, a reliable toolchain can be built of those small tasks. *OF COURSE* a monolithic megamonster is going to have fewer lines of code than all the different components shoe-horned into it. And of course *it's going to get details wrong* in those individual components, but the monolithic megamonster may rely on those flaws or make debugging of them unreasonably difficult.

      I can only assume that all people who support this argument run GNU Hurd, as it's a microkernel, instead of that 16,000,000+ line of code "monolithic megamonster" known as the Linux kernel.

    5. Re:More information on the topic by Anonymous Coward · · Score: 1

      Of course you can rip out the init system. It will warn you about removing essential packages, but that's all. You can switch between systemd-init and systemv-init every other boot if you want to.

      I get the impression that you're deeply ignorant of all of these things you talk about. That's probably because you are. Maybe you should read more about what systemd actually does. Maybe you should do what your "gut" tells you no matter whether it makes sense -- hopefully purging two packages isn't too hard for you. And maybe you should go fuck off to BSD land.

    6. Re:More information on the topic by evilviper · · Score: 2

      I can only assume that all people who support this argument run GNU Hurd, as it's a microkernel, instead of that 16,000,000+ line of code "monolithic megamonster" known as the Linux kernel.

      Just because you can point to one microkernel that doesn't really work, and one monolithic kernel that does, will not invalidate the perfectly valid points made about the benefits of modularization. Yours is just a logical fallacy:

      eg. "I'm sure everybody that likes bicycles never drives a car..."

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    7. Re:More information on the topic by ustolemyname · · Score: 3, Interesting

      Just because you can point to one microkernel that doesn't really work, and one monolithic kernel that does, will not invalidate the perfectly valid points made about the benefits of modularization. Yours is just a logical fallacy:

      eg. "I'm sure everybody that likes bicycles never drives a car..."

      Except it's not valid points made about modularization in this context. It's a blanket statement that modular is better, for which a single counter example is sufficient to disprove. The AC's post didn't mention specific flaws with systemd, instead they asserted generalizations about how modular is better than monolithic. Just because there are potential benefits to a modular system over a monolythic system does not mean a specific modular system is better than a specific monolythic system, leaving the AC's post as little more than FUD.

    8. Re:More information on the topic by cant_get_a_good_nick · · Score: 1

      I noticed this:

      2. Support for Hurd/kFreeBSD

      I know Debian is pretty tightly bound to GNU, but they're using cycles for compatibility for these two systems that are barely not-quite-vaporware?

      Oddly I'm not trolling. I'm a developer and I'd groan if my boss gave me the constraint "make sure you're compatible with these systems that represent .0001% of the installed base"

  9. I see a lot of discussion about systemd by Anonymous Coward · · Score: 1

    Obviously, there's been a big push across the board by many various distros, but what are the real benefits of systemd? Is it better for average end-users (Easier? Faster?) or those more technically inclined (more stable, uses less resources, more configurable)? Or is this simply a case of it just being non-Canonical?

    1. Re:I see a lot of discussion about systemd by broken_chaos · · Score: 5, Insightful

      The biggest thing that pushed adoption was when it absorbed udev. You can still run udev without it, but it's plastered with systemd branding and building udev without also building systemd (and then having to manually strip udev out, if you want to run it standalone) is difficult. Beyond that, Gnome 3.8 made it (almost) a hard requirement. Strictly speaking you can run Gnome without, but, as I understand, it loses almost all of the power/disk/device management.

      People like it because it's obsessed with boot times (which is apparently a really important thing to people who don't actually run a real-world system, where boot times of 10 seconds vs. 5 seconds are meaningless), has a few useful features (often, subjectively, questionably implemented), and has really good PR. The problems with it include an obsession with APIs (Unix, everything is a file -> systemd, everything is an API), an everything-and-the-kitchen-sink approach (NIH: write their own binary-formatted logging daemon, their own cron daemon, their own implementation of dbus, ...), and a horrid misunderstanding of what an initsystem really needs to do for servers (LP: "Control groups of course are at the center of what a modern server needs to do." -- which, really, what it needs to do is serve things, not shuffle processes around various metaphorical boxes). The project is, as a result of including the kitchen sink, also extremely monolithic -- everything is stuffed in a single git repo, a single tarball, and is heavily interconnected.

      Two of the primary developers (Lennart Poettering and Kay Sievers) are also notoriously hard to deal with if you ever suggest they've done something incorrectly. You can find a lot of examples of this, largely to do with LP's attitude towards anything that isn't systemd, and Sievers' regular breaking of udev over the past few years.

    2. Re:I see a lot of discussion about systemd by Junta · · Score: 4, Informative

      systemd versus upstart is mostly anti-canonical sentiment coming home to roost. Canonical has made it clear they don't want to play nice with the wider non-canonical community, and now that's going reciprocal. In a way, systemd and Wayland should be grateful. A non trivial amount of the increased urgency behind migration to those schemes are driven by a distaste for canonical as they push upstart and Mir.

      systemd versus sysv init most visibly leads to faster boot (by providing a richer dependency model and avoiding spawning as many processes through skipping shell scripts a lot). The downside should be clear in general, the philosophy leaning more toward compiled modules over shell scripts means it's harder for a lay person to dig in and follow things and understand how they work. If you dig deeper you'll notice that the number of getty processes is lower for most people by skipping spawning such things until the VC is active and other similar things. These are things that really don't meaningfully add to the experience in 99.999% of cases, but it's the sorts of little awkward/arbitrary things that systemd aspires to be a bit more fancy about managing. If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    3. Re:I see a lot of discussion about systemd by Junta · · Score: 4, Insightful

      The problems with it include an obsession with APIs

      Incidentally, this also means they align more closely with Microsoft thinking than traditional Unix thinking. At some point I wish these people would just accept they want Windows and go with Windows and leave Linux alone.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    4. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      They cloned Theo de Raadt?

    5. Re:I see a lot of discussion about systemd by richlv · · Score: 1

      3 times. one was lennart, wan was kay - and 3rd was the designer of slashdot beta

      --
      Rich
    6. Re:I see a lot of discussion about systemd by GodWasAnAlien · · Score: 5, Insightful

      "systemd versus sysv init most visibly leads to faster boot".

      That was the original marketing. systemd of course is much much more than boot.
      Systemd touches every part of the OS.

      https://en.wikipedia.org/wiki/...

      Upstart was bad. Systemd is worse. Both were born as boot/init systems and are unconstrained in scope.

      Any program unconstrained in scope will grow into a monolithic mess.

    7. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 5, Insightful

      The problem for Gnome and KDE is, that systemd is vastly superior to anything out there, and that it will help them dump loads of hard to maintain code, and give them easy access to make powerful distro-agnostic programs.

      systemd provides a a common, uniform Linux plumbing system that makes life easier for all user program developers. So of course Gnome and KDE will start to take advantage of systemd, why shouldn't they?

      The main problem with those who for some reason or another doesn't like systemd, is that they are incredible lazy. Instead of actually getting together to make an alternative development stack to systemd, they rant against Poettering and spew empty platitudes about "UNIX philosophy".

      The most pathetic example of this anti-systemd laziness, is of course "ConsoleKit". It has now been unmaintained for +1½ years, but it is a crucial piece of infra-structure for any Desktop. But instead of either maintain it or make an alternative, anti-systemd people just rant against Gnome for no longer making it a priority to support this piece of abandonware. All rant and no work.

    8. Re:I see a lot of discussion about systemd by fast+turtle · · Score: 1

      Very valid point about the boot speed obsession. If I'm running Linux, I simply don't give a damn about boot speed because I don't have to boot but once a year. If WIndows didn't push out updates every fucking month (nor require them) I'd not have to reboot but when the power goes out for more then a couple of hours as my battery backup offers 3+ hours of standby time when system goes into S5 mode.

      One of the damn reasons I don't like SystemD is the monolithic design. Simply put, the fucking idiots are pushing a Windows style boot instead of a minimal boot that SystemV-init followed. Totally against the KISS principles.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    9. Re:I see a lot of discussion about systemd by fast+turtle · · Score: 3, Interesting

      I'm an old school user and absolutely hate SystemD because it absolutely violates the LFSH standard by requiring /usr to be part of the root file system. This is the primary complaint against SystemD in regards to the Gentoo community and I'm sorry to see that Debian has fallen for breaking the KISS principle.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    10. Re:I see a lot of discussion about systemd by maxwell+demon · · Score: 2

      Those people want both Windows and Open Source. Maybe ReactOS would be a better match.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    11. Re:I see a lot of discussion about systemd by Junta · · Score: 1

      The point being that boot time is the most *visible* benefit and the rest of the benefit is dubious at best. It's interesting to see people create strawmen of complexity. In one case, they went through someone who got permission denied in error_log for apache and then understood to check permissions and selinux context. They then manufactured a straw man of someone confused by that doing service httpd status to see if it was running (who the hell get's http error 401 and wonders if the httpd service is running at all), who then looks at apache log, see file permission based error, and then goes to /var/log/messages. They say how with all this magic, they run status on the service and sees related messages (of course they conveniently avoiding having the general volume of log entries that would betray how awkward that is).

      It's all the problem of people who do this for a living instead of a means to an end. It's easy to completely lose perspective when you spend too much time overthinking things. The best designs are really done by people with another job to do and wanting the least fuss and muss out of these sorts of things.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    12. Re: I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      No expert, but this couldn't say more clearly that it's not a systemd requirement: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

    13. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      Any program unconstrained in scope will grow into a monolithic mess.

      e.g. Emacs

    14. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      eudev let you out of it, obviously it got a load of criticism for doing that by the usual suspect, but is still working fine.

    15. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      ... If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.

      Anybody without a proper rescue boot media is up shit creek when a system is so broken that the binary tools doesn't work any more, be it journalctl or grep or cat. And frankly, working directly on system with a RW filesystem where fundamental tools doesn't work is simply bad practise anyway.

      With a boot media it is a piece of cake to read the journald log files. You can even merge them with the boot media's log files to compare the boot processes. systemd and journalctl are designed to work with multiple log files from different machines at the same time, while doing wizard-like sorting and comparison, and integrity checking, and ...

      So even in this situation systemd is superior in functionality compared to old style syslog text files. Yeah, I thought that binary log files was an evil thing too, but systemd's implementation proved my prejudice wrong.

    16. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 1

      has a few useful features (often, subjectively, questionably implemented),

      ability to kill runaway processes reliably is not a useful feature? starting services on demand is not a useful feature?! Those are only two effects of using systemd, useful both on workstations and servers.

      as for monolithic: it's about as monolithic as the linux kernel (psst, it also comes in a single tarball)

      and while the solutions they provide are rather heavy handed, they solve actual, real problems

    17. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1, Troll

      Obviously, there's been a big push across the board by many various distros, but what are the real benefits of systemd? Is it better for average end-users (Easier? Faster?) or those more technically inclined (more stable, uses less resources, more configurable)? Or is this simply a case of it just being non-Canonical?

      First, sysvinit sucks. All other Unix'es have abandoned it years ago. Only lethargy and lack of real improved Linux init-systems kept Linux on this sinking boat.

      Linux distros have historically been extremely fragmented with no commonality between them for doing even simple things. It is impossible to make a simple distro agnostic gui that shows what the distro is called, or how to set time, or change the network values. There are probably 20 known different places that distros hide their name and release number.

      There was also a widening gap between the development of Linux kernel features, and what user programs actually used. There simply wasn't any common infra structure.

      systemd is an (very successful) attempt to create common Linux plumbing system that tries to solve the problems described above. It is incredible helpful towards all desktop environment developers with such a common and uniform platform, they can now easily make distro agnostic programs that can do interesting and useful things, and eg. both Gnome and KDE can remove huge chunks of fragile code concerning user and session management.

      By tying the init system with the kernel, it suddenly becomes possible to do things impossible before, like logging from the second the kernel gets boot strapped, or using cgroups to ensure that important things gets priority (from desktop startup process, to give priority to foreground video's)

      From logging, to program development, to speed and resource improvements, systemd is superior to anything else out there on every thing that is even slightly important. That is why almost every distro is embracing it, or is going to adopt it in the future (even Slackware will in the end). Disregarding rants against one of systemd main developers, Poettering* and empty platitudes about "UNIX philosophy" or "KISS", systemd is simply the most technical superior Linux init system in existence.

      So the future Linux development stack is systemd, cgroups, kdbus and Wayland, It is an incredible powerful combo.

      *Poettering, a main systemd developer among the +400 contributers, are often accused of making sound actually work on Linux with his Pulseaudio sound daemon. A crime not easily forgotten by those people that now posses useless knowledge about arcane Alsa rituals needed to do anything useful in the days before PA.

    18. Re:I see a lot of discussion about systemd by Grishnakh · · Score: 1

      >You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.

      As long as the logfiles are standardized, this shouldn't be a problem. Do I worry if I need to look at a .zip file or a .tar.gz or .tar.bz2 file? Of course not, because any Linux system has the tools available to view these archives. The only real problem is if I want to view something like a .tar.gz on a Windows system, but even viewing and editing text files is problematic on Windows since it uses a different line-ending standard than Unix and Linux systems, so you can't even claim that those plaintext logfiles can be viewed anywhere. Try opening plaintext logfiles in Windows Notepad and see what happens. Or try grepping that logfile for some string; oh right, you can't, because Windows doesn't have grep. You're just used to plaintext logfiles because Linux systems all have lots of tools useful for viewing those files and extracting data from them. When Linux systems all (or mostly) have systemd, they'll have the tools useful for viewing systemd logfiles as well.

      Imagine if some Linux distro had plaintext logfiles, but they were all gzipped. Would you be complaining about that? How trivial is it to extract data from logfile.gz? Using tools like zgrep, zcat, or regular piping and redirection, it's trivial. It shouldn't (in theory) be any different with systemd logfiles; just use the appropriate tool to extract data in textual form (this tool probably has options to perform useful filtering on the data), and then you can pipe this into something else to process it further.

    19. Re:I see a lot of discussion about systemd by peter.kese655 · · Score: 1

      We run a server farm using Ubuntu servers for years and I can tell: I like Ubuntu but Upstart is a pain and it is broken. We will probably switch to Debian if they adopt systemd. It is no wonder that Redhat and Suse have tried it but switched away.

      In addition... all modern systems, especially laptops, have to adopt to much more varying hardware and networking situations than what was the case in the past. Add in the containers, cgroups and other server functionalities, I really think we should get something more powerful than bash scripts to sit in between kernel and the userspace.

    20. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      I'm an old school user and absolutely hate SystemD because it absolutely violates the LFSH standard by requiring /usr to be part of the root file system. This is the primary complaint against SystemD in regards to the Gentoo community and I'm sorry to see that Debian has fallen for breaking the KISS principle.

      No, systemd didn't break anything. It is merely the messenger that tells that a separate /usr is a broken idea on a modern Linux. systemd works fine with a separate /usr, but your Linux distro probably doesn't.
      Just use "initramfs" if you actually have a real need for a separate /usr.

      Look here for more information:
      http://freedesktop.org/wiki/So...

    21. Re:I see a lot of discussion about systemd by Sri+Ramkrishna · · Score: 1

      Yep. Pretty much. Good post.

    22. Re:I see a lot of discussion about systemd by Sri+Ramkrishna · · Score: 1

      Not only kill runaway process, but contain them in their own jail so that they don't take too many resources. (eg cgroups)

    23. Re:I see a lot of discussion about systemd by Junta · · Score: 2

      With a boot media it is a piece of cake to read the journald log files.

      My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of those projects have to be aware and pick up updates. I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.

      It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling. The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.

      I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    24. Re:I see a lot of discussion about systemd by Junta · · Score: 4, Insightful

      Actually, I would complain if the currently active log file were gzipped. It's a needless impediment to read the files. Besides, once a developer has said 'gzip' the files, then they decide 'well, I can bzip them', then later 'oh, well, .lzma is good', then 'oh, use xz'.. This is the sort of situation that systemd sets up: a treadmill where diagnostic environments must match runtime environments or else.

      When Linux systems all

      This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world, and now systemd systems will break from that strategy.

      Just because you *can* do something doesn't mean it should be done. Just because this is one way at getting to more sophisticated log analysis infrastructure doesn't mean there is not a better way which would have made everyone happy.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    25. Re:I see a lot of discussion about systemd by Unknown+Lamer · · Score: 3, Interesting

      The worst part is that systemd existed about ten years ago: GNU Daemon Managing Daemon, written in Scheme. It has recently been resurrected as the init system of GNU's Guix distribution... instead of ini-files (which have gotten out of control already in systemd and have transformed into an absurd little programming language with awful syntax and undefinable semantics) you extend it using Scheme modules which can be loaded without recompiling the entire daemon. New functionality is implemented as classes, methods, and plain old functions (better than shell pseudo-functions and "well just add a new ini key in C").

      I'm not sure why we're reverting to an init system written in a barely-typed static language that doesn't have garbage collection (I really like it when a process I can never kill has any chance of leaking memory), can segfault with nothing more than a small typo, requires new releases to add even minor new features, and has an upstream that is ... difficult (I mean come on, rejecting patches to support not-Linux? Even when an offer to maintain the other system comes with the patch?), ... especially since Debian has (except for the whole GFDL is non-free spat) been pretty closely aligned with GNU.

      --

      HAL 7000, fewer features than the HAL 9000, but just as homicidal!
    26. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      With a boot media it is a piece of cake to read the journald log files.

      My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of
      those projects have to be aware and pick up updates.

      That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.

      If you run a distro using systemd, LVM, Btrfs, or any other such newish technology, you need a boot media to match, and not rely on your old 1995 edition of Yggdrasil Linux. Floppies just aren't reliable these days anyway.

      I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.

      It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling.

      First of all, the systemd log file format is fully documented and covered by the interface stability promise. Look here for more information:
      http://www.freedesktop.org/wik...
      So it isn't going to change suddenly. So it isn't a problem at all.

      Secondly, there are already many tools and programs that can directly read and manipulate the journald log files. Among these are of course good old syslog-ng that now handles such log files natively. There are more to come, especially since it is now possible to make GUI logviewers that actually work because of the structured file format.

      The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.

      I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.

      Not sure what exactly you are complaining about here, so I am guessing.

      Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way), and because the present logfiles effectively had become an API because of those many many log analysing scripts SA are using. Of course, there was also several different syslog variants too.

      It is of course very easy to convert journald log files into text files if that is what you want, syslog will do this automatically, but it has excellent export tools too.

      It is quite possible view MS-Windows event-log files from Linux. You can't use cat or less, but there are actually programs available.

    27. Re:I see a lot of discussion about systemd by Grishnakh · · Score: 1, Insightful

      This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world,

      No, we haven't. We do exactly the same thing as Windows. We use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows. We like to call this "plaintext", but it's really a misnomer for a very particular binary encoding standard. (Go back in time and find some sysadmin for an EDBDIC system and ask them what their definition of "plaintext file" is.) So you can't easily view and work with these files on a Windows system (just try opening one of these files in Notepad). Do we care about this? I don't know about you, but I don't; any Linux or Unix system can view Unix-standard text files just fine, and that's all that matters.

      The same goes for cases where the file is gzipped; there isn't a Linux system from the last 20 years that doesn't have gzip installed. And on modern systems, xz is commonplace as well.

      The only thing that matters is if your data, in whatever format it's in, is easily accessible and manipulatable. For those of us using Unix or Linux, there's various kinds of files which are: "plaintext" (ASCII/Unix EOL), gzipped, bzip2ed, even pkzipped, because these all have easily and universally-available tools to access this data: you can expect any modern Linux system to have these tools installed by default. As long as the tools to view and manipulate systemd logfiles are similarly prevalent (which they will be on any systemd distro, as long as they don't go changing the binary standard for these files), it'll be no different. No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).

    28. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      Ups, a paragraph sign wasn't made properly. The "My boot..." paragraph belongs to the OP of course.

    29. Re:I see a lot of discussion about systemd by deragon · · Score: 1

      You are thinking server. Linux is also about the desktop. And you will shutdown your laptop more often to preserve battery, particularly on laptops where unfortunately, suspend to ram is not working.

      Same for a console like SteamOS.

      --
      Remember the year 2000? They promised us flying cars. They delivered the PT Cruiser...
    30. Re:I see a lot of discussion about systemd by Junta · · Score: 1

      That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.

      Oh, I'm glad you can tell me what I know. I have to support a wide variety of systems, thousands of servers, I don't get the luxury of supporting only one version or even one distribution of linux or even just linux. Things like systemd exacerbate the problem of managing a heterogeneous environment where versions, distros, and platform can vary greatly. Things aren't rosy in that situation to begin with, but that's no excuse to take liberties to make things even worse when a better thought out scheme would still work.

      Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way)

      How is that different between journald and structured text logs? systemd also requires someone do the effort to make loggers play nice with it. If you've done the work to create an API through which 'good little boys and girls' will log through that to allow structure to be known, you can make the text file readily available alongside/in conjunction with binary metadata. You say 'syslog will do that automatically', but the target clearly is to discourage that from being the case (Fedora no longer runs rsyslog by default).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    31. Re:I see a lot of discussion about systemd by Junta · · Score: 3, Insightful

      use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows

      Dealing with \r\n versus \n is *totally* different scale than this. Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r'). EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.

      And on modern systems, xz is commonplace as well.

      My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.

      No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).

      I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation. I still would be in a fix despite having all the filesystem and block device wrangling required to get at the files.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    32. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0, Interesting

      Systemd is a steaming pile of shit, but this is standard for anything coming from Poettering.

    33. Re:I see a lot of discussion about systemd by Grishnakh · · Score: 1

      Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r')

      So you need to install extra tools... I don't see how that's different.

      And besides, how do you grep through Unix logfiles on Windows anyway? Oh yeah, install extra third-party tools from somewhere....

      EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.

      There's nothing "screwed up" about it, it's simply a different encoding. There's nothing sacrosanct about ASCII, it just happens to be the most popular encoding, which makes it a de-facto standard, but it's not the only way to encode text.

      My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.

      xz performs better than gzip; that alone justifies its use. It's not like it takes a lot of hard drive space. And it hasn't replaced gzip; every system still has gzip installed, along with bzip2, even though the latter has fallen out of use (and never was used that much to begin with). And IIRC, gzip still decompresses .Z files. Everything is backwards-compatible. Who cares if there's something else later, as long as backwards compatibility is maintained? And it's not like we've had a plethora of compression tools in the last decade anyway. ZIP and RAR go back to the early 90s, there's some truly ancient formats from before then in the DOS world (like .zoo) but in the Linux world of the last 10-15 years there's only been gzip, bzip2, (both over 10 years old) and now xz. So really, we've only had one new tool in the last decade.

      I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation.

      That's why you don't use ancient systems to work on newer systems. Try reading a bzip2 file on some ~1996 Slackware system; if you want to use newer stuff, you have to move to newer systems and software. There's nothing new going on here besides the normal progression of technology and standards, you're just complaining because someone is trying to introduce a new standard and you never want to change anything, at all, ever.

    34. Re:I see a lot of discussion about systemd by ChunderDownunder · · Score: 2

      'uniform Linux plumbing system' ?

      Last I checked, KDE ran on Open/Net/FreeBSD and even Windows and OS X. Gnome, which seems to be largely a Red Hat driven technology these days, couldn't give a rat's arse about portability but why should other desktop environments be steered to Linux-only?

    35. Re:I see a lot of discussion about systemd by trek00 · · Score: 1

      You get the point. No one seems to care about servers vs. desktop clients, even if most Debian install are servers, not desktops as they use Ubuntu for that.

    36. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      Oh, I'm glad you can tell me what I know. I have to support a wide variety of systems, thousands of servers, I don't get the luxury of supporting only one version or even one distribution of linux or even just linux. Things like systemd exacerbate the problem of managing a heterogeneous environment where versions, distros, and platform can vary greatly. Things aren't rosy in that situation to begin with, but that's no excuse to take liberties to make things even worse when a better thought out scheme would still work.

      systemd is going to make your life so much easier in the future. I suggest you take your time to do some serious study on it, it will really pay off.

      But to the point: you don't have to support a myriad of Linux's. If the rescue boot media can booth the hardware and read the filesystem, then you can read the journald log files. If the original system is up, then if NFS or similar works, you can also export the journald log file directory and work on it on a remote machine.

      How is that different between journald and structured text logs? systemd also requires someone do the effort to make loggers play nice with it.

      systemd solves this problem in a rather elegant way. It could in theory then just dump the log files in a semi structured text format, but then you would lose the power of an indexed log file. That index is insanely useful and extremely fast. And there is transparent auto compression, integrity checking, sealing, and all sorts of nice things you can do with a structured database.
      The many advantages of a binary log file format, far outweighs any advantages by using a text format.

      If you've done the work to create an API through which 'good little boys and girls' will log through that to allow structure to be known, you can make the text file readily available alongside/in conjunction with binary metadata. You say 'syslog will do that automatically', but the target clearly is to discourage that from being the case (Fedora no longer runs rsyslog by default).

      Come on, that syslog isn't included isn't a problem for anybody remotely interested in having a text file copy of the logfiles. A simple command like "yum install syslog" will deal with that.

      But the fact is that syslog just isn't needed on most Fedora installations. Syslog-ng is still useful as a log sink, but isn't needed on systemd systems.
      journalctl is simply such a good tool, that I fail to see what benefit a duplicate text copy of the log files will provide, unless there are some legacy stuff that needs support.

    37. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 1

      I actually perfer writing unit files for systemd, and I prefer that it has many things already build in. I prefer that it enables me to use cgroups to manage processes. I like that it has proper socket based activation. I like that it centralizes a lot of things about the linux system.

      Yes, not everything about it is perfect.. but from my experience it works better than current systems based on shell scripts, and upstart which... I don't like the event system. It feels backwards.

    38. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 2

      'uniform Linux plumbing system' ?

      Last I checked, KDE ran on Open/Net/FreeBSD and even Windows and OS X. Gnome, which seems to be largely a Red Hat driven technology these days, couldn't give a rat's arse about portability but why should other desktop environments be steered to Linux-only?

      Yes, that is true last time you checked, and next KDE edition (KDE SC 5/Plasma 2) will of course also run on *BSD. But with reduced functionality on all non-systemd systems, compared with the systemd version.

      This is not because of some sinister conspiracy, but because systemd offers easy use of many nice features that KDE and Gnome (and LXQT etc) would like to use, and non-systemd systems doesn't provide.

      The point is exactly, that systemd is a very nice uniform Linux plumbing system, and that DE's are starting to take advantage of that.

    39. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      Only on slashdot could you get a heap of hot, unsubstantiated air (vastly superior blah blah blah) and an sweeping ad hominem rated as "5, insightful".

      Fuck beta, but hey, does it matter? With the quality of the posts and moderators being what it is these days, who really cares. It's dead Jim. Put a Beta in it!

    40. Re:I see a lot of discussion about systemd by rduke15 · · Score: 2

      You are thinking server. Linux is also about the desktop.

      Are you kidding?

      How many servers run Linux?
      How many Desktops?
      Who cares about Linux (who is the "audience" for Linux)?

      My main machine is actually a Linux notebook. It's a pretty miserable desktop, but it's OK for what I do, and I have the comfort of a real shell, and real keyboard with all the keys, and can try out sonme server stuff on my notebook. But I could replace it with a Mac or Windows notebook if necessary.

      Where I really care about Linux is on servers. Headless servers, with neither Gnome nor KDE installed.

      Until now, I heard that systemd would boot faster. Maybe it has some other benefits for servers, but boot spped is certainly not one of them. The servers spend much more time in the BIOS screens than booting the OS, and they reboot about once a year or less. So to convince me, it will need much more than a few seconds of boot speed...

    41. Re:I see a lot of discussion about systemd by shutdown+-p+now · · Score: 1

      The only real problem is if I want to view something like a .tar.gz on a Windows system, but even viewing and editing text files is problematic on Windows since it uses a different line-ending standard than Unix and Linux systems, so you can't even claim that those plaintext logfiles can be viewed anywhere. Try opening plaintext logfiles in Windows Notepad and see what happens.

      \r\n is the standard way of saving text files on Windows, sure, but any sane Windows application can still understand \n line endings, just as it can understand / as path separator. Any application that is compiled with Visual C++ and uses its standard library to read files (i.e. fgets or std::getline) will handle this just fine. Notepad just happens to be this particularly obnoxious piece of software that doesn't get it right, despite numerous complaints to the developers. I am not aware of any other Microsoft software that doesn't handle this, and I can't recall the name of any third-party software that I've seen that would not handle it, because the last time I saw such was many years ago.

      Or try grepping that logfile for some string; oh right, you can't, because Windows doesn't have grep.

      Sure it does, it's called findstr. And then there's also select-string if you're in PowerShell (which, again, is preinstalled on Win7+).

    42. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      xz performs better than gzip; that alone justifies its use.

      Depends on what you mean by "performs". It (typically) provides a better compression ratio, but is significantly slower to compress and decompress. gzip (and other even faster algorithms like lzo) still have a place, especially where compression is used in a live system (filesystem level compression, for example). Even bzip2 has a place to shine, as it is faster than xz and produces smaller files when compressing relatively-small text files (such as manpages).

      Aside from being a minor diversion about compression algorithms, I suppose my larger point is that older tools have their place, even when something new comes along that "replaces" it by being "better". Quite a few people don't mind that systemd exists, they just mind the voracity with which it is pushed to replace all init systems, forever by some developers. Right tool for the job and all that -- one-size-fits-all typically doesn't actually fit all.

    43. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      Like the Linux kernel, who do firewalling and routing, and also have several redundant filesystem, start to absorb X11 and several differents messages passing ( or IPC ) systems ? And with several API for security, and this kind of stuff ?

    44. Re:I see a lot of discussion about systemd by erik.martino · · Score: 1

      In the cloud, boot speed matters a great deal. You want to be able to scale quickly in response to increased load.

    45. Re:I see a lot of discussion about systemd by KMSelf · · Score: 1

      There are numerous solid reasons for /usr

      • Network boots.
      • Partitioning in general
      • Modular filesystem permissions (I can mount /usr/ ro,nodev, / requires dev and write access

      There are others, but that's just off the top of my head.

      I've been watching Poettering's comments and attitude, and have to say I've got a bad feeling about this. Too complex. Not a sufficiently compelling use case.

      --

      What part of "gestalt" don't you understand?

    46. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      There are numerous solid reasons for /usr

      • Network boots.
      • Partitioning in general
      • Modular filesystem permissions (I can mount /usr/ ro,nodev, / requires dev and write access

      There are others, but that's just off the top of my head.

      I've been watching Poettering's comments and attitude, and have to say I've got a bad feeling about this. Too complex. Not a sufficiently compelling use case.

      systemd fully support a separate /usr .

      There may be solid reasons for a separate /usr, and Lennart agrees on that. His whole point is, that actual Linux distros no longer support a separate /usr, which result in spurious and hard to track and debug bugs, which is why systemd issues warnings with such setups, unless you use initramfs. You can always ignore the warnings.

      He actually have a very fine technical explanation here:
      http://freedesktop.org/wiki/So...

    47. Re:I see a lot of discussion about systemd by Bill,+Shooter+of+Bul · · Score: 1

      Systemd handles all the difficult edge cases with init systems better than anything else. It won't start things in the wrong order, deadlocks can be detected in configurations without having to boot, It will always cleanly unmount file systems, it won't lose track of forking daemons.

      As an end user of a single desktop, you're unlikely to notice a difference between upstart and systemd aside for the differences in syntax when managing daemons. The edge cases that upstart sucks at are relatively rare occurrences that I've been fortunate to avoid.

      As a developer, I love the idea of systemd. I want to rewrite my ( in house, proprietary ) daemons to require it.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    48. Re:I see a lot of discussion about systemd by Bill,+Shooter+of+Bul · · Score: 1

      Exactly.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    49. Re:I see a lot of discussion about systemd by Grishnakh · · Score: 1

      So what about filesystems? What are you going to do when your hard drive, with ext4-formatted filesystems, has a problem and you want to plug it into a system that only supports ext3? That's right, you can't. Of course, this isn't a problem now since ext4 is common, but it was when ext4 was brand-new, and it's probably still a problem if you try this with btrfs. Did you make the same complaint about ext4 (and ext3 before it), that you wouldn't be able to use it on older OS installations?

    50. Re:I see a lot of discussion about systemd by Junta · · Score: 1

      you're just complaining because someone is trying to introduce a new standard and you never want to change anything, at all, ever.

      I'm saying charging forward without any significant regard for adequate backwards compatibility is lunacy. Also, any advance that changes things in an incompatible way needs to be weighed carefully for benefit versus cost. On two fronts I see systemd as problematic: neglecting optimal backwards compatibility 'just cause' and if we embrace that vision, then what are we getting in exchange? Not really that much in practical benefit (yes, journalctl can do all sorts of tricks that most people never even felt the need for).

      --
      XML is like violence. If it doesn't solve the problem, use more.
    51. Re:I see a lot of discussion about systemd by Junta · · Score: 1

      systemd solves this problem in a rather elegant way.

      My question was that 'structured text log requires cooperation of the logging program' was a tick against structured text, but I don't see how that argument does not equally apply against journald. You needn't lose the power of an indexed log file either. The one use case you put forth that can *not* be accomodated is compressed. Sealing, integrity checking, and indexed operations can be done through discrete storage of textual bulk data and binary metadata.

      A simple command like "yum install syslog" will deal with that.

      Small comfort if you find yourself trying to debug a problem on a non working system that had not yet done that step. There is a pretty large red flag that should be going up when a facility with nearly 100% append data intended for diagnostic purposes disregards the value of plain text logs.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    52. Re:I see a lot of discussion about systemd by Junta · · Score: 1

      So you need to install extra tools... I don't see how that's different.

      Those aren't extra, they come with windows.

      And besides, how do you grep through Unix logfiles on Windows anyway? Oh yeah, install extra third-party tools from somewhere....

      Actually, Windows comes with servicable grep equivalent out of the box, but that's not really the use case I care most about.

      There's nothing sacrosanct about ASCII, it just happens to be the most popular encoding,

      *EVERYTHING* for the last several decades can translate ASCII to a human consumable form. That's pretty damn significant to ignore.

      xz performs better than gzip; that alone justifies its use. It's not like it takes a lot of hard drive space.

      My point was being too aggressive about switching between technologies adds a lot of complexity to trying do support a mixed environment.

      That's why you don't use ancient systems to work on newer systems.

      CentOS 6 is the *current* version. If you install CentOS *today* that's what you get.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    53. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      My question was that 'structured text log requires cooperation of the logging program' was a tick against structured text, but I don't see how that argument does not equally apply against journald. You needn't lose the power of an indexed log file either. The one use case you put forth that can *not* be accomodated is compressed. Sealing, integrity checking, and indexed operations can be done through discrete storage of textual bulk data and binary metadata.

      Mixing binary metadata and text, well that sounds nasty to me. I wouldn't trade in the advantages of pure text log files for binary ones, unless there was huge improvement; a small, or even partially large improvement wouldn't sway me.

      I think that journald is a huge improvement on all important matters over simple text log files; I was sceptical at first, but it is really well designed full of small features that shows it is made by people who cares about people working with CLI UI's. Tab completion everywhere, including switches like "journalctl --(TAB)" shows all full length switches. Nice.
      It also knows about every field and record and their values, so you no longer have to plod through the log files just to see what the daemons are called, or even what daemons have written to log files. It just goes on and on with features that doesn't exist in syslog systems.

      You may claim that some if not all these features could have been implemented in syslog, I personally don't think so. I have seen many syslog implementations come and go over the years, all hoping to improve the messy Linux logging. There have been improvements, but nothing comparable to journald.

      It is not that syslog developers are stupid and lazy; I happens to think that many of them are quite sharp, like Rainer from Syslog-NG. So there are probably other reasons why they didn't improve things to the level that journald does.

      A simple command like "yum install syslog" will deal with that.

      Small comfort if you find yourself trying to debug a problem on a non working system that had not yet done that step. There is a pretty large red flag that should be going up when a facility with nearly 100% append data intended for diagnostic purposes disregards the value of plain text logs.

      Not sure what scenario exactly you are describing here, but if it is possible to mount /var in any way, or exports its contents with NFS or similar, or even copying files manually through USB, then it is possible to read the journald logfiles in that rather singular event that journalctl for some reason doesn't work.

      I am sure that you can construct a contrived scenario where neither thing from above is possible, but that doesn't convince me at all. In the real world (and yes, I know how sucky it is to admin other peoples stupidly broken setups), it just isn't a problem that journald log files are binary.

      It is on the other hand, easy to argue, that debugging broken systems are incredible more easy and powerful on systemd enabled machines; you get logging much earlier than syslog provides. Stuff like "systemd-delta" shows in an instant, exactly what non-default config files are used by the daemons and so on. The "-x" switch that enables Journal Message Catalogues; think how nice it would be, if the daemons error messages where explained in some detail, intertleaved with the actual log messages, but only when needed. Oh, including (click-able) links directly to those responsible for the daemon for further information.
      Monotonic timestamps when comparing to different server's intertwined service and daemon startup, is a piece of cake on systemd. The list just goes on and on.

      My point is, that for every contrived scenario where binary log files may be a problem, I can give multitudes of everyday scenarios where they and systemd, is a vast improvement over the existing Linux init and logging systems.

    54. Re:I see a lot of discussion about systemd by Cramer · · Score: 1

      Instead of actually getting together to make an alternative development stack to systemd

      We don't need to. sysvinit WORKS; it's stupid-simple, small, and trivial for anyone with a brain to actually manage. I don't get the whole push for databases, binary logs, 100k+ lines of C code... to do what a few hundred lines of shell scripts and config files have done for decades -- with a shell that's going to be on the system anyway.

      (I'm not saying the BSD way of *one* shell script (rc.conf) is the way to go, but systemd is the super-complex bazaaro version of rc.conf.)

    55. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      Instead of actually getting together to make an alternative development stack to systemd

      We don't need to. sysvinit WORKS; it's stupid-simple, small, and trivial for anyone with a brain to actually manage. I don't get the whole push for databases, binary logs, 100k+ lines of C code... to do what a few hundred lines of shell scripts and config files have done for decades -- with a shell that's going to be on the system anyway.

      (I'm not saying the BSD way of *one* shell script (rc.conf) is the way to go, but systemd is the super-complex bazaaro version of rc.conf.)

      There are two options here; either you are the bright and really informed person, that knows better than all enterprise Linux distros from Red Hat/CentOS, to Suse and Debian and all the other Linux distros switching to systemd, or else, they may have some knowledge and insight you don't have.

      The fact is, that systemd, together with Wayland, kdbus, and cgroups, are the future Linux plumbing system and development stack.

      sysvinit is simply on life support now, together with X. They both served well in the past, but they should both have been retired from Linux years ago. Now there are alternatives, superior in every way, which is why people join up behind them.

      Don't get left behind when the future arrives.

    56. Re:I see a lot of discussion about systemd by Cramer · · Score: 1

      Do the phrases "designed by committee" and "political motivation" mean anything to you? The "other distros" are jumping on systemd as a "me too" reaction more than any real technical merit. (generally, the people making the call are not technical people.) GNOME and udev are two of the prime pushes to go with systemd -- as systemd has eaten udev, and GNOME requires logind. systemd does have a few pluses, but it also hauls in a truck load of unnecessary, and complex, bloat.

      I don't give a shit what the systemd or upstart camps claim about shell scripts; writing, testing, and debugging init scripts is trivial. (making a single script for *every* distro can be trying, because they all do things a little different. if you think distros aren't going to do the same thing to systemd, think again.)

    57. Re:I see a lot of discussion about systemd by Peter+H.S. · · Score: 1

      Do the phrases "designed by committee" and "political motivation" mean anything to you? The "other distros" are jumping on systemd as a "me too" reaction more than any real technical merit. (generally, the people making the call are not technical people.) GNOME and udev are two of the prime pushes to go with systemd -- as systemd has eaten udev, and GNOME requires logind. systemd does have a few pluses, but it also hauls in a truck load of unnecessary, and complex, bloat.

      I don't give a shit what the systemd or upstart camps claim about shell scripts; writing, testing, and debugging init scripts is trivial. (making a single script for *every* distro can be trying, because they all do things a little different. if you think distros aren't going to do the same thing to systemd, think again.)

      Those phrases are totally content free. "political motivation" can mean sinister hidden agendas, or an impetus to stop social wrong doings. Accusing developer driven distros like Arch Linux for "political motivated mee-too" following is just plain laughable.

      I don't find it credible that you, unlike all the really, really smart people involved in Linux distributions, are gifted with special clear sight, that makes you see the hidden caballistic plot behind systemd.

      Sure, systemd is a new way of doing things on Linux, but it is worth it. There seriously isn't any love among developers or users for sysvinit anymore. It is a dead end that survived far too long in Linux.

      Consider the possibility that you may be wrong, and that you just align your judgements along what is comfortable and known for you. And even though you like sysvinit very much, it wouldn't hurt you learn about systemd either.

    58. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      Is this plumbing system so magic that cannot be implemented on existing systems?

    59. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      e.g. Linux (it is afterall a monolithic kernel)

      vi: the 'write' way....

    60. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      systemd provides a a common, uniform Linux plumbing

      That's not true. The API and documentation are a mess. Poor code organization including things as simple as modularity. Note that I am not talking about the processes or threads. The code has been written by people who talk a lot but are disorganized and don't think systematically. Just lists of features. To take just one example amongst many the binary logging could easily have been modularized but they chose to closely bind it for no particular benefit despite their claims.

    61. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      This plumbing system isn't magic. Before systemd, nobody had a convenient way of plumbing together the system like system. If you can write your own plumbing that isn't systemd, maybe people with use it.

    62. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      I think the main problem with those of us who don't like systemd, is that sysvinit is fine.

    63. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      And the fantastic thing about standards is that there are so many of them, everybody can have their own!

    64. Re:I see a lot of discussion about systemd by Anonymous Coward · · Score: 0

      systemd is an (very successful) attempt to create common Linux plumbing system that tries to solve the problems described above. It is incredible helpful towards all desktop environment developers with such a common and uniform platform, they can now easily make distro agnostic programs that can do interesting and useful things, and eg. both Gnome and KDE can remove huge chunks of fragile code concerning user and session management.

      So 2014 is the Year Of The Linux Desktop? I'm so excited!

    65. Re:I see a lot of discussion about systemd by Gryle · · Score: 1

      I don't run a server. I run Linux on my desktop and my tablet (Mint on a Dell XPS12). Am I no longer part of the audience?
      (Please note that I don't have enough technical knowledge to debate Upstart vs systemd. I dislike being dismissed as not part of the "audience" because I don't use Linux in the same way you do.)

      --
      Only two things are infinite, the universe and human stupidity, and I'm not entirely sure about the universe - Einstein
  10. Gee by Ultra64 · · Score: 5, Insightful

    Who would have thought there would be consequences to spamming every article with whining and bitching?

    1. Re:Gee by Anonymous Coward · · Score: -1

      You are a fucktard. You don't see the evil of what happened to a fellow user only because it's not you who's being abused by people who really care a shit about you. Enjoy this next week, moron, and probably the inevitable future. One day you will deeply regret what you did, or didn't do now.

    2. Re:Gee by madprof · · Score: 1

      It's just a news site. There are loads of others. Calm down.

    3. Re:Gee by Anonymous Coward · · Score: -1

      There is no winning this fight. There is no financial incentive for DICE to do anything with Slashdot. There's a reason the site keeps being sold. The redesign was their hope to be able to salvage the site financially. If you get what you want, you're still fucked: the place will probably be shut down anyway. So what exactly are you doing besides spreading hate and stupidity?

      Not defending the beta, mind you, it's just retarded to pick up the torches and pitchforks instead of trying to work with these people. You have no leverage. I am sure that every dime spent on the site is now, to the owners, a waste. We know that you're not going to foot the bill, either, nor help to program any potential replacement. When they decide to scrap the beta and shut the site down, will you congratulate yourself on the moral victory, having lost the war?

    4. Re:Gee by Anonymous Coward · · Score: 0

      You really believe what you're saying here?

      You sound like you resigned to let others make terrible mistakes and not lift a finger. Do you treat the est of your life this way?

      The people trying to fight the change are not fuelled by hate or stupidity, but by love and logic. We believe in something enough to fight for it. If we could work with DICE, we would, it's they that aren't working with us!

      And as for people not being prepared to help to program a replacement, or footing the bill, you must surely know that's not true. While you sleep, people are doing this right now. It would be great if DICE would provide historical data and code, but they do not care enough I imagine, even after it dies.

      Well, enjoy believing there's nothing that can be done, sadly you might be right, but maybe try supporting those who dare to try.

    5. Re:Gee by Anonymous Coward · · Score: 0

      There are also consequences to driving the users away.

    6. Re:Gee by Anonymous Coward · · Score: 0

      Not defending the beta, mind you, it's just retarded to pick up the torches and pitchforks instead of trying to work with these people. You have no leverage. I am sure that every dime spent on the site is now, to the owners, a waste. We know that you're not going to foot the bill, either, nor help to program any potential replacement. When they decide to scrap the beta and shut the site down, will you congratulate yourself on the moral victory, having lost the war?

      If people didn't have leverage, then they wouldn't be getting IP banned for mildly disapproving...

      Systemd being pushed into debian has a lot in common with this beta...

      The really sad thing is that there'd be a nice easy way of getting the "audience" onboard with this

      Put the beta code on github opensource it and let it be fixed, bet you'd see feature parity with slashcode commenting pretty quickly

      Everyone wins

      Might be too late for it now though, depends on how much trust got burnt away

    7. Re:Gee by Anonymous Coward · · Score: 0

      Strange that /. is usually first to call for premature revolution but here now roll over is +5. The moderation should hide the boycott posts if the community disagrees with it. No need for the authoritarian action which you are condoning.

    8. Re:Gee by Tough+Love · · Score: 1

      There's only one Slashdot.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    9. Re: Gee by Anonymous Coward · · Score: 0

      Not sure what the relevance of that statement is. You assume Slashdot is somehow unique or special in a useful way?

    10. Re:Gee by Anonymous Coward · · Score: 0

      The same way that wikipedia is just an information site?

    11. Re:Gee by gnoshi · · Score: 4, Insightful

      Maybe he was downvoted by all the people who actually want to use the site instead of having to dig through 1000 'boycott Slashdot' and 'BETA SUX0RZZ!!' messages, and this is an example of the moderation system working.

      We get it. Everyone hates beta. I hate beta. However, I hate digging through the 'FUCK BETA!' messages nearly as much as I hate beta. By all means, boycott the hell out of site, but I'll just send feedback and if they don't listen I'll find some other site to read. Then I'll come back and have a peep every couple of months to see if they got the message.

    12. Re:Gee by Anonymous Coward · · Score: 0

      Who would have thought there would be consequences to spamming every article with whining and bitching?

      Uhh.... shill

    13. Re:Gee by DrJimbo · · Score: 1

      Einstein was wrong. DICE does play God with the Slashdot-verse.

      --
      We don't see the world as it is, we see it as we are.
      -- Anais Nin
    14. Re:Gee by Stormwatch · · Score: 1

      In Soviet Russia...

    15. Re: Gee by madprof · · Score: 1

      No. They aren't comparable. Wikipedia has millions of pages of original content. Slashdot is news stories with discussion. Its value is in the ability of the discussion software and quality of the stories linked to.

    16. Re:Gee by Anonymous Coward · · Score: 0

      "Maybe he was downvoted by all the people who actually want to use the site instead of having to dig through 1000 'boycott Slashdot' and 'BETA SUX0RZZ!!' messages, and this is an example of the moderation system working."

      Ten thousands times THIS.

    17. Re:Gee by Anonymous Coward · · Score: 0

      Maybe he was downvoted by all the people who actually want to use the site instead of having to dig through 1000 'boycott Slashdot' and 'BETA SUX0RZZ!!' messages, and this is an example of the moderation system working.

      We get it. Everyone hates beta. I hate beta. However, I hate digging through the 'FUCK BETA!' messages nearly as much as I hate beta. By all means, boycott the hell out of site, but I'll just send feedback and if they don't listen I'll find some other site to read. Then I'll come back and have a peep every couple of months to see if they got the message.

      Fuck Beta you boot licking swine!

  11. Join the slashcott farewell: by Anonymous Coward · · Score: -1

    The Individual Midnight Thread - Farewell

    I'm moving with all the great community of smart people and old-timers to http://www.altslashdot.org/ [altslashdot.org] (server will be up & running in few hours).

    See you all great guys there!

    We are also on IRC ##altslashdot on freenode

  12. Fpailzors! by Anonymous Coward · · Score: -1
  13. I vote for old slashdot over beta upstart by Anonymous Coward · · Score: -1

    Slashdot is officially dead. Beta killed it. Goodbye Slashdot.

  14. Thank You Slashdot by SuperKendall · · Score: 2, Insightful

    Justice is served. Keep up the bans and let's get rid of the deadwood.

    I fully support the rights of a bar to throw out the belligerently drunk - that's not censorship, it's called caring for your customers. None of us are here to read moronic posts about website style changes. We are here to read insightful commentary on technical stories and if you can't handle that, you do not and should not belong.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Thank You Slashdot by Anonymous Coward · · Score: -1

      When you return one day to the bar you helped build for ten years and find it full of 12 year olds discussing about puppys and WWE, and telling you that you are not welcomed there, think again about what you said today. I don't think you really believe a word of what you said, and if you do: I feel sorry for you. For real.

    2. Re:Thank You Slashdot by Anonymous Coward · · Score: 2, Insightful

      I fully support the rights of a bar to throw out the belligerently drunk

      The problem is the drunk one is the barkeep. The patrons told him to stop before he wrecks to whole place, but there is no stopping him. Every day he gets drunk and wreaks half the bar. Soon he'll be drinking alone. And it all started with that damn game of Dice.

    3. Re:Thank You Slashdot by Anonymous Coward · · Score: 0

      We are not customers. The advertisers are their customers, and they are screwing their advertisers over by poisoning the community and reducing its value. "Slashdot abandoned... everything of value was lost."

      I tell you, the behavior of Dice/Slashdot over the course of this fiasco has made me want to not just boycott the site, but leave forever and never come back. After vomiting on BETA.

      “Slashdot only allows anonymous users to post 10 times per day (more or less, depending on moderation). A user from your IP has already shared his or her thoughts with us that many times. Take a breather, and come back and see us in 24 hours or so. If you think this is unfair, please email posting@slashdot.org...”

      Oh, lookee here. Censorship AND gag orders.

      Fuck Dice. Fuck them up their stupid asses!

    4. Re:Thank You Slashdot by seyyah · · Score: 1, Interesting

      The problem is the drunk one is the barkeep. The patrons told him to stop before he wrecks to whole place, but there is no stopping him. Every day he gets drunk and wreaks half the bar. Soon he'll be drinking alone. And it all started with that damn game of Dice.

      So leave. If the new redesign is as bad as promised, I'll leave when the time comes. No need to ruin Slashdot ahead of schedule.

    5. Re:Thank You Slashdot by wonkey_monkey · · Score: 1

      The patrons told him to stop before he changed the wallpaper and took away the pool table, but there is no stopping him.

      FTFY.

      --
      systemd is Roko's Basilisk.
    6. Re:Thank You Slashdot by dmbasso · · Score: 1, Offtopic

      Hopefully your kids are going to take the same stance (ignoring the issue) when you start dying of cancer. Then after you die, they can find another dad.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
    7. Re:Thank You Slashdot by efitton · · Score: 1

      And stopped serving alcohol and limited the jukebox yo Justin Bieber.

    8. Re:Thank You Slashdot by Anonymous Coward · · Score: 0

      Don't forget, they get bereavement funds from the government as well.

    9. Re:Thank You Slashdot by HiThere · · Score: 1

      Did you intend that to make any sense? If you did, you need to explain a bit more.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    10. Re:Thank You Slashdot by Reservoir+Penguin · · Score: 1

      Yes this. I sincerely wish a slow and painful death on anyone participating in the amateurish campaign to hijack threads with irrelevant beta hate posts. Die fuckers. P.S. 10+ years Slashdot poster

      --
      US-UK-Israel: The real Axis of Evil
  15. Upstart is The Slashdot Beta of th init systems? by williamyf · · Score: 1

    Or, the CLAs are the Slashdot Beta of OSS Communities?

    I do not know, just keeping the flame alive... ;-)

    --
    *** Suerte a todos y Feliz dia!
  16. Beware journald... by Junta · · Score: 5, Insightful

    I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible (ambition to replace at, cron, change from running static number of getty on VC specified by inittab to on demand spawning of getty as auto detected). It's clear they regard users valuing plain text data with some disdain. There is plenty of opportunity to achieve the gains whilst concurrently providing a plain text stream to peruse natively, but they have *zero* interest in trying to pursue such paths.

    This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.

    In general, distributions embracing this become increasingly opaque to admins. Distribution behavior flows through an increasingly complex labyrinth of crap that it approaches Microsoft level BS. I'm somewhat disheartened at the possibilities here.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Beware journald... by Anonymous Coward · · Score: 0

      Yes. I don't like SystemD itself but all the baggage it comes with and the dependencies it tries to build are just... it's like some sort of cancerous kraken. Yes. That bad.

    2. Re:Beware journald... by fnj · · Score: 3, Informative

      In general, distributions embracing this become increasingly opaque to admins.

      Essentially all important server distros have caved at this point. RHEL7 is systemd. Pretty sure SuSE and Mageia are (or soon will be) systemd, if there are any of those left. Arch for the server dangerous-livers is systemd. Now Debian.

      I would call all of them lemmings (except Red Hat, which is the actual instigator), except realistically what were they to do? Get left by the wayside? The writing on the wall is clear. For me it's enough to pay a lot more attention to BSD.

    3. Re:Beware journald... by Narcocide · · Score: 3, Insightful

      I too, lament the apparent impending demise of sysvinit shell script startup and plain text logging/process handling. Functional transparency in Linux booting was a good thing, and it will be missed. It seems more to me like these people arguing so hard over whether to replace sysvinit with upstart or systemd as though just leaving it alone was not an obvious option are more interested in changing the Linux init system to something inherently less secure and more obfuscated so that they can leverage it as a tool in some sort of entirely separate logistical/technical/political maneuvering and pissing match. I don't know any actually experienced sysadmins who are not involved directly with upstart or systemd development (and thereby have a vested career interest in promoting one or the other) who think eliminating sysvinit after all these years has any sanity or operational value whatsoever. The actual complaints about sysvinit are things that in practical use are only minor annoyances to the uneducated, quickly overcome by a modest amount of experience. The obvious maintenance nightmares that will be created by what these guys want to replace it with (either systemd or upstart, but for differing reasons) would dwarf any problems anyone ever had with sysvinit even if they were persistent, actual technical limitations, not just basically "user error."

    4. Re:Beware journald... by Anonymous Coward · · Score: 0, Troll

      I don't think I have much qualm about systemd as it relates to the init process.

      Right, ever tried to actually use the fucking thing? Sure I can alias 'halt', 'shutdown' and 'reboot' to systemctl counterparts but none are going to work if I just upgraded dbus. We can list a myriad of issues but making shutdown rely on an ipc daemon... need I go on?

      Can we get some competent engineers in the room over at systemd HQ? Than perhaps when they're done with the required ground-up rewrite of shitstormd, Dice can hire them to fix beta!

      #fucksystemd #fuckbeta #fuckslashdice

    5. Re:Beware journald... by Anonymous Coward · · Score: 0

      The actual complaints about sysvinit are things that in practical use are only minor annoyances to the uneducated, quickly overcome by a modest amount of experience. The obvious maintenance nightmares that will be created by what these guys want to replace it with (either systemd or upstart, but for differing reasons) would dwarf any problems anyone ever had with sysvinit even if they were persistent, actual technical limitations, not just basically "user error."

      The idea that sysvinit is a simple and transparent system may have been true fifteen years ago, and it may still be true on some servers which only have to support a relatively small and static set of hardware, but on desktops sysvinit has become a nightmare. A set of init scripts that is sophisticated enought to cope with a huge and diverse array of hotpluggable devices and devices that may enumerate in arbitrary and unstable ways, appearing and disappearing without warning, may technically be 'just' shell code, but it may as well be a hex dump of an ELF file for all the sense I can make of it unless I have hours to spend examining it. I guess you can call it "user error" that I am not prepared to spend a week becoming a guru in Bash and Linux boot processes just to make a few changes to network startup, but I don't think I am being unreasonable.

    6. Re:Beware journald... by Peter+H.S. · · Score: 5, Interesting

      I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible...

      I was sceptical about binary log-files too in the beginning. However, I didn't have to play around with the journalctl tool before I realized that systemd's logging is far superior to any existing simple text logging.

      stuff like "journalctl -b 2" (only show logs from previous boot) and "journalctl -F _SYSTEMD_UNIT" (show all systemd units that have ever written to the logs) are pure gold. The amount of tab-completion with everything is just so nice. Try "jou (TAB) -F (TAB)" and it will show all possible values.
      You get logging info from much earlier in the boot process then previously, and with kdbus something that will get even earlier and later in the boot process and when shutting down.

      journalctl works great with all the usual text tools like grep, just think of it as a super 'cat' with god-like sorting powers.

      Forget what others sneers about Poettering and systemd, and give it a proper workout with a distro that supports it properly, like Fedora 20 or similar. Make up your own mind by actually using it.

      This is a good starting point:
      http://www.freedesktop.org/wik...

      To me it is clear that systemd simply is the future Linux plumbing system, and to me it is a quite brilliant solution as it is now.

      Especially logging is a huge improvement. Novices can for the first time actually do usable filtering without knowing arcane programs and switches. A simple "journalctl -b -p err" will reveal much of interest for the novice trying to debug a problem. (shows all messages of priority levels ERROR and worse, from the current boot).

      And because the log is structured in db form, there will be GUI logviewers that are actually useful, and that can do filtering and sorting by eg. error levels, monotonic timestamps etc.

    7. Re:Beware journald... by Narcocide · · Score: 3, Informative

      As someone who does run Linux on desktops as well (and has been doing so for much longer than a week) I can tell you conclusively that if you think you need to become a Bash guru just to make "a few changes to network startup" then YOU ARE DOING IT WRONG probably starting with not reading the distro-specific setup instructions, and making the typical noob mistake of assuming that just because something seems evidently possible to accomplish without reading said instructions that reading the instructions wouldn't have uncovered a much easier approach, i.e. the way it was meant to be done.

      Either that or you're misrepresenting the amount of functional alteration you're attempting to actually accomplish with your setup, in which case... boy will you feel betrayed when you find out what type of stuff you'll need to "become a guru in" the first time you don't like the out-of-the-box functionality systemd provides.

    8. Re:Beware journald... by skids · · Score: 3, Interesting

      This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.

      That's disenheartneing to hear, considering how many times I have had to hack the hell out of my init scripts to kill avahi because I DO NOT WANT IT, and the fact that pulseaudio came in and made a mess where jackd was just starting to make things sane, and the time spent would have been better spent improving jackd.

      But on the other hand, jackd had that unfortunate attempt to fork into a C++ reimplementation, and lost its (never fully supported) ability to run as a systemwide daemon so background daemons could use the soundcard, and pulseaudio has since turned an about face and started supporting a systemwide daemon, more RT features (AFAIK not quite yet up to snuff with what JACKd offered) and has been less of a general nuisance recently.

      So, there's something to be said for software that starts out as inferior but due to the charisma and/or persistance of its proponents, eventually manages to get a larger development community, because that community will beat it into shape, and hopefully manage to shed as much cruft left over from the inferior design through a concerted deprecation effort. It's a hassle to us users, but works out eventually. It looks like this has happened and will continue to happen with systemd.

      We could avoid that if the competent projects were somehow given an injection of participants, but people that write necessarily-complex code generally tend to spend most of their time doing just that, not glad-handing on mailing lists, whereas the authors of insufficient simplied solutions have more time to politic. The only part about that that stings is that the latter often uses the former as a cheat-sheet going forward and does not bother to give credit,

    9. Re:Beware journald... by Peter+H.S. · · Score: 3, Insightful

      I think Pulseaudio was a great step forward for sound on Linux. Yes, it did uncover many sound card driver bugs, and bugs in Alsa back in 2004, but that also meant that those bugs got fixed. My internal sound chip was somewhat flakey before pulseaudio, and PA simply broke it completely, but that also meant, that when the bugs was fixed, the sound chip driver and Alsa layer worked perfectly ever since. I just used a popular and well supported SB compatible sound card instead while the bugs where fixed.

      At the time, every other sound daemon was neither system wide, nor working properly. PA solved all problems in a rather elegant way, so for nearly a decade Linux have had an excellent and powerful sound deamon. Sound just work, and the "per application" sound volume is worth everything.

      That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it. If PA ever was so bad as some people like to claim, why didn't alternatives spring up instead?

      Sure, PA doesn't do low latency stuff like Jack, but it was never meant to. Instead PA works in perfect unison with Jack, in that it can suspend itself when certain programs need low latency sound operations, just like PA works on top of Alsa, not replacing it.

    10. Re:Beware journald... by Grishnakh · · Score: 1

      Instead of copying my post about this very thing elsewhere, I'll just link it here:
      http://linux.slashdot.org/comm...

      I really think this plaintext logfile business is overblown.

    11. Re:Beware journald... by Anonymous Coward · · Score: 0

      Yes the systemd thing has pushed me from linux (user/beta tester since 1995, Redhat 4.0 not RHEL) to BSD.
      I have a Arch linux server that uses systemd and bind has to be restarted after startup, it never comes up properly with systemd.
      It also has a problem with ntp under systemd as it always sets the date to Dec 13 1969, the ntpd fails to start.
      I have to ssh into the server and stop ntpd run ntpdate and restart ntpd, then a restart on named and it is good.

      I'll take init scripts any day as this would be trivial to fix using sysvinit.
      Will be moving that server to FreeBSD as soon as I get it built.

    12. Re:Beware journald... by Junta · · Score: 3, Interesting

      I realized that systemd's logging is far superior to any existing simple text logging.

      I accept that is the case, but the approach threw out the baby with the bathwater. They could have maintained first class support for plaintext data either alongside or indexed by their binary blobs. I have used journalctl and it does have theoretically useful features. I have to say that, in practice, I've never found myself in particular need for what journalctl has added and only have used it to see that I could do it. There wouldn't have been a downside. They would have had the capabilities and performance they wanted, and the cases where an utterly trivial to read chunk of data would still be preserved.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    13. Re:Beware journald... by Anonymous Coward · · Score: 0

      Supposedly syslogd is still supported.

    14. Re:Beware journald... by skids · · Score: 1

      That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it

      You don't count jackd as competition?

      Instead PA works in perfect unison with Jack,

      Last time I worked with getting the two to interoperate, pulse's jack module was calling long-deprecated libjack functionality.

      That said, these days the only problem I really have with pulse is its long dependency list (less than awesome level of package modularity), given that the state of jackd has deteriorated so. If I was into pro audio, I'd probably have more problems with both packages.

    15. Re:Beware journald... by Peter+H.S. · · Score: 2

      Just run syslog alongside journald, and you will have all what you are used to have. You even gain many benefits like earlier logging in the boot and other things. You can even turn of that journald uses any storage space or binary logs, but just let it forward everything directly to syslog.

      Personally I don't find it needed, though I ran my Fedora desktop like that in the beginning until I weaned off my old fear of binary log files.

    16. Re:Beware journald... by Anonymous Coward · · Score: 1

      Pulse audio is a prime example of the worst sides of free software. You never fix what is broken, instead you just add your own particular kind of stink-fart to the already existing mess.

      If Plötterling was so concerned about the state of audio, he could have sat down and fixed what was broken in ALSA. If ALSA didn't cooperate, he could have forked it. That's how things are supposed to work. Instead we got this broken shit that just papers over some of the flaws in ALSA, while adding it's own set of problems. Ever tried setting up a surround system with PA? Have fun.

    17. Re:Beware journald... by raxx7 · · Score: 2

      No, jackd and pulseaudio try to solve different sets of problems.
      They don't compete even the slightest. If you think otherwise, you're completely off base.

      jackd is not a generic sound server, doesn't want to be and hates anyone who thinks it should be one.
      jackd is a virtual patch panel for audio. It let's you take audio sources (input hardware or applications) and connect then to audio sinks (output hardware or other applications). And it does so while striving for absolute minimum latency.

      But it's ill suited for general purpose.
      jackd needs to be configured manually, with some detail. Eg, since jackd does not sample rate conversion, you need to select a rate.
      jackd does not support hot plugging of hardware, you need to restart it.
      jackd of course, will not automagically redirect your audio when you plug in your USB headset.
      jackd does not provide per-application volume control.
      jackd has no bluetooth support and, AFAIK, it doesn't really like the alsa bluetooth plugin.
      jackd is CPU intensive.
      jackd is sensitive to misbehaved applications. ...

    18. Re:Beware journald... by fnj · · Score: 2

      The amount of tab-completion with everything is just so nice. Try "jou (TAB) -F (TAB)" and it will show all possible values.

      Can you elaborate on this? I am on Arch with systemd, typing in a bash cl, and tried exactly your "jou (TAB) -F (TAB)" example. Just as I expected would happen, the first tab filled in "rnalctl ". So far so good. Every arbitrary command has done this for years. And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list of every file and every directory in the current directory. A useless list, as a filename is not appropriate as an arguent to the -F option to journalctl. How could it do anything else? Are you suggesting you can make it offer a lift of fields appropriate to the -F option?

      Are you using some magic shell which understands the syntax of every executable command line in the system? I want me one of those.

      And because the log is structured in db form [lists pluses]

      And because it is a db file, it can also get corrupted. And a corrupted db is almost impossible to extract anything useful from. A corrupted text file, which is only appended and never positioned ahead of EOF, can be read perfectly up to the point of corruption, and with some work can be read after the end of the corrupted section too.

      All that aside, I grant the pluses of the journal, and as long as I can run syslog in parallel, I guess I don't have any sunstantial issues. It should never be mandatory to have the journal though.

    19. Re:Beware journald... by fnj · · Score: 2

      Heh, I would have phrased it a bit differently: "Until I threw my prudent caution about relying only on binary log files to the wind". But as long as I don't employ you in IT, it is only a preference. And hey, I don't rule out that I might evolve to the same preference.

    20. Re:Beware journald... by gweihir · · Score: 1

      Indeed. Human-readability is at the very core of UNIX data formats. Pushing for making the logs binary is so incredible stupid, it is staggering. To me, it looks like they are trying an "embrace and extend" move here, where everybody will be dependent on their tools afterwards. If that is not megalomania, then I do not know what is. Binary log files will _not_ happen on any of my systems, they are fundamentally stupid and indicate evil intent on the part of the people that want them.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    21. Re:Beware journald... by gweihir · · Score: 1

      WTF? I can only hope, once they work with it, people start to see how stupid, and immature (yes, immature) the whole approach is.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    22. Re:Beware journald... by gweihir · · Score: 4, Interesting

      Indeed. "Those that sacrifice reliability for speed will neither have reliability nor speed." --me

      And all that for something irrelevant like boot times. What I do not get is why so many people are so stupid about this. Maybe the NSA is pushing for the worst possible system so they have plenty of places to break in? Or to push people away from Linux? The thing systemd reminds me of most is IPSec, which we are now know to have been deliberately NSA-sabotaged by increasing its complexity.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    23. Re:Beware journald... by ftobin · · Score: 3, Interesting

      Tab completion is largely a function of the shell (bash/zsh/etc.), not of the program being completed.

    24. Re:Beware journald... by Anonymous Coward · · Score: 0

      If PA ever was so bad as some people like to claim, why didn't alternatives spring up instead?

      Because typically the response was "remove pulseaudio", rather than "make something new".

      This is also the sort of comment that gives the open source community a really bad reputation of being hostile towards plain old users of software. People who aren't developers intimately familiar with a specific program are not the only ones who have useful feedback, especially when something is aimed at being for everyone to use.

    25. Re:Beware journald... by Anonymous Coward · · Score: 1

      For me it's enough to pay a lot more attention to BSD.

      Or try Gentoo. The big problem for Debian is that Gnome has it by the nuts. That's an awful thing considering the state of Gnome, but Debian already decided not to give up its Gnome addiction. Gentoo, on the other had, holds things pretty wide open. There is no default desktop or a default filesystem type: Gentoo leaves the choice up to you. OpenRC is the default init system, but you can run systemd instead, if that floats your boat. You can even use OpenRC as the init system and run systemd alongside it.

    26. Re:Beware journald... by rastos1 · · Score: 1

      Novices can for the first time actually do usable filtering without knowing arcane programs and switches. A simple "journalctl -b -p err"

      I'm not a novice and the grep switches and regular expressions are ingrained in my brain for years already. Learning another tool to do the same thing is just waste of my time and energy.

      P.S. how is "-b -p err" less arcane then grep command line options or /etc/syslog.conf syntax?

    27. Re:Beware journald... by fph+il+quozientatore · · Score: 1

      I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you can write an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable.

      So your arguments in favor of binary log files seem quite moot.

      --
      My first program:

      Hell Segmentation fault

    28. Re:Beware journald... by Anonymous Coward · · Score: 0

      yes there is magic tab completions for command parameters with bash:P

      in archlinux:
      pacman -S bash-completion
      source /usr/share/bash-completion/bash_completion

      alot of packages ( including systemd ) these days installs "parameter" completions for bash. see under /usr/share/bash-completion/completions/

      if you are using arch, you should check out https://wiki.archlinux.org/index.php/Color_Bash_Prompt for some good tips to improve bash
      first bashrc on that wiki shows how to enable autocompletions and "command not found" which shows you which package a missing command is in automagically..

    29. Re:Beware journald... by oojah · · Score: 1

      Are you using some magic shell which understands the syntax of every executable command line in the system? I want me one of those.

      No magic shell, just bash. I knows what you tell it. Lots of distros take care to provide this sort of support, I couldn't comment on arch. Perhaps you're missing some bash-completion package? See e.g. https://github.com/RoadRunnr/s...

      --
      Do you have any better hostages?
    30. Re:Beware journald... by Anonymous Coward · · Score: 1

      I *am* into pro-audio, and I have no problems with either package. In fact I love both packages, and I love the way they work together, very handy.

      Last time I worked with getting the two to interoperate, pulse's jack module was calling long-deprecated libjack functionality.

      Must have been a long time ago (in software terms), because it works flawlessly as of right now. There's nothing to do to "get the two to interoperate", you just start JACK while Pulse is running and, besides having to manually set the default PA sink to the JACK sink from your DE's mixer (or pavucontrol), the transition is seamless. This used to be very flaky, but that was fixed a few versions of PA ago.

      Oh, and also...

      You don't count jackd as competition?

      No, it's not competition at all. Different use cases. PulseAudio is for consumer use and necessarily too imprecise for pro-audio. JACK is very precisely controllable and inflexible once set so as to be completely stable in professional applications, but this makes it pretty cumbersome for everyday consumer usage.

    31. Re:Beware journald... by Anonymous Coward · · Score: 0

      There is still good old Slackware!

    32. Re:Beware journald... by visualight · · Score: 2

      For a long time I"ve told people that the difference between Windows And Linux is that then Windows there is a menu somewhere, and if what you want to isn't on it, you can't do it.

      There's no menu for Linux, no limits. Till now. If Lennart hasn't thought of your use case, or doesn't care about it, then it's not going on the menu.

      .

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    33. Re:Beware journald... by CronoCloud · · Score: 1

      Ever tried setting up a surround system with PA? Have fun.

      It should "just work", well at least as long as you're using HDMI or SPDIF. Bring up pavucontrol and choose Digital 5.1 out.

    34. Re:Beware journald... by CronoCloud · · Score: 1

      And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list of every file and every directory in the current directory. A useless list, as a filename is not appropriate as an arguent to the -F option to journalctl. How could it do anything else? Are you suggesting you can make it offer a lift of fields appropriate to the -F option?

      It does completion exactly as described by GP in Fedora 20:

      [CronoCloud ~]$ journalctl -F
       
      _AUDIT_LOGINUID __MONOTONIC_TIMESTAMP
      _AUDIT_SESSION _PID

      etc etc, damn lameness filter won't let me put in the entire thing.

    35. Re:Beware journald... by Anonymous Coward · · Score: 0

      For now.

    36. Re:Beware journald... by Peter+H.S. · · Score: 1

      Can you elaborate on this? I am on Arch with systemd, typing in a bash cl, and tried exactly your "jou (TAB) -F (TAB)" example. Just as I expected would happen, the first tab filled in "rnalctl ". So far so good. Every arbitrary command has done this for years. And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list of every file and every directory in the current directory. A useless list, as a filename is not appropriate as an arguent to the -F option to journalctl. How could it do anything else? Are you suggesting you can make it offer a lift of fields appropriate to the -F option?

      Oh, you miss one of the great joys of journalctl. Get the "bash-completion" package and try again. Basically every field, record and their values is tab-able.

      try "journalctl (TAB)" and it will show you some field names like _PID, _EXE etc.
      You can tab all the way in these examples:
      journalctl _EXE=/usr/bin/umount (shows what umount has written in the log)
      journalctl _TRANSPORT=stdout (journald captures all stdout, so this shows all log entries generated this way)
      journalctl _KERNEL_SUBSYSTEM=usb (shows all usb messages generated by the kernel)

      journalctl _MACHINE_ID=5644ac089b164945bfdc47a77f74324d (every machine has UUID, since hostname and what not changes. This is mostly useful when when working with multiple computer logs at the same time. The point is, that even with +100 computers in the loq file, it only requires a single tab after the "=" to show each and every one. And you may only need to key in the first digit or two, before you can use tab to complete the entire UUID.

      Of course there is also full tab support for all switches
      Try "journalctl --(TAB)"

      And because it is a db file, it can also get corrupted. And a corrupted db is almost impossible to extract anything useful from. A corrupted text file, which is only appended and never positioned ahead of EOF, can be read perfectly up to the point of corruption, and with some work can be read after the end of the corrupted section too.

      All that aside, I grant the pluses of the journal, and as long as I can run syslog in parallel, I guess I don't have any sunstantial issues. It should never be mandatory to have the journal though.

      Sure db's may get corrupted, but are useful too, or otherwise we would all use flat file text databases for everything.
      Anyway, the journald log files isn't a pure db, it just feels like it because it is structured and indexed. Here is what it says on the label:
      "The systemd journal stores log data in a binary format with several features:

      Fully indexed by all fields
      Can store binary data, up to 2^64-1 in size
      Seekable
      Primarily append-based, hence robust to corruption
      Support for in-line compression
      Support for in-line Forward Secure Sealing"

      So it appears to work exactly the same way as you describe text log files, with its append based approach.

      Corruption in syslog text files happens all the time. The process may be killed in mid write, a hard shutdown may truncate a message etc. But it is extremely hard to verify loosely structured text files. journald OTOH have internal verification: "journalctl --verify" (don't drop your pants when it shows corruption, it just shows those dead writes you never notice in the text log)

      While journalctl have some ability to read corrupted fields, there is still room for improvement according to Lennart Poettering with the exact problem of reading after the corrupted place, so they are working on being able to salvage as much information as possible from a corrupted entry/file, no matter where the corruption occurs.

      I can only recommend to spend some hours going through the documentation and examples on this site:

    37. Re:Beware journald... by Peter+H.S. · · Score: 1

      I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you can write an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable.

      So your arguments in favor of binary log files seem quite moot.

      Oh, I can see you are quite new to Linux log files, they are basically free form dumps of whatever anything wants to write to syslog in any which way they please. It is impossible to make anything else than a crude GUI; a 'less' just with windows decorations. This is exactly why both Gnome and KDE dropped their previous attempt on making such a GUI.

      I won't bother discussing the advantages of systemd and journald with you anymore, you have already made up your mind without any real technical knowledge or experience with systemd. This is sadly the attitude I see with many Linux users these days; gone are the glory days of curiosity and hacking, when new Linux technology was exciting, and people eagerly read the LKML for news. Today it is all about sneering at open source developers, and blankly rejecting what other claim should be rejected.

    38. Re:Beware journald... by skids · · Score: 1

      All of the above list read more like a "things Poettering could have fixed in jackd instead of throwing an entirely new wrench into the gears" than a justification for PA, personally. Jackd's plugin architecture could easily have provided for a service discovery plugin, naive app plugin, etc.

      Pretty sure you can already do volume control of individual apps in jackd, though,

    39. Re:Beware journald... by Anonymous Coward · · Score: 0

      Well, I guess.. congratulations to you..
      Ever since I was forced to install pulseaudio for steam, my audio has been popping and cracking everytime something new tries to play audio.

      After several months of uninstalling pulseaudio and then later being forced to install it again (steam)...
      It drove me absolutely nuts..

      Then found out the solution was quite simple..
      in /etc/pulse/default.pa
      I had to add tsched=0

      Why this is even necessary, I have no clue.

    40. Re:Beware journald... by Anonymous Coward · · Score: 0

      Its not just everytime something new plays.. Without tsched=0 I also get crackling and popping everytime I jump to any point in an audio or video file.. It's the kinda thing that can drive you insane.

    41. Re:Beware journald... by Anonymous Coward · · Score: 0

      Ah flame bait. I'll bite. First, its his *desktop*, not some critical server. And if you're storing plain text logs on the server and not forwarding them to some central syslog or aggregator you're either in a tiny shop or doing it wrong.

      And really, how often do you have to look at log files? If you say more than once a day, you're doing it wrong. Yeah, I get it, I work with buggy web apps but thats not central service logging and its logged to a central aggregator anyway after being written locally.

      Take a long look at your fear and realize those kids on your lawn won't hurt you. Its your inability to adapt to change that will. Complexity requires more disruptive change.

      Also, ever had a newbie log onto a server that went crazy and try to less a 10GB file? Yeah, he's an idiot, but at least with this method you're less likely to have an idiot admin who should never have been hired kill a server by looking at a log.......;)

    42. Re:Beware journald... by Peter+H.S. · · Score: 1

      Heh, I would have phrased it a bit differently: "Until I threw my prudent caution about relying only on binary log files to the wind". But as long as I don't employ you in IT, it is only a preference. And hey, I don't rule out that I might evolve to the same preference.

      Prudent caution and all that is all good and well. In the end is all about risk and risk assessment, and the first step to that is to be enabled to make informed assessments based on technical knowledge.

      Most people react to binary log files with understandable scepticism, especially people who have been around some time. But initial scepticism isn't an informed position either. We are talking systemd here, the future Linux plumbing system on Red Hat/Fedora/CentOS/Sci-Linux, Suse, Debian, Arch Linux etc, etc. The future is likely to arrive where you work too, if you deal with Linux.
      So I have been reading up on systemd and journald. I don't think you really have, and that is a shame.

      My main point in any risk assessment is, that even if it possible to construct contrived scenarios where binary log files can be a problem, these freakish events are far, far outweighed by that many huge improvements systemd and journald gives the SA every day, on every machine, in all situations, from debugging to development.

      So don't let prudent caution turn you into a technophobic Luddite.

    43. Re:Beware journald... by raxx7 · · Score: 1

      jackd is not a jack of all trades.
      It's a specialized application, with a very specific purpose, that it does very well.
      Making a general purpose sound server requires a different set of compromises.

      "Fixing" those things in jackd means, at best, extra code to support features that are not primary goals for jackd. At worse, it means sacrificing some of jackd's critical features, such as low latency at the expense of everything else.

      It Lennart tried to fix jackd, then the proverbial wrench would be thrown at his head by the jackd developers.

    44. Re:Beware journald... by skids · · Score: 1

      It's a specialized application, with a very specific purpose, that it does very well.

      I don't buy that. Then, I've opened the hood of the jackd source enough to see that it was fully capable of doing the job, without sacrificing anything. Once you have a low latency sound server, providing a buffering module for more casual use is not that challenging. Once you have a patch panel capable of routing sound around as well as jackd, providing for pluggable device support is a natural extension of that.

      Your argument is the equivalent of saying that web browsers are highly specialized HTML/HTTP renderers and extending them to handle scripting would compromise their ability to fetch HTML over HTTP and render it.

    45. Re:Beware journald... by konoame · · Score: 1

      journalctl is almost 1s slower than tail -f /var/log/...

    46. Re:Beware journald... by fnj · · Score: 1

      Well, as it happens I've done a bit more than read up on them. I've changed my own personal day to day desktop from RHELish6 (actually PUIAS/Springdale) to Arch and have been immersing myself in systemd and journald. Sure, I've had some bad moments, but on the whole (1) I am coping, and (2) I haven't been let down.

      That said, I'm going to leave my own personal 36 TB ZFS double RAID-Z2 primary server at CentOS6 likely until it reaches EOL, and my next server build is going to be FreeBSD 10, while keeping bleeding edge Arch on my own desktop unless/until I find something better.

      I will say you have done a good job airing out things in discussions on this post.

    47. Re:Beware journald... by fnj · · Score: 1

      Well, it turns out there is a lot going on with bash add-ons. Check out the AC directly under your comment, and Peter's around a page below. I am trying this stuff out now.

    48. Re:Beware journald... by fnj · · Score: 1

      yes there is magic tab completions for command parameters with bash:P

      in archlinux:
      pacman -S bash-completion
      source /usr/share/bash-completion/bash_completion

      alot of packages ( including systemd ) these days installs "parameter" completions for bash. see under /usr/share/bash-completion/completions/

      if you are using arch, you should check out https://wiki.archlinux.org/ind... for some good tips to improve bash
      first bashrc on that wiki shows how to enable autocompletions and "command not found" which shows you which package a missing command is in automagically..

      Somebody mod up this AC. He hit it on those nose. I just did exactly as suggested and I am feeling a bit high at the moment. This is heady stuff.

    49. Re:Beware journald... by fnj · · Score: 1

      Man, did I ever do the right thing mustering up my courage to ask the question and revealing my specific ignorance. I am checking bash-completion out right now; thank you (and AC also). I am definitely enjoying ...

      I am pretty new with journald but have been using it for several days on my desktop. I've already had my first heart-in-mouth moment, but turns out it wasn't doing anything wrong, and it took no more than "man journalctl" to see what I was missing. I'm also running syslog in parallel, and haven't piucked up any problems with that either.

    50. Re:Beware journald... by fnj · · Score: 1

      For anyone confused at this point, I've checked this out and I'm pretty sure that everybody who has the "good completion" has package bash-completion installed, and everybody who doesn't is missing out on the package :-)

    51. Re:Beware journald... by jgrahn · · Score: 1

      I don't see why any of this wouldn't be possible with text logs. Yes, you can write GUIs that parse text log files. Yes, you canwrite an utility that does all the grepping and sorting for you. Yes, you can filter out logs from the previous boot. I don't think the performance loss would be noticeable. So your arguments in favor of binary log files seem quite moot.

      Oh, I can see you are quite new to Linux log files, they are basically free form dumps of whatever anything wants to write to syslog in any which way they please. It is impossible to make anything else than a crude GUI; a 'less' just with windows decorations. This is exactly why both Gnome and KDE dropped their previous attempt on making such a GUI.

      So, how does making it a binary blob help? The data sources will just produce free form dumps as before, and that's what will end up on the logs. The things that are structured is the time stamp, facility and critical/error/info etc level, and they are easily parseable anyway.

      So either the binary blobs don't help at all, or all Unix applications will be forced to adopt some non-Unix structured logging. For my applications, I can say right now I will not do the changes needed to achieve the latter ...

  17. RE:Soooo by Anonymous Coward · · Score: -1, Offtopic

    Oh, you'll still think FUCK BETA is off topic? How quaint.

    you like the Timothy auto feed too, huh?

    Enjoy your lovely new brilliantly designed and targeted tech news website when it arrives!

    (and they they made them turn against each other...those good ol propaganda tactics still work a treat, wake up someone's selling you!)

  18. Die, Ubuntu, Die (on topic = marginal) by callmetheraven · · Score: -1, Troll

    Ubuntu: The distro for people not clever enough to install something more serious, and don't know that Mint is a far better choice for such people. Whenever I encounter someone who endorses Ubuntu, I downgrade their geek score down to that of a Windows 8 fan.

    I admit that the idiotic ebonified pseudo-mult-culti-faggy name "Ubuntu" (sounds like the name of Idi Amin's dog, "sit Ubuntu, sit") was the cause of my initial distaste, but since the list good of reasons to hate Ubuntu has grown long. As a longtime Debian lover (have version 2.0 install media right here), the less Debian becomes like Ubuntu the better!

    --
    You can have my SIG when you pry it from my cold, dead hands.
  19. So Long Debian! by zixxt · · Score: 0, Flamebait

    As a current Debian(testing,Jessie) user this strikes me as a bad choice. However I am thankful that there other sane distros not drinking Lennart Poettering's brain cell killing kool-aid. So I say hail o/ to the Linux Distros not selling their souls, Slackware, Gentoo , Ubuntu thank you guys for not being retards and seeing the suckyness of systemd.

    Seems I will have to migrate off Debian pretty soon. It was a good year I had with Debian but with this it seems Debian as chosen to be a follower, a kool aid drinker and a also ran instead of being unique. Thank you Lennart for killing off another distro for me to love.

    --
    ---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
    1. Re:So Long Debian! by Anonymous Coward · · Score: 0

      Gentoo has options for systemd. You apparently need it for certain versions of gnome.

    2. Re:So Long Debian! by Anonymous Coward · · Score: 0

      systemd is the init system equivalent of Beta. Fuck Beta. Fuck Lennart too.

      The gentoo community hates systemd you will be most welcome.

    3. Re:So Long Debian! by zixxt · · Score: 0

      systemd is the init system equivalent of Beta. Fuck Beta. Fuck Lennart too.

      LOL true Dat.

      The gentoo community hates systemd you will be most welcome.

      Thanks

      --
      ---- GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
    4. Re:So Long Debian! by Anonymous Coward · · Score: 1

      A lot of whining, but no actual arguments. May you have the kindness to give reasons for your aversion to systemd before insulting people?

    5. Re:So Long Debian! by fast+turtle · · Score: 1

      Looks like the MS Embrace/Extend/Extinguish is reaching the End-Game since SystemD is exactly that. Who will pay the Piper in the future? Thankfully not I as I didn't call them in but now I'm down to a single Open Source OS - BSD as Linux has screwed the pooch.

      Can't stand Apple and Sure as hell don't care for the crap called Win8. Guess I need to dive into BSD again and start learning how to use it.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    6. Re:So Long Debian! by Anonymous Coward · · Score: 0

      Actually, he has no need to switch to systemd. That should be enough said. Debian left the sane world for the ricer world of init systems.

      If you think that he was insulting people by not switching to systemd, you are sadly mistaken. If anyone has insulted people, it was originally Lennart who insulted people to get his way on getting systemd into distros to feed his superiority complex. That is the sole reason this even is an article today. We do not have to appease you with an arguing some more because we don't have to waste CPU cycles on a system that does nothing better than any other init system, other than to pretend Lennart's superiority.

    7. Re:So Long Debian! by HiThere · · Score: 1

      That said, if reports about window managers beginning to rely on systemd are valid, this may have been a foced move. I, personally, see no reason to move from sysvinit, but if KDE starts to perform poorly, because it's assuming that it can depend on systemd to supply some services....well, I'd be unhappy.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    8. Re:So Long Debian! by gweihir · · Score: 2

      And that shows just how _wrong_ this all is. A GUI has no business in hell depending on an init-system. This is all very un-UNIX, KISS-violating, bloated, Windows-like. Why do so many people not see what incredible amount of things they are breaking with systemd?

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:So Long Debian! by gweihir · · Score: 1

      I really hope Gentoo will stay away from making systemd mandatory. I now have a good reason to migrate there.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    10. Re:So Long Debian! by Anonymous Coward · · Score: 0

      For the exact same reasons I never used or quickly removed aRts/ESD, gdm/kdm, HAL, *kit, NetworkManager, suspend/hibernation, Avahi, PulseAudio, Ubuntu, Compiz, KDE 4, Gnome 3, etc. They bring mostly useless features aimed at basic Windows/Mac users for more bells and whistles, generally as an added layer complexifying everything, with often stability problems, and more difficulty debugging them. They always get in my way, as an advanced user, who mostly knows what he wants, and what he's doing. They limit my control, and often my privacy and security. And I have to waste a lot of time and energy avoiding them.

      It all feels like trying to explain why I'm on GNU/Linux and not Windows (or more recently, Macintosh), to some gamer/office/Hotm^H^H^H^HFacebook friend, or my family...

      I could rather easily deal with it a few years ago, on Gentoo GNU/Linux, with FVWM and various other "alternative" packages, which are often better in all aspects for me, but recently it's become harder and harder, as these things are being forced more globally and more deeply, including on applications which are more difficult to replace, with always more support from the "newer generations" who'd do just as well on Windows or Mac...

      The goal of systemd is "configuration-less systems"... There is just nothing else to be said... Nope.

      Whatever the possible mitigations and eventual remaining options (for how long?)... I have no need for it, at all. It's not for me. Most of my problems in the past 10 years on GNU/Linux have been because of these sorts of programs.

      I boot quickly enough already without it (sure is easier precisely without all these sorts of programs bloating bootup...). They tout multiseat as a main feature worth switching for... I mean, WTF... I'm the only one using my PC, thank you very much... And binary logs...?!

      Superfluous uselessness.

      (/. Beta sure is very comparable... So much wasted space (and I mean really wasted, not the let's-remove-the-menu/status-bar kind of "wasted space"...). So little room for stuff that matters...).

    11. Re:So Long Debian! by Bill,+Shooter+of+Bul · · Score: 1

      Gnome wants to allow admins to keep track of what different users are doing and enforce permissions and what not on their utilizeation of the system.

      Sounds good right? They had policykit, but determined that logind did that task better. Logind ( part of systemd) just does a better job of doing that one job. It turns out that monitoring all the processes a user creates through using a desktop is a very simular task to the more general job of monitoring a daemon and all of its processes. So it makes sense to have the same tool perform very simular tasks.

      So, if you don't understand what systemd does and what gnome needs, your statment makes a *lot* of sense. But when you figure out what everything does, it just looks wrong. Why re-invent the wheel for the same task? This *is* KISS. Re-inventing the wheel is not KISS, adds bloat, duplication of effort and bugs.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
  20. Re:Die, Ubuntu, Die (on topic = marginal) by loufoque · · Score: 3, Insightful

    Ubuntu used to be good before they destroyed themselves around 2011.
    Mint is an Ubuntu fork after all...

  21. READ THIS (it works) by Anonymous Coward · · Score: 0

    To get you past redirects to beta, easily http://games.slashdot.org/comm...

  22. Irrational Hate by Tenebrousedge · · Score: 5, Interesting

    No, it is loathed by a small, vocal, percentage of system administrators, who have very little in the way of technical arguments at their disposal. This vote may be considered evidence in that respect.

    There is very little to recommend init scripts. I dismiss arguments that they are any easier for any average mortal to deal with than any other piece of code, and there is very little justification for wasting CPU time on a non-interactive process. Additionally, this will merely be a default -- those who want slow boots, or think cgroups are evil, can go ahead and install systemv-init and purge systemd. Or, since systemd, d-bus, pulseaudio, and wayland are evidently the future of Linux, the malcontents can install BSD -- it comes with a free chip for your other shoulder.

    --
    Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
    1. Re:Irrational Hate by ThePhilips · · Score: 2

      No, it is loathed by a small, vocal, percentage of system administrators, who have very little in the way of technical arguments at their disposal.

      I hear that argument a lot. The problem with it that systemd's approach likewise has "very little in the way of technical arguments". To the most questions you get blank non-responses which amount to "it is like it is".

      There is very little to recommend init scripts. I dismiss arguments that they are any easier for any average mortal to deal with than any other piece of code, [...]

      systemd moves to C what was historically done by shell scripts. Admins and testers - people who deal with the init system more than anybody else - can't C but can shell. What's more, on a typical systemd system, literally all the gritty bits of initialization are hidden in the binaries. If you need to modify some aspect of their behavior - tough luck. Pottering is one of the proponents of the 100% configuration-less system: majority of the binaries do not even have any command line options to customize their behavior.

      If PulseAudio example taught us anything, systemd has a chance at being something - only after Pottering is done with it and leaves the project.

      P.S. Do not take me as a upstart proponent. I have installed both Fedora and Ubuntu in VM and have to say that like none of them. Or rather. I do not like the Fedora. (But heck, GNOME 3 desktop is hard to like and it sets the mood from the beginning. Dysfunctional Alt-Tab alone is worth dismissing the whole distro.) Ubuntu in that respect is much more palatable. But then, upstart plays there only a small, albeit important, role of starting up basic system services - rest, including service management, is done by the usual sysvinit scripts. Fun fact: Fedora boots about twice slower than the Ubuntu, despite systemd's promise of faster boot times vs. Ubuntu's reliance on the slower sysvinit scripts. In the end, I'd still take sysvinit.

      --
      All hope abandon ye who enter here.
    2. Re:Irrational Hate by Anonymous Coward · · Score: 0

      >
      > since systemd, d-bus, pulseaudio, and wayland are evidently the future of Linux
      >

      The future of Linux should continue to be a system that allows much variety and choice. If Linux deviates from this pluralistic path and adopts a monolithic, one-size-fits-all philosophy, then it will be the ruin of perhaps the greatest computing project ever.

    3. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      I've been a system administrator for over 15 years. I can count on one hand how many times I had to touch the init system.

    4. Re:Irrational Hate by petermgreen · · Score: 1

      Additionally, this will merely be a default

      We don't know that yet. There are certainly people within debian who think the chosen default should "merely be a default", there are also people within debian who think there should be "one and only one suported init system". In the middle we have people who think it should merely be a default for the project as a whole but some software may depend on the default init system (gnome3.................).

      This vote seems to have ignored that issue and from reading the mailing list discussion some members of the TC are very unhappy about that fact.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    5. Re:Irrational Hate by Anonymous Coward · · Score: -1

      Monolithic, you mean like the kernel? You know, the thing that we actually call Linux? The thing that isn't affected by this at all? That thing?

      "If you like your init system, you can keep your init system." Gentoo certainly will. Personally, I think sysv, Alsa, and X11 are pieces of crap that have dragged down the state of the art on linux and ought to be disposed of as soon as possible. I've heard the technical arguments on both sides, and I understand that the old ways have some severe limitations. X11 as implemented is garbage, even before they took out the print server. Talk about monolithic. Alsa was completely inadequate for all but the simplest audio tasks. Windows Audio, as introduced in Vista, was leaps and bounds ahead. And I guarantee no one here complaining about init scripts has ever touched the complex bits of that system. Writing complex bash code that is also intended to be portable is an ugly process, far beyond the abilities of the neophyte, error-prone, and usually difficult to merge when the upstream changes. Writing C code is pleasant by comparison. The parts that are trivial under sysv-init, are still trivial with systemd, and you get a host of other benefits. Process and service control get much better, and one other benefit is being able to start up services in parallel. Because blocking on boot for no good reason is fucking retarded.

      To the sibling poster: Fedora vs Ubuntu bootup times are fairly meaningless by themselves. Run bootchart and figure out why, then come back and tell us that e.g. systemd adds x% to your boot up time, on the same hardware, running the same processes. And quit lying about being a system admin.

    6. Re:Irrational Hate by HiThere · · Score: 4, Insightful

      Personally, I prefer the traditional init system from UnixV...but then I also prefer grub over grub2. I like to be able to edit my scripts easily, and not dig through several files and try to puzzle out the documentation. (In the case of grub2 my puzzling out the documentation hasn't been that successful...I frequently need several attempts to get a change that would have been simplicity itself in grub. OTOH, I've only got one machine that I can use, so any change is difficult. If I make a mistake, I may need to reinstall the whole system. I can't just look up an answer on the internet...because that requires the machine to be working.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    7. Re:Irrational Hate by Burz · · Score: 1

      Fun fact: Fedora boots about twice slower than the Ubuntu, despite systemd's promise of faster boot times vs. Ubuntu's reliance on the slower sysvinit scripts. In the end, I'd still take sysvinit.

      Actually, that comparison with Fedora doesn't do it justice: Ubuntu 13.10 boots twice as fast as Windows 7 on my laptop. Its *exceedingly* fast in that respect.

    8. Re:Irrational Hate by GaryOlson · · Score: 1

      I've been a system administrator for over 15 years. I can count on one hand how many times I had to touch the init system.

      Then you haven't been trying hard enough. Any organization with even a hint of unique internal business processes requires modification of the init system.

      --
      Every mans' island needs an ocean; choose your ocean carefully.
    9. Re:Irrational Hate by Boltronics · · Score: 1

      Then you must be administering Windows boxes.

      --
      It's GNU/Linux dammit!
    10. Re:Irrational Hate by Anonymous Coward · · Score: 0

      I've been a system administrator for over 15 years. I can count on one hand how many times I had to touch the init system.

      I've been a Linux user since '97 or '98 and, while the amount of init mangling has decreased in recent years, I still find I have to make various minor adjustments to various init scripts on my Debian desktop.

      Usually related to bugs with packages in the testing repo, but not always. Sometimes just behaviour changes that can't be configured by the /etc/default/ system, sometimes non-standard packages, etc.

    11. Re:Irrational Hate by Anonymous Coward · · Score: 0

      Any organization with even a hint of unique internal business processes requires modification of the init system.

      I didn't realize that Linux init system is that poorly designed.

    12. Re: Irrational Hate by Anonymous Coward · · Score: 0

      With an ssd and an i7 13.10 boots to an auto-logged in gnome 3 desktop faster than my projector can pick up the video signal on its hdmi port. I click reboot, the projector clicks away, by the time it cycles its inputs the system is already back and logged in.

    13. Re:Irrational Hate by Anonymous Coward · · Score: 0

      Personally, the bottleneck is ADSL syncing, so whatever init system is fast enough for me.

    14. Re:Irrational Hate by ThePhilips · · Score: 2

      I'm working in software development, so our needs - and admin's tasks - are different.

      In fact, most of the tweaking is done by the testers (who being on the receiving end of the pre-release software) often end up being responsible for making the software working as a whole.

      Init script tweaking incidents went down considerably, but still happen.

      In the end, and as we are concerned, even *single* incident enough to justify the hard requirement for tweakable init system.

      Though, to give a balanced perspective, it's not like systemd is fully locked down. It is also tweakable, but to a lesser extent. I simply lack the professional experience with it to say whether it would be suitable or not.

      P.S. With the embedded developer hat on, though I haven't done it in age, I can say that systemd is certainly unfit for embedded. I typically put into binaries only the minimum - for performance and resource consumption reasons - rest is in plain shell/etc scripts. One can easily patch a script - but to update a binary one literally has to start whole release cycle again.

      --
      All hope abandon ye who enter here.
    15. Re:Irrational Hate by brufar · · Score: 1

      you could make use of a live distro (Debian-live for instance) to lookup a fix on the internet and then make the corrections. re-installing the OS for a typo in a config seems a bit overkill. Plenty of live distros out there for this simple task.

      --
      far...out
    16. Re:Irrational Hate by Anonymous Coward · · Score: 0

      This is why you keep a liveCD/liveUSB around, preferably of the same distro. You always have a bootable system that way, and if you really screw things up, you can chroot into your installed distro and make whatever required changes.

      The process is more or less as described here; none of the commands appear to be distro-specific.

    17. Re:Irrational Hate by Anonymous Coward · · Score: 0

      No, it is loathed by a small, vocal, percentage of system administrators, who have very little in the way of technical arguments at their disposal. This vote may be considered evidence in that respect.

      There is very little to recommend init scripts. I dismiss arguments that they are any easier for any average mortal to deal with than any other piece of code, and there is very little justification for wasting CPU time on a non-interactive process. Additionally, this will merely be a default -- those who want slow boots, or think cgroups are evil, can go ahead and install systemv-init and purge systemd. Or, since systemd, d-bus, pulseaudio, and wayland are evidently the future of Linux, the malcontents can install BSD -- it comes with a free chip for your other shoulder.

      sysadmin since, well, before linux. these days, netbsd and debian, primarily (a good deal of gentoo....) I have chips on both shoulders, it seems. In any case, I have a good deal of experience with init systems (also mixed environments sysv and djb daemontools running in parallel). For the life of me, I see no reason to switch from a morass of different init scripts to a morass of config files for a monolith.

      What's the advantage of a variety of (variously bad) configs for systemd over independent init scripts?

      And exactly what kind of systems do you administer. I manage 2 types of mail clusters (one postfix centric, two qmail centric), a virtual server farm using old school linux vserver containers, a new school puppet/foreman managed kvm cluster, and lots and lots of web servers and their services. Which is to say, i replace MOST package init within the context of my deployment tools (mostly puppet/foreman) anyway, but really, really am not looking forward to the cluster fuck of having to rewrite ALL of it because of systemd.

    18. Re:Irrational Hate by DuckDodgers · · Score: 1

      Interesting that Fedora boots slower than Ubuntu for you. I hadn't noticed a difference, but then I wasn't booting them at the same time either.

      I think in examining a next technology choice, you have to put the emphasis on "simple", as in "uses the minimal amount of complexity required to effectively complete the task" versus "easy" as in "creates the smallest learning curve for people using the current technology choice". If you're under a hard deadline, "easy" trumps "simple" because it is faster to transition. Otherwise, "simple" gives you something that takes less work to understand, requires less knowledge of the predecessor technology with makes it "easy" to bring in new talent that does not know the previous technology, and requires less work to customize because there is less to know.

      Debian isn't run by a company, they have all the time in the world to get this decision right. So forget what init has now, forget that lots of current administrators know init, forget that lots of current administrators know shell scripting. What replacement for init is the simplest way to get the features they want?

      I suspect the very backwards compatibility that makes the transition to Upstart easier will hurt it in the long term. Systemd's break with the past makes a transition headache but may make more sense in the long term. Or maybe there are a number of other options that are superior but not well known.

    19. Re:Irrational Hate by HiThere · · Score: 1

      Well, my system's a bit old, so a usb boot won't work. I *do* have a couple of live CDs, but ... I just prefer to avoid THAT kind of hassle.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    20. Re:Irrational Hate by ThePhilips · · Score: 1

      Otherwise, "simple" gives you something that takes less work to understand, requires less knowledge of the predecessor technology with makes it "easy" to bring in new talent that does not know the previous technology, and requires less work to customize because there is less to know.

      The problem with the argument in context is that init system plays special role and bringing in "new talent" isn't precisely feasible in real world.

      Even with the systemd, wrong .service might work most of the time while still break later in unpredicted ways. (And the amount of pre/post conditions/etc configuration options and dummy, OS-specific dependencies already provide more than enough rope.)

      At least with upstart, wrong job would simply hang the boot of the system.

      Debian isn't run by a company, they have all the time in the world to get this decision right. So forget what init has now, forget that lots of current administrators know init, forget that lots of current administrators know shell scripting. What replacement for init is the simplest way to get the features they want?

      Wrong argument. Admins want their systems to manage themselves on auto-pilot as to not to distract them from their coffee breaks and solitaire. :)

      (Admins do not want to deal in with init system directly - they want it work for intended purpose right out of the box, as shipped by vendor. (And I happen to work for a company which ships softwre on pre-configured *nix boxes.) Some vendors (even 1st party ones) do not even support tinkering with the init system.)

      I suspect the very backwards compatibility that makes the transition to Upstart easier will hurt it in the long term. Systemd's break with the past makes a transition headache but may make more sense in the long term. Or maybe there are a number of other options that are superior but not well known.

      I personally do not consider ability to freely edit init configuration to be of "backward compatibility" character. It is a feature.

      I will not argue that upstart has no drawbacks. Still this is the first time I have actually seen an init system which tries to solve old forgotten problems. The problems for which often in past I had to give up and write a dummy two-line C program to wait for an event and trigger some action later.

      IOW, I can have dumb scripts for normal services and event-driven jobs for special services. Both freely editable in a text editor.

      P.S. I have no doubt that systemd would win in the end. Not because of some technical advantages, but primarily because upstart has tainted CLA. The tainted CLA already drove some people away from it. But if you want to have a technical argument in favor of systemd, then use the much better SMF (service management facility). Because one provided by upstart currently is really really barebone.

      --
      All hope abandon ye who enter here.
    21. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      I shouldn't have to try anything. You shouldn't be doing too many unique business processes in the first place. the only thing we have different is a new runlevel that has some small number of services + network.

    22. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      Nope, all kinds of Unix and Linux. I have never administrated a windows box in my life.

    23. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      Join teh systemd list and ask. Just explore and see what can be done. In fact, you might find new or interesting solutions that might not have been possible before.

    24. Re:Irrational Hate by Boltronics · · Score: 1

      Nice! I like your style. :)

      But I think you've been quite lucky to not have needed to touch it. I've frequently had to edit /etc/inittab (usually to change getty settings), change runlevel configurations, or package software with init scripts that need tweaking.

      From my point of view, I don't care about saving 5 seconds of boot time. I'm more concerned about ease of configuration and maintenance, as well as reliability.

      --
      It's GNU/Linux dammit!
    25. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      yeah, it's nice. I don't work in IT anymore and moved into doing distro engineering (hence the systemd stuff). But I know I used to be irritated with the change, but the experience is somewhat similar to when I moved from Perl to Python. I knew I could do all this stuff in Perl but I had to force myself to use Python until it was second nature. In the end, it is similar and you know software evolves. If systemd guys listen and is able to evolve it, listening to systems administrator then things are going to look a lot better.

    26. Re:Irrational Hate by Boltronics · · Score: 1

      That's true. Point taken.

      --
      It's GNU/Linux dammit!
    27. Re:Irrational Hate by Anonymous Coward · · Score: 0

      Personally I have a Raspberry Pi setup as a network boot server (among many other things) which allows all my machines (regardless of age) to boot straight into a number of different linux setups directly over the network, its ideal for when I manage to screw something up and leave a machine unbootable and its even better when it comes to installing a clean system, saves a lot of fumbling around looking for usb sticks or CD's and allows me to quickly change any aspect of the systems Im booting.

    28. Re:Irrational Hate by Anonymous Coward · · Score: 0

      Well, if you only have a single machine and you're tinkering with your bootloader configuration, you should always have a bootable and working liveusb distro on an usb stick, that you know you can always boot and then look up info on the internet.

    29. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      Ugh, sorry for the terrible writing - basically I was saying that what looks foreign will become familiar over time as with anything else. The one difference with my Perl -> Python analogy is that I took the initiative to do that, and so I had an incentive. Much harder when the change is not something you initiated. Which is the heart of a lot of this debate.

    30. Re:Irrational Hate by Boltronics · · Score: 1

      I know what you mean. We started using Salt Stack at my workplace because it was a clear advantage over the previous way we were managing our infrastructure configuration, and perhaps because of that interest and enthusiasm, the process of migrating was much easier - even though the setup can be complex.

      In the case of systemd and friends, the question of how this is going to advantage my job/workflow or my workplace specifically, is less clear. I guess this is a good argument for some early initial investigation so we can hopefully find that answer and motivate ourselves.

      --
      It's GNU/Linux dammit!
    31. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      Indeed!

    32. Re:Irrational Hate by Anonymous Coward · · Score: 0

      Preview button! Preview button! Preview button!
      Would have allowed you to catch your mismatched <quote> </quote>.

  23. systemd devs can go fuck themselves by Anonymous Coward · · Score: 4, Interesting

    Their recent updates have broken udev so badly, that Gentoo decided to fork udev to retain the old design. Debian should pay attention.

  24. Nature takes care of mistakes like these. by Anonymous Coward · · Score: -1, Offtopic

    Nature has gotten pretty good at taking care of blatant mistakes. This is especially true in the software world.

    Look at XFree86. They fucked up big-time, and now the project is basically dead. Almost everybody has abandoned it, never to return.

    Look at GNOME 3. They fucked up big-time, and now the project is basically dead. Almost everybody has abandoned it, never to return.

    Look at Windows 8. They fucked up big-time, and now Windows is sliding further into irrelevancy. People and companies are moving to OS X, Android, iOS and Linux, never to return to Windows.

    Look at Firefox 4+. They fucked up big-time, and now the project is dying. Users are fleeing it in droves, never to return.

    Look at Slashdot Beta. They fucked up big-time, and now the community is dying. People are leaving, or will be leaving, permanently, never to return.

    Maybe Debian is next. They've made a bad decision, and it's likely that their importance will diminish, much like has happened to Fedora and other Linux distros that have made really stupid choices. People will move to Ubuntu, or even to the BSDs, never to return to Debian.

    1. Re:Nature takes care of mistakes like these. by superwiz · · Score: 0, Offtopic

      Thinking that Windows is dead is so cute. Yeah, I had the "hate it" attitude around 3.11, too. But, you know, it's been a while. Win XP is still used after 13 years. You'd be hard pressed to find a linux distro with the same longevity. Heck, you'd be hard pressed to find a kernel release with the same longevity. In fact Win XP is so good that I only realized how good Win 7 was about a year ago. As desktop environments go, it's absolutely ridiculously amazing. Writing services for it is a pain, but I am guessing only because I never formally studied it and had to figure it out on my own. Windows 8 sucks? I have no idea. No one uses it. Win 7 is good enough. But if it really is a pain, it's a continuation of the pattern. The even-versioned releases of MS products always flop.

      --
      Any guest worker system is indistinguishable from indentured servitude.
    2. Re:Nature takes care of mistakes like these. by HiThere · · Score: 0

      MSWind may not be dead, but the signs are strong that MSWind8 is. IIUC MS is already planning to release MSWind9 fairly soon.

      OTOH, I don't closely follow MS decisions. Perhaps they've changed their minds again, and are now planning to stick with it.

      Still, it's not just that MSWind7 is good enough. (Is it? I've never used it, and due to the last MS EULA I read I have no intention of using it. But it could be. After all, MSWind95B was better than MSWind98.) But people have been refusing to use MSWind8 in droves. So much so that they quickly rushed out a patch upgrade to 8.1...which apparently solves some of they problems (whatever they were), but not enough to satisfy people. So much so that some manufacturers have started selling MSWind7 again. (That must have taken some smooth talking to get MS to allow it.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    3. Re:Nature takes care of mistakes like these. by smash · · Score: 0

      Try a Mac. Windows 7 / XP only looks good because you're putting it in the context of other versions of Windows or half-assed Linux desktop environments (and by half-assed, I mean BASIC functionality like not being able to open files from a network share from within various applications, for example - try open a file from within VLC from an SMB share, for instance).

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    4. Re:Nature takes care of mistakes like these. by superwiz · · Score: 0

      DOS 4, DOS 6, Win98, Vista, Win8... all even-versioned. Like I said, the even-versioned ones flop.

      --
      Any guest worker system is indistinguishable from indentured servitude.
    5. Re: Nature takes care of mistakes like these. by Anonymous Coward · · Score: 0

      Open nemo, connect to server, point vlc at fuse mountpoint? What's the difficulty?

    6. Re:Nature takes care of mistakes like these. by Bryan+Ischo · · Score: 1, Offtopic

      I personally have tried a Mac. After 18 years of nearly Linux-exclusive computing, in 2012 I was wooed enough by the new retina Macbooks and tired enough of dealing with Linux suspend/resume/hibernate nightmares on laptops, that I decided to give a Mac a try.

      Long story short: I like it, and nearly love it, but am disappointed in many aspects. The hardware is definitely a high point - I can honestly say that I have never owned another laptop with even close to the same quality of hardware design or manufacture as my 15 inch rMBP. And I say that despite having to return it to the store once to fix the image retention (at the same time getting a mainboard upgrade to fix the video flickering problem that was common on this laptop), again to fix the wireless that they somehow broke during the first fix, and finding that about 6 months later I killed 4 or 5 pixels on my own when a small grain of sand got onto the display and I closed it (the retina displays have literally *no* protection of the LCD surface and it is easy to pit/scratch them - my fault for taking the laptop on vacation I guess).

      Mac OS X has impressed me with how well it integrates with its hardware, how nicely and seamlessly the UI functions, and how good the video drivers are. Also Apple's Objective C implementation and libraries are an interesting mix of weirdness and awesomeness, with the very best documentation I have ever read for any programming environment hands down (Microsoft's widows documentation is a complete and utter joke when compared to Linux man pages, let alone compared to the incredible documentation that Apple has for its APIs).

      However - the Mac is still a let down in some areas. Printing is surprisingly difficult and bad. I am amazed that a company that created the desktop publishing market and that sold the first Laser printer, can have such an awful print dialog. It's inconsistent between apps and doesn't let me WYSIWYG the printouts whatsoever (I print alot of coloring pages for my kids and it's amazingly hard on the Mac, no matter what program I use, to get an image centered and fit to a page for printing). Also, some of the UI misbehaves sometimes - I've taken to completely disabling the wireless status icon in the menu bar because it tends to freeze up the entire menu bar functionality whenever it's searching for networks or otherwise unhappy. Which happens just about every time the laptop comes back from sleep.

      Also I cannot stand the fact that Apple cannot give the user the choice of whether or not click-to-focus or focus-follows-mouse. Oh my god the number of times that I have been unable to interact with a program while looking at a web browser or somesuch because they overlap and I have to fidget and fuss with window positioning and size to be able to do my work. On any other system without this ridiculous flaw, I can type into my emacs buffer while observing some web page with documentation partially on top of some part of the emacs windows. But on Mac OS X I often just have to give up and copy-paste into a text edit window, save that to a file, and then open that within emacs because I just cannot manage to get the stupid windows to overlap in a way that lets me get what I need to do, done.

      I think if Apple would not be such fascists about some UI policy, the Mac OS X experience would be alot better.

      But overall, I'm like 90% happy with Mac OS X. Definitely beats the living hell out of Windows.

    7. Re:Nature takes care of mistakes like these. by xfizik · · Score: 0

      Windows XP has seen 3 service packs with major functionality overhauls. Not to mention countless update Tuesdays. Not sure how you can compare longevity with all the facts on the table.

    8. Re:Nature takes care of mistakes like these. by smash · · Score: 0

      Agreed. There are things that annoy me about OS X as well, as with any platform. However - the list of annoyances is far more liveable for me than the list with Windows or a typical Linux or FreeBSD desktop.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    9. Re: Nature takes care of mistakes like these. by smash · · Score: 1, Offtopic

      Wow, that sounds way simpler than just browsing the network share that is already visible from within dolphin, from within VLC's file-open dialog, like I do with every other platform!

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    10. Re:Nature takes care of mistakes like these. by DarwinSurvivor · · Score: 0

      Debian is about the biggest project not yet using Systemd. Fedora switched ages ago, Arch switched a year ago and once Debian does it, I'm pretty sure the vast majority of its decendants (Ubuntu, Mint, etc) will probably follow suite shortly. Systemd is a little more complex to maintain, but the performance difference alone is *astounding*. I remember when Arch made the change and I instantly went from a 30 second boot to an 6 second boot with apache, mysql and a bunch of other auto-start stuff turned on.

    11. Re:Nature takes care of mistakes like these. by Cramer · · Score: 0

      Seriously, how often does one reboot linux systems such that the startup is the thing that requires optimization?!? And saying systemd is "a little more complex" is like say the Sahara is a "little dessert".

      I thought *NIX purests insisted the entire system be so simple it could be maintained with nothing more than cat and vi. systemd (and SMF) are as far from there as you can get and still be in the solar system.

    12. Re: Nature takes care of mistakes like these. by Anonymous Coward · · Score: -1

      I thought this was news for nerds, not news for people-who-cannot-be-arsed-to-click-on-three-or-four-buttons.

    13. Re: Nature takes care of mistakes like these. by smash · · Score: 2

      If you think being a nerd is about doing things the most awkward ass-backward way possible, you're an idiot. Easy things shouldn't be difficult. Make easy things easy, and spend the time recovered on less pointless fuckwittery.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    14. Re:Nature takes care of mistakes like these. by DarwinSurvivor · · Score: 1

      It's not just boot time that is faster (it was just the most obvious). Even normal service starting/stopping and some logging stuff is faster. There are also some very powerful log querying you can, though I haven't really looked into them much myself.

    15. Re:Nature takes care of mistakes like these. by Cramer · · Score: 1

      Binary log files are Evil(tm). A single stray byte out of place and the log is destroyed. (never used checkpoint firewall, or innoDB I guess)

    16. Re:Nature takes care of mistakes like these. by tverbeek · · Score: 1

      Why didn't you list DOS 2? Oh yeah, because it was hugely popular (for its time), thanks to its support for hard drives with subdirectories. Not as widely deployed as DOS 3 would be, but far from a flop.

      You're correct that DOS 4 flopped. That's one data point. (And really, that was IBM's failure, not Microsoft's.)

      DOS 6 was widely adopted, replacing DOS 5 (which had little to recommend it except that it wasn't DOS 4) and living a long and productive life under the 16-bit versions of Windows.

      Windows 98 enjoyed quite a bit of success, and (except for being a trojan for IE4) deservedly so; 98SE was the Windows that people stuck with on their older hardware rather than installing the resource-hogging Windows XP. Perhaps you were thinking of the deservedly-reviled Windows ME, which followed it?

      You're also correct that Vista and Win8 have been flops. So that's three data points, but non-consecutive. Microsoft's success/failure pattern isn't quite as simple as you misremember.

      --
      http://alternatives.rzero.com/
    17. Re: Nature takes care of mistakes like these. by Anonymous Coward · · Score: 0

      The reason mac cant have focus-follows-mouse is the unified menu bar, as discovered by unity. Think about how hard it is to get from the focused window to the menu without crossing another window and changing focus.

      IMHO one of the things Mac does right is avoiding radical ui changes even when it turns out they got it wrong. The unified menu makes sense for the old "single app running at a time" paradigm, but is a mistake for the newer "multiple apps running and interacting" paradigm (which also favour's focus follows mouse). However, think how disruptive it would be to drop it?

  25. easy to hate what hasn't been tried. by Anonymous Coward · · Score: 1

    Yyyeah, no, I heard a lot of hate for it, but Oh god, upstart is a disaster. It's a dependency-based system that doesn't do anything with its dependencies! Systemd's a little bit terrifying, but it actually does the job it sets out to do, while every time I sit down with upstart I wish I was just using basic sysV+LSB init.

  26. A non-conspiratorial response by Anonymous Coward · · Score: 0

    I've been using all my banked karma to vote down the cut & paste protest messages about beta.

    I've been marking each and every one of them as "Off-topic" (well until my karma ran out). I assume that after a certain threshold of negative posts there are built-in repercussions under the system.

    I know sober reflection isn't popular when discussing the site redesign but there you go.

  27. Re:Die, Ubuntu, Die (on topic = marginal) by Anonymous Coward · · Score: 0

    What Mint really needs to get widespread adoption is a better story around major release updates. They say something like, "better just save your user data, reinstall the system from scratch, and restore your data...", or "uhh you can try to update but we don't promise it'll work..."

    Not good answers. If they fix that, Ill switch to Mint tomorrow.

  28. OpenRC by Anonymous Coward · · Score: 0

    This is the first I've heard of OpenRC, but it sounds like the ideal compromise to improve the init system while remaining compatible with it and not consuming unrelated projects into it.

    https://wiki.debian.org/Debate/initsystem/openrc

    1. Re:OpenRC by Anonymous Coward · · Score: 0

      As a gentooer I've using openrc for several years - it's excellent. I'm so disappointed it isn't being adopted by debian, a huge opportunity has been missed by both openrc and debian, shame.

      Its main strength, from my point of view, is its easy maintainability and extensibility, even as a non-expert. This is something sorely lacking by design in systemd which is the largest gripe people have against it. Fuck Beta, fuck Lennart.

    2. Re:OpenRC by HiThere · · Score: 2

      An earlier post by another proponent of OpenRC said that it was still too beta to be adopted, even though he regretted it.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    3. Re:OpenRC by broken_chaos · · Score: 1

      Too beta in Debian. It's been used for years in Gentoo, but was only added to Debian's package archives a couple months ago.

  29. A lot of "collateral damage" mis-moddings. by Anonymous Coward · · Score: -1

    I know things have been somewhat hectic around here these past few days, what with the negative response from the community to the beta, and the extensive down-modding we've seen as a result of the outrage. Mis-moderations do happen now and then, of course, but it seems to be particularly bad lately. Perfectly good comments, making perfectly valid and correct points, and corresponding perfectly to the topic of discussion, are modded down without any obvious reason why.

    The GP is right. In this case, it just so happens that the Slashdot beta website is in fact a very good example of what can happen to a software project that makes bad decisions that prove to be harmful to the users. We can even witness the inherent truth to this statement within the comments of this very thread of discussion! The GP's comment deserves a +5, Insightful mod, not -1. If it applies to Slashdot and the other projects mentioned, it applies to Debian, as well.

    I really hope that these obvious mis-moderations come to an end soon enough. The level of censorship here is edging toward that we see at Reddit or Hacker News. That kind of overt censorship is one of the main reasons why so many people come to Slashdot, rather than those sites. The discussion here is much more robust and open to original thought, whereas such things are shunned and punished at Reddit and Hacker News. If the awful beta website doesn't drive people away, then the modding-down of perfectly good comments likely will.

    1. Re:A lot of "collateral damage" mis-moddings. by Barsteward · · Score: -1, Troll

      Anonymous Cowards are still as full of bullshit as they ever were, perhaps no-one will miss them when the beta goes live - fuck off to Digg or reddit or better still "My little Pony" (its about the correct age for them)

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    2. Re:A lot of "collateral damage" mis-moddings. by Anonymous Coward · · Score: 0

      I'm glad to see that you're using your full, real name here, "Barsteward". Otherwise, we may have to think that you're hiding behind some sort of a pseudonym, posting in an anonymous fashion. It's a good thing that isn't the case, isn't it?

    3. Re:A lot of "collateral damage" mis-moddings. by Delwin · · Score: 0

      Most of us who use use-names on the Internet have our real name tied to them in so many places that it is trivial to connect the two, and thus they serve no real purpose in terms of security. They are nicknames, nothing more.

  30. Re:Die, Ubuntu, Die (on topic = marginal) by BanHammor · · Score: 3, Informative

    You do know your pretty flagrant racism makes your opinions automatically much less sound, right?

  31. sad. Now what is the alternative? Fork? by GodWasAnAlien · · Score: 1

    Upstart was unnecessary in Ubuntu. Systemd is not necessary in Fedora or Debian.

    There are other ways to get fast boots, without create another monolithic do-everything daemon with spaghetti dependencies.
    Basic software engineering principles (and Unix principles), should tell you that do-everything daemons, like upstart, systemd, hald are bad ideas.

    With such complex, unmodular core Linux systems, Linux based OS's will grow increasingly more unstable and insecure.

    Also, systemd and upstart make Linux much less suitable for embedded systems.

    The choices, I guess, are:

    Fork the pre-systemd Debian.
    Start fresh, perhaps even starting with the simple event based init system from the most popular Linux distribution in the world ... Android.

  32. Good, because it's inevitable by Bryan+Ischo · · Score: 5, Interesting

    This is good because it will get systemd onto even more systems, which will hopefully be a forcing function for improving it so that it's more usable.

    The introduction of systemd into my distros of choice (I was a heavy Arch Linux user until this year, when I switched back to Fedora after a ~8 year absence) has caused me more problems that any other single change to any part of the Linux operating system in my history of its usage (and I've been using Linux since 1994).

    I'm at the point in my life where I just want things to work; and I found that systemd has in many places not worked well. I wholly believe that the problems are generally due to the implementation of the individual services, and not bugs in systemd itself, although I suspect that the 90 degree turn taken by systemd and its associated complexity are the genesis of the problems in the individual services themselves.

    In particular, I've found that systemd on Fedora cannot properly start up an NFS server. I have a post-start up script that I run manually to start NFS because no matter what I do, it does not seem possible to force systemd to start all of the requisite NFS services. systemds tools for figuring out what could be going wrong are, I am sure, complete, but very impenetrable to a person who wants to understand the minimum necessary to fix a problem.

    Additionally, it seems to be easy to break systemd's boot scripts in a way that prevent systemd from being able to boot the system (it's happened to me over and over again through what seemd like innocuous user actions), and I have never successfully gotten systemd to boot into its recovery shell. I can get to the recovery shell but I can never type anything into it, it seems like there's something borked with the way it handles keyboard input somehow.

    In summary, systemd is much less mature than init ever was, which, combined with its tendency to reimplement everything and thus de-evolve much of what used-to-work into no-longer-works-easily, has resulted in whole system failures at a rate that I have never, ever experienced before under Linux.

    All that being said, it's pretty clear that lots of Linux distro maintainers are more excited by the few advancements that systemd makes over the old init system, than they are put off by the lack of maturity and quality of systemd; therefore, systemd is an inevitability, and I'm glad that debian is taking it now, because it will mean even more developer effort towards fixing its problems.

    In short: more pain for other people, making them more likely to fix my problems for me. So I'm happy that debian is doing this to their users, for my benefit.

    1. Re:Good, because it's inevitable by Peter+H.S. · · Score: 1

      Additionally, it seems to be easy to break systemd's boot scripts in a way that prevent systemd from being able to boot the system (it's happened to me over and over again through what seemd like innocuous user actions), and I have never successfully gotten systemd to boot into its recovery shell.

      This is most likely because the system is waiting for a disk that actually aren't there or a variant of that. So use "nofail" , "nobootwait" or "x-systemd.automount" if you mess with fstab and aren't sure your changes will actually work on boot, or if it is a removable drive etc.
      There is a short discussion of it here:
      http://www.reddit.com/r/archli...

      IMHO, systemd is doing this the correct way; if a disk is suddenly missing at boot, it is considered a critical failure that must be fixed from eg. the rescue console, before the system continue. That sysvinit would plod along with booting without system critical disks coming online may be convenient for those who makes error in their fstab, but may be a outright disaster for other users.

    2. Re:Good, because it's inevitable by Bryan+Ischo · · Score: 2

      It's not the dropping into a recovery shell that is the problem; that is something that I would expect to happen (and always happened under init, as well).

      It's the fact that the systemd recovery shell is nonfunctional. It doesn't accept keyboard input. I had this happen under Arch Linux, then switched to Fedora, and had the same thing happen. And thus concluded that it's endemic to systemd since it's hard to believe that both Arch Linux and Fedora independently managed to screw up systemd's recovery shell in their patches to or configurations of systemd.

    3. Re:Good, because it's inevitable by Peter+H.S. · · Score: 1

      Well, I don't think the rescue shell sees much action then, and if nobody file a bug report, then it could take a while before it is fixed.

    4. Re:Good, because it's inevitable by fnj · · Score: 1

      A system rescue shell that doesn't accept keyboard input is pretty blatantly busted. One wonders how it could possibly make it through a test suite.

    5. Re:Good, because it's inevitable by gweihir · · Score: 2

      "Forcing it on many systems so that it gets improved as to be more usable." WTF? Are we now cloning the MS business model as well? If this thing is not rock-solid, highly usable and in a final state, it has no business at all being a default init system, except in highly experimental installations.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    6. Re:Good, because it's inevitable by ShoulderOfOrion · · Score: 2

      I don't care if it's in a final state (no software ever is). However, I echo the OP's lament that pushing out software that does half of what the old software did, half as well, seems to be a common and distressing mode of operation among too many developers. KDE 4.0, Unity, Gnome 3, etc., would have been a lot more acceptable if it was at least as functional as what it replaced. The common pattern seems to be throw out beta software, spend two years sorting out the issues until most users are satisfied, and then start over from scratch, just because. It would be nice if more developers followed the example of eg the LateX project and valued functionality and stability over 'oooh, shiny new thing!'

    7. Re:Good, because it's inevitable by gweihir · · Score: 2

      Indeed, very true. Or the myriad of stable window managers (I use fvwm, one major update in the last 15 years), instead of trying to clone Windows with KDE and Gnome and never really reaching an usable, mostly stable state.

      This may be a result from more and more commercial development going into Linux: These people have to justify their existence. With LaTeX, fvwm and other "stable" things, things get fixed when they are broken, not before. And if they are not broken, they just stay unbroken.

      The other thing that applies to these projects is the following quote:

      "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare

      I guess, Poettering and his ilk do not understand that a simple system can be far more optimized, stable, better than a complex system and usually is and that them replacing a simple system with a complex one just demonstrates their incompetence and inexperience.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Good, because it's inevitable by DuckDodgers · · Score: 1

      This is Debian we're talking about. If they go with systemd in release Jessie, it won't go out until it's rock solid. If that takes three years, it won't be unusual for Debian.

    9. Re:Good, because it's inevitable by gweihir · · Score: 1

      Well, yes. And no. "Jessie" is testing. IN many cases you need to run Debian testing to get newer software. So this is a mixed blessing.

      There is also some hope it will never be "rock solid" (in fact it pretty much cannot be, but the issue is whether the people responsible for this move will be able to see that), and that it will get ripped out a gain. Come to think of it, if that happens, it could be the best solution. A resounding "this is a piece of trash" after Debian really tried to make systemd work would be a really good outcome.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  33. Re by binarylarry · · Score: 0

    Fuck you.

    --
    Mod me down, my New Earth Global Warmingist friends!
  34. tried an true? by Gravis+Zero · · Score: 1

    honestly, i would rather have something that is known to work in the long term and not need update to patch bugs or possible changes to the config file implementation. let's just use something that we know works.

    on the other hand, couldn't it be an optional package (a package is required but there are multiple to choose from) with the default as systemd?

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:tried an true? by gweihir · · Score: 1

      Neither tried nor true, but the main developer (Poettering) has an ego so big he thinks he is the second coming. After the really bad pulse-audio, he apparently decided to set himself a statue by violating any and all UNIX principles and cloning what Windows does. No way that crap is finding its way on any of my systems.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  35. My biggest gripe with systemd... by wonkey_monkey · · Score: 2

    ...is that "systemctl" is a lot of keys to type, and the last four are all consonants.

    At least "service" is an actual word.

    --
    systemd is Roko's Basilisk.
    1. Re:My biggest gripe with systemd... by ustolemyname · · Score: 1

      Yeah, but it tab completes, so on the other hand it's the only word you have to type and the only spelling you have to get correct.

      My biggest gripe with service is that it doesn't support tab-completion.

    2. Re:My biggest gripe with systemd... by Anonymous Coward · · Score: 0

      Service still work fine at least on RH derivated distro.

    3. Re:My biggest gripe with systemd... by Anonymous Coward · · Score: 0

      alias sc='systemctl'

    4. Re:My biggest gripe with systemd... by Anonymous Coward · · Score: 0

      At least on Fedora,"service" just passes on any of "start|stop|restart|try-restart|reload|force-reload|status" to "systemctl". (It's just a shell script. You can "$EDITOR $(which service)" and take a look.)

  36. Re:Soooo by Anonymous Coward · · Score: 0

    ironic how this has been rated -1 offtopic. lol.

  37. Many here hate Microsoft by Anonymous Coward · · Score: 0

    Then why's mgt. here pulling a "Windows 8" trying to shove beta on people that don't want it? Answer (always is) is money. Tracking and money via cookies and javascript. They are going to destroy this place with that. Steve Ballmer must've taken the reins as the NEW CEO of /., eh?

    1. Re:Many here hate Microsoft by bug1 · · Score: 1

      If your using this sites comment system to try and destroy this site with a boycott, why do you expect to have good karma on this site ?

      Then why's mgt. here (rant removed) ?

      That reponse pretty much explains why your karma is burnt and your posting anon. Your post is not relevent to the story or the comment you replied to.

    2. Re:Many here hate Microsoft by Anonymous Coward · · Score: 0

      It's very relevant. You can't sell people on what they don't want. The comparison's apt. I never had an account here either.

  38. All hope is lost by Anonymous Coward · · Score: 0

    ./.

  39. Re:Die, Ubuntu, Die (on topic = marginal) by Anonymous Coward · · Score: 0

    Debian user of the year I take it?

  40. Re:Die, Ubuntu, Die (on topic = marginal) by Anonymous Coward · · Score: 0

    s/racism/homophobism

  41. Smart people are quiet by Anonymous Coward · · Score: 0

    And don't care much for the cancerous systemd and the continuing Microsoftification of Linux, just because systemd is the "new thing" and "new thing" has to be better.

  42. Help us Linus Torvaldskenobi! by Anonymous Coward · · Score: 0

    You are our only hope to get rid of this bullshit about to infest our systems.

  43. We're tired by Anonymous Coward · · Score: 0

    How about you learn to use google.

  44. Bring yer shotgun..... by rts008 · · Score: 1, Flamebait

    You'll need more than a shotgun if you head my way, punk.

    And looking at your username, your shell won't help you a bit.

    I couldn't care less that the protesting about beta has your panties in a knot.
    We are fighting the change to beta with the tools available to us. If you don't want to be in the conflict, just leave....no one is stopping you.

    If you are going to sink to physical threats, then I am your Huckleberry, bring it on if you are more than talk. I'm in Oklahoma, and posted my address prior on /. if you are serious, otherwise you can STFU, IMO.

    I'm also off work recuperating from a surgery, so time and schedules are not a limiting factor. Come on! I'll even give you a handicap: I ONLY get to use my issued Ka-Bar!(that's an indication of how much of a threat you really are)

    BTW, you could use a LOT of work/education on your insult/name-calling skills, as they are currently presented, they're pretty lame. ;-)

    --
    Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
    1. Re:Bring yer shotgun..... by Anonymous Coward · · Score: 0

      Isn't the primary tool for fighting the change to beta...leaving Slashdot? Let beta be. It will fail, and DICE will either capitulate and bring back proper classic, or sell off the "property" to a new owner. Hopefully *that* owner will have the presence of mind to reinstate basic.

      I appreciate all the "every thread is beta bitching" attempt, but it's clear to me (even before this attempted change) that DICE is more concerned about page views than either quality, or community. Seriously, do we need a AGW story every second day? Where did all the actual tech news go? Run back 10~12 years or so and see what CmdrTaco was posting day to day vs the bullhockey here now. It's Snowden this, spying that, AGW for click-bait bullshit day after day. Slashdot is dead. May it live again in another place, in a future time.

  45. Sour Grapes by Tenebrousedge · · Score: 1

    Yes, yes, Gnome3 depends on logind/systemd. Also ConsoleKit ceased development. It's almost as if they think it's a better technology. But hey, you want to install a massive monolithic DE, it's gonna pull in some dependencies that you may or may not like. That is not Debian's problem, actually -- if they showed any signs of being amenable to discussion on the matter, then you might complain to the Gnome developers.

    This vote ignored the issue of what kind of default the default should be, because it only had one question that was being decided. It is unlikely to be the end of the discussion on the matter, so I am sure that all those with opinions will get their fair say -- just not on this vote. I realize that the vote may not have gone your way, but those grapes were probably sour anyway.

    --
    Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
  46. Re:Die, Ubuntu, Die (on topic = marginal) by DNS-and-BIND · · Score: 0

    That's not true at all, otherwise Al Sharpton and Jesse Jackson would be ostracized instead of valued White House guests.

    --
    Shutting down free speech with violence isn't fighting fascism. It IS fascism!
  47. Why by Anonymous Coward · · Score: 0

    Why don't they just switch to openRC.
    It is actually cross platform (i.e. can also be used for BSD)

  48. Damn. Time to move away from Debian. A shame. by gweihir · · Score: 3, Insightful

    I am not putting a convoluted, megalomaniac-spawned and KISS-violating atrocity like systemd on my systems. The binary log-format alone is a faux pas to severe as to invalidate the whole thing. Are there any good server-distros left that stay away from systemd or that are at least commited to maintaining a different init system longterm, preferably the classic SysV init?

    Of course systemd will fail eventually (once enough people realize it is a bad clone of what Windows does and makes things worse, not better), but I am unwilling to wait that long or tolerate all the disadvantages this thing brings in the meantime.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Damn. Time to move away from Debian. A shame. by Anonymous Coward · · Score: 0

      I recommend OpenBSD.

    2. Re:Damn. Time to move away from Debian. A shame. by Anonymous Coward · · Score: 0
  49. Re:sad. Now what is the alternative? Fork? by gweihir · · Score: 1

    If not good alternative presents itself, I may just rip it out myself and stay with SysV init. Boot-times are pretty irrelevant, especially for a server-distro like Debian.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  50. Re:Die, Ubuntu, Die (on topic = marginal) by fnj · · Score: 0

    Ah yes, the appeal to labels rather than substance. So unlike the poster you reply to.

  51. I switched to BSDs because of the Linux distros ac by Anonymous Coward · · Score: 1

    Linux is no longer Unix-like and is slowly turning into some sort of a Windows hybrid (RedHat and others) that will ultimately become the enemy of Unix. Terrible decision by Debian. Other Linux distros will follow suit and will most certainly become non-Unix more and more as time reveals their true intention.

  52. Woot! by Anonymous Coward · · Score: 0

    Go Gentoo, its your birthday!

  53. Re:sad. Now what is the alternative? Fork? by Anonymous Coward · · Score: 0

    Gentoo forked it the minute we saw this coming.

  54. Slashcott! by LaminatorX · · Score: 1

    This site used to be great. Even in it's latter days, it's been good. That is poised to change. Before long, it will be mediocre, and ordinary.

    I didn't see a problem when Dice Holdings initially bought Slashdot. I figured there would be efforts to drive nerd traffic towards their job listings and such. That was fine. We all need jobs.

    Things have changed now. Beyond the shifts in story choices, the slashvertisements, and so on, something fundamental has changed: Slashdot's owners do not appreciate it.

    Their recent financials show that they have written its value as an asset down to zero. They have legally claimed it to be worthless. That is at the root of what is happening now. They want to fundamentally change the nature of this site in order to remake it into something with big growth potential.

    Beta is just the latest symptom of this disease. It will not be the last. In striving to make it into a site that will bring them a growing user base and growing revenue per user, they have shown a willingness to dumb down the interface in the name of making it more accessible to newcomers, to cast aside essential elements of decade-spanning community culture, and to plow ahead with changes in the face of overwhelmingly negative user feedback.

    This is not going to change. This will not go away. I will not support it.

    I will be gone for this entire week, in protest. While away, I will work to create a new community where things can be run with quality user discussions as the paramount objective.

    Be seeing you.

  55. Hoping for the Best by Foresto · · Score: 1

    I'm among the many who have built up a healthy aversion to certain software after having been repeatedly burned by Pulse. I would not have chosen systemd. That said, I have tremendous respect for the Debian team, and am optimistic that the worst of the problems we find with their choice will be addressed within a couple of years. Let's get the bickering out of our systems quickly, and move on to helping one another turn the new init into something genuinely good.

  56. Systemd, consolekit by Anonymous Coward · · Score: 0

    If I wanted to run a huge monolithic system, where the people building the system want to tell me how to use my computer, I would be running Windows 8.

    As for ConsoleKit, what? I've never felt the need to install it. Seems like it was always just a precursor to systemd. Other than that, I never figured out what it really is. The closest thing I ever found to documentation, made it sound like it's a way of overriding the security of the system, allowing people who should never be allowed to run anything as root to do just that.

    ConsoleKit, RootKit... Perhaps not coincidental that the names have so much in common.

  57. cgroups by Anonymous Coward · · Score: 0

    Cgroups is a kernel feature. It worked fine before systemd. Now, though, the systemd people have decided that they be the owners of this kernel feature, and nobody else be allowed to use it.

  58. /usr by Anonymous Coward · · Score: 0

    Yet, every distro that decides to jump on systemd, suddenly adds the requirement that /usr be on the root partition.

    Maybe the distroes know something that the systemd propaganda forgets to tell.

  59. Propaganda by Anonymous Coward · · Score: 0

    Yes, that's the official systemd propaganda.

    Yet, /usr on a separate partition has always worked, and unless you can afford a one TB SSD (preferably two, these things are not relibable enough to run without RAID), putting / on an SSD and /usr on a one TB hard drive is a great idea. Only when systemd comes along do distroes start requiring /usr on /.

    As for initramfs, anyone suggesting to me that a server use initramfs, will be forced to fix a non-working initramfs, using only the tools available on said initramfs, and making the change stick for long enough to reboot the machine and run mkinitramfs. Failing that, they will be transferred over to the other "format and reinstall" Windows admins.

  60. Anonymous Coward by Anonymous Coward · · Score: 0

    You're only seeing the positive sides of it, you haven't experienced the downsides yet.

    Last time I tried displaying log files using journalctl, it took half a minute(!) to display the entire log! Considering the two most common operations I do are "tail /var/log/foo" and "tail -F /var/log/foo" and the first thing suddenly takes 300 times longer, and the second thing is impossible, I say journald as a log system is broken.

    Not to mention that journalctl will bail out after disk corruption, since it's binary log files suddenly aren't in the format it expects.

    There's no way to fix this, because they're fundamental issues with binary logging. Binary logging is, will always be, and has always been broken and a *bad idea*.

  61. "Default on linux" by Anonymous Coward · · Score: 0

    So does "default on linux" mean I can use the alternative kFreeBSD/Hurd init on Debian/Linux as well? Because I can't use systemd on HA clusters, where the service management is done by something else and init can't demand to be the only cgroups writer. Upstart would be painful enough, but systemd is impossible.

    Perhaps I'll take a closer look at mint, after all. Or is there a binary distribution using an init that restricts itself to init? Integration with service management is a problem for me.

  62. wtf is wrong with people? by greenfruitsalad · · Score: 2

    as a debian user i am puzzled by why this monstrosity was chosen instead of something that adheres to the 'do one thing and do it well' philosophy. why are we slowly turning gnu/linux into windows?

    Zawinski's law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

    i propose we include an email client functionality now and be done with this horrible one-thing-breaks-all thing.

    1. Re:wtf is wrong with people? by Bill,+Shooter+of+Bul · · Score: 1

      Basically, because upstart doesn't do the job of an init system well. SystemD does.

      SystemD does also do a number of other things well. Its not monolithic in the sense that there is a single binary doing everything. Not all of the apis that connects the pieces together are guaranteed to stay stable, but they have made some promises of api stability when it makes sense.

      So many things can be made better by having a really good Pid 1. And some things only make sense integrated into Pid 1.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    2. Re:wtf is wrong with people? by Cramer · · Score: 0

      No, it's a crap-ton of binaries that depend on another crap-ton of bullshit libraries. (anything that requires D-Bus, is, by definition, a mistake)

      What the fuck is wrong with shell scripts and shell fragment configuration files? It's worked for many decades.

    3. Re:wtf is wrong with people? by Bill,+Shooter+of+Bul · · Score: 1

      They suck at managing daemons, that's what the hell is wrong with them.

      Init systems have "worked" for different definitions of work. There are porblems with shell scripts, they lose track of threads easily. They're slow, easy to create circular dependancies.

      Take a look at the debian init positions, and see for yourself what they think are major drawbacks of sysvinit. Absolutely *no one* on the tech commitee thinks its a good idea to stay with it. As much animosity as there is between the systemd and upstart camps, no one has listed any other solution besides upstart and systemd as a first or second choice. That should tell you something.

      https://wiki.debian.org/Debate...

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
  63. RAH RAH RAH by Anonymous Coward · · Score: 0

    Just you wait, Leisure Shit Larry. Soon Dice is going to put the hammer down on known trolls like yourself.

  64. Don't be... by Anonymous Coward · · Score: 0

    Don't be a pretentious douche. It's not like he said, "Ubuntu: It's Debian for Shit-Colored Niggers."

  65. Insightful? by Anonymous Coward · · Score: 0

    This is high-school internet tough guy crap, c'mon guys. Be less obvious.

  66. asdasd by Anonymous Coward · · Score: 0

    Makes room for other sites that can manage their finances and have a better business plan. We are a large audience dying for high quality tech & science journalism because there just isn't enough of it, it is possible to make money out of us.

  67. Systemd is broken by design by Anonymous Coward · · Score: 0

    read more at http://ewontfix.com/14/

  68. Email debian 727708@bugs.debian.org by Anonymous Coward · · Score: 0

    Email debian:
    727708@bugs.debian.org
    debian-devel@lists.debian.org

    Tell them Fuck Systemd

    Don't let lennart pottering (harry potter?) take over all of linux. Don't let his fan bois conquer debian.

    We need a General Resolution to overturn this crap. The systemd people might be a majority in key positions, but likely not elsewhere.
    Let your voice be heard.

  69. systemd is broken by design, by Anonymous Coward · · Score: 3, Informative

    read more about it at: http://ewontfix.com/14/

  70. Re:Die, Ubuntu, Die (on topic = marginal) by Anonymous Coward · · Score: 0

    multi-culty really gets on your nerves, doesn't it?

  71. Re:Die, Ubuntu, Die (on topic = marginal) by BanHammor · · Score: 1

    Please elaborate.

  72. Re:Die, Ubuntu, Die (on topic = marginal) by BanHammor · · Score: 1

    I can't criticise personal choices. (It seems he has approximately the same problem with Ubuntu as he does with black or gay people though.)

  73. Re:sad. Now what is the alternative? Fork? by jgrahn · · Score: 1

    Also, systemd and upstart make Linux much less suitable for embedded systems.

    Actually, I think it's partly the embedded people who are pushing for systemd. Which worries me, since many of them don't know or care about Unix.

  74. Is Nothing Sacred? by Anonymous Coward · · Score: 0

    Sourceforge: Now Spyware.
    Debian: Rolling releases and Harry Pottering Taint.
    Semantic Desktop: Shoot me.
    Slashdot: Intent on becoming Pentrest apparently.
    Cyogenmod: Sells out.
    Freshmeat: Can't even recall what bland name they changed it to.
    Wayland and Vnc: Fuck that.

    Fuck where is safe Are any of the bsds safe? Theo is a dick so wtf is a neckbeard to do.