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."

227 of 379 comments (clear)

  1. 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 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.

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

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

    3. 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.

    4. 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.

    5. 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.

    6. 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.

    7. 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.

    8. 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.

    9. 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
    10. 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.

    11. 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.

  2. 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 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.
    4. 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 ?

    5. 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.

    6. 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."
    7. 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.

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

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

      Maybe not in YOUR timezone.

    9. 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.

  3. 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 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.

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

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

    5. 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.
    6. 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
  4. 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.

  5. 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).

  6. 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 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)
    2. 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....

    3. 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.

    4. 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.

    5. 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
    6. 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.

    7. 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"

  7. 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 richlv · · Score: 1

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

      --
      Rich
    5. 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.

    6. 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.

    7. 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
    8. 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
    9. 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.
    10. 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.
    11. 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.

    12. 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

    13. 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.

    14. 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.

    15. 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.

    16. 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...

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

      Yep. Pretty much. Good post.

    18. 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)

    19. 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.
    20. 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.
    21. 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!
    22. 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.

    23. 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?).

    24. 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.

    25. 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...
    26. 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.
    27. 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.
    28. 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.

    29. 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?

    30. 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.

    31. 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.

    32. 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.

    33. 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.

    34. 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...

    35. 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+).

    36. 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.

    37. 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?

    38. 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...

    39. 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.
    40. 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.
    41. 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?

    42. 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.
    43. 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.
    44. 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.
    45. 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.

    46. 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.)

    47. 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.

    48. 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.)

    49. 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.

    50. 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
  8. 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 madprof · · Score: 1

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

    2. 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.
    3. 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.

    4. 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
    5. Re:Gee by Stormwatch · · Score: 1

      In Soviet Russia...

    6. 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.

  9. 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: 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.

    2. 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.

    3. 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.
    4. 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
    5. Re:Thank You Slashdot by efitton · · Score: 1

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

    6. 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.
    7. 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
  10. 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!
  11. 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 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.

    2. 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."

    3. 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.

    4. 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.

    5. 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,

    6. 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.

    7. 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.

    8. 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.
    9. 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.

    10. 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.

    11. 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.

    12. 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. ...

    13. 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.

    14. 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.

    15. 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.
    16. 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.
    17. 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.
    18. 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.

    19. 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.

    20. 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?

    21. 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

    22. 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?
    23. 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.

    24. 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.
    25. 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.

    26. 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.

    27. 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:

    28. 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.

    29. 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,

    30. 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.

    31. 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.

    32. 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.

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

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

    34. 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.

    35. 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.

    36. 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.

    37. 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.

    38. 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 :-)

    39. 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 ...

  12. 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/)

  13. 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.
  14. 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...

  15. 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 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.

    3. 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
    4. 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.
    5. 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.

    6. 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.
    7. Re:Irrational Hate by Boltronics · · Score: 1

      Then you must be administering Windows boxes.

      --
      It's GNU/Linux dammit!
    8. 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.
    9. 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
    10. 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.

    11. 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.
    12. 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.
    13. 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.

    14. 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.

    15. 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.

    16. 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!
    17. 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.

    18. Re:Irrational Hate by Boltronics · · Score: 1

      That's true. Point taken.

      --
      It's GNU/Linux dammit!
    19. 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.

    20. 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!
    21. Re:Irrational Hate by Sri+Ramkrishna · · Score: 1

      Indeed!

  16. 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.

  17. 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.

  18. 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?

  19. 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.

  20. 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?

  21. 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.

  22. 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.
  23. 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.
  24. 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.

  25. 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
  26. 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."
  27. 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.

  28. 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.
  29. 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.

  30. 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.
  31. 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
  32. 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.
  33. 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.
  34. 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.
  35. 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.
  36. 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.

  37. 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.
  38. 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.
  39. 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.
  40. 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.

  41. 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.

  42. 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.

  43. 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.

  44. 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.
  45. 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.
  46. 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 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.
  47. 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.

  48. systemd is broken by design, by Anonymous Coward · · Score: 3, Informative

    read more about it at: http://ewontfix.com/14/

  49. 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.
  50. 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.
  51. 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.

  52. Re:Die, Ubuntu, Die (on topic = marginal) by BanHammor · · Score: 1

    Please elaborate.

  53. 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.)

  54. 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)

  55. 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."
  56. 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/
  57. 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.