Debian 8 Jessie Released

linuxscreenshot writes: After almost 24 months of constant development, the Debian project is proud to present its new stable version 8 (code name Jessie), which will be supported for the next five years thanks to the combined work of the Debian Security team and the Debian Long Term Support team. (Release notes.) Jessie ships with a new default init system, systemd. The systemd suite provides features such as faster boot times, cgroups for services, and the possibility of isolating part of the services. The sysvinit init system is still available in Jessie. Screenshots and a screencast are available.

Comments

systemd vs initd

[Pikoro]

here we go...

Guess it's time to change my email address...

Re:systemd vs initd

[Anonymous Coward]

Nyet! Do not change your email address... I am begging you to NOT do this! I will kill myself if you change your email address...

Re:systemd vs initd

[Pikoro]

Wow. You seem more attached to my address than I am. Perhaps I should offer @init.sh email addresses for the die hards :)

Re:systemd vs initd

[Anonymous Coward]

I love systemD! Pottering is the next Bill Gates + Steve Jobs + DaVinchi!! Amorphous blobs of code for all the cool kids running arch and Debian.

Re:systemd vs initd

[Anonymous Coward]

I want systemd@init.sh !

Re:systemd vs initd

[doctor_shim]

well last time i was on /. it was emacs vs. vim, so I'm very glad we moved on.

Re:systemd vs initd

[asvravi]

Sign me up for systemd@init.sh please :)

Poettering?

[Anonymous Coward]

More liek PWNNering amirite giuz?

Don't trust Jessie

[MichaelSmith]

Bad news

Re:Don't trust Jessie

[Anonymous Coward]

Why, did he just build a FULLER HOUSE?

File manager without file, edit, view..

[Blaskowicz]

The screenshots aren't looking bad but that Gnome quest for removing menu bars goes a bit far. What if you find yourself with no free space in a file manager window to right-click on. I tell people to use "Edit / Paste" or "File / Create a new folder" in that case.

Re:File manager without file, edit, view..

[Anonymous Coward]

A little? GNONE is garbage these days that you avoid with a 20ft pole. If you want to run some other window manager, like blackbox or xfe, then GNOME apps are terribad. There is no window title because they no longer use standard calls to create their windows.

I basically removed things like Evince and replaced it with much more usable qpdfview, and that is only because of terrible user interface in GNOME.

Re:File manager without file, edit, view..

[Anonymous Coward]

You should thank them for doing something new, without simply copying other systems.

Re:File manager without file, edit, view..

[Jobless *topia]

I think Debian made a mistake by again making Gnome the desktop default. They should have stuck to XFCE or chosen LXDE, which is approaching Gnome 2 in usability..

Re:File manager without file, edit, view..

[Anonymous Coward]

sarcasm detected

Re:File manager without file, edit, view..

[Anonymous Coward]

For me, Linux on the Desktop (ie. me putting up with it) died with Gnome 2. Now, I use a MacBook Pro and I touch Linux only through SSH.

Re:File manager without file, edit, view..

[kthreadd]

GNOME applications works just fine with other desktop environments and window managers. What used to be the biggest concern, the app menu, is no longer handled by adding a separate menu bar in the window with just for that menu. Instead, most applications show it as a button in the headerbar when not run within GNOME.

Re:File manager without file, edit, view..

[Anonymous Coward]

http://cdimage.debian.org/cdim...

go there ->

choose your architecture ->
    * i386/amd64/others

choose your download type ->
    * media format (cd, dvd, bd)
    * download method (bt, jigdo, direct iso)

choose your 'default' desktop -->
    * gnome (default, unspecified in filename)
    * kde
    * xfce
    * lxde

download FIRST disc only for your selection.

Re:File manager without file, edit, view..

[CronoCloud]

en GNOME apps are terribad

"terribad" isn't an english word, quit hanging out with geeks who have ESL, "chan" people, and other dudebro types.

I think this would have been a better way of stating it:

" If you want to run some other window manager, like blackbox or xfe, then GNOME apps have terrible usability issues."

See, saying it that way doesn't make you sound like you look like this guy:

http://cdn.arstechnica.net/wp-...

Re:File manager without file, edit, view..

[Anonymous Coward]

"Terribad" is a perfectly cromulent word, you pedant.

Re:File manager without file, edit, view..

[Anonymous Coward]

Sam for me. Evince was one of the last gnome applications I was still using but after a recent upgrade, I discovered that the UI was redesigned and was mostly useless. I tried various alternative pdf viewers and I discovered Zathura. No UI there. Everything is done via keyboard shortcuts but its fast and the mouse is only used for copying, to follow links (double click) and scrolling with the wheel. The keyboard shortcut seems mostly inspired from emacs and vi and they can be redefined.

 

Re:File manager without file, edit, view..

[marcello_dl]

> "terribad" isn't an english word
*English

Re:File manager without file, edit, view..

[ssam]

Install MATE desktop ( http://mate-desktop.org/ ), if you want the full GNOME2 style, or just the MATE apps if you like GNOME shell, but want a full featured file browser (caja), pdf viewer (atril), text editor (pluma) etc.

Re:File manager without file, edit, view..

[Gadget_Guy]

You should thank them for doing something new, without simply copying other systems.

I think that a window full of icons has been done before. It is not exactly a revolutionary interface.

Re:File manager without file, edit, view..

[kthreadd]

The UI was redesigned but it still has the capabilities of the old UI, if you're willing to look for things in another place. Most things were moved to the app menu and the drop-down menus in the top-right corner of the viewer window. Keyboard shortcuts are of course still there.

Re:File manager without file, edit, view..

[vga_init]

I have been using Gnome 3 on Fedora for about a couple years now, and I honestly can't understand why people don't like it. In fact, I don't really feel like using other UI's anymore because Gnome 3 is too efficient. Yes, it still has its quirks. The title bar is a little big and gets obnoxious when you maximize some applications, but I'm willing to accept that in order to get everything else it offers.

The best thing about Gnome now is that it doesn't get in my way. Switching apps/windows is easy. All the useless crap I don't need to see has been taken off the screen. The application launcher is nice, though nothing particularly innovative because anyone who has used Mac OS X or Windows 7 knows what it's doing.

I'm guessing that people who don't like Gnome 3 never really learned how to use it, like people who say they hate vim. Learning how to use Gnome 3 isn't even that challenging in itself, as the main keyboard shortcuts are very standardized. Launcher and window behavior are exactly what you'd expect them to be. It's fast and sleek, end of story.

Also it can't be denied that the desktop has undergone appreciable improvements with literally every release. Two years ago the keyboard layout switcher was broken, but now it works beautifully (this feature is important to me because I switch layouts a lot). Fedora 22 has just gone into beta, and if you want to see what Gnome is like now then you can give that a spin. Like I said, I don't use anything else anymore, although when I want to remember what using Windows XP was like, I'll load up KDE or XFCE or LXDE or something. Plus if you're really that attached to Gnome 2, Gnome 3 got a "classic" mode several releases ago which basically duplicates Gnome 2's UI features. You'll get your drop-down app menu back and the little task bar at the bottom.

Re:File manager without file, edit, view..

[kthreadd]

I can only agree. GNOME 3 was a bit rough around 3.0/3.2 and wasn't really that great until 3.8/3.10. Unfortunately, it was in the early days when a lot of people tried GNOME 3 for the first time. Debian with GNOME 3.14 will be a great desktop experience.

Re:File manager without file, edit, view..

[Anonymous Coward]

Gnome 3 leaks 500MB .. 1.5 GB every day, at least here. Maybe it's not as bad for everybody but I will have to stay away from it for as my workflow is not "do not own a desktop with nvidia card and 4..8 GB of memory".

And no, it's not caching. The memory is never released. And it has been this way since 2013.

Re:File manager without file, edit, view..

[AchilleTalon]

Terrifuck!

Re:File manager without file, edit, view..

[Anonymous Coward]

A little? GNONE is garbage these days that you avoid with a 20ft pole. If you want to run some other window manager, like blackbox or xfe, then GNOME apps are terribad.

Lol, angry gnussolini nerd. And the rest of the world with brains keeps not caring and happily uses Unity and Gnome-shell.

Re:File manager without file, edit, view..

[101percent]

reasons why you're wrong

Re:File manager without file, edit, view..

[Kjella]

Lol, angry gnussolini nerd. And the rest of the world with brains keeps not caring and happily uses Unity and Gnome-shell.

The rest of the world uses Windows and OS X on the desktop, Android and iOS on mobile and couldn't care less about Unity and Gnome-shell. Even Windows Vista got Linux beat on StatCounter. You can use the classic desktop paradigm that ~78% use (Win7 + WinXP + OS X + Vista), join the new touch paradigm with ~19% (Win8 + Win8.1) or you can go your own way. My impression is that they're trying to design a car driven by joystick because some UX designer thought it was better, what's tested and works is too boring.

How about winning over some existing, established markets before trying to chase the latest fad? And even if it's not a fad, open source never moves fast enough to be first because there's no overall leader. Sure you could slap Linux on a tablet like Microsoft did with Windows many years before Apple, but it won't work well until all the application developers feel having a touch UI is an itch they need to scratch. Sure we can have visionaries, but Jobs was a visionary with an army of developers to turn them into reality. A Linux visionary is a man with a powerpoint slide. Or actually a LibreOffice Impress slide, I guess.

Re:File manager without file, edit, view..

[Anonymous Coward]

Linus uses Gnome and told me to tell you that you are a faggot.

Re:File manager without file, edit, view..

[jones_supa]

What process is hogging this memory?

Re:File manager without file, edit, view..

[fnj]

Or I can use okular, and I don't have to GUESS how to do things. It's all discoverable, un-hidden menus, just like the days when people used to believe in standards.

Re:File manager without file, edit, view..

[kthreadd]

They are not hidden, they have just moved to another place. The top-right corner is quite common nowadays to put these. Even Firefox has that now so it should be discoverable.

Re:File manager without file, edit, view..

[Anonymous Coward]

Because when a browser does it it makes that ui nightmare an example to follow for the desktop. Jeez. chrome and then firefox were mocked mercilessly for the fuckery of the interface and now with just to apps it becomes the norm.

At one point in my youth I recognised the benefits of having to learn a well thought out way of doing thing, and in time the general populous would migrate to this as well. Now most interfaces seem to cater for wave the mouse (and now knuckle) around until the magic happens.

Re:File manager without file, edit, view..

[The Infamous Grimace]

Yeah, that design is so original.

Re:File manager without file, edit, view..

[Anonymous Coward]

AchilleTalonmasturbates

Re:File manager without file, edit, view..

[RabidReindeer]

terribad (tr-BAD). Bad to an extreme degree. From 'terrible"+"bad" (cf.), implying worse than either. See also horrawful.

Oxford English Dictionary, 2016 Edition, All Rights Preserved.

Re:File manager without file, edit, view..

[CronoCloud]

Fuck the OED, they started catering to the "lets add all the new Internet meme words" people. Besides, I'm from the US and it is NOT in the Merriam-Webster. Considering it seems to be UK and EU types that use it most...

I really don't care what some meme-addled strongbad-watching twenty year old gamer-geeks think, it's not a word.

If someone wants to say "bad to an extreme degree" they can say "extremely bad" or "extremely terrible" that's what adverbs are for. Would Whitman, Steinbeck make up silly words like "extremebad" or "extremible"

Now get off my lawn.

Re:File manager without file, edit, view..

[Anonymous Coward]

Gnome shell.

Re: File manager without file, edit, view..

[Anonymous Coward]

That's too much of a pain!I Debian has taken away my choice (during iinstal)!

Blows my mind how these guys are fine withrridiculously complicated command line workflows, crazy install procedures that usually require editing config files, and then complain when something they're used to isn't the default, but perfectly accessible, choice.

Crusty as fuck.

Re:File manager without file, edit, view..

[fph il quozientatore]

That's cute.

Re:File manager without file, edit, view..

[Anonymous Coward]

Debian's biggest mistake ever was choosing gnome as its default desktop environment instead of KDE. Yes, KDE4 was released long before it was ready. They should have stuck with KDE3.xx until KDE4 was more mature.

Re:File manager without file, edit, view..

[jcdr]

I have multiples machines, each with a different Desktop: Gnome 3, Unity, XFCE and MATE.

My biggest problem with Gnome 3 is the fact it's not designed to work well with multiple windows overlapping and spread on a lot of virtual desktops. I usually have more than 100 windows on about 40 virtual desktops. This kind of use is a nightmare with Gnome 3 or Unity because the respective position of the virtual desktops change dynamically so it's impossible to map in the brain. The second problem is the upper left corner switch that place each widows in a random order impossible to memorize, so totally useless for me. The next problem is the animations and effect that make everything slow and distracting. The next problem is the panel extension that are difficult to select because of big catalog of similar entries, and rarely a good quality both in term of usability and in term of look. Finally the menu really hurt on big screen like 4K because it open from the left of the screen but the sub-menus are on the right of the screen. This menu take so much place that it require a lot of mouse translation to do almost anything. Whats totally ridicule is that even by displaying so few items on a 4K screen, this menu is not even able to display the full name of all application because it truncate it to the size of the icon. So no, I really don't like Gnome 3 (and Unity that share a lot of same bad design).

XFCE and MATE are extremely efficient and blazing fast for my use case. There make easy to map in my brain the respective position of a lot of virtual desktops. The panel widget are coherent and easy to select in a small list of entries but with a lot of features of each entries. The menu is the most simplest possible, but display the full name of all the applications, require a minimum of space so it's fast to use with the mouse and is easy to customize. No animation, no effect, just maximal speed. Finally there perfectly scale on a 4K screen without any disadvantage. And i like the windows tab menu with a useful text into each tab describing precisely what's is in each related window.

Put simply, Gnome 3 idea is big graphic and small or no text. What I need is small icon and a lot of text.

Re:File manager without file, edit, view..

[Anonymous Coward]

We've been able to Alt-Tab between windows since at least Windows 3. How has Gnome 3 made that easier?

Re:File manager without file, edit, view..

[dumfrac]

I have been using Gnome 3 on Fedora for about a couple years now, and I honestly can't understand why people don't like it.

I completely agree. It took a while to get used to it, but once over that stage, I found that it didn't get in the way of what I was doing at all. The interface is simple and clean.

Re:File manager without file, edit, view..

[Anonymous Coward]

Heh ... the GNOME settings window even has most of the same subsection names as in earlier versions of Mac OS X. But of course, they are completely different, with recent versions of Mac OS X having a right-facing flying blue UN flag on a pole for 'Language & Region', while GNOME has a right-facing flying blue UN flag on a pole for 'Region & Language'.

GNOME, meanwhile, has a white human figure with arms outstretched on a light blue circle for 'Universal Access' - while in current versions of Mac OS X, the white human figure with arms outstretched on a light blue circle is for 'Accessibility'. It was only labelled 'Universal Access' in previous versions of Mac OS X.

And so on. Completely different.

Re:File manager without file, edit, view..

[Anonymous Coward]

Plus if you're really that attached to Gnome 2, Gnome 3 got a "classic" mode several releases ago which basically duplicates Gnome 2's UI features.

It's too late for that. If they'd included that from the start, I'd have stuck with Gnome. Instead, they tried to force a new UI on me, and lost me completely. I can never trust that they - meaning the Gnome dev team - won't do the same again.

Re:File manager without file, edit, view..

[jbolden]

Debian in so far as they picked either their issue was the license and that got resolves around 1999. KDE3 to 4 was never the cause of Debian tilting towards Gnome.

Re:File manager without file, edit, view..

[Anonymous Coward]

Just do the job in a terminal. Gnome is meant to be easy. If you know enough to want to do something complicated like that, then you know enough to be able to figure out how to do it on a command line. Gnome is very good at displaying terminals.

Re:File manager without file, edit, view..

[Anonymous Coward]

Does anyone install Debian with the default desktop? I always thought that everyone went the netinstaller route. It's just way more convenient if you have a decent connection.

Re:File manager without file, edit, view..

[Anonymous Coward]

I agree with the fact that it can improve your productivity once you learned to master it, yet it's really hard to customize sometimes. For example sometimes ago the 3.6 to 3.10 iteration they forced the desktop switcher to show everytime, there was an extension to remove it back, but it was unmantained, I had to hunt it from some guy's repo and fix it to run on 3.10. But to think that you HAVE to seek for an extension for that kind of silly customization it's just mind boggling. Why not offer an advanced configuration mode? Why cinnamon guys seem to be doing it right?

Also it can't be denied that the desktop has undergone appreciable improvements with literally every release

Would you call improvement to dropping at least one nautilus feature each release? What about turning one of the most beloved Linux editors (from the GUI era) into something that most people don't want to touch with a 10 foot pole? Is it making something so essential as changing the startup applications a hidden configuration setting in gnome-tweak-tool that doesn't offer the flexibility that it offered in gnome 2? Why dropping features that were there 10 years ago? They worked well, people liked them!

I used Gnome 3 for many months, I really wanted to like it, I liked the workflow, but I realized that I was struggling with it most of the time. Then I figured out that I was using mostly apps from outside gnome environment since gnome apps became so useless, that I might as well ditch the whole thing. I came back several times. But the trend of remove and obscure settings keeps going on.

Now I use a window manager with the MATE project apps, they might be boring or look dated, but sure they get the job done and they are _reliable_. I know that next time I open Caja, the statusbar showing my available disk space will be there, that I'll be able to make symlinks from there, that I can delete files without learning some obscure keystroke.

 

I don't think I'm close minded, but there are issues with gnome 3, or perhaps there aren't but they just changed the way of the project. They want to have their DE their way and only THEIR WAY, and that's fine for them since they're the developers but not for me.

Re:File manager without file, edit, view..

[John Marter]

If you used to like evince, consider atril.

Re:File manager without file, edit, view..

[Blaskowicz]

The netinstaller can install the desktop. I installed Ubuntu 10.04 that way by the way and wow, that was impressive all the way (on the target desktop, hit F12 and boot from ethernet, hit enter to launch the text mode installer. A rather short while after, you got a really good looking GTK2 desktop with everything on the latest security updates).
That saves a lot of time and bandwith vs wget-ing the iso, putting it on media etc.
Then debian squeeze was kind of the debian version of ubuntu 10.04 (lenny was close to 8.04).

Re:File manager without file, edit, view..

[ChunderDownunder]

Thanks for the tip. Atril seems lightning quick and uses far less memory compared with Okular on a heavily image-laden PDF.

Re:File manager without file, edit, view..

[vga_init]

My hat goes off to you because you go above and beyond the average usage case. Plus you know what you need, which is important.

What I get from a lot of commentators is that they feel betrayed like Gnome 3 is somehow forced on them, or just saying that they don't like how it works. I'm in no way trying to say that everyone should have to use Gnome 3 (desktop choice is important, after all), or that it must clearly be the best desktop ever (to be honest there's something special about Gnome 2 / MATE that is hard to replace). I just want to say that it's a little unfair that Gnome gets this angry sea of negativity, with people suggesting it's the worst DE ever conceived by man. It may not tickle everyone's toes, but it's not THAT bad.

Re:File manager without file, edit, view..

[jcdr]

Debian Jessie, just released, is AFAIK the first leading distribution that allow to select the desktop of choice directly from the installer. This is a welcome move, because before, yes some user like me did't have so much choice, unless you install manually a desktop (hard to do), or switch to an other distribution (I use Mint on a laptop). Part of the problem is that XFCE and MATE take some years to get the high quality there provides today. What's interesting is that XFCE and MATE have get this quality precisely because so many peoples was frustrated with the Gnome 3 experience.

The way the Gnome project managed the transition will stay for long as an example of bad practice. The main error was to abandon the Gnome 2 code while the code Gnome 3 did not allow most of the users to make the transition based on there own motivation because at some point there will found that Gnome 3 is better. The reality is still that Gnome 3 did not reach this point for enough users that the venerable XFCE project gain support like never before and the MATE project started from the abandoned Gnome 2 code.

And there is the Cinnamon project that try to bring the MATE feature on a Gnome 3 base. All of this show how much frustration the Gnome 3 project have created early. Now the situation is far better and in a near future I beat that the winning project will be the one that will be the fastest to integrate in a nice way the beast features of all the projects. I suspect that Gnome 3 is not in a good condition to win the race, as his evolution since a couple of years in anemic compared to MATE for example.

Re:File manager without file, edit, view..

[vga_init]

Back in the pre-Gnome 2 days a lot of distros actually used to offer you a bunch of choices at install time which DE or WM you wanted, but that trend changed when distros started to focus heavily on offering one desktop experience that the system was targeting. Some distros would have separate teams working on different environment packages, so technically with distros like Fedora and Ubuntu, other desktops are available at install time, but you have to select the appropriate installer because they have different install images now. With many distros installing an additional desktop environment after the default can basically be done by typing a command.

Re:File manager without file, edit, view..

[dave420]

The OED is simply a dictionary. They report on words being used. They don't decide what are or are not words, they just reflect the current usage. Shooting the messenger isn't helping.

Re:File manager without file, edit, view..

[jcdr]

Right.

The evolution from FVWM/FVWM95/IceWM/Scwm/Sawfish (in my case) to Metacity was a big progress because The windows management API goes normalized and was separated from all the others goodies provided by a desktop. At this time Gnome 2 was a superb improvement (KDE too) for the users without losing really used features from the previous projects. XFCE, MATE and Cinnamon continue on this track, with some success. Gnome 3 WM Mutter was a different kind of evolution, more like an experimental project. There nothing wrong to try experiment, but closing Gnome 2 WM Metacity project so early was a bad choice. The most obvious prove of this is the fact that the developers of Mutter ported Metacity to GTK3+ instead of adding Metacity features into Mutter:
http://ftp.gnome.org/pub/GNOME...

From my point of view, Metacity should have been ported to GTK3+/Gnome 3, first and then Mutter could have started as a new experiment, not the contrary. The actual situation is just the natural correction of this error that have taken a lot too much attention than if it was done the right way.

Re:File manager without file, edit, view..

[Anonymous Coward]

Typical Asperger's type literalist /. comment. It's entirely obvious to anyone with three brain cells that *in this context* "The rest of the world" means "The rest of the Linux desktop using world" given that is the "world" we are discussing.
And people wonder why nerds are often mocked and despised...

Re:File manager without file, edit, view..

[squiggleslash]

They did include a "classic mode" from the start. It was originally called "Fallback". Over time they've updated how and why they implemented it, but the classic desktop was never really removed, just hidden behind absurd levels of obfuscation because they really thought you'd like GNOME Shell if only you'd use it.

Re:File manager without file, edit, view..

[Wolfrider]

--FORTY virtual desktops?? What in the world are you running on all of those?

Re:File manager without file, edit, view..

[fnj]

Bullshit. They are HIDDEN. A menu bar that says "File", "Edit", and "View" in plain English or $LOCALIZED_LANGUAGE_OF_CHOICE is not hidden. Something that can only be accessed by knowing a secret location, or by finding a cryptic symbol and determining its purpose, is hidden.

SAA/CUA did not happen, and take over everywhere that mattered, because it was the product of a bunch of masturbating monkeys. It was the end product of research and insight of genuine experts in human interface, including Apple's HIG, and ultimately the innovators behind Xerox Star.

Re:File manager without file, edit, view..

[Demonoid-Penguin]

I think Debian made a mistake by again making Gnome the desktop default. They should have stuck to XFCE or chosen LXDE, which is approaching Gnome 2 in usability..

Maybe you don't understand choices? Debian allows you to install many desktops - or none. Feel free to set your standards by the lowest common denominator (masses has a silent m?). But not every Debian user calls continuously hitting Enter an install. Even point and click retards can choose a different desktop from the gui installer menu - so why do you pretend default is something forced on you?

Debian - the Universal operating system.

The word you use, think, doesn't mean what you believe it means.

Re:File manager without file, edit, view..

[jcdr]

Actually 42, and I used to have 64 of them.

I manage multiple projects, once per line of virtual desktop except for the top line where I have all the social applications, general browsing, music, and unrelated stuff. On a typical project line I have desktop with the documentation, the schematics, the routing, the source code, the compilation, the console on the target, usually multiple times when there are more than on application to do. Some project have multiples machines involved and to be monitored. There a document to fill for the client, there are some experiment to do. This quickly take a lot of windows and desktops.

Now why did I not close the windows as soon as I don't need them and re-open them when required? Because I can simply just leave them as there are without any problem. If I have an idea on a project I can check it very quickly. If someone ask something about a project I just have to switch to the related virtual desktop where I will find the windows arranged in there usual way with documentation ready to be read, code ready to be edited and console connected to the target ready to take input.

In this situation, I really don't like to close my session or reboot. I need a system as stable as possible. I rebooted about 3 months ago to install a GPU, but I remember having passed a full year without any reboot.

beware...

[Anonymous Coward]

wait for first update. they released, again, without actually following their policy (which they are so anal about otherwise, re: docs, firefox, etc) of actually getting rc bug count to 0 before release. following historical trends of bug closure towards release, i was not expecting jesse until late summer at earliest.

Re:beware...

[gweihir]

So much in a hurry? Clearly they are hiding something.

Re:beware...

[Anonymous Coward]

They want to bury debian 7.

These cunts should be shot.

YAY! MULTIPASS Big Bada Boom!

[Anonymous Coward]

http://tanuki-tinka-asai.devia...
http://tanuki-tinka-asai.devia...

Better than Neo:
http://tanuki-tinka-asai.devia...

systemd fast?

[Anonymous Coward]

Lulz. Startup with Kubuntu 15.04 takes twice the time as with 14.10. systemd reduces boot times, my ass. Maybe it smokes Upstart and OpenRC in microbenchmarks, but didn't we learn something about microbenchmarks in the 3DMark days?

Re:systemd fast?

[greenfruitsalad]

well, on my computer it shortened startup time by about 10% (not much), the shutdown time however is another matter. if i forget to unmount nfs, it pauses for 2 minutes showing countdown and then continues shutdown. i've had many wtf moments with systemd.

Re:systemd fast?

[hitmark]

It is also the one init that goes into crisis mode if that usb devices you have a entry for in fstab is not present on boot.

A short hint Poettering, when it comes to unix boot, / is paramount, everything else is "best effort". Because once / is up, the sysadmin has the resources to get anything else sorted and mounted.

Oh wait, systemd is part of the effort to push everything into /usr...

If you want to make PoetteringOS go do so, and stop shitting all over long established, and time tested, behavior!

Re:systemd fast?

[deek]

This seems to be a common problem with changing from another init to systemd.

Basically, you have to mark your non-essential, auto mount on bootup, fstab entries with the option "nofail". It does make sense, as you can have essential parts of your system mounted on other partitions.

I would hope that this issue is handled by the upgrade process to systemd. Inform the person doing the upgrade to add the option, or automatically add the option to the fstab file for non root partitions.

Re:systemd fast?

[hitmark]

Yeah, nofail. Thats up there with their abuse of debug in the kernel command line.

nofail is simply about supressing the error message on a failed mount, nothing more, nothing less.

Have the whole system go into panic mode because of a vestigial USB mount is missing is not sane by a long shot.

Re:systemd fast?

[deek]

I agree that they abused "debug" in the kernel command line. Though that's a whole other can of worms, and you could argue that the term "debug" is generic, and should apply to all systems, not just the kernel. Using "kernel.debug" and "systemd.debug" would be more specific ways of flagging what system should enable debug messages on boot, and would be specific enough to avoid all the confusion that lay at the root of this problem.

The use of "nofail" here does fulfil a purpose though, even if it does cause some people headaches when changing init systems. But, like I said, this should probably be handled by the upgrade process, not by systemd itself.

If you don't want systemd to panic about a failed USB automatic mount on startup, then you have a number of options.

  * Specify "noauto" in fstab
  * Specify "nofail" in fstab
  * Install an automount system, and delete the entry from fstab.
  * Use the systemd automount feature, and delete the entry from fstab

  Look, systemd is different. It's not a complete drop-in replacement for sysv init, though it can work as such 99% of the time. Accept that it can be different, and work from there. Moaning about it just makes you sound like an overprotective old man with his lawn.

Choose init during installation?

[Jobless *topia]

Thanks to its rolling release Unstable branch, I haven't installed Debian in a long time. So this question is directed to those who are planning a fresh install. Does the Jessie installer give a choice between init systems? I know I can choose the default and then change using apt-get, so this for now this is more of an inconvenience than a dealbreaker.

Re:Choose init during installation?

[Pikoro]

Just did an install in a vm. No. There is no option to choose an init system. systemd is default. If you want to use sysvinit, you have to do it via a pre-install script which basically means, netinstall.

Re:Choose init during installation?

[kthreadd]

Or use something like FAI. It's widely used in larger deployments and allows you to customize as much as you want of the system at install time.

Re:Choose init during installation?

[Eunuchswear]

Just did an install in a vm. No. There is no option to choose an init system. systemd is default. If you want to use sysvinit, you have to do it via a pre-install script which basically means, netinstall.

Why just netinstall? The instructions I've seen on the web say: https://wiki.debian.org/systemd#Installing_without_systemd

If not using a preseed file, this can be added to the boot arguments instead by hitting TAB at the boot menu on the desired entry and appending the above preseed line at the end of the boot command.

That doesn't work?

Re:Choose init during installation?

[Pikoro]

Trying it now. Will replay with results.

Re:Choose init during installation?

[Pikoro]

Ok. Yes. It seems to work. Just append this to the end of the boot string after pressing tab and you'll have a sysvinit system:

preseed/late_command="in-target apt-get install -y sysvinit-core"

Re:Choose init during installation?

[Anonymous Coward]

> systemd is default.

That sucks. Since it swallows stderr and syslog output, that makes it very hard to troubleshoot start-up problems.

Re: Choose init during installation?

[Anonymous Coward]

This has burned me twice now.

Re:Choose init during installation?

[Demonoid-Penguin]

> systemd is default.

That sucks. Since it swallows stderr and syslog output, that makes it very hard to troubleshoot start-up problems.

If only systemd did logging. If only sad anonymous arseclowns had someway of finding answers for themselves.

Re:Choose init during installation?

[csirac]

No, you don't have to do it with preseed. Just sudo apt-get install sysvinit-core. At any time, for the entire lifecycle of your installation. You can switch back with sudo apt-get install systemd-sysv at any time too. Change back and forth at will; I have, and whilst I initially had big problems with it, Debian's packaging now even has filled in the gaps that the systemd project themselves seem uninterested in fixing, such as full crypttab support/compatibility that the old sysv/cryptmount ecosystem had supported.

Re:Choose init during installation?

[Anonymous Coward]

But it doesn't take systemd off. Sold as an init but much much worse than that. So the choice between inits was a false dichotomy as noone voted about wether we wanted the bits of systemd that aren't init.

Re:Choose init during installation?

[csirac]

Don't get me wrong, I was a pretty loud critic. Right now I work on embedded ARM where most COM vendors are still - in 2015 - selling brand new kit which can barely run kernel 3.2, let alone 3.7 required for cgroups/systemd - most systemd fanatics try to tell me to compile from mainline kernel sources, which ignores the fact that these things are all one-of-a-kind once-off type systems where I'd have to port the shitty once-off BSP code which barely made it over the wall in the first place (which I have done - and took weeks on my last attempt, due to shitty quirky b0rked interrupts on the MMC interface for that board), not just "yolo, git pull && recompile dawg # to hell with re-certification and customer revalidation" that web hipsters seem to assume is the case.

But honestly, the technical committee in Debian were the ones we entrusted to make this kind of decision, so it's a meta-lesson in community participation. You can make all the RedHat conspiracies you want but at the end of the day the technical committee volunteers decided it was too much work (read: they didn't have the help like you or I around) to take on spinning a distro with the option to install without systemd.

So all I'm saying is that the Linux ecosystem is shit, but we have only ourselves to blame.

Re:Choose init during installation?

[goarilla]

If only systemd did logging. If only sad anonymous arseclowns had someway of finding answers for themselves.

But If you can't write to these log files because your root or /var filesystem doesn't mount
then you would have wished for stdout/stderr on the console !

Re:Choose init during installation?

[Anonymous Coward]

Default boot uses systemd, but there is a sysvinit entry in grub menu. Just take a look !

Re:Choose init during installation?

[Demonoid-Penguin]

If only systemd did logging. If only sad anonymous arseclowns had someway of finding answers for themselves.

But If you can't write to these log files because your root or /var filesystem doesn't mount then you would have wished for stdout/stderr on the console !

Oh? Why wouldn't I just read /run/systemd/journal instead?

[unplugs disk that /var is mounted on and starts box]
var.mount mount process exited, code=exited status=32
hmmm, no information on what went wrong?

journalctl -u moron
It seems you are correct. I do apologise (unless I got the unit wrong...).

Please continue posting your informative advice.

P.S. Weren't you the genius who wondered why "we" don't know what happened before time and space began? Where do I sign up for your newsletter?

Re:Choose init during installation?

[goarilla]

Oh? Why wouldn't I just read /run/systemd/journal instead? [unplugs disk that /var is mounted on and starts box] var.mount mount process exited, code=exited status=32 hmmm, no information on what went wrong?

That's what systemd tells you not the output of the actual mount utility. It could lie. What if mount fails because of a severe filesystem error ? What if the initrd is broken and the actual mount helper utility is not present ?

P.S. Weren't you the genius who wondered why "we" don't know what happened before time and space began? Where do I sign up for your newsletter?

No, I was the "genius" that got confused because the medium article mentioned 2 BIG BANGS. That send a red flag for me because I was taught that yes, we can't look "before" the big bang because there simply was no time. And offcourse cosmic inflation happened after the big bang !

Something needed to happen to set up the initial conditions for the Big Bang, and that “thing” is cosmic inflation, or a period where the energy in the Universe wasn’t dominated by matter (or antimatter) or radiation, but rather by energy inherent to space itself, or an early, super-intense form of dark energy.

PS. Nice Ad hominem.

Re:Choose init during installation?

[Demonoid-Penguin]

Oh? Why wouldn't I just read /run/systemd/journal instead? [unplugs disk that /var is mounted on and starts box] var.mount mount process exited, code=exited status=32 hmmm, no information on what went wrong?

That's what systemd tells you not the output of the actual mount utility.

It could lie. What if mount fails because of a severe filesystem error ? What if the initrd is broken and the actual mount helper utility is not present ?

No answer to why I wouldn't just read /run/systemd/journal? NOTE: another strawman corner case is not an answer - it's just dodging a question.

For the output of mount I'd just replace moron with the name of the relevant unit I want output from.

Do you have any evidence that systemd lies?

You made a claim that systemd would give no information if /var didn't mount - I demonstrate that it does and you respond with more claims. That, by definition, is dodgy. My experience is that when a kernel build fails I still get information about the failure - likewise broken initrds. Maybe you should supply some actual evidence? Confirmation bias much? You do know what evidence is right? e.g. the sort of things you'd put in a useful bug report. Until you base your claims/"concerns" on such I'm going to go with the evidence to date, despite trying to find support for the presumption of your good intentions - that you're full of shit.

Facts are good - hand wavy "concerns" not so much. And don't let the conflating "default" with "no choice" cloud your perfectly rational objections.

systemd sux

[Anonymous Coward]

and it gonna kills Linux, if not stopped

Re:systemd sux

[Anonymous Coward]

Perhaps it will kill your glorified memories of how GNU/Linux used to work. Things are changing and most importantly, things are improving. You don't have to like those improvements, but they are. The people that make GNU/Linux distributions, especially Debian, are super-serious about it. They would not have used systemd if it threatened the system's existence.

Re:systemd sux

[dbIII]

most importantly, things are improving.

They certainly have to continue to improve before systemd becomes a more worthwhile option than the things it is replacing.
The only problem systemd solves is to replace things so old that they are maintained by people that have been coding for longer than Lennart Poettering.

Re:systemd sux

[Anonymous Coward]

You mean untested, unaudited code that is forced into production environments? Code that has full network access as root?

We went through this song and dance in the 1990s with sendmail that had multiple security holes in it, be it remote root or local priv escalation. The stakes are quite high these days... are the distro maintainers confident that they are doing their best to provide security for their customers?

I'd question that. No systemd based distro has been certified with EAL, FIPS, or Common Criteria yet.

Re:systemd sux

[Anonymous Coward]

You mean untested, unaudited code that is forced into production environments?

Untested, unaudited and forced into production? I've used it in production for five years (5!) now. Just because Debian is slow to adopt new technology doesn't mean that it's untested. People have used systemd in real-world production systems on other distributions since 2010, and has been around for a couple of years before that. This is hardly something brand new that just came from nowhere.

Re:systemd sux

[Anonymous Coward]

The distro maintainers are faggot SJWs, they kicked out anyone who was not (Ted Walther, etc). Pottering supports SJWism.

Re:systemd sux

[Anonymous Coward]

Code that has full network access as root?

On one of my non-systemd systemd:

ps -ef | grep inetd
root 1482 1 0 Apr19 ? 00:00:18 /usr/sbin/xinetd -dontfork -pidfile /var/run/xinetd.pid -stayalive

You mean like that one?

Re:systemd sux

[Eunuchswear]

So set up a distro maintained by straight white males, for straight white males.

Oh, you can't because you haven't got the brains or balls to do anything other than sit in the corner whining.

Re:systemd sux

[Eunuchswear]

You mean untested, unaudited code that is forced into production environments? Code that has full network access as root?

So, what systemd things have access to the network?

#netstat -naput | grep systemd
udp 0 0 0.0.0.0:54562 0.0.0.0:* 24001/systemd-times
# ps -fp 24001
UID PID PPID C STIME TTY TIME CMD
systemd+ 24001 1 0 Apr09 ? 00:00:00 /lib/systemd/systemd-timesyncd

Not running as root, running as user "systemd-timesyncd"

 

Re:systemd sux

[Anonymous Coward]

So, what systemd things have access to the network?

PID 1
http://0pointer.de/blog/projec...

Re:systemd sux

[Anonymous Coward]

"Oh, you can't because you haven't got the brains or balls to do anything other than sit in the corner whining."
And fork Xonotic

(And before that, Crossfire RPG)

Re:systemd sux

[Anonymous Coward]

>So set up a distro maintained by straight white males, for straight white males.
All of them before the SJW invasion.

Re:systemd sux

[Anonymous Coward]

I've used it in production for five years (5!) now. Just because Debian is slow to adopt new technology doesn't mean that it's untested. People have used systemd in real-world production systems on other distributions since 2010, and has been around for a couple of years before that.

Really, that long? Funny, because according to the systemd Wikipedia page the initial release was March 30th, 2010. The Wikipedia page itself wasn't started until August 2010, and Poettering's systemd announcement, where he mentions having an "experimental" init to compete with upstart (which had been around years before systemd) is dated April 30th, 2010.

That means that, no, it wasn't around a "couple years before" 2010, and wasn't added to any distro repositories until a year later, so your claim to have been using it on "production systems" for "five years now" is just as much bullshit as the claim that systemd existed years before 2010.

The only way you've been using systemd in production that long is if you're from the future and using systemd-timetraveld.

Re:systemd sux

[Barsteward]

as in only systemd? did you read the the link?

Re:systemd sux

[Hognoxious]

GP is reading from his own CV. He also has 3 years experience in doing the needful with Java 9.

Re: systemd sux

[Anonymous Coward]

You're correct and my memory was wrong. Fedora 15 came out in 2011 so it's only four years in production.

Anyway, you can't say that it's not tested.

Re:systemd sux

[arglebargle_xiv]

I'd question that. No systemd based distro has been certified with EAL, FIPS, or Common Criteria yet.

What does that have to do with security? All of the certifications you've mentioned are an evaluation of how desperate a vendor is to bid on government contracts, not of the security of a system.

Re:systemd sux

[Eunuchswear]

So now you're worried that someone will be able to hack systemd by making it exit a poll(2)?

systemd pid 1 may have sockets opened and bound but it doesn't read from them. How are you going to hack that?

Re:systemd sux

[SumDog]

Really? It's the apocalypse?

Look, I don't like systemd from a design perspective. But it does do one or two things really well: It's standardized init scripts between each distribution and it has full process control. It can track a process no matter how many children it makes.

It does way too much other stuff too. The binary logs are dumb. It's not small and modular. Yada yada.

The biggest problem which needed to be solved was full process management and none of the other projects were really getting anywhere.

It sucks. It shows that Redhat controls way to much. Other projects weren't able to get in. Yea I know. But it's not causing systems to go unstable and crash all the time. Put some perspective into it.

Re:systemd sux

[Anonymous Coward]

It's pretty naive of you to think that systemd is written perfectly, and without bugs. No software is like that. All it takes is one small buffer overflow, and something like systemd running with extreme privilege could very quickly become extraordinarily dangerous. Maybe it doesn't do some particular action now, but exploit a flaw in it to run custom code, and all of a sudden it's doing things you ever expected it to.

Re:systemd sux

[Anonymous Coward]

Many Social Justice Warriors are straight white males. They're working on distros for straight white males.

Social Justice is a mental disability that can affect anyone of any sexual orientation, of any skin color, and of any gender.

Re: systemd sux

[Anonymous Coward]

So what should we use instead? xinetd? It's not like this type of functionality has not been around for some time.

Re:systemd sux

[Anonymous Coward]

"It's pretty naive of you to think that systemd is written perfectly, and without bugs. No software is like that." - who said it was, even software thats been running for years can turn bad. the AC inferred that systemd "things" all run in PID1 which is complete crap. All other "things" in the systemd project (as opposed to the systemd daemon) are configurable as to whether they are used or not.

Re:systemd sux

[RightwingNutjob]

They would not have used systemd if it threatened the system's existence.

Sure. Let's assume that because it's the emperor, he must be wearing the finest of clothes.

As comrade Reagan used to say: Trust but verify

Re:systemd sux

[ruir]

Oh you just discovered he runs the servers for the HR department?

Re: systemd sux

[Anonymous Coward]

Fedora, in production?!?! LOL, just stop, it hurts.

Re:systemd sux

[gweihir]

Well, many systemd proponents will lie shamelessly about its characteristics. That is one reason why I have long since concluded that there is a massive PsyOps campaign behind getting it established. That also means that the NSA has its fingers deep in there, possibly without Poettering realizing. (And arrogant and incompetent lead developer is the perfect way to get lots and lots of bugs in there that will make the TAOs job much easier breaking into Linux in the future.)

History is full of inferior (and often grossly so) technological solutions being successful, just because they were pushed hard enough. The customer is stupid, and unfortunately that seems to be true for most of the Linux users as well.

Re:systemd sux

[gweihir]

If you extend the concept of SJWs just a bit, you can fit movements like National Socialism right in there. They most definitely started out as SJWs.

Re:systemd sux

[gweihir]

How are going to verify in the future that it is still not reading from them? In complex C-code?

The only legitimate reason to have sockets open is if you _are_ reading from them. Anything else is either gross incompetence or preparation to read from them at a later time, possibly clandestinely.

But thanks for giving me yet another reason to stay away from that Trojan Horse.

Re:systemd sux

[Anonymous Coward]

It reveals the weakness of the Linux "community" as more and more contributions are paid and done for profit, and the rest don't have the resources to go another way. I don't have a problem with that, but I think there are going to be more controversies like this in the future.

Re: systemd sux

[kthreadd]

Nothing wrong with using Fedora in production. It depends on what you want. If you want stable and boring the no, don't use Fedora. But if you want to use the latest technology and is OK with rolling forward every 6-12 months then Fedora is actually a great OS to run in production. There's a reason why "software collections" is a big feature in RHEL, and that is that it's more and more common that you actually need newer versions than what's in your "enterprise" distribution. And if that's the case then using a newer distribution could actually be the right solution. There are of course reasons why you wouldn't use Fedora. If you want a support contract or require certain certifications then use RHEL or something else.

Re: systemd sux

[buchanmilne]

You obviously aren't aware of inetd or xinetd, although you probably have them running, started by your precious sysvinit.

Re: systemd sux

[gweihir]

(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations. And no, I do not use them. The whole idea struck me as pretty problematic wayyyy back.

Another characteristic of the systemd-cretins: They think they know everything, and all others are clueless. They also think that anybody that does not like systemd has no clue about UNIX system administration. The actual reality is very different.

Re:systemd sux

[greg1104]

So set up a distro maintained by straight white males, for straight white males.

Done!.

Re: systemd sux

[drinkypoo]

You obviously aren't aware of inetd or xinetd, although you probably have them running, started by your precious sysvinit.

First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons. Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.

Re:systemd sux

[Eunuchswear]

History is full of inferior (and often grossly so) technological solutions being successful, just because they were pushed hard enough.

Notably, Unix.

Re:systemd sux

[Eunuchswear]

So no slackware users are female, homosexual, black or trans.

How do you know?

Re: systemd sux

[Eunuchswear]

(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations.

Uh, just like systemd?

Re: systemd sux

[Eunuchswear]

First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons.

Please name a modern Linux system that comes without [x]inetd.

Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.

Neither will systemd. As I said above on my system with no xxx.socket units systemd is not listening on any socket.

Re: systemd sux

[gweihir]

Where did you miss the statement that even in this simple, non-complex fashion (i.e. not like systemd at all) I think this is a bad idea?

Re:systemd sux

[gweihir]

Only somebody truly clueless about the history of computing could make such a statement. Also, relevance?

Re:systemd sux

[Eunuchswear]

Those who do not know multics are condemmed to reinmplement it, badly.

Re:systemd sux

[Peter H.S.]

It is pretty close to 4 years since the Fedora 15 was released with systemd:
LibreOffice was 3.3.2 (4.4 now)
Apache was 2.2 (now 2.4)
Kernel was 2.6.38 (4.0 now).

It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.

Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).

Re:systemd sux

[Demonoid-Penguin]

Perhaps it will kill your glorified memories of how GNU/Linux used to work. Things are changing and most importantly, things are improving. You don't have to like those improvements, but they are. The people that make GNU/Linux distributions, especially Debian, are super-serious about it. They would not have used systemd if it threatened the system's existence.

Linux is dead. Someone said udev would kill it, and they were right. Oh wait...

Re:systemd sux

[Peter H.S.]

You mean untested, unaudited code that is forced into production environments?

systemd code is both thoroughly tested and audited. In fact, Red Hat has a professional security audit team that actively audit systemd code, this is more than can be said for OpenRC or SysVinit or any other systemd alternative.

They also have integrated Coverty static code checking and good coding guidelines to ensure maximum security.

systemd have been used by distros since 2011 (It predates the Linux kernel 3.0 series) and some of its code like udev goes back to 2003. It is much better tested than most other Linux software.

Re: systemd sux

[Mike Greaves]

Please name a modern Linux system that comes without [x]inetd.

Ummm. The DEBIAN JESSIE install that I just did yesterday (small mail server) included no [x]inetd.

I didn't ask for it and Debian didn't include it by default.
Just getting used to 'systemd' too..
Mike

Re:systemd sux

[thegarbz]

The only problem systemd solves is to replace things so old that they are maintained by people that have been coding for longer than Lennart Poettering.

Yep, along with all the other problem the outdated init system presents that we have spent years and years patching and adding helper programs to work around.

Re:systemd sux

[thegarbz]

GP is reading from his own CV. He also has 3 years experience in doing the needful with Java 9.

And you don't? How do you ever have a hope of finding a job in IT? Next you're going to tell me you don't have 3 years experience as a Windows 10 admin. Maybe this industry just isn't for you.

Re:systemd sux

[Anonymous Coward]

But it's not causing systems to go unstable and crash all the time.

Not ALL the time, no. But I expect systems to NEVER crash, rarely crashing is not good enough. Systemd's PID 1 crashed on me when a script left a dead symlink and I tried to restart the daemon owning that symlink. Nothing like that EVER happened to me with sysvinit and starpar.

Yes I am aware that particular bug was fixed. But what this tells me is that the design of systemd makes it possible for trivial bugs to crash PID 1. What's next? A PID 1 crash triggered by a problem with a socket, mount point, or device file?

Re:systemd sux

[Anonymous Coward]

Maybe it doesn't need to be hacked. Perhaps causing a denial of service by triggering a bug that causes PID 1 to crash is enough to accomplish the attacker's goal.

Re:systemd sux

[Anonymous Coward]

It is absurd to suggest that systemd isn't proven and tested in the wild for a long period.

I made no claim about its maturity in my comment, though I'd say that in Debian's case it's much less tested than its successor and perhaps it would have been wise to present it as an installation option to make fallback easier in case systemd's init is troublesome. Btfs has been in development since 2007 and still hasn't supplanted ext4 due to niche problems, but Debian felt it was appropriate to push systemd as default. I say this only because Debian has generally been very conservative when making massive changes like this in the past, so it's uncharacteristic to change something as important as the init more recklessly than, say, switching from KDE3 to KDE4.

All I was doing with my comment was pointing out that the other AC was exaggerating to make systemd sound more mature and better-tested than it really is. It looked like an attempt to suggest systemd has been in development as long as upstart, which is untrue.

Also note that some systemd code like udev, existed even before the systemd project was announced, so at least part of the systemd code is much older than 5 years (udev was released in 2003).

I had a feeling someone would try this argument. Udev is older than the systemd project (and init), and has been included by default in distros for a long time now. Trying to insinuate, as you are, that this means systemd is that old is disingenuous. Especially in a discussion that's clearly focusing on the systemd init. The summary mentions the init part and boot times, the original comment in this thread was "systemd v initd", etc.

Nobody here was talking about udev, so trying to use it to insinuate systemd-init has been around longer than 2010 is deliberately misleading.

Re:systemd sux

[Anonymous Coward]

He checked both of them to make sure...

Re:systemd sux

[Uncle Warthog]

All other "things" in the systemd project (as opposed to the systemd daemon) are configurable as to whether they are used or not.

Indeed. Could you please point me to the section in the documentation on how to configure not to use journald?

Re: systemd sux

[buchanmilne]

(x)inetd does not control what it attaches, the user does and via plain-text files that are in easy to find standard locations.

# systemctl status rsyncd.socket
rsyncd.socket - Rsync Server Socket
      Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled)
      Active: inactive (dead)
      Listen: [::]:873 (Stream)
  Accepted: 0; Connected: 0
# cat /usr/lib/systemd/system/rsyncd.socket
[Unit]
Description=Rsync Server Socket
Conflicts=rsyncd.service

[Socket]
ListenStream=873
Accept=yes

[Install]
WantedBy=sockets.target

What is this, a non-text file? How is systemd controlling this, any more than xinetd was?

Re: systemd sux

[buchanmilne]

First, most modern Linux systems come without an inetd or xinetd, because they have no services which aren't supplied by long-running daemons.

Every modern Unix-like system has inetd or xinetd available, many install one of them by default.

The service we require xinetd for on every production server is: Netbackup's bpcd.

Second, inetd won't listen on things it doesn't need to listen on, let alone xinetd.

# readlink -f $(which init) /usr/lib/systemd/systemd
# netstat -plant|grep systemd
#

How is systemd any different?

Re: systemd sux

[buchanmilne]

Ummm. The DEBIAN JESSIE install that I just did yesterday (small mail server) included no [x]inetd.

I didn't ask for it and Debian didn't include it by default.
Just getting used to 'systemd' too..

It didn't install xinetd systemd is the default :-p

# apt-cache search xinetd
?

Re:systemd sux

[buchanmilne]

If you don't need the feature, it doesn't listen on any socket.

The default installation on most distros will probably not use socket activation, but some systems will *require* socket activation, just like in the past they required inetd or xinetd.

Re: systemd sux

[goarilla]

Last time I tried Fedora (11 or 12) It broke constantly. Although much of it was possibly due to KDE4 going through its "infant years".

Re: systemd sux

[Anonymous Coward]

We have fedora 8 on a number of 24/7 production servers that's been running like 7 years or so.

No problems that caused me problems for maintenence or eventually converting to VM, but all the ubuntu's have been a pain with bugs that never got resolved and only mitigated in later ubuntu's. My impression is Ubuntu is fragile and broken where our fedora boxes are rock solid.

I will say, though, the fedora boxes were installed by experienced, competent developers whereas the Ubuntu boxes by IT.

Re: systemd sux

[Anonymous Coward]

Read it again, you missed the "some" and "part" words that makes you look like you can't read or intentionally ignoring his point.

Re:systemd sux

[ookaze]

You use words and talk about things you don't even understand, you make gross generalizations and I'm sure you think that makes an argument.
First, a customer is everything but stupid, surely you meant a consumer.
You make fallacious sentences like "many systemd proponents will lie shamelessly about its characteristics". This sentence is a subject of study in itself, given that its meaning changes depending on who reads it. It contains no evidence, is based on nothing but your perception of reality.
Then comes the scare tactic with this gem : "That also means that the NSA has its fingers deep in there, possibly without Poettering realizing".
It seems to me you don't have even the start of a clue of computer science and how it works. It also seems to me that you keep the NSA as the utmost authority in security.
Did you know that (you won't understand one thing of what I'm going to say but whatever) the NSA was beaten by their own weak cryptographic algorithm policy (low key length) that they imposed on foreign countries?
The NSA is not the supra smart entity you think it is.

The systemd suite

[Hognoxious]

The systemd suite

Stop. That's the problem, right there.

Re:The systemd suite

[Anonymous Coward]

SystemD is like the Office, deliciously filled with politics, backstabbing and sleeping to the top.

Re:The systemd suite

[thegarbz]

Oh is that all it takes? Okay then: SYSTEMD SUX. Now where's my +5 insightful?

Re:The systemd suite

[Anonymous Coward]

Yup, SystemD is part of the SJW plot to destroy Debian and ultimately all open source.

Systemd wins?

[Anonymous Coward]

If systemd is in Debian, we might have consider that it won, even though there was a ton of backlash. Time to go read the docs on that animal, or I'll be plain old granpa neckbeard a lot sooner.

Re:Systemd wins?

[Anonymous Coward]

why bother just don't use debian.

Re:Systemd wins?

[Anonymous Coward]

Or just install a different init system. But yeah, this is about systemd so truth has nothing to do with it...

Re:Systemd wins?

[Anonymous Coward]

Why bother? Just use debian with systemd.
Do you really think that systemd will kill your wife and eat your dog?

Re:Systemd wins?

[Anonymous Coward]

systemd is not just an init system, it could be that some don't mind the init system part but take exception to the rest it offers/imposes or will offer/impose in the future. In that case installing an alternate init is hardly an apropriate response.

The good part of all this is that capable people who have been able to rely of the good governence of their distro of choice, in the past have been prompted to take control of their systems to ensure freedom of choice. It will be interesting to see if the main distros, who have made decisions against user choice, atrophy as quickly as you would think when they get the users they deserve with the skills base they cater for.

Re:Systemd wins?

[Anne Thwacks]

Do you really think that systemd will kill your wife and eat your dog?

Yes. and with its bare hands, to boot!

Re:Systemd wins?

[Anonymous Coward]

Its the mindset, the design, the politics and the use of force.

In short my dog has better manners and I'd trust him to design better software.

Systemd will get all the sheep users it diservers and the rest will migrate away, slowing introduce our distributions at our works places, quietly without people realising. We did it last time and will do it again.

And where we have control we'll save 'not in my shop' and pitty the poor bastards that have to deal with pointy haired bosses, but we've always done that.

Re:Systemd wins?

[The Infamous Grimace]

Do you really think that systemd will kill your wife and eat your dog?

Yes. and with its bare hands, to boot!

Well, it's gotta do what it's gotta do to boot the machine.

Re:Systemd wins?

[Anonymous Coward]

Do you really think that systemd will kill your wife and eat your dog?

Yes. and with its bare hands, to boot!

Hands?
more like insidious tentacles...

Re:Systemd wins?

[Anonymous Coward]

Do you really think that systemd will kill your wife and eat your dog?

Yes. and with its bare hands, to boot!

Well, it's gotta do what it's gotta do to boot the machine.

But think of the children!!

Re:Systemd wins?

[gweihir]

Despite the systemd mob being intent of forcing it in everywhere, it can still be avoided. You do not lose much. Giving up is so AC.

Re:Systemd wins?

[Anonymous Coward]

This is why everyone said that implementing reiser-compatability in systemd was a bad idea.

Why does it have to be systemd?

[Anonymous Coward]

Isn't there at least one mainstream distro that isn't going along with this systemd madness? To quote brilliance seen on slashdot:

Many features.
In the bloat.
Off to FreeBSD.
In a safety boat.
burma shave

Re:Why does it have to be systemd?

[Barsteward]

if you don't know which distros are not using systemd by now, you aren't working hard enough, bye bye and enjoy your new home at freeBSD which will eventually get a systemd/launchd system as they are investigating using one themselves.

Re:Why does it have to be systemd?

[ruir]

If you do not understand the concept of open source, force by the numbers and respect, you may very well go to hell. Debian has arrived where it has today because of people. FreeBSD knows better than using that shit. Know that also trivago turned me down a year ago because my *BSD was a little rusty, They just said very vaguely "all of we are linux guys, and we thought we were more up-to-date with your FreeBSD stuff as we want to migrate there. Take your conclusions, if you are too busy insulting people and making up stuff.

Re:Why does it have to be systemd?

[Barsteward]

"Take your conclusions, if you are too busy insulting people and making up stuff." eh? i'm not sure what you are on about with that statement.

systemd will not work on FreeBSD because of linux kernel features so they will probably design their own implementation. read this http://www.reddit.com/r/linux/... or watch this https://www.youtube.com/watch?...

Re:Why does it have to be systemd?

[ruir]

I am just saying FreeBSD is a system made by sysadmin to sysadmins and not overrun by political bastardos. I sincerely doubt they will go the same route.

Re:Why does it have to be systemd?

[Anonymous Coward]

Hopefully their implementation will do one thing and not fucking suck at it.

Re:Why does it have to be systemd?

[Peter H.S.]

I am just saying FreeBSD is a system made by sysadmin to sysadmins and not overrun by political bastardos. I sincerely doubt they will go the same route.

The co-founder of FreeBSD have already stated that systemd is a good thing and it is exactly what FreeBSD needs for the future:
https://www.youtube.com/watch?...

There are already *BSD developers working on this, including a systemd compatibility layer. So yes, FreeBSD will have a systemd clone init system, and binary log files too, it is only a matter of time.

Re:Why does it have to be systemd?

[RinkSpringer]

[Disclaimer: I've clicked through the slides, not watched the presentation] - yet your comment makes me feel you may expect too many changes, much too quickly. You see, the opinion of a co-founder isn't necessarily the opinion of the entire project. Anyone is free to contribute whatever he/she feels like the project needs; whether it will be adopted may be an entire different matter. Core changes like these _will_ get quite of lot of discussion, likely because the rc system 'just works' and I would not expect it to be changed anytime soon by something that hasn't matured. Note that this is just the expectation I have from working a few years within the FreeBSD project, so YMMV, etc.

Re:Why does it have to be systemd?

[Anonymous Coward]

Jump to about 27 min marker on the video talk by Jordan Hubbard for info about getting a modern init system. there has been a port of launchd for freebsd https://github.com/freebsd/openlaunchd but that said, it might not come to fruition as its a bit too MAC OS centric.

Re:Why does it have to be systemd?

[Anonymous Coward]

The co-founder was stating that a system base is a good thing, not that a systemd base is a good thing.
As for the rest, total rubbish.

Re:Why does it have to be systemd?

[Bengie]

The problems SystemD are trying to solve are real and FreeBSD is looking into the issue and my FreeBSD people agree with this. What the founder won't say, but other people will is that SystemD is a horrible implementation. Both Linux and WinME tried to solve the same issues, but Linux did a hella better job.

Re:Why does it have to be systemd?

[Anonymous Coward]

my = many

Re:Why does it have to be systemd?

[Peter H.S.]

systemd isn't a horrible implementation, it is in fact extremely good in many areas and extremely well coded and documented, which is exactly why FreeBSD will clone that instead of SMF/Launchd or try to invent a new solution.

Re:Why does it have to be systemd?

[Anonymous Coward]

And this is exactly what everyone in debian said, I'd say the count down has begun, trust no-one.

Re:Why does it have to be systemd?

[Peter H.S.]

Sure, not everyone agree with JH (yet), and FreeBSD do lack development manpower to make a fast transition away from rc, that is why he described it in a "FreeBSD the next 10 years talk".

My point is that FreeBSD _will_ get a systemd-like init-system, it is only a matter of when.
Of course there will be a lot of discussion, and for political reasons it will be dressed up as not being a systemd clone, and people will moan about learning something new, and there will be lots of drama on the mailing lists whipped up by a small vocal minority.

But like in Linux, the vast majority of actual developers and FreeBSD sponsors will quickly realise the many benefits of doing things the systemd way.

Re:Why does it have to be systemd?

[drinkypoo]

systemd isn't a horrible implementation, it is in fact extremely good in many areas and extremely well coded and documented, which is exactly why FreeBSD will clone that instead of SMF/Launchd or try to invent a new solution.

Regardless of what tack they do take, FreeBSD won't clone SMF or launchd because both SMF and launchd are festering pieces of shit hated by everyone familiar with them.

Re:Why does it have to be systemd?

[Peter H.S.]

Yes. systemd had the advantage of learning from both systems, using what they did right and discarding what they did wrong (xml etc). The systemd developers really did their homework well in this regard.

I am sure that the FreeBSD developers will study systemd intensely before making their own version too.

Re:Why does it have to be systemd?

[drinkypoo]

Yes. systemd had the advantage of learning from both systems, using what they did right and discarding what they did wrong

Sadly, that didn't stop them from making their own sophomoric mistakes made by neither, nor useful idiots from defending their incompetence and poor decision-making abilities.

Re:Why does it have to be systemd?

[Peter H.S.]

Sadly, that didn't stop them from making their own sophomoric mistakes made by neither, nor useful idiots from defending their incompetence and poor decision-making abilities.

IMHO, most people criticising systemd haven't really bothered up upon its design or why it is designed the way it is, but rely on third party blogs and random forum comments. There really are good technical decisions behinds its design:

Take the logging system; if you want "metal-to-metal" logging, that is from before rootfs is mounted to potentially after it is dismounted, and you want to collate all logging messages, no matter how and when they are generated, you will end up with a design like systemd's "journal".

All other existing Linux logging facilities have logging gaps and are unable to create collated logfiles from the entire boot and shutdown process.

systemd really solves many old Linux problems in one go, not at least the problem with the partially fossilized plumbing system: eg. cron was made with the assumption that computer was always on. This is a problem when most Linux devices these days runs on batteries and frequently are suspended or shut down.

But there is not central cron-developer group, there are only fragmented forks of ancient abandonware versions of eg. Vixie-cron, so cron can't be fixed, nor can there ever be a new cron version that fixes any problems that will make it incompatible with cron. cron is simply doomed to permanent fossilisation.

Getting systemd-timers is so nice in that they not only fixes old cron problems, but also makes it possible to change future implementations of it. It is simply great that there is a central developer hub that can take RFE's and patches for this.

I am really not aware of any "sophomoric mistakes" regarding systemd's design; it is small, modular, lean on resources, fast, stable, have lots of great features that are very easy to use.

IMHO nothing else on Linux even come close to all the features systemd have, which is why all major distros have chosen to use it.

Re:Why does it have to be systemd?

[drinkypoo]

IMHO nothing else on Linux even come close to all the features systemd have, which is why all major distros have chosen to use it.

That's because you're ignorant. Try more Linuxes so that you can be exposed to more things.

Re:Why does it have to be systemd?

[Peter H.S.]

That's because you're ignorant. Try more Linuxes so that you can be exposed to more things.

Well, I know SysVinit (including variations like Slackware uses) and Upstart. Both are pitiful when compared with systemd, especially killing processes and handling PID's. And all the service management tools you can tack on top I know of like Monit and S6 are painfully labour intensive to use and lacks fundamental features. (Monit has pretty graphs though).

Any init-system without integrated resource management like cgroups and easy to use service monitoring and easy to use security frameworks using namespaces and capabilities, are hopelessly nobbled when compared to systemd.

Just the fact that systemd uses structured plain text files for service and daemon configuration is a huge win compared to using script files, that are basically executable config files that mixes code and config options in one unstructured lump that are hard to parse for both humans and machines.

Re:Why does it have to be systemd?

[Anonymous Coward]

The co-founder of FreeBSD have already stated that systemd is a good thing and it is exactly what FreeBSD needs for the future

I'm pretty sure the co-founder means the init system, not the logging system with corrupt logs, the dns server with decade-old exploits, a network configuration/dependency resolution system that crashes and burns with an NFS mount and so on. You know, all the stuff that systemd advocates suddenly start saying isn't really part of systemd-init when people point out how buggy all this shit is.

Turtles all the way down

[Anonymous Coward]

nt

Going with the flow

[Anonymous Coward]

They must have noticed all their downstream forks are using systemd and decided it was time to change.

Systemd wins nothing

[Anonymous Coward]

If systemd is in Debian, we might have consider that it won, even though there was a ton of backlash

Unlike closed-source environment such as Windoze / Apple, those of us using Linux will always have a choice

Instead of 'read the docs' we have the choice of going to other distros that do not use systemd

Copping out is never the Linux users' way

Re:Systemd wins nothing

[Anonymous Coward]

I build debs at my day job, so "go with another distro" isn't a great option. I'll need to read at least the part about init.d scripts, if they've gone away, what they've been replaced with, at least. Not much different from what I had to do for Ubuntu's upstart, so I could understand what was happening when things would start.

Re:Systemd wins nothing

[Eunuchswear]

Of course you could just read the summary and realize that a Debian can be "a distro that doesn't use systemd".

Re:Systemd wins nothing

[ruir]

Read my post. You can pin systemd to -1. At the moment, I am largely based in Debian, I am just building 6 debs.

Re:Systemd wins nothing

[kthreadd]

Why would you pin systemd to -1 if you use it to build debs? What part of systemd prevents you from building debs?

Re:Systemd wins nothing

[ruir]

I just pin systemd to not be infected by random beta crap imposed by a misguided political decision, and if you care to read the previous comment, someone said it largely build most of the debs themselves, and they do not have the luxury to upgrade anymore. Do not try to read more into what others post, and peruse the thread when in doubt.

Re:Systemd wins nothing

[Anonymous Coward]

If only you could, you know, actually 'read the docs'. Unfortunately as with every other broken piece of lennartware, you'll find that easier said than done. You'll find documentation a largely not even started project, and that much of what exists is broken, outdated, confusing or and / or wrong. Because you see, Lennart doesn't do documentation. I guess it would impede his ability to spread bullshit and lies a bit too much.

Re: Systemd wins nothing

[buchanmilne]

Really?

I found the systemd documentation installed on my machines tgst have systemd to be very comprehensive.

But it seems the anti-systemd crowd don't know how to find or read man pages, so I'll provide a link to one they can read: here .

Systemd absorbs *gender equally effected by...

[Anonymous Coward]

chaotic forces of the universe, into Fair Scheduled Pottering-engineered equality init system. Libtards have one less thing to complain about.

Not just systemd

[Anonymous Coward]

It's a bit sad to see that the summary only speaks about systemd and merely links to the release notes for the rest. This is a great release with lots of improvements. GNOME 3.14, LibreOffice 3.4, GCC 4.9.2, Perl 5.20. I'm still trying to figure out what the -ctk9 will do with the kernel. There's also much improved UEFI support. So much more than just systemd happened in this release, something which a lot of users don't even have to interact with, it's a shame that's all that the summary talked about.

systemd != improvement

[Anonymous Coward]

Things are changing and most importantly, things are improving

Things in the Linux scene are changing, and yes, there are things that have had tremendous improvement, __despite__ the wrath of systemd

Dear Debian

[Anonymous Coward]

Why you start up so fast? Very nicely done!

Re:Dear Debian

[Anonymous Coward]

Why you start up so fast? Very nicely done!

So the twice a year I reboot is faster? That doesn't mean a damn thing to most Debian users. Ignoring stderr, nonzero exit statuses, and syslog messages is a much bigger deal. With those problems, systemd makes it nearly impossible to troubleshoot problems.

Re:Dear Debian

[Anonymous Coward]

So the twice a year I reboot is faster? That doesn't mean a damn thing to most Debian users. Ignoring stderr, nonzero exit statuses, and syslog messages is a much bigger deal. With those problems, systemd makes it nearly impossible to troubleshoot problems.

This has been debunked already: http://news.slashdot.org/comments.pl?sid=7312219&cid=49545633.

Never used RHEL7, and if they do in fact have a buggy version of systemd, well, that's their problem (and please take it up with them, because if you are using RHEL, you're probably also paying them), but Debian 8's version does not have this issue, so claiming it here in this thread about Debian is quite disingenuous. Repeat after me: systemd in Debian 8 does not throw away stdout/stderr from services. (Unless you explicitly tell it to, i.e. StandardOutput=null. The default value is syslog, btw.)

Regarding exit codes: systemd is actually vastly superior to the init script mess when it comes to exit codes:

1. It can also keep track of exits after the daemon was already initialized. And you can do neat things like Restart=on-failure to restart a service if it suddenly exits with a non-zero exit code, for example.

2. If you have the situation that service B requires service A and is ordered after it (b.service contains both Requires=a.service and After=a.service, if service A fails, systemd will NOT attempt to start service B afterwards, because it now knows that it won't work. If you boot with sysvinit + traditional init scripts, the exit code of the first init script is silently ignored and the second is always started, because the scripts that themselves call the init scripts at boot (or runlevel change in general) don't know about the dependencies between services.

Both things are nothing unique to systemd, there have been other solutions that can do the same (upstart being one of them, for example) - but it's really telling that the solution that a lot of people here yearn for, i.e. sysvinit + init scripts, can't do either of those.

And to go into a bit of depth in regard to the example discussed in the comment I linked, because apparently people can't really wrap their heads around it: systemd is not ignoring that exit code, not even the slightest. The only question here is: when does systemd consider the service to be started?

With traditional init scripts, since they were called synchronously, the only way to start a service was to have the service fork and close its original process. The boot could then proceed, and the service would be started in the background. But with systemd, the service doesn't have to fork itself in order to properly start, because it's always going to be started by PID1 directly. That simplifies tracking the service, but introduces another problem: when do we know when the service is finished starting? With forking services, this was straight-forward: the service forks, initializes and the original process exits only after initialization is complete, so a zero exit code from the daemon's original process indicates that is has been started properly (although a lot of services didn't actually do that properly, btw., they'd just fork, exit and then do initialization in the child, which means the child could die instantly but the init script would still think everything went smoothly). But if a service doesn't fork, then you need a different way of telling when initialization is complete. systemd provides various ways of doing so:

Type=simple: this is what was used in the example. Using this setting (the default), systemd will simply start the service and if the program could be started at all, it considers it to be successfully initialized. That means it won't wait for the program to exit or do anything here. And for this reason, in the example linked, systemctl start appears to think

Re:Dear Debian

[danomac]

For me startup is very quick with systemd, it's the shutdown that's slow. About three minutes to shutdown.

Re:Dear Debian

[gweihir]

THREE MINUTES? WTF? Does it have to send all your recorded keystrokes to the NSA first or what?

Re: Dear Debian

[Anonymous Coward]

systemd evangelists/zealots are so disgusting, much as Zdnet's Windows paid for ones.

Re:Dear Debian

[hitmark]

Likely he has a network mount going, and because systemd can't tell NFS from EXT it yanks down the network before unmounting, as networking is earlier in the dependency graph.

So it will sit there and wait for the network mount to time out before moving on.

I guess having a network mount service alongside a mount service get systemd panties in a twist. Or perhaps Poettering only use dropbox...

Re:Dear Debian

[gweihir]

Plausible. Also a strong indication of inexperience and incompetence on the side of the systemd team. Of course we already knew that. It is not like they could have looked at what was already there and find solutions that work, like mounting/umounting NFS at a different time....

Re:Dear Debian

[hitmark]

When the issue was raised to them enough for Poettering to take notice, their "solution" was a default timeout on every service for both bootup and shotdown.

This then blew up the following Fedora alpha, because they had a service that ran on first reboot after a system update that ended up taking long enough to tripped said timeout...

Their overall development methodology seem more at home with a website than a central OS component.

Re:Dear Debian

[gweihir]

Indeed. And if all the other places they screw up where not enough, this combination of incompetence and arrogance when working on _infrastructure_ would be quite enough to never allow their trash on any of my systems.

Re:Dear Debian

[Uncle Warthog]

For me startup is very quick with systemd, it's the shutdown that's slow. About three minutes to shutdown.

Mine is actually slower but not by a huge amount, somewhere between 5 and 10%, varying from one boot to the next. The shutdown is either quite a bit faster, enough so that I worry whether things are being shut down correctly, or a whole lot slower, with no rhyme or reason as to why or which one I'll get on any particular shutdown. Systemd's "improved" logging system is, of course, no use in figuring it out.

Re:Dear Debian

[ookaze]

Plausible. Also a strong indication of inexperience and incompetence on the side of the systemd team. Of course we already knew that. It is not like they could have looked at what was already there and find solutions that work, like mounting/umounting NFS at a different time....

Actually, it's a strong indication of inexperience and incompetence on the side of the "sysadmin" who experience this issue.
I have several servers and desktops with NFS mounts and systemd, and they all start and stop extremely fast.
Some desktops have the home mounted as NFS, and they shutdown in less than 2 seconds, which always amazes me.
Perhaps the difference is that all my NFS mounts are defined as systemd units, and they are all using the "on demand" feature of systemd, which equals automount. Automount was how I was handling my NFS mounts before systemd, so as not to break my systems in case of network issues, which would mean a reboot.

Is that proven?

[dbIII]

The systemd suite provides features such as faster boot times

I haven't seen any sign of that anywhere and I saw the opposite on a eeepc by about half a minute when I put a newer distro with systemd on it. Is there any proof or are the faster boot times just on the wish list?

Re:Is that proven?

[Carewolf]

The systemd suite provides features such as faster boot times

I haven't seen any sign of that anywhere and I saw the opposite on a eeepc by about half a minute when I put a newer distro with systemd on it. Is there any proof or are the faster boot times just on the wish list?

It has been significantly faster for me. Anyway the reason is that it can run multiple scripts at the same time which sysv couln't (though upstart did something similar).

Re:Is that proven?

[dbIII]

Considering how it blocks (with no output as to why) if a filesystem is not present is it REALLY doing enough in parallel or just enough to have race conditions in the binary logs?

Re:Is that proven?

[Barsteward]

blocks or goes through a time out process waiting for it to come online? Have you checked journalctl for the output, its a very comprehensive journalling system.

Re:Is that proven?

[Anonymous Coward]

Considering how I am too stupid to mark non-essential fstab entries nofail

FTFY

Re:Is that proven?

[gmack]

This is the correct behaviour. If a filesystem doesn't mount, it will hold off on anything that depends on the filesystem working. I can't imagine why you would want it any other way.

Re:Is that proven?

[dbIII]

Yes - the correct behavior as Lennart sees it is to halt and wait for the user to insert a rescue CD.
I don't see that as correct myself but he has a desktop perspective inspired by growing up after Win95 and not paying much attention to server environments.

Re: Is that proven?

[gmack]

it does not halt and wait for a rescue cd. It waits for the set timeout to expire(5 mins afik) but dont let facts get in the way of a good troll.

Re:Is that proven?

[DrXym]

The typical work flow for sysvinit is - open a script, launch bash / python / whatever, parse script, invoke daemon, daemon invokes itself again as detached process, script ends. All the scripts are run consecutively.

The typical work flow for systemd is open a unit file, launch the daemon directly as a detached process. Units can run in parallel according to their dependencies. No script required or 2-stage daemon launch.

So yes systemd can obviously improve boot times. However some debian discussion threads suggest they were just pointing systemd to launch the sysv scripts which seems a bit pointless really and won't do much to improve startup.

Re:Is that proven?

[Anonymous Coward]

You use an underpowered PC and don't see any improvements with a newer version that runs systemd. That's the same as saying that electric cars are useless because your electric golf car can't even reach the minimum speed to be allowed on the high way. Systemd is not developed to improve the performance of Eee PC's or other netbooks, they are meant to provide Linux with the modern features that are long overdue.

Re: Is that proven?

[RightwingNutjob]

Which is not the correct behavior for a headless server. The correct behavior is to start anyway and for any user processes that depend on access to the unavailable filesystem to exit with a -1 status and log whatever perror() spits out to standard error, at which point it is clear to the sysadmin what happened and without having the other stuff on the box held up. LP really must have grown up with Win95, because real Linux servers often do more than one thing at a time and hold more than one service at a time, and this behavior of systemd breaks that functionality on a logical level (that is it's not a bug, it's an error on the part of the designer).

Re:Is that proven?

[Anonymous Coward]

The systemd suite provides features such as faster boot times

I haven't seen any sign of that anywhere and I saw the opposite on a eeepc by about half a minute when I put a newer distro with systemd on it. Is there any proof or are the faster boot times just on the wish list?

It has been significantly faster for me. Anyway the reason is that it can run multiple scripts at the same time which sysv couln't (though upstart did something similar).

And you also likely boot from an SSD, right?

I can boot "soon to be ancient" Windoze 7 on an old Core2 Duo HP laptop in 2GB of RAM to the login GUI in less than 10 seconds from a SSD. Fast enough I would say for a bloated operating system like Windoze.

Re:Is that proven?

[gweihir]

This is one of the synthetic mantras systemd has been aggressively pushed with. It does not matter whether it is true or relevant, just that you believe it and join the cult.

Re: Is that proven?

[gmack]

And then slow devices cause the server to fail to start correctly every time? There is a reason that so many init.d startup scripts had sleep statements. It makes sense to argue that the timeout is too long but it make no sense that things shouldn't wait for things they depend on. That's the whole point of "dependency based booting", most of the systemd alternatives do the exact same thing.

Re: Is that proven?

[Peter H.S.]

Which is not the correct behavior for a headless server. The correct behavior is to start anyway and for any user processes that depend on access to the unavailable filesystem to exit with a -1 status and log whatever perror() spits out to standard error, at which point it is clear to the sysadmin what happened and without having the other stuff on the box held up.

Just bumbling along with boot even if critical disks are missing is just dumb. Allowing raid arrays to come online in degraded mode without any spares just because some disk were late in reporting in is stupid and dangerous.
The sysdamin can always mark non-critical disks with "nofail" if he knows the userspace software can handle missing them.

Re:Is that proven?

[hitmark]

Heads up, nofail is only about sending an error. Not evacuate the ship because a busboy is missing!

Systemd's handing of nofail is up there with its handling of debug, and likely with the same level of arrogance from the devs.

Re:Is that proven?

[hitmark]

Ah yes, SSD. Didn't Poettering recently yank the "spinning rust" optimizations from systemd because all the devs used SSDs?

This will the kernel devs decided to keep an old subsystem around because someone, somewhere, was still using it?

The difference in attitude between the kernel and userspace is staggering. I swear userspace devs are actively user hostile at times.

Re:Is that proven?

[thogard]

Lots of useful things can happen even if most file systems don't mount.

I have systems in data centers half way around the world. I want sshd to wake up as soon as the networking is up. Once the whole thing is up and stable, I want the initial sshd to be killed off and the normal production one started. The sshd started early uses no shared libraries and uses a config that lets root login. This means that if the machine is screwed up, I can get in if things are broken without depending on the lights out management card or some other virtual console hack.

Remember that on very large systems there are always errors on a disk and some systems are large enough that their mean time between failures is always now. That doesn't mean the systems aren't still useful in production.

Re:Is that proven?

[thegarbz]

Is there any proof or are the faster boot times just on the wish list?

I can't remember where but I distinctly remember reading that systemd does NOT provide the fastest boot times. Faster than sysvinit in many scenarios, but not faster than some other parallel startup setups.

But then really fast boot times was not at all the point. It was more of a side effect of being an event based init system rather than a linear list of scripts executed in order. In fact the speed of boot is not mentioned on the project page, and even Poettering's blog only mentions that it's faster than Upstart in Fedora 17 and only due to one specific reason.

Re: Is that proven?

[dbIII]

Is that any excuse for just hanging indefinitly (5 minutes my arse - saw one hang overnight) without any output to anywhere to tell you what is going on?

Re: Is that proven?

[Peter H.S.]

Is that any excuse for just hanging indefinitly (5 minutes my arse - saw one hang overnight) without any output to anywhere to tell you what is going on?

Well, SysVinit systems aren't magic either, if there is a kernel-GPU bug or similar low level error, systems may hang forever without any useful output, and without rootfs there isn't any logging done.

But did you try VT9 etc.? Was crash shell enabled? I find that systemd with initramfs like Dracut is a breeze to debug when it comes to boot problems; stuff like "rd.break=pre-mount" is great if there are serious rootfs problems, or appending "1" or "emergency" to the kernel cmd-line. This is a good start page about debugging systemd machines:
http://freedesktop.org/wiki/So...

Playing around with a systemd-nspawn OS container is also a good way of simulating various boot errors and how to recover from them.

All in all, systemd is a great improvement when it comes to boot problems, not at least because there can be full logging from initramfs already.

Re:Is that proven?

[Carewolf]

The systemd suite provides features such as faster boot times

I haven't seen any sign of that anywhere and I saw the opposite on a eeepc by about half a minute when I put a newer distro with systemd on it. Is there any proof or are the faster boot times just on the wish list?

It has been significantly faster for me. Anyway the reason is that it can run multiple scripts at the same time which sysv couln't (though upstart did something similar).

And you also likely boot from an SSD, right?

I can boot "soon to be ancient" Windoze 7 on an old Core2 Duo HP laptop in 2GB of RAM to the login GUI in less than 10 seconds from a SSD. Fast enough I would say for a bloated operating system like Windoze.

No, I was mostly refering to my old laptop which has an old spinning disk, and boot time went from a minute to under a half. On my workstation with an SSD, it went from 10 seconds, to well, i guess 2 or 3, practically instantanious.

Re: Is that proven?

[dbIII]

IMHO it's nowhere near ready yet but other opinions can vary.
I think like Pulseaudio and NetworkManager before it the software has been rushed out in an alpha state and that's a systemic problem with RedHat and gnome which has spread to other distros (via gnome).

The problem above was on a developers machine where he had a typo in the hostname of an NFS mount so the entire thing locked up on boot and needed to be started up from a rescue CD. That's a newbie level fuckup and not something a person writing an init system should have problems with by the time they tell people their software is ready for release.

I've seen another where a system just would not start because the network card had been replaced - what a piece of crap. It's for laptops and not for hardware that may change.

Re:Is that proven?

[ookaze]

Ah yes, SSD. Didn't Poettering recently yank the "spinning rust" optimizations from systemd because all the devs used SSDs?

This will the kernel devs decided to keep an old subsystem around because someone, somewhere, was still using it?

The difference in attitude between the kernel and userspace is staggering. I swear userspace devs are actively user hostile at times.

There's no difference between kernel and systemd for old subsystems, you're just plain wrong with understanding problems or ignorant on purpose.
What was yanked is the readahead part, and it is because there was no maintainer for it. The devs didn't have SSD so they couldn't maintain it.
It's pretty basic stuff that are very easy to understand, the same happens in the Linux kernel.
Now, when I read your conclusion from these facts, I'm sure I won't ever ask you any advice or logical thinking.

Re:Is that proven?

[ookaze]

Is there any proof or are the faster boot times just on the wish list?

I can't remember where but I distinctly remember reading that systemd does NOT provide the fastest boot times. Faster than sysvinit in many scenarios, but not faster than some other parallel startup setups.

But then really fast boot times was not at all the point. It was more of a side effect of being an event based init system rather than a linear list of scripts executed in order. In fact the speed of boot is not mentioned on the project page, and even Poettering's blog only mentions that it's faster than Upstart in Fedora 17 and only due to one specific reason.

systemd actually DOES provide faster boot times, but that's in a native systemd environment, not in a kludge one where systemd has to launch shell scripts.
Actually, systemd is so fast that it showed lots of race conditions in many projects startup, like gdm or mysql.
It's true that fast boot times was only one point at the start of the systemd project, it never was its ultimate goal.

Re:Is that proven?

[thegarbz]

systemd actually DOES provide faster boot times

Quantify that. Faster than what? Faster than Upstart? If so why?

Systemd is not the only parallel booting system out there. Though given it's excellent tools for analysing the boot process I have no doubt that systemd could be fine tuned to be fastest. But out of the box there's nothing intrinsically magic about it.

Re: Is that proven?

[gmack]

I've had that problem with systemd, you wait 5 mins until it comes up or you can boot with init=/bin/bash and make whatever changes you need to.

No need whatsoever for a rescue CD.

Re:Is that proven?

[hitmark]

Kernel devs have in the past and will in the future (at least as long as Torvalds is in charge, and i fear the day he retires) keep sub-systems and such in the code if they know there are users of it out there.

Damn it, even though everyone says that you should use the ip command for anything network related, ifconfig still works. This because the interfaces between the program and the kernel is still there, after having been labeled "depreciated" for a decade or more.

A basic operating rule for Linux kernel developers is "do not break user space!".

Debian 8 so far, so good

[ruir]

People be aware of some caveats upgrading. Been testing it in the last year, and using it since news year eve in less critical systems in production. systemd has to be pinned to -1 or your servers will get upgraded to it without any interaction from your part. Beware also that Apache configurations change. Some configurations might get broken. libjpeg8 was missing and docker.io still is; backports may solve this. Apache configurations changed a lot. Be also aware that things get installed by default, for instance I had to delete rpcbind from most of my servers. Be also aware open vmtools gets a little confused after the upgrade and needs to be upgraded explicitly.

Re:Debian 8 so far, so good

[kthreadd]

systemd has to be pinned to -1 or your servers will get upgraded to it without any interaction from your part.

Of course it gets installed, it's the default init system in Jessie. Most users would expect to have it installed when upgrading, considering that it's a major new feature in Jessie and meant as a replacement for sysvinit.

Beware also that Apache configurations change.

Apache went from 2.2 to 2.4, which in Apache speak is pretty much a major version change. There were lots of changes in 2.4, especially making the event-based mpm the default. But there's also a lot of other changes so expect that you have to go through and possibly change a lot of configuration. I also have a number of custom Apache modules that had to be partly rewritten. But once that was done things have been running just fine.

Re:Debian 8 so far, so good

[ruir]

First time I tested it, 1.5 years ago, systemd was not a welcome upgrade. And besides, it may very well be the default init system, however installing it in a production servers when there are no dependencies (no Gnome for instance) is just breaking things for the sake of breaking them. This is the first time, it would be thoughtful to be a transition time. Ha, and this also breaks modsecurity, I forgot.

Re:Debian 8 so far, so good

[Anonymous Coward]

> Some configurations might get broken.

Absolutely true. My team has been suffering with upgrading about 18,000 servers from standard init scripts to this systemd garbage. systemd ignores stderr, syslog messages, and exit statuses. systemd bugs have made our life hell. My wife filed for a divorce this week since I haven't been home before midnight since last year. systemd is a half-baked piece of garbage. It should have never been forced down our throats since it isn't finished yet.

Re:Debian 8 so far, so good

[Anonymous Coward]

Care to elaborate? It certainly doesn't ignore standard error, syslog or exit statuses. Only time I've seen that had been with badly written init-scripts that did stupid things like redirecting stderr to /dev/null.

Re:Debian 8 so far, so good

[ruir]

Have you not the sense of the dark humour? he is a troll.

Re:Debian 8 so far, so good

[ruir]

I think you are a troll, but I will take the bait. Just pin the systemd to -1 and it will buy you 2 years before 9 to go the freebsd route.

Re:Debian 8 so far, so good

[Ben Hutchings]

Debian 8 has libjpeg-turbo, replacing libjpeg8 and matching most other distributions.

Re:Debian 8 so far, so good

[ruir]

The problem is the name change without updating other packages or creating a meta package. Thanks for the heads up, i will create a meta package manually.

Re:Debian 8 so far, so good

[Barsteward]

you were trolling nicely until you said you had a wife. trolls don't have wives.

Re:Debian 8 so far, so good

[Anonymous Coward]

> It certainly doesn't ignore standard error, syslog or exit statuses.

It most certainly does. I've seen it on more than a hundred servers running Red Hat 7. It ignores all three of those things. We had to add external checks of services rather than using the exit status of systemd, because system ignores nonzero exist statuses. It returns zero even when the service returns a nonzero value. I've seen several people here post reproduction steps then they were attacked by the fanbois.

Re: Debian 8 so far, so good

[Anonymous Coward]

Are you that guy that keeps saying that systemd can't track mongodb? It has been demonstrated time after time that IT'S A BUG IN THE MONGO INIT SCRIPT.

Re:Debian 8 so far, so good

[gweihir]

Ah, rpcbind, that old backdoor. The picture becomes clearer.

Re:Debian 8 so far, so good

[MoonSweep]

Thanks for this useful information (where are my mod points when I need them ?)

Also, be careful of this bug: the "Standard system utilities" task now pulls 41 GTK-related packages because of a new dependency on pinentry-gtk2 from gnupg2. After a server installation, if you selected the "Standard system utilities" task, be sure to "apt-get remove --purge pinentry-gtk2" (which will install pinentry-curses to satisfy dependencies) and then "apt-get --purge autoremove" to get rid of all those useless packages. Or (didn't test it yet but it should work), install without the Standard task, prevent pinentry-gtk2 from being installed by pinning it to priority -1 in a preferences file (man apt_preferences), and then run "tasksel --new-install" to select the Standard task.

Debian Systemd SJWs

[Anonymous Coward]

"...but only 394 votes ultimately decided Pluto's fate: 237 in favor of demoting the planet and 157 against."

1 vote decided for the systemd takeover in debian.
There was a split 4-4 vote in the debian technical comittie.
Which was then tie-broken by the chair who just happened to be a rabid force-it-down-your-throght supporter.

Then there was a GR with 1 pro-systemd option and 3 or 4 anti-systemd options, so all the anti-systemd votes got split and diluted (together they would have defeated the systemders 60 to 40)

Fuck these people. SJW pieces of shit.
(Same type people banned marrying young girls everywhere, also look at planet.debian.org during the systemd debate: transgender this, women that, bla bla bla. fucking pieces of shit ruin everything good)

---

The "bug" (RFP) has been tagged as "won't fix"
If you aren't a progressive, the debian people
do not want your software, they state this here
in more concise words:
https://bugs.debian.org/cgi-bi...

Opensource isn't about code anymore, it's
about community and beliving and professing
the correct thing. If you do not believe
the correct thing you are removed (example: Ted Walther)
or your software is attacked and removed from its
host (As gpcslots2 was in the past by feminists:
  http://esr.ibiblio.org/?p=1310 )

How do you feel about this change?

Re:Debian Systemd SJWs

[Anonymous Coward]

http://whatwillweuse.com/fodder/terrorware/ -Beth Lynn Eicher

Boycott Jessie

Re:Debian Systemd SJWs

[Eunuchswear]

1 vote decided for the systemd takeover in debian.
There was a split 4-4 vote in the debian technical comittie.
Which was then tie-broken by the chair who just happened to be a rabid force-it-down-your-throght supporter.

No, that's not what happened. The vote was: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729

          4x D U O V F (bdale, russ, keith, don)
                    F U D O V (steve)
                    U D O F V (colin)
                    F V O U D (ian)
                    U F D O V (andi)

So 4 people wanted systemd, or upstart, or openrc, or even sysvinit but lets stop the boring wrangling,
3 people wanted upstart, or systemd, or openrc, or sysvinit
and one wanted sysvinit, or basicly anything but systemd.

There was no 4-4 split.

As for your insane frothing about SJW's, fuck off you paedophile moron.

Re:Debian Systemd SJWs

[ruir]

Fuck the voting/democracy shit. It is outrageous that without previous planning/package pinning all the systems get automatically upgraded to systemd without further asking. A true democracy would be to ask when installing "do you go with systemd or the alternative" and the sending the stats back to debian.

Re:Debian Systemd SJWs

[Anonymous Coward]

"As for your insane frothing about SJW's, fuck off you paedophile moron."

Deuteronomy 22 28-29, hebrew.

Re:Debian Systemd SJWs

[Anonymous Coward]

Nope, it was a 4 - 4 split tie-broken by the pro-systemd chairman.

Try again faggot shill.

Re:Debian Systemd SJWs

[Barsteward]

"Deuteronomy 22 28-29, hebrew."

"As for your insane frothing about SJW's, fuck off you paedophile christian moron." - does that work better for you?

Re:Debian Systemd SJWs

[Anonymous Coward]

I read all that stuff in the links. Some of it goes way back and pretty much forgotten, except for the casino game which appears to be banned because of the reputation of the author MikeeUSA, who is admittedly a feminist hater + misogynist. So I get where he is coming from.
I'm a bit of a misogynist myself. I consider a great majority of women as 'peculiar', twisted, crazy, psychotic and have their own agendas which reflects their particular form of insanity and unreasonableness. Blame it on their hormones or upbringing or whatever. I just don't care anymore.
There is a women against feminism group I heard of recently. Don't know much about them.
The fact that PC has been forced upon us by women is something we have to live with. Change will occur in time though.
I don't give much hope for MikeeUSA though as he has been identified as a troll and hate-mongerer in the Debian community. Maybe he should be looking for another hobby?

Re:Debian Systemd SJWs

[Eunuchswear]

You don't know how to read, I even posted the link.

Everyone except Ian Jackson wanted systemd or upstart rather than sysvinit.

Four people prefered systemd to upstart, four prefered upstart to systemd.

Since the chairman was one of the four who prefered systemd then systemd it was.

Re:Debian Systemd SJWs

[Eunuchswear]

Fuck these people. SJW pieces of shit.
(Same type people banned marrying young girls everywhere, also look at planet.debian.org during the systemd debate: transgender this, women that, bla bla bla. fucking pieces of shit ruin everything good)

Since many places let you marry girls as young as 15 years old (E.G. Mexico) just how young do you like them?

As long as you're into post-puberty you could try Yemen. Watch out for the drones.

Re:Debian Systemd SJWs

[Eunuchswear]

I consider a great majority of women as 'peculiar', twisted, crazy, psychotic and have their own agendas which reflects their particular form of insanity and unreasonableness. Blame it on their hormones or upbringing or whatever. I just don't care anymore.
There is a women against feminism group I heard

But are they more or less reasonable than wierd kiddy-fiddlers who claim that SJW's and "transgenders" are the only thing stopping them marrying "young girls".

Re:Debian Systemd SJWs

[Anonymous Coward]

Debian is not, and has never been about democracy.

It is about getting shit done. You do the work, you get to do the calls. Unless it is something so outrageous that the TC or a GR is needed. And we heavily frown upon GRs overriding techinical matters. I am a sysvinit maintainer in Debian. I don't trust Pottering, and I don't like a lot of the crap behind systemd. But I would appreciate even less to have idiots that never put one hour of work on ANY initsystem "voting" over it.

If they had put work on sysvinit, systemd would not exist in the first place. It is not like sysvinit in Debian hasn't been booting in paralell for years.

Re: Debian Systemd SJWs

[Anonymous Coward]

Then you should already know. Pretty much nothing systemd does is wanted by the sysvinit lovers. System V init had the appearance of needing no work.

Re: Debian Systemd SJWs

[Fwipp]

Those darn SJWs won't even let me marry an eleven year old girl anymore!

Re:Debian Systemd SJWs

[Anonymous Coward]

Hmm, boy, did that came out wrong. To be clear, the "idiots" are those who make a major issue out of systemd _and_ do so in a way to make the work/distro environment bad for everyone... without ever having done any *real*, *productive* work whatsoever to make the init system world a better place.

Users really can't really do much more than give us informed opinions on their use cases and complain when something is not working well. They don't deserve being called "idiots" just because they are not programmers, so the rant was not supposed to target them. We had thousands of bugs reported during sysvinit days. We will have lots in the systemd days as well. Nothing new, there. It is not like sysvinit was anywhere close to perfect, and systemd does get some stuff right a lot better than sysvinit.

Pottering at least works like crazy and has a vision (which I do _not_ share, but I can deal with it). Most trolls are not worth the resources they take up from the environment.

Re: Debian Systemd SJWs

[Anonymous Coward]

"System V init had the appearance of needing no work.".

Not to any of us who actually worked in it. It is just that people will not help until forced by their own interests and by that time, it is often too late.

Re:Debian Systemd SJWs

[gweihir]

I detect a troll from the pro-systemd propaganda force. The "young girls" thing is just a way too obvious attack point. As usual, many morons will fall for it though.

Re:Debian Systemd SJWs

[Anonymous Coward]

Was there during the whole debate, read every message as it was posting. I know what happened. You are a deceiving shill.

4-4 for/against systemd which then had to be tiebroken.
Guess why it had to be tiebroken.

Because there was a tie.

Re:Debian Systemd SJWs

[Anonymous Coward]

At 15 you get maybe one year untill they have thick ass thighs and are nolonger cute.
If you're an ass man that's fine.
Many white males are not ass men.

Re:Debian Systemd SJWs

[Anonymous Coward]

How is someone who programs and makes media for opensource projects a troll where people who do not do that but support feminism are contributors?

Re:Debian Systemd SJWs

[Anonymous Coward]

Deuteronomy 22 28-29, hebrew.

Men are entitled to young girls as brides. The penalty for rape of a girl child is to keep her and pay her father money.

The Bible is "weird" and "wrong"
SJWs and "transgenders" are normal and right.

What the Old Testament says to do should be done. Hans Reiser did the correct thing. It is the one and only way to get rid of feminism.

Re:Debian Systemd SJWs

[Anonymous Coward]

in just about all of your posts you attack people with ad hominems and generally come off as a complete dick. please correct this behavior.

thank you,
everyone else

Re:Debian Systemd SJWs

[Anonymous Coward]

>Pottering at least works like crazy and has a vision (which I do _not_ share, but I can deal with it). Most trolls are not worth the resources they take up from the environment.

So did hitler. Both were german fucks.

Re:Debian Systemd SJWs

[Anonymous Coward]

>Trolls >Not worth anything

Fork of Xonotic.
Before then Fork of Crossfire RPG,
Before then various console scripts and videogames for linux.

Also lots of music and media released opensource.

Re:Debian Systemd SJWs

[Anonymous Coward]

seriously, cut out the ad hominem crap. it has no place here and taints any valid arguments you are trying to make.

Re:Debian Systemd SJWs

[Anonymous Coward]

Yea man, girls are ick. Lets fuck men and old women!

Girls aren't ever cute, nice and pretty. Men and old women are where it's at!

All the old religions are wrong.

Re:Debian Systemd SJWs

[Anonymous Coward]

Yeah, fuck you too, you intolerant, bigoted imbecile.

Re:Debian Systemd SJWs

[Eunuchswear]

It's not the 1980's, we don't tolerate paedophiles any more.

Re:Debian Systemd SJWs

[Eunuchswear]

So you would have prefered upstart?

(By the way "Was there during the whole debate, read every message as it was posting" sounds so informed. Not quite so sexy considering I posted the link to the whole "debate").

Re:Debian Systemd SJWs

[Eunuchswear]

Pointing out that a self confessed paedophile, who claims that Debian gone to hell "since it has was taken over by SJW's" who want to restrict his access to under-aged girls is "ad hominem"?

Re:Debian Systemd SJWs

[drinkypoo]

All the old religions are wrong.

Religions are for control, and part of that is letting the people in control do whatever they want. Part of being a moral adult is not doing whatever you want, but doing the part of what you want that won't harm others. Most so-called adults ain't, they're just old people.

Re:Debian Systemd SJWs

[Anonymous Coward]

I'm guessing he's a king and a billionaire too.

Because wanting something makes you have it.

Re:Debian Systemd SJWs

[Anonymous Coward]

"part of being a moral adult is doing whatever is advantageous to women"

A feminist was just killed in pakistan :)
Marry little girls. Kill feminists.

Re:Debian Systemd SJWs

[Anonymous Coward]

Fuck the voting/democracy shit. It is outrageous that without previous planning/package pinning all the systems get automatically upgraded to systemd without further asking. A true democracy would be to ask when installing "do you go with systemd or the alternative" and the sending the stats back to debian.

Nonsense.

The citizens who get to vote are the people who do all the work of maintaining and developing the OS. The freeloading users (like me, BTW, it's been many years since I contributed to Debian; "freeloading" is an accurate description, not an epithet) don't get a vote and shouldn't get a vote. If you're not paying and not contributing then while open source projects are happy to help you because it makes them feel good to have users, you don't get much of a say where significant work is involved.

Well, actually, that's not entirely true. You do have two other ways of pushing your agenda.

One, you can get involved. Or, if you're not a developer, you can pay someone else to get involved on your behalf. It's not that hard to become a Debian developer, and if you were to stand up and offer to maintain sysvinit and all of the other components systemd replaces, keeping everything working so it's a seamless install-time (or later) choice, and you could convince them that (a) you really mean it and (b) you're really capable of doing it, they'd have been happy to offer that alternative.

Remember that Debian is a distribution that prides itself on offering a huge variety of options, including 10 architectures and an alternative kernel. I see no reason this would have been different if someone were willing to do the work.

Two, if getting involved sounds like too much work and you prefer to continue freeloading, then you can and should vote with your feet, moving to a distribution that works the way you prefer. If enough people do that, Debian may decide that it made a mistake (open source projects do care about their freeloaders, just not as much as they care about their citizens).

Re:Debian Systemd SJWs

[thegarbz]

What makes you think that any open source project is democratic?

Re:Debian Systemd SJWs

[gweihir]

Part of being a moral adult is not doing whatever you want, but doing the part of what you want that won't harm others. Most so-called adults ain't, they're just old people.

Very much this. Quite a few of these old people have the self-restraint of children and ethics worse than many children. This is why greed and fear rules the world and nearly destroyed it a couple of times.

Re:Debian Systemd SJWs

[Anonymous Coward]

>It's not the 1980's, we don't tolerate paedophiles any more.
Proof that pedophiles have to do what works: take a page from
the moslem pedophiles who marry little girls: kill your opponents.
Take a page from the old testament pedophiles: kill your opponents.
Take a page from the vedic pedophiles: kill your opponents.

They do not tolerate you except as dead or imprisoned.
Obey your God and kill them.

Man is master, and he may have his girls, but it is clear: only if he
kills those opposed.

Re:Debian Systemd SJWs

[byuu]

Yeah, that had to be the most obvious false flag post I've seen in years. It's like they're not even trying.

Re:Debian Systemd SJWs

[juanfgs]

The main difference is that the guys who forked Xonotic, MATE and other projects expressed their dissatisfaction via code, not an edgy smear campaign with a "haXXor" like page citing FUD about things they didn't actually understand.

Re:Debian Systemd SJWs

[Anonymous Coward]

The 'fuck young girls, quote deuteronomy, kill all feminists etc.' AC poster posts frequently and obsessively on every /. thread I see (regardless of systemd relevance). They are quite disturbing really, I think they are actually a pedophile, but I obviously can't tell if they act on their impulses, or are too afraid so they just talk about it constantly. Anyhow, it would probably be a good idea for the police to investigate them given their clearly expressed desires to rape young girls and kill women. They should remember when they post that /. has their IP address, which the police can obtain with a court order.
I'm not even in the US so I don't really have any standing but any good LEOs in the US reading this should consider carefully if they can do anything. The AC in question has posted this sort of thing 100's of times, their posts should be easily found.

Re:Debian Systemd SJWs

[gweihir]

Indeed. However, the response justifies their not investing much effort.

Re:Debian Systemd SJWs

[Anonymous Coward]

Yes, those advocating old testament biblical values should be caught, prosecuted, paupered, and then imprisoned, raped by homosexuals, and then killed (by aids in the anglo states, by bullet in the eastern states).

As is tradition in every leftist state (soviet or anglo).

Every dead SJW is a gift from the God of the old testament.
Thank you God for the killing of that feminist woman in pakistan yesterday.

Thank you very much.

Re:Debian Systemd SJWs

[Anonymous Coward]

Agreed. It looks like an attempt to get SJWs (who are, whatever else one may say about them, a powerful social and media force) in on one side of the debate.

Re:Debian Systemd SJWs

[Anonymous Coward]

They seem to me less like a pedophile and more like someone's conception of what a pedophile should be. If they do get traced from their Slashdot posts, I'd put maybe 2:1 odds in favour of them being a false-flag.

Has anyone done dist-upgrade yet?

[Keruo]

Anything special to note here or is it safe to just run dist-upgrade from 7 and try if it boots?

Re:Has anyone done dist-upgrade yet?

[ruir]

filter the threshold to 2 points and read my thread above.

Re:Has anyone done dist-upgrade yet?

[Ben Hutchings]

Please read the release notes, there are various things that may need manual attention before you upgrade.

Re:Has anyone done dist-upgrade yet?

[Keruo]

Skimmed the notes and ran upgrade.
After rebooting was greeted with nice grub rescue> file not found and grub_divmod64 symbol errors when trying to insmod normal.

Some searching around ended up telling me the installer only runs grub-install on disk 1 of the RAID1 config, so off to bios to change boot order of the HDDs and reboot got be back up and running.

Re:Has anyone done dist-upgrade yet?

[Ben Hutchings]

Sorry about that. Once you've recovered, consider running 'reportbug release-notes' to request an additional note about this gotcha. (I assume that there is already a bug report against grub).

Re:Has anyone done dist-upgrade yet?

[Anonymous Coward]

Make sure all of your filesystems that are in fstab and are used by some software (e.g. I had bind mounted directory on filesystem that required manual mounting to /var/lib/docker/). Otherwise it will just die after trying to mount it for 1.5 minutes for no other message than saying it couldn't mount the filesystem. You will need to enable some debugging on kernel cmdline (I took quiet away and added systemd.log_level=debug, I didn't bother to check if only one would suffice) to get it to tell which service required that mount point (after it fails to mount, so you will need to wait at least that 1.5 minutes).

Ya big Jessie

[Chrisq]

get with it, run a manly operating system ya big Jessie.

Systemd can be removed completely from Debian 8

[Anonymous Coward]

https://wiki.debian.org/systemd#Installing_without_systemd

Re:Systemd can be removed completely from Debian 8

[jeepies]

Jessie installs systemd by default on new installs. Should one desire to install without systemd, i.e use sysvinit-core instead (old sysV5 init), it is possible to use preseed to replace systemd with sysvinit at the end of the install (This probably won't work if selecting one of the desktop environments that require systemd specific features however).

It's good information, but the last line from the link is the real problem.

Different opinions

[Anonymous Coward]

Let's see here. First I heard "systemd" was coming. I had no idea what it was. Then, running Mint 17.1, I found out what it was, switched to Ubuntu 15.04 to find out. I had heard horror stories how bad it was but I thought the people complaining must be some "old lazy system admins" how learned something new 20 years ago.

Ok, so here I am in Ubuntu 15.04. I see the shutdown/reboot process is fast. Why? Because the shutdown part of the reboot is fast, not the actual startup (compared to Ubuntu 14.10). I find out probable reason why it is that way. Normally processes are first sent the SIGTERM signal to make them quit in a controlled way. But that needs some waiting.

Now I see the new behavior is to just reboot/shutdown without waiting. Any unfinished editing is lost, connections are torn down forcefully. Why? Because this is the way it should be: http://lists.freedesktop.org/archives/systemd-devel/2014-October/024452.html

Then I read more about this attitude from Wikipedia: "For instance, Poettering has advocated speeding up Linux development at the expense of breaking compatibility with POSIX and other Unix-like operating systems such as the BSDs.[12][13]".

I'm not anymore so sure about this. Personally, I will switch back to Mint until the regressions are fixed. What is the current progress and why do we have this type of "cowboy coding" process in place for standards and/or "de facto" functionality/dependencies? Why are there so many in Slashdot creating comments such as "Do you really think that systemd will kill your wife and eat your dog"?

Re:Different opinions

[Anne Thwacks]

Why are there so many in Slashdot creating comments such as "Do you really think that systemd will kill your wife and eat your dog"?

Is it not obvious? Some people (mostly systemd supporters) are jealous of other (more normal, except perhaps here) users who are married with dogs. (I cannot comment on users who are married to dogs, but for them there is goatse.d).

Re:Different opinions

[Anonymous Coward]

Agreed. I made the mistake of updating. I didn't realize what was happening until I read your post. I shutdown often (laptop with dead battery, hibernate doesn't work) and Firefox keeps coming up with "closed unexpectedly" on restart. I had assumed it was another Firefox bug, but looking closer, yes, nothing it closing cleanly when I shutdown. So now instead of letting the shutdown process close everything I have open (something every other OS does?), I'll have to manually close everything and that will take considerable more effort on my part. And what about all the little toolbar widgets and headless programs/services? I assume they're being killed as well. Is there any way to shut them down cleanly like before? It sounds like I need a script to send SIGTERM to everything.

It's not too late for me to downgrade (I did a fresh install). I probably will. This OS is broken by design.

Re:Different opinions

[thegarbz]

Any unfinished editing is lost, connections are torn down forcefully.

I don't cry about this. Too many programs out there assume that the only scenario for them is a perfectly and ordered shutdown, and then if something happens such as lockups, system crashes, or power outages there is suddenly as massive amount of data lost or corrupted. Maybe this will force some people to actually write their software in a more tolerant way.

Re:Different opinions

[Joey Vegetables]

The only ways to prevent data corruption upon improper shutdown come at a massive cost in performance. Essentially, a filesystem wishing to pose such a guarantee must block until it can confirm that data is physically written to the device - NOT just cached in that device's RAM. I think you will find that this is many orders of magnitude slower than normal writes, and still dependent on proper behavior of the hardware. Having said that, most filesystems have options that will enable that tradeoff for you, in cases where it is sufficiently important. Or you can use a production-quality relational database, which, in most cases, can be configured in such a way that the loss of a single filesystem will not cause irreparable damage beyond the last few seconds of data entry.

Re:Different opinions

[olau]

Are you sure you've got this right? This is not what I see on Debian.

Note that Ubuntu has until recently been stuck on Upstart.

systemd

[rl117]

After using and developing Debian for 18 years, this is the first release I have no plans to use, all thanks to the gnome and systemd idiocy. It hasn't been a nice experience, seeing a system build up with loving care by so many people over so long being willfully trashed by a small handful of people. I for one have no interest in being RedHat's bitch; if I wanted to be, I'd be a suffering Fedora or CentOS user. Debian has lost its independence and freedom.

I've been using FreeBSD for nearly 18 months now, and rarely boot up Debian on my systems or VMs. Going back 5 years, I'd never have imagined this is the way things would play out. Tragic.

Re:systemd

[ruir]

Well said sir, well said. I would be interested in knowing a little more about your FreeBSD experienced. If you have linked.in, click in my homepage and join me in linked.in. Regards

Re:systemd

[Ben Hutchings]

Debian had a GR to decide this issue, so please don't spread conspiracy theories about "a small handful of people". Good luck with FreeBSD.

Re:systemd

[Anonymous Coward]

You're right to avoid the upgrade because of systemd. Linus was correct that they ignore bug reports even for serious bugs. I've seen several here that reproduce serious bugs, but the posters are attacked by the systemd guys. They have no desire to fix problems with systemd.

Re:systemd

[rl117]

"Spreading conspiracy theories." Please. I may be many things, but a conspiracy nut is not one of them; there is really no need to make such silly insinuations, it's not like the prior debate was any better. The number of people who pushed for this over the last few years was very small, in comparison to the total developer base, and the GR was irrelevant to that--that was only at the end stage of the process. I'd personally long since withdrawn from the "debate" at that point, because it was so nasty and unpleasant and I had better things to do with my time than be abused by my fellow developers. A win for rude, pushy and obnoxious people who shouted loudest and longest and ignored everyone else...

While I am missing Debian as a project to participate in after spending so long working on it, I am most certainly not missing participation on the lists due to the unnecessary amount of unprofessional vitriol and bile. I'll be looking for somewhere a bit more pleasant for my next project.

Re:systemd

[rl117]

Sorry, I don't use linked.in; feel free to mail me if you like though!

A short summary would be running a general-purpose NAS system with FreeBSD 10.1 at home with ZFS, NFS4 serving homedirs and other storage and a bunch of jails running PostgreSQL, build environments, kfreebsd, etc. And my main desktop dual boots FreeBSD 10.1 and PC-BSD, both of which work just fine. The only minor niggle is the GPU fan speed which needs tweaking due to running at full speed, but I run kde4, i3, fluxbox without any trouble.

At work, we have a FreeBSD 10.1 jenkins build node to test our code against clang++ 3.4/3.5, and I currently run a set of VirtualBox VMs for local building and testing. I may possibly switch over to it for desktop use as well if it serves work needs (currently using Ubuntu)

Re:systemd

[ruir]

pin systemd -1 to servers, it wil buy some time to migrate to something else.

Re:systemd

[ruir]

I see. I am running Debian at work under vmware, around 200 VMs and growing. Also investing in devop tools like ansible and docker.

Re:systemd

[Ben Hutchings]

A win for rude, pushy and obnoxious people who shouted loudest and longest and ignored everyone else...

Well that's what I see from the systemd detractors, not its proponents. They're still shouting loudly, in the comments on every article even tangentially related to it. Of course they are being ignored by systemd proponents and most neutral parties because they mostly repeat the same myths and slurs.

Re:systemd

[gweihir]

The problem is that due to all the "useful idiots" (that is a technical term, btw) the systemd PsyOps campaign managed to acquire (impressive success for them, I admit, as this was supposed to be a target group with actual domain knowledge) they get away with any and all bad coding as long as it does not prevent booting outright in too many cases. Just look at how cults and religions work: Most of their followers ignore lies and obvious defects with all their might.

Re:systemd

[Anonymous Coward]

Fortunately, I live entirely on the command line, mixed with tmux (because dvim doesn't seem to stable and crashes a lot), so the whole window manager garbage goes right past me, concern-free. :D

Re:systemd

[Anonymous Coward]

Don't let the door hit you on your ass.

Later!

Re:systemd

[nadaou]

if the fucking thing wasn't being rammed down our throats there wouldn't be an issue. but it is, so people are up in arms about having something they do not want being rammed down their throats.

personally the saddest part of this for me is to witness the political maneuvering which brought this to be invade beautiful debian. it is toxic to the goodwill of the community, which has always been debian's most valuable asset.

Re:systemd

[jcdr]

I also found Gnome 3 a bad choice for my use, but Debian Jessie is the first release to propose a lot of alternative directly from the installer, so regarding this subject I found it a improvement compared to the previous release. I personally will select MATE instead of Gnome 3.

The systemd transition is an other subject. I personally found it preferable to the stack of scripts on top of system V init. Ok it require to learn something new, but the basic is very simple and most of the stuff need just a bit of practice. I don't think that the alternatives of systemd will be in position to stay competitive for long, as the architectural change bring a too much advantages to maintainers that do the real work.

Re:systemd

[msobkow]

Yes, because doing something along the lines of "apt-get install kde-full" is such an onerous task that I couldn't even think of using an OS that would force me to do that. :P

Re:systemd

[rl117]

That's an irrelevant, flippant answer. This has *absolutely* *nothing* to do with how easy it is to install KDE.

Too much noise over SystemD

[dell623]

Seriously. There are a small number of people whose opinion is worth listening to even when it disagrees with the groups managing almost every single major distribution of Linux. Granted, some of them will be on slashdot. But definitely not anywhere near the number that pop in to these threads and whine. I use Linux to get things done. I have also used FreeBSD quite extensively, but there are a number of applications that don't quite support FreeBSD, and there is no equivalent of Red Hat. I plan to deploy Ceph soon for example for a storage cluster, and I want to be solving issues related to making Ceph work effectively, not spend time getting it up and running, compiling things myself. So I'll go with a *nix distribution that Ceph is most extensively tested against (RedHat or Ubuntu when I last checked).

If you want to build Debian without systemd and deal with all the niggly annoying issues that will come out of that and get progressively worse, go for it. Just don't pretend it's a viable option for anyone trying to get shit done, trying to keep systems running, trying to get systems up and going in short time. Sure, if you have an abiding interest in operating systems, love compiling kernels and creating custom builds of your favourite distribution, go for it. But the idea that any organization using Linux for critical systems would consider rolling their own distro to avoid systemd is ridiculous. Systemd won. Get over it. Discussions about how it is better or worse are mostly academic at this point. We are approaching almost a year since RHEL switched - if it was that catastrophically bad, we would know by now.

Re:Too much noise over SystemD

[Anonymous Coward]

Yeah if you call lost data "academic".

Re:Too much noise over SystemD

[ruir]

What compiling? I have a farm of virtualized Debian 8 servers and they have been chugging happily in the last few months with systemd pinned to -1. And who are you to tell others to shut up and suck it up?

Re:Too much noise over SystemD

[Anonymous Coward]

I don't understand why you're defending something that drops stderr, higher priority syslog messages, and nonzero exit statuses. All of those things are important to normal users. To technical users, they're even more important.

LOL the captcha is shoddy. That is what the half-ass systemd garbage is.

Re:Too much noise over SystemD

[Anonymous Coward]

Because he is a paid shill.

Re:Too much noise over SystemD

[Anonymous Coward]

And multiple of them have posted here with clear reproduction steps, but instead of fixing problems, the systemd guys make constant death threats. They called my daughter's daycare and made her teacher cry. Rather than fixing problems with systemd ignoring nonzero exit statuses, ignoring stderr, or ignoring syslog messages, they instead called my daughter's daycare and threatened to kill her. They're so fucking lazy that they would rather threaten little girls than fix their problems.

Re:Too much noise over SystemD

[ruir]

I dont understand why in earth you are both posting as ACs in such an important matter.

Re:Too much noise over SystemD

[Anonymous Coward]

Forcing systemd on a linux user is like pushing gay sex on a straight man. There will always be some who bend over an take it, some may even like it. I would imagine that there may be some holdouts.

The fan boys will sell the the gay sex on grounds of it being truely modern, with any number of familiar features but with a modern implementation and a whole range of new possibilities not before available. Just wait and see what we do next, you'll be amazed.

For some it'll just seem like their being fucked up the arse.

Re:Too much noise over SystemD

[Barsteward]

you should have blocked up all the orifices on your head before you stuck it up your arse as its now full of shit.

"For some it'll just seem like their being fucked up the arse." - needs a correction - "their" to "they are" or "they're"

Re:Too much noise over SystemD

[Anonymous Coward]

Wow, that's pretty bad. All they did to me was email my boss for opening a bug with a suggested patch. My patch fixed one of the serious problems we had here with systemd ignoring nonzero exit statuses, and it was ignored and my boss emailed a threat. Calling your daughter's daycare was going too far.

Re:Too much noise over SystemD

[Anonymous Coward]

It's more comfortable to say the truth from behind a mask.

Re:Too much noise over SystemD

[Anonymous Coward]

We are approaching almost a year since RHEL switched - if it was that catastrophically bad, we would know by now.

• Systemd doesn't unmount all devices before calling reboot/halt and thus corrupts a clean RAID1
• System with Intel firmware RAID-1 does not mount /home on boot (udev/systemd race with mdadm issue)
• boot problem with btrfs
• Keyboard shortcuts handling in text virtual consoles is broken with systemd
• keyboard layout changes back to english, allthough german (austria) is selected during install/Changing default keyboard is ignored
• System fails to mount LUKS encrypted volume at boot after kernel upgrade

Re:Too much noise over SystemD

[Eunuchswear]

I dont understand why in earth you are both posting as ACs in such an important matter.

Because they are lying.

systemd has bugs and implementation decisions that some people don't like, but, wierdly, there is a strange subculture of trolls who like to complain about systemd "throwing away output and exit statuses", behaviour which, if true, would be easy to replicate and should be reported as a major bug.

But no non-AC has ever been able to replicate the problem, and no bug report about this behaviour has ever been made.

Re:Too much noise over SystemD

[Anonymous Coward]

So in short "shut up and stop whining" ended with "if it were so bad, poeple would be whining about it by now!"

Re:Too much noise over SystemD

[Anonymous Coward]

This is the only insightful comment I've read in this entire thread. Yet it got modded down to troll. This systemd hatred is beyond comprehension. If it is this bad, how can it be adopted by all major distributions? The truth must be somewhere in between.

Re:Too much noise over SystemD

[Anonymous Coward]

It is the sysv init system that has been dropping stderr for decades. Yet, curiously, no one had been complaining about that.

Re:Too much noise over SystemD

[russotto]

This systemd hatred is beyond comprehension. If it is this bad, how can it be adopted by all major distributions?

Political machinations.

Re:Too much noise over SystemD

[ruir]

And there in lies the rub. The point about it is not adopted by all distributions, but by the PEOPLE/sysadmins.

Re:Too much noise over SystemD

[secretsquirel]

+1 sad but true. unless you're main product is IT services and it's your job to optimize kernels and specify every single package etc., in 90% of the business world it will be CYA/industry standards and move on to the actual work.

This will happen and you'll hear about it every time it does. - "If you want to build Debian without systemd and deal with all the niggly annoying issues that will come out of that and get progressively worse"

Re:Too much noise over SystemD

[ruir]

Best comment i have seen so far here.

Re:Too much noise over SystemD

[ruir]

As i said to other, your comment would be a very valid point if the code and know-how how to deal the sysvinit has not been there for +20 years.

Re:Too much noise over SystemD

[Bengie]

Most of the people complaining about SystemD are not complaining about how well it works most of the time, but how horrible it works when things go bad. Why did my system crash? Not sure, SystemD corrupted itself. All I hear is "It works great" or "something went wrong, can't figure it out".

Re:Too much noise over SystemD

[Bengie]

would be easy to replicate and should be reported as a major bug

The devs don't care. These issues have been reported. Like the binary log corruption bug. After over 1 year of sitting, the bug got closed with a "working as intended" and dev border-lining lambasting the submitter. I can understand that a file can get corrupted because of faulty hardware or an FS bug, whatever. What I don't understand is how someone designs something as critical as a log to be non-atomic and easily get corrupted from an unexpected shutdown because it's designed that way.

As someone who designs systems that must be maintained, logging is vital to any amount of debugging why a system failed. SystemD fails with the most fundamental issues.

Re:Too much noise over SystemD

[Eunuchswear]

would be easy to replicate and should be reported as a major bug

The devs don't care. These issues have been reported.

No they haven't. There is no bug report for any of these ficticious problems.

Like the binary log corruption bug. After over 1 year of sitting, the bug got closed with a "working as intended" and dev border-lining lambasting the submitter. I can understand that a file can get corrupted because of faulty hardware or an FS bug, whatever. What I don't understand is how someone designs something as critical as a log to be non-atomic and easily get corrupted from an unexpected shutdown because it's designed that way.
 

What bug is that exactly? The bug where if the journal is closed incorrectly a new one will be opened to avoid losing messages?

Re:Too much noise over SystemD

[Bengie]

In the past year, someone on /. had a link to SystemD's own bug tracker where there was a bug someone submitted which was about SystemD corrupting the log during unexpected shutdowns. It wasn't just that you couldn't write to the log, but the entire log was lost. When one of the main devs closed the bug, he added a very sarcastic reason rhetorically asking the submitter how SystemD should be able to read a corrupted log and to delete the log and move on, working as intended.

All I heard was a big whoooosh, as the dev didn't seem to recognize that a volatile log is a horrible thing to have when trying to figure out what happened moments before your computer crashes. A log that can no longer be written to is one thing, but a log that self-destructs because of a race-condition is another.

It's entirely possible that this is no longer an issue for one reason or another, but the fact that one of the core Devs who is responsible for how the system as a whole works, seemed to not even recognize the seriousness of the issue, then proceeded to treat the submitter like some sort of imbecile, made me lose all confidence in their ability to write such a system. I may have caught him on a bad day, but the core dev sounded like a complete moron. He is the kind of person that if you willingly work with him, you are stupid by association.

Re:Too much noise over SystemD

[Eunuchswear]

It wasn't just that you couldn't write to the log, but the entire log was lost.

Are you sure? This is the most quoted bug about journal corruption: https://bugs.freedesktop.org/show_bug.cgi?id=64116

I see no sarcasm.

Re:Too much noise over SystemD

[ookaze]

The devs don't care. These issues have been reported. Like the binary log corruption bug. After over 1 year of sitting, the bug got closed with a "working as intended" and dev border-lining lambasting the submitter. I can understand that a file can get corrupted because of faulty hardware or an FS bug, whatever. What I don't understand is how someone designs something as critical as a log to be non-atomic and easily get corrupted from an unexpected shutdown because it's designed that way.

As someone who designs systems that must be maintained, logging is vital to any amount of debugging why a system failed. SystemD fails with the most fundamental issues.

I can't believe one moment that a company gives system design to people like you who have astounding comprehension issues.
You don't have any idea of how a log or any file is written to disk, you are still wondering why an unexpected shutdown can corrupt a file, I dare not tell you that can corrupt an entire filesystem, gasp!
It's pathetic to read such behaviour, because logs got corrupted before with your syslog daemon, but you weren't aware of it. For you, as you weren't aware of it, your log weren't corrupted: a fallacy you can't manage to grasp. Sorry, that's not how it works in the real world. Now, journald can verify its log integrity, and all of a sudden, lots of ignorant people come complaining about a problem that always was there, because journald actually provides this information. Instead of being thankful, ignorant people calling themselves sysadmins want others to do the work only themselves can do, which is securing their log files and their filesystems.

Re:Too much noise over SystemD

[ookaze]

In the past year, someone on /. had a link to SystemD's own bug tracker where there was a bug someone submitted which was about SystemD corrupting the log during unexpected shutdowns. It wasn't just that you couldn't write to the log, but the entire log was lost. When one of the main devs closed the bug, he added a very sarcastic reason rhetorically asking the submitter how SystemD should be able to read a corrupted log and to delete the log and move on, working as intended.

You should not go everywhere talking about your understanding problems. We understand you can't read correctly or understand anything about computer science.
For the record, the log is NOT lost, it is still there (unless the filesystem removed it), and only the corrupted part in it are not displayed by the systemd standard tools.
And no, systemd does not corrupt the log during unexpected shutdown, there is no code to do such a mischievous thing in systemd.
Actually, computer programs are not sentient entities, they're not magic, they're not self aware. It's just that an unexpected shutdown in itself prevents the OS from doing its normal cleanup, and the corruption can happen at any level. Filesystems and (log) files got corrupted by unexpected shutdown before systemd was even created.

Think about it

[Ilgaz]

here we go...

Guess it's time to change my email address...

The base of everything that will effect the number one operating system on portables (Android) and possibly "internet of things" has been upgraded after 24 months of work by individuals and Fortune 500 and all we will discuss is systemd.

If they weren't involved, it is like winning lottery for Microsoft and they didn't even purchase a ticket.

Re:Think about it

[Anonymous Coward]

Android? The internet of things?

I think you're confusing Debian with Linux as a whole.

not enough noise over systemd

[ruir]

This beta crap has been imposed over us unnecessarily and politically. Debian also got out of its way and is updating all servers to systemd without our asking, and without any visible dependencies, breaking configurations in the process. This is far more than "noise", what you have is fellow technicians and users, your customers and peers, for christ sake, telling you they are not happy. Many of us that have been months already using Debian with systemd pinned a testimonial that this would not be a required situation. To add insult to injury, everyone that speaks about this tabu is told to suck it up, man up, or that just is making noise. This is the antithesis of Debian and opensource. Debian and linux in spirit is about choice and flexibility, and many of us deflected from Windows and other flavours of Unix just because of that. We have been betrayed and sold. To the ones that say this was a consensual and democratic process. A true free and open process would be to include a choice at installation/upgrade time between the choices. If I do have a choice on the web server, on the DNS server, on the mail server, even on the kernel, on the shell that I deliver for my users, despite having defaults, than why, for christ sake, is systemd being rammed down our throats? Get a grip you and honestly, fuck you all.

Re:not enough noise over systemd

[Anonymous Coward]

Apparently the guys that control Debian don't think you need access to stderr, exit statuses, or syslog messages. systemd drops all three due to design problems.

Re:not enough noise over systemd

[Ben Hutchings]

A true free and open process would be to include a choice at installation/upgrade time between the choices. If I do have a choice on the web server, on the DNS server, on the mail server, even on the kernel, on the shell that I deliver for my users [...]

You can't choose any of those through the installation GUI. All of them require a custom pre-seeded install or post-install action.

If you upgrade an x86 system, both systemd and sysvinit will be installed and you can select sysvinit from the GRUB menu.

Re:not enough noise over systemd

[ruir]

In my testing servers, my sysvinit was upgraded to systemd without a single request or warning, and worse yet, sysvinit was not upgraded and had to be upgraded manually.

Re:not enough noise over systemd

[Barsteward]

repeating crap troll bait won't make it true

Re:not enough noise over systemd

[Anonymous Coward]

sorry but the world has spoken. aside from some neckbeard IT drones whining on slashdot, most people prefer systemd. it is superior.

Re:not enough noise over systemd

[jbolden]

There were already emerging chains on Jessie last year where packages needed a recompile or work to run without systemd effectively That's not to say that every system had such chains but that they were starting to emerge and complicate work. The systemd advocates never said Jessie wouldn't work without systemd but rather that:
a) Jessie was likely the last version that would work while being a broad based distribution without systemd
b) They couldn't insure that upstream packages would continue to support initd based features for 2-3 years so not using it would introduce security issues
c) Given the speed of systemd development and its ties with architecture the changeover was likely to be vastly more breaking 3 years later (i.e. 2015 is going to be much easier than 2018).

As for choice and flexibility... Debian is a compiled distribution Most packages don't introduce complex chains of dependencies but some do. And on those Debian has had to make choices about defaults. The way those choices are made is by looking at the direction of upstream. Debian's policy is pretty clear. If the initd people want initd then work with the upstream software to make sure their software is not introducing systemd dependencies and work with the package maintainers or easy option switches. Debian supports that. What they can't support is 2 different distribution. If Devuan ever comes to be then you'll have a long term systemd free Debian. If not Crux, Alpine... exist . No one is taking away choice from Linux.

Re:not enough noise over systemd

[Anonymous Coward]

People here have posted good reproduction steps here several times. Also, I've seen them posted to reddit. Every time the systemd fanbois attack the poster rather than the problem. Returning a zero exit status for a service that fails to start is a serious problem. Swallowing stderr is an even more serious problem. That makes it very difficult to troubleshoot problems. I've wasted days with Red Hat 7 trying to troubleshoot SELinux-related problems. I had to resort to using strace to see the actual error messages. With Sys V init scripts, they print stderr directly to the console, rather than silently deleting messages, so that made it much easier to find the cause of problems in Red Hat 6 before the switch to systemd.

Re:not enough noise over systemd

[Anonymous Coward]

repeating crap troll bait won't make it true

True, but the fact that those are serious problems and people have posted multiple good reproduction steps here certainly makes it true. Swallowing stderr makes it very difficult to troubleshoot start-up problems.

Re:not enough noise over systemd

[Anonymous Coward]

Lets face it given the attitude of the people pushing systemd to the freedoms that caused the migration from non-free in the first place,their attempts a revisionist history and their general rudeness let them have their "win".

You get judged by the company you keep and I'd rather have nothing to do with:
debian, gtk3/gnome, systemd, pulseaudio, avahi, freedesktop and anything with the word 'kit' in it.

The amount of time burned wrangling this crap over the last 5 years and avoiding new crap from the same people has been excessive.

I thought the careful choice of distro/packaging, pinning and destop would be enough but as fast as I ran and the more I learned to implement this the way I needed the more this bunch raced expanding their encroachment and finally overtaking my distribution.

I tried to be angry for a while but now I'm just sickened by the whole affair. I tried to act and debate on technical merit and code quality/design/stability issues and it did no good. Its now at at point where I truely dislike the actual people involved and they can rightly dismiss me as amongst the 'haters gonna hate' crowd. But it took me a long time to get there.

Re:not enough noise over systemd

[ruir]

Your reasoning would sound more fair if *sysv* was the newcomer. It is like exactly 20 years of core and experience disappeared overnight and was necessary to redo all over again. And I still do not understand why you do have to upgrade server from sysv to systemd when there are no dependencies on sight without a single courtesy warning in the installation scripts, and *ignore* the sysv packages installed, not even upgrading them to debian 8.

Re:not enough noise over systemd

[ruir]

Why not posting with a true user?

Re:not enough noise over systemd

[ruir]

correction "it is not exactly"

Re:not enough noise over systemd

[raxx7]

Just upgraded my hobby server from Wheezy to Jessie. sysvinit was upgraded and remained as the init.
The only bits of systemd in the system are the libsystemd* libraries.

Maybe you have a service which has some systemd dependency?

Re:not enough noise over systemd

[Barsteward]

those 2 "problems" you listed have been thoroughly debunked thats why they are crap troll bait

Re:not enough noise over systemd

[Barsteward]

stderr is logged in the journal so it can been viewed as many times as you like via the journalctl program - so how is that a problem? try reading up on so called problems before taking spurious claims as fact

Re:not enough noise over systemd

[Anonymous Coward]

what a complete load of bollucks

Re:not enough noise over systemd

[jbolden]

What do you mean by fair? From from the perspective of Jessie or fair from perspective of some broader Linux community? if you mean the formers: Debian can't control what upstream software producers do. If in 2016 an upstream package has no interest in fixing a security hole that only impacts sysv what are they going to do about it? They would then have to have a security update that could break init scripts.

As for how to handle upgrades on existing servers that have complex code I really don't have much of an opinion. Certainly systemd breaks stuff on existing servers as far as init scripts which is one of the reasons I think changing the default was important to do early before the forking between systemd-linux and sysv-linux got large enough that automated updating became unworkable. I assume basically that Debian wants updates to Jessie to be a lot like new installs and not have to support two systems in the field. So that end users understand version upgrades can break stuff, while minor updates don't. Knowing you are updating from 7 to 8 is the warning that breaking change could occur. And then they are moving them over to the new update.

As for 20 years disappearing overnight. Sort-of yes. The direction systemd is going towards is uniform process management like you see on mainframes and minis and away from the workstation process management that Unix uses. I think that's the right thing to do, but I'm not going to deny that in many ways the people who are supporting the systemd / IaaS / PaaS stacks are trying to put back into Unix the stuff that Ritchie, Thompson... were taking out.

Re:not enough noise over systemd

[GuB-42]

Debian is all about choice, that's why it is opensource and you can fork it if you don't like their design choices. Many successful distros started as a fork of Debian, including Ubuntu, so I don't see why the same can't happen for sysv init lovers.

Re:not enough noise over systemd

[Anonymous Coward]

Because there are a lot of people who simply don't care or want to register. It's a thing. Get over it.

Re:not enough noise over systemd

[thegarbz]

Debian also got out of its way and is updating all servers to systemd without our asking

There's a simple reason for this: Debian is not a democracy. I don't know where people get these silly ideas. It's a project run by a few core maintainers who make all the decisions. Linux on the whole is about choice, choice of which distribution you run, and choice of how to configure that distribution within its provided parameters.

The only thing new here is that suddenly its a parameter you actually care about. Nothing else has changed in the way systems are run.

Don't like it? Why not support one of the forks?

Re:not enough noise over systemd

[ruir]

This is worse than Debian deciding it is much work supporting people running Apache and upgrading all the servers to Nginx wihout our asking because it is "better". I do not see why you dont bugger off too.

Sadness

[Foresto]

Thanks, Poettering. :(

Re:Sadness

[ruir]

More fuck you and bye.

Re:Sadness

[Anonymous Coward]

That's what people who are right say!

Systemd vs sysinit boot speed anecodote

[Sits]

Anecdote 1: I've just timed a Debian Jessie single CPU hard disk based VM install with BTRFS as the filesystem, a GNOME 3 desktop where the user is auto logged in boot and where an autostart script records the time. Here are my rough systemd and sysvinit results (times are from after the kernel core finished to when the GNOME script ran):
sysvinit (apt-get install sysvinit-core)
First boot: 20 seconds
Second boot: 18 seconds
Third boot: 19 seconds
systemd (apt-get remove sysvinit-core)
First boot: 15 seconds
Second boot: 16 seconds
Third boot: 15 seconds

sysvinit averages 19 seconds, systemd averages 15.33 seconds. In this case it does appear that systemd booted the system faster.

Anecdote 2: Same as above but where the VM's disk is sitting wholly in RAM. Time for sysvinit dropped to 5 seconds and the time for systemd dropped to 4 seconds.

My personal guess is that the more you are running, the slower the disk the more likely systemd is to benefit you. You don't say how you did your comparison though or what type your "disks" were. If your comparison was between different versions of Linux distro then it could simply be that the previous version did less (which is always the fastest way to boot)...

Another anecdote: a few years back I saw Slackware systems at a University converted over to systemd. Boot times (which involved waiting for multiple NFS mounts) went from over three minutes to down to less than a minute because more of the waiting was done in parallel.

Re:Systemd vs sysinit boot speed anecodote

[dbIII]

went from over three minutes to down to less

Something is definitely seriously wrong in that case. Are you sure it wasn't a change to autofs to mount them on demand instead of boot or using more correct NFS mount options that made the difference?

The other bits are interesting and make your point but that final one is a somewhat pathological case.

As for my example - a eeepc with an SSD but not a very quick CPU. Boot time with the stock distro (xandros) was about 15 seconds, around 45 with a cut down recent Fedora with hardly anything starting. It now has FreeBSD10 on it.

Re:Systemd vs sysinit boot speed anecodote

[Sits]

The NFS mounts were always mounted at boot and not on demand both before and after systemd. The difference was that because there were multiple NFS mounts only proceeded in serial before the switch. After the switch the waiting of the mounts happened in parallel not just with each other but other services too. Yes it is entirely pathological but it really happened (and presumably other parallel inits would have solved it this way too).

For what it's worth I have an EeePC too. The default Xandros distro was a classic case of not running very much because it was highly custom (e.g. no printing, no mdns, kernel doesn't have to probe for all different kinds of hardware, hotplug of USB devices, io scheduler set to deadline etc) and thus was fast - I would always expect it to outperform a generic "full fat" Linux distribution. I'd expect your FreeBSD to beat my current XFCE Ubuntu setup too because I bet you can get start less. With lots of hand tweaks the boot speed to an XFCE desktop on my EeePC 900 is still 17 seconds...

Re:Systemd vs sysinit boot speed anecodote

[Anonymous Coward]

Anecdote 3: with Linux 4.0, the Jessie's systemd will block for 95 seconds when it tries to mount NFS share, even if the wifi is not yet ready on that stage of system startup. This happens on both of my Debian/Jessie machines.

Re:Systemd vs sysinit boot speed anecodote

[hitmark]

Iirc, systemd no longer optimize for "spinning rust" as the major devs have all moved to SSD...

Re:Systemd vs sysinit boot speed anecodote

[Sits]

Interesting... Googling around backs up your memory - systemd's readahead implementation was removed in v217.

Re:Systemd vs sysinit boot speed anecodote

[ookaze]

Anecdote 1: I've just timed a Debian Jessie single CPU hard disk based VM install with BTRFS as the filesystem, a GNOME 3 desktop where the user is auto logged in boot and where an autostart script records the time. Here are my rough systemd and sysvinit results (times are from after the kernel core finished to when the GNOME script ran):
sysvinit (apt-get install sysvinit-core)
First boot: 20 seconds
Second boot: 18 seconds
Third boot: 19 seconds
systemd (apt-get remove sysvinit-core)
First boot: 15 seconds
Second boot: 16 seconds
Third boot: 15 seconds

sysvinit averages 19 seconds, systemd averages 15.33 seconds. In this case it does appear that systemd booted the system faster.

Anecdote 2: Same as above but where the VM's disk is sitting wholly in RAM. Time for sysvinit dropped to 5 seconds and the time for systemd dropped to 4 seconds.

My personal guess is that the more you are running, the slower the disk the more likely systemd is to benefit you. You don't say how you did your comparison though or what type your "disks" were. If your comparison was between different versions of Linux distro then it could simply be that the previous version did less (which is always the fastest way to boot)...

Another anecdote: a few years back I saw Slackware systems at a University converted over to systemd. Boot times (which involved waiting for multiple NFS mounts) went from over three minutes to down to less than a minute because more of the waiting was done in parallel.

Your examples are useless as long as we don't know if systemd was running in native mode (with only systemd units) or in compatibility mode (by having to translate init scripts to units and still launch them as shell scripts). In compatibility mode, systemd has more work to do than in native mode. The compatibility mode is basically useless for systemd, it's only useful for the admin as a temporary workaround, when you're translating init scripts to systemd units.
Only then can you really enjoy the power of systemd.

libjpeg forks only sane way to go

[Anonymous Coward]

Debian 8 has libjpeg-turbo, replacing libjpeg8 and matching most other distributions.

About time. For some time now, the IJG has practically been run by some kook who insists he's the only one who understands the "fundaments of DCT image compression" and furiously trolls any attempt to prove otherwise. The latest versions of libjpeg feature various compatiblity-breaking "improvements" that actually make the compression worse both subjectively and objectively.

Good-bye

[The Infamous Grimace]

Good-bye Debian. It's been fun, but you've changed, and not for the better.

not enough noise over systemd

[ruir]

This beta crap has been imposed over us unnecessarily and politically. Debian also got out of its way and is updating all servers to systemd without our asking, and without any visible dependencies, breaking configurations in the process. This is far more than "noise", what you have is fellow technicians and users, your customers and peers, for christ sake, telling you they are not happy. Many of us that have been months already using Debian with systemd pinned a testimonial that this would not be a required situation. To add insult to injury, everyone that speaks about this tabu is told to suck it up, man up, or that just is making noise. This is the antithesis of Debian and opensource. Debian and linux in spirit is about choice and flexibility, and many of us deflected from Windows and other flavours of Unix just because of that. We have been betrayed and sold. To the ones that say this was a consensual and democratic process. A true free and open process would be to include a choice at installation/upgrade time between the choices. If I do have a choice on the web server, on the DNS server, on the mail server, even on the kernel, on the shell that I deliver for my users, despite having defaults, than why, for christ sake, is systemd being rammed down our throats? Get a grip you and honestly, fuck you all. xxxx

Btrfs?

[Dwedit]

Will Btrfs work well on this version? It says that the kernel is 3.16.7, and the newest kernel is 4 versions ahead, and the Btrfs wiki claims that it's best to use the newest kernel possible.

Re:Btrfs?

[ruir]

Use the real deal ZFS in FreeBSD

Re:Btrfs?

[Anonymous Coward]

You can use the real deal http://zfsonlinux.org/ too. Works great, especially if you have IEEE-1394 or other odd-bus devices, support for which are, uhm, unreliable or needing a maintainer in FreeBSD 11 current.

Re:Btrfs?

[Dwedit]

Tried FreeBSD + ZFS in an emulator, one poweroff later, it won't boot anymore.

My summary on systemd

[gweihir]

Already a little bit older, but still completely relevant:
- There are no technical merits of systemd that are important or critical, just some convenience issues
- Systemd is in hurried development, a stable feature set is nowhere in sight
- The development leads are known incompetents with inflated egos and no communication skills
- There are a number of design decisions that are very, very bad for security and stability

At the same time I see:
- Systemd is pushed strongly with emotional (not factual) arguments
    -> This is a coordinated and targeted propaganda campaign. A campaign focused on technical merits is not even attempted seriously.
- Systemd opponents are ridiculed, insulted and their arguments are not taken seriously, very much SJW-style
- Systemd is getting very hard to avoid

I can only deduce that there _must_ be one of or a combination of the following going on:
- Linux was getting too hard to hack and the intelligence community is pushing for systemd to fix that
- Linux did not generate enough support revenue for Red Hat and this is intended to fix that
- Red Hat wants total control over Linux and systemd is their attempt to establish that

So if it walks like a duck, quacks like a duck, the most probable explanation is that it
is a duck and hence I conclude that something nefarious is going on and the last three
items are the most likely candidates IMO. I cannot believe that two known incompetent
hacks with bad personalities can screw over a whole large tech-savvy community all by
themselves. They must have significant, coordinated help, with significant propaganda
and manipulation experience. Whether it is military PsyOps or just commercial PR, the
effects are the same. And they are massively negative and destructive for Linux and
its community if not repelled decisively.

Re:My summary on systemd

[Anonymous Coward]

Anyone against systemd is a misogynist/non-progressive who is then kicked out.

Feminists should be killed.
Hans Reiser did the correct thing.

Re: My summary on systemd

[Anonymous Coward]

My thoughts exactly. Plus there must be a concerted effort to bash everyone in every forum who, for whatever reason, complain about systemd. Let's also not underestimate the huge resources underpinning this effort. No normal Linux user or admin could waste his/her precious time defending, post after post, the non-existing and half baked benefits of systemd.
That's why I also think that guy, Poettering, must be a placeholder for the real developers who derailed true Linux philosophy, community, and 20+ years of hard work. Such developers may be in some US government agency payroll .
Having built my own private Wheezy repository, that's what I intend to use for all my future installations.
As for Debian 16, code named Debian Lennart, It may go the drain. I don't give a damn.
Now, c'mon paid systemd apologists: do your job and earn your next check. Bash me as much as you can.

Re:My summary on systemd

[jbolden]

You are paranoid. The very first statement is wrong: There are no technical merits of systemd that are important or critical, just some convenience issues Nothing is critical. However in terms of important process management has been important for many years on many operating systems. It was part of most of the commercial Unixes and improved them considerably. So yes it is important.

As far as technical merits the technical merit is it does basic process management and thus allows for hooks to more advances process management.

Re:My summary on systemd

[gweihir]

As somebody that has worked with several commercial Unixes, I can only call your statement utter bullshit. Sure, some special-purpose server-only installations where software done by incompetent people needs to run may actually have that need, but that is not the target systemd is aiming for. At all. And aren't you forgetting that that systemd is usually advertised with "faster boot-times!" to the masses? You must have misplaced your shill-instruction sheet.

Re: My summary on systemd

[Anonymous Coward]

Why not cut out their tongues of chop off their fingers when they slander you?

Re:My summary on systemd

[jbolden]

AIX System Resource Controller
Solaris Service Management Facility
Linux had a bunch of cludgy systems like daemon tools.

Etc... So you don't know what you are talking about those things most certainly exist.

As for faster boot times ... your claim was what systemd does not one feature it had in 2010. Initial state during boot to running state with daemons states is just one of the states that systemd manages that most certainly is not the entirety or even the primary drivers of its functions.

Re:My summary on systemd

[gweihir]

Sure these things exist. But the are not _needed_ at all as part of the init-system and they are not needed to be the same for all daemons on the system either.

For example, DJB's daemontools work perfectly well (they are only "cludgy" if you are clumsy or stupid). I have done some special-purpose variants myself, one of which worked reliably for a real-time high-volume data collection task for more than a decade. The claim that anything like systemd is needed here is a pure lie, plain and simple.

Re:My summary on systemd

[jbolden]

You had just claimed they didn't exist, that it was "utter bullshit" that "process management was part of most of the commercial Unixes and improved them considerably". That they didn't exist.

As for things like daemontools working well... service A depends on B which depends on C. B starts having problems and needs to restart:

i) What should the system do about A? How does it get notified?
ii) How the the connection to C reestablished when B is restarted?

That sort of chain can't be handled. Daemontools can restart the simplest services but is structurally unable to handle the complexity of interdependencies. That's not a question of being clumsy or stupid. High volume vs, low volume has nothing to do with additional complexity in process management. And if you had extensive experience you would know that. I think you need to stop throwing around words like stupid, clumsy, bullshit and your claims to extensive experience and rather read about process management and why system administrators want it.

Re: My summary on systemd

[Anonymous Coward]

Now, c'mon paid systemd apologists: do your job and earn your next check. Bash me as much as you can.

They don't need to. The anti-systemd arguments are nearly all so poor and pathetic they entirely discredit themselves and their poster. Example: the GP post, and yours.

BTW I don't run systemd at present becuase I'm seriously back level but when I do upgrade, based on the quality of the pro/anti posts, I'm looking forward to it being either a neutral (probably won't notice at all) or positive experience.
90% of the antis seem to be retards, many of them drooling on with irrelevancies about 'SJWs' and 'faggots' - always the sign of a juvenile idiot posting.

Re:My summary on systemd

[gweihir]

You seem to have trouble understanding text. Re-read what I wrote. Hint: I never claimed they do not exist. And second hint (since you seem to need it): The "bullshit" may have referred to something else than the "existence".

As to your example: That is contrived. Of course what to do depends on the concrete details, not some abstract and artificial situation. In a concrete situation it turns out that it is the task of a service depending on another one to be able to handle it going down. It is decidedly not the task of a generic reliability-wrapper. That is just abysmally bad design.

Re:My summary on systemd

[jbolden]

How can a service handle a situation when it is down? The services have to register in advance how to handle things. Moreover other services might still have issues.

  B depends on C and C needs to reinitiate with B, but D is also talking to C. How does the new B signal C?

As for it being contrived that's one of the key issues in process management how to handle chains and stacks of processes. That doesn't happen much in the sysv world because sysv handles it so badly that everything ended up having to write its own process manager.

Re:My summary on systemd

[gweihir]

Really, stay away from process management. You do not have what it takes to get it right. And your desire for the respective systemd-functionality now becomes abundantly clear: You want it to do things that you are not smart enough to do yourself. That is not good engineering at all.

I re-iterate: Process management is not the task of an init-system. It can only suck at it. The sysV-init designers realized that and only provided the bare minimum, leaving the actual service designers to do their own that does it right. Systemd instead tries to solve a problem it has no business solving. That is not good at all.

Re: My summary on systemd

[Anonymous Coward]

"They don't need to"

Ha! you just did. You called me a juvenile idiot posting. I agree with you on the first part: I'm an idiot. As for the second, no. I'm old, very old. But Your other arguments, plus the standard way to call us names, is clear proof you are one of them.

Regards, shill.

Re:My summary on systemd

[jbolden]

So far you've been wrong about just about everything. I know you think that prefacing nonsense with insults makes it an argument but it isn't.

Mainframes do precisely what you claim cannot be done and have done since long before Unix. So your categorical assertions of what can and can't be done are simply and obviously provably false. The fact that rather than admit this and engage you continue to be rude proves that you lack character as well as knowledge.

Re:My summary on systemd

[Anonymous Coward]

So far you've been wrong about just about everything..

That's been your opinion of anyone that hasn't agreed with you, regardless of the validity of their arguments. Face it, you're just a troll too.

Re:My summary on systemd

[ookaze]

Already a little bit older, but still completely relevant:
- There are no technical merits of systemd that are important or critical, just some convenience issues

This is your opinion, you're entitled to it, my opinion is the contrary of what you're saying.
systemd replaces many of the kludges that were inconsistently added to sysvinit (like daemontools or inetd) to have a system that was a little bit manageable.
Even process management was pathetic with sysvinit, nobody used it because of that, except to launch getty and a bunch of scripts, which is very sad.

- Systemd is in hurried development, a stable feature set is nowhere in sight

That much is true, that's the true problem between systemd and stable distributions. The other benefits must be huge for the distributions to accept to maintain old systemd releases (like 209 which is full of various bugs which can be annoying).

- The development leads are known incompetents with inflated egos and no communication skills

Fallacy, and again your opinion, mine is different. I find the development leads very competent, I'm noone to judge on their ego and I don't care, it's irrelevant to code an init system, like communication skills which are not needed at all to code. To troll on Slashdot, perhaps communication skills are useful, but not to code an init system. Which must be why systemd is so much more advanced than the other init systems on Linux.

- There are a number of design decisions that are very, very bad for security and stability

So file bug reports, that's how it's done in the community. Anti-Linux shills however, they only troll and never do anything.
You can even go to the dev ML and explain the problems. I don't see any design decision which is bad for security and stability myself, but several minds are better to locate these.

The rest of your post is nonsense: systemd has only been evaluated on its technical merits, that's how it won nearly every Linux distro.

Sysd slower boot for me - but to be fair . . .

[walterbyrd]

As I understand it, sysd startup time is faster when you a lot of applications to start at boot time. Because sysd starts the apps in parallel, it goes faster.

But, if you are running a standard desktop. sysd is probably slower.

Is Devuan out?

[walterbyrd]

My understand was: Devuan was supposed to come out at the same time as Debian 8.

I would be interested to know if anybody has tried Devuan, and what was the experience like?

Re:Is Devuan out?

[Anonymous Coward]

Lol no, and it likely never will be, sadly.

Perhaps if Devuan was headed by someone other than a pot-smoking hippie called Jaromil that bans anyone who is opposed to feminism etc, then maybe Devuan might do something and save us.

But it is, and it won't.

Re:Is Devuan out?

[ookaze]

Lol no, and it likely never will be, sadly.

Perhaps if Devuan was headed by someone other than a pot-smoking hippie called Jaromil that bans anyone who is opposed to feminism etc, then maybe Devuan might do something and save us.

But it is, and it won't.

Oh man, I knew Devuan was BS, just by reading their supporters on Slashdot who are mostly people with no technical knowledge at all regarding init systems, but now that I know that its members are feminist friendly, I'm sure it won't go anywhere. SJWs are not compatible with improvement IMHO, I wouldn't touch these people with a 10 feet pole.

Ships with Xfce 4.10

[ttyX]

I wonder if they'll update to Xfce 4.12 sometime in the future but am not holding my breath.

Head scratching...

[rbrander]

Despite a CompSci degree and over 15 years of using nearly every breed of Linux at work and home, I feel like a guy who just wants the car to go listening to automotive engineers get angry over a debate on number of cylinders.
I upgrade only when forced to, these days: Linux met all my needs years ago. I was just compelled to upgrade from a long-obsolete Mint to 17.1, which I gather will be around for years before all support stops.
Is there any hope of this particular Good Thing vs Bad Thing debate being settled by, say, 2017?
That's all most of us want to know.
Proof's in the pudding, guys. My hat is off to everybody who tries out the new distro and takes the proverbial arrows in the back so the rest of us can know about a year or so from now if all the dark predictions about "systemd" come true or not.

Re:Head scratching...

[jbolden]

Systemd has been standard on distributions for about 2 years. There arrows are long past. Debian is a conservative distribution, they went when it was getting painful not to.

Re:Head scratching...

[SeaFox]

Systemd has been standard on distributions for about 2 years.

Yeah, that's why Ubuntu just switched two days ago.

Re:Head scratching...

[raxx7]

Ubuntu was already using their own init (upstart) since 2009 and they were not, understandably, motivated to drop it in favor of systemd.
They only decided to move to systemd as Debian decided on systemd as the new default, instead of upstart.

Re:Head scratching...

[jbolden]

Ubuntu was the originator of Upstart. They announced they were considering the switch about 2 years ago, announced the switch Feb 2014. So I don't know where you are getting 2 days.

Re:Head scratching...

[SeaFox]

So I don't know where you are getting 2 days.

I'm getting it from the story I linked about Ubuntu 15.04, the first version that uses systemd, being released -- two days ago.

Re:Head scratching...

[jbolden]

In complex projects there is a lag. Software isn't done by magic. Once software people decide to start moving towards a standard the actual use of standard in release product lag. Ubuntu announced it couldn't continue with upstart and needed to switch away two years ago. That doesn't cause the repositories to instantly change.

Debian Dev on why you should use systemd.

[Anonymous Coward]

http://etbe.coker.com.au/2015/...

For some reason the men in the Linux community who hate women the most seem to have taken a dislike to systemd. I understand that being âoeconservativeâ might mean not wanting changes to software as well as not wanting changes to inequality in society but even so this surprised me. My last blog post about systemd has probably set a personal record for the amount of misogynistic and homophobic abuse I received in the comments. More gender and sexuality related abuse than I usually receive when posting about the issues of gender and sexuality in the context of the FOSS community! For the record this doesnâ(TM)t bother me, when I get such abuse Iâ(TM)m just going to write more about the topic in question.

While the issue of which init system to use by default in Debian was being discussed we had a lot of hostility from unimportant people who for some reason thought that they might get their way by being abusive and threatening people. As expected that didnâ(TM)t give the result they desired, but it did result in a small trend towards people who are less concerned about the reactions of users taking on development work related to init systems.

The next thing that they did was to announce a âoeforkâ of Debian. Forking software means maintaining a separate version due to a serious disagreement about how it should be maintained. Doing that requires a significant amount of work in compiling all the source code and testing the results. The sensible option would be to just maintain a separate repository of modified packages as has been done many times before. One of the most well known repositories was the Debian Multimedia repository, it was controversial due to flouting legal issues (the developer produced code that was legal where they lived) and due to confusion among users. But it demonstrated that you can make a repository containing many modified packages. In my work on SE Linux Iâ(TM)ve always had a repository of packages containing changes that havenâ(TM)t been accepted into Debian, which included changes to SysVInit in about 2001.

The latest news on the fork-Debian front seems to be the call for donations [4]. Apparently most of the money that was spent went to accounting fees and buying a laptop for a developer. The amount of money involved is fairly small, Forbes has an article about how awful people can use âoecontroversyâ to get crowd-funding windfalls [5].

MikeeUSA is an evil person who hates systemd [6]. This isnâ(TM)t any sort of evidence that systemd is great (Iâ(TM)m sure that evil people make reasonable choices about software on occasion). But it is a significant factor in support for non-systemd variants of Debian (and other Linux distributions). Decent people donâ(TM)t want to be associated with people like MikeeUSA, the fact that the anti-systemd people seem happy to associate with him isnâ(TM)t going to help their cause.

Just wondering...

[Anonymous Coward]

If someone attacks systemd systems till it is secure enough or till no one likes to use it and return to sysvinit...

R.I.P. Debian

[fluido]

R.I.P. Debian, you have been a faithful friend for many many years. And there's dark forebodings for the whole of Linux, too. As an environment where I could always agree with the important choices that were taken, I mean.
Debian and RedHat were born roughly at the same time. I remember how sad I was to see a split in the Linux world, but a good option was available to me: I could let the jacket-and-tie folks go the way of RedHat, and keep navigating on the interesting seas that Debian was heading towards.
Now, no more. The Debian spirit is all but extinguished,and we are bound to have two RedHats for the price of one.
Pity. Occasion lost.
Now, what will I do with my beloved Debian tee shirt?!?

Upgraded painlessly without forced downtime?

[troff]

I had a home server on Wheezy (or, should I say, "stable". Wow, not gonna make that mistake again). I did a dist-upgrade before I'd read the release announcement and spent five minutes wondering why my home page no longer came up.

"What do you mean, 'Please upgrade your kernel before or while upgrading udev'? What do you mean, 'can't install linux-image-amd64', udev is broken'?" What the hell happened to my beautiful Wheezy -

- oh, crap, what do you mean, Jessie with systemd is the new stable ALREADY.

I also tried Pikoro's instructions above twice in a VM at work; *twice*, got the installer failing on me at the "Installing Software" step. And no hint as to what went wrong. So screw it, I thought. I'll install off the live image with all the defaults including that f'ed up systemd, rather than off the xfce-image.

"Oh, look. Broken a third time at the 'Installing Software' step. Using no online repositories (behind a work firewall with a corporate authenticator I can't use in the install environment) with the default first DVD image. And it still broke in the 'Installing Software' step." ... so, my hat off and some deep respect to Pikoro and those who got Jessie to install without the systemdevil, let alone *with the ordinary defaults*. I'm just glad I got an archived copy of 7.8.0, because:
- an on-the-metal upgrade FAILED to upgrade and has forced every service offline
- two VM installs with the xfce-cd, trying to keep systemd out failed
- a third VM install with the first full DVD, trying to keep out systemd failed
- and a fourth VM install, with the live disk image and accepting all the defaults failed.

Damn you RedHat, damn you everyone who brought systemd to light.

And damn you Debian, for going along with this - and pushing me the biggest Debian lie I've ever seen - "upgraded painlessly without forced downtime".

Call my evidence anecdotal, call it a data point in a shifting window. I call it the next day I can spare re-installing Debian 7.8.0, excluding every Jessie/Stable repository and repartitioning a 20W machine I set up over four years ago so that these upgrade stuff-ups will never necessitate me restoring from backup again.

Thanks for Wheezy, Debian. I hope against, but do believe that's going to be the last time I thank the Debian project again and hope like crazy Devuan does a good fork.

Re:Upgraded painlessly without forced downtime?

[ookaze]

Obviously you don't grok anything about what you are doing, you're ignorant but still you blame systemd.
Hint: systemd is not what is installing your distribution, systemd has nothing to do with the fact that your distribution won't upgrade correctly.

Stable?

[felipou]

Wait, you're telling me systemd is stable? Like, debian-stable level (or should I say debian-level stable)?

A super important core system software that had its initial release 5 years ago?

Is Debian still Debian?

systemd "benefit"

[Anonymous Coward]

The only "benefit" I've seen from a live systemd deployment is nondeterministic slow-down of boot time by 0 - 200 seconds. (Yep: 3 minutes 20 seconds.) This is on a HTPC running OpenELEC 4.x. Boot times were seconds. Now, about half the time, there's an extra minute or so of getting to stare at a text mode service starting screen informing that a job for X failed. Stare. Stare. Stare. Oh, look, it finally booted anyway.

So, I really don't get where all this "it boots faster under systemd" crap is coming from. I'm seeing unpredictable slowdowns of up to a factor of 10. (Yeah, reliable 20 second boots were the norm under OpenELEC 3.x for my setup.)

systemd was in native mode for the first two

[Sits]

Anecdotes 1 + 2 were running in native mode because it was initially a fresh install that was then switched sysvinit-core. Anecdote 3 I don't know (most likely compatability mode as it was several years ago). Even if all the anecdotes were only running in compatibility mode the results show systemd finishing quicker...

Does the above make things any better and how fast do you expect things to go when you're bottlenecked on I/O throughput? Is 15 seconds for a hard disk or 4(!) seconds for a RAM disk so bad?