Systemd-Free Debian "Devuan" Planning Their First Developer Gathering This Spring

[aht0]

it has nothing to do with package bloat, problem is that most people are too stupid to realize that after updates for zlib, openssl, glib, libstdc and a dozen others you practically should restart every service or your update was completly useless

without live patching all these idiots probably reboot sooner or later

As long as kernel's internal data structures have not changed, live patching does not concern packages at all..
Say, you are live-patching from 4.4.0-70 to 4.4.0-73 <- it's the same kernel API-wise, with minor fixes applied. Nothing has changed which would require additional messing with external packages. Might be just fixes for couple of security bugs in the kernel.

And since it's enterprise-feature (or more precisely: enterprise is most interested in it) because for them maintenance downtime equals large sums of lost money - I cannot figure out, why the hell are you categorizing it's potential users as "idiots". Enterprise sysadmins are not your Joe "where is the power button" Average.

[Weasel]

if you pretend something you have to prove it with the exact steps and return values you did

any smart human being would be able to do so, especially in case of a virtual machine, but you are not a smart being to begin with

a smart human would anyways have shouted against the package management system or the packager but given that you are proven as idiot...

No because the entire thing I posted here was just "out of my memories", I didn't sit down to copy the log when it happened, cause I didn't care, and this thread wasn't up then, so why would I even copy it?

It might surprise you, but when something like this happens, I don't think of immediately grabbing some proof against you on phoronix, cause to me you don't matter. It didn't occur to me at all to do it, is that so hard to understand? I just wanted to get on my way with whatever I needed the VM for. I don't think of you 24/7 like you do with this Weasel guy you keep mentioning all the time, know him?

[aht0]

BLA!

services which are that important are clustered anything and so there is nothing like "maintenance downtime equals large sums of lost money" or it's not enterprise at all

the point is that all this people which think uptime is a penis enlargement most of he time apply security updates but the services are still vulnerable because they have loaded the old library versions and hence they are idiots, when you have services which don't allow any downtime you have some sort of live-migration and hence there is no downtime because of a kernel update and a reboot

Are you seriously claiming that clusters cover the whole enterprise use case?

[aht0]

call it cluster or whatever, when you have a service which must not be down for 5 seconds you need to take care that it don't happen and when something goes down provide HA with whatever implementation, after that you can reboot every node whenever you want without service outage for the rest of the world
if you dont have proper HA and your service is that important that it needs it you have a design problem where your kernel updte and reboot is the smallest issue at all
you sound really clueless while trying to appear like a professional sysadmin which you aren't

Feel free to go personal if you like, I am fairly immune and will be taking your text far less seriously because personal insults, implying idiocy etc look unprofessional and create impression of either raving kid or religious fanatic.

Anyway, you keep talking only about cluster-based computers. Military, IT and economic infrastructure have plenty of vertically scaling systems, where your talked approach simply does not work. Why? Because workflows requiring concurrent processing. Delays between cluster nodes are at best measurable in microseconds. Delays on a shared memory bus are measurable in nanoseconds. You should know the difference between microsecond and nanosecond. Ton of tasks exist requiring real-time processing where sluggish clusters simply won't cut it.

Systems may have anywhere from many hundreds to many millions users connected to it and reboot might simply be not an option. These systems may be forced to run Solaris because that one has had the feature for a long time. Quite a few such systems lineups support officially Linux though (for example IBM z mainframes). Latter is an extreme example but it could as easily be 8-socket or 16-socket x86_64 server instead filling the role in some government critical infrastructure unit. Either way, when you have a server you mentally categorize as "I have to be cornered like a rat before I consider rebooting it" live patching matters very much. Quite opposite from your view point.

[Weasel]

given that you pretend you didn't care you make a lot of fuss!

Still confusing past tense with present tense, I see.

to learn something - when i make mistakes i document them and so i never make the same bullshit twice

And why should I give a shit about the EXACT output when I know how to band-aid fix it which is what's important to me? (a temporary VM I don't give a shit of as long as I get to use it for what I temporarily needed)

when you don't have hard facts because you didn't care enough to note them shut up at all

If you or other guy were following such advice you wouldn't even have 1 post on this forum.

[Weasel]

because otherwise when you make a fuss based on your typical argumentations for EVERY topic the logical conclusion for everyone is that you did shit?

No the logical conclusion is that, if I actually prove this with a log (which you'll claim I made up so the only way to prove it is to do it yourself as I've already mentioned 10 times by now)... then my word will become law until proven wrong, but it won't because you will always waste my time no matter what.

i.e. if I'm right 100 times I'm likely to be right 101th time unless proven wrong (hypothetical example).

Here's what I think happened: after linking systemd-libs to arokh, he realized he's full of shit but tried to prove me wrong desperately by following my steps, and actually got that bug as well now, so now he's silent because he knows he fucked up. You didn't yet but you can get there.

[Weasel]

i don't have to prove anything given that everybody knows it was you fucking too stupid to operate a package management and realize what you must not do and where the problem comes from and report it there - it's that simple - if you can't handle dependecy problems proper without destroy your system you are an clueless idiot seeking to blame somebody else for your own stupidity

I fixed my problem in 2 minutes.

Why don't you show the fix yourself to prove you are capable of it?

Oh wait you can't because you're an incompetent trash who talks big.

[arokh]

Almost forgot this glorious thread, got bored today and remembered it so it's noob bashing time.

Oh really? https://www.archlinux.org/packages/c.../systemd-libs/

Sorry, what were you saying? Retard.

Ups, that backfired. I meant the other way around obviously, as libsystemd has been replaced. Like I said though, doesn't matter in this context. Just an attempt to shit on you some more, which actually isn't necessary as we got plenty to go on.

Also I said the COMMAND not the OUTPUT. The conflict was the output later when installing. That's where systemd-libs showed up, you stupid trash.

Also doesn't matter, what matters is that you have no idea why the conflict arose and have convinced yourself it's because of systemd. Stupid is as stupid does.

At this point it's clear you're a fucking joke and you literally don't know what you are talking about, you embarrassment "Arch noob". You and hreindl don't know shit, keep proving that with every post you make.

This is too funny. Reminds me of the Iraqi general who was claiming Bagdad wasn't invaded at all with American tanks rolling around in the background.

Me and hreindl (or any other sane person that got the conflict you had) would use our brains for about 5 seconds and understand why it arose. Then we would do what's necessary to accomplish the original task without getting the conflict. Not go on a public forum screaming about systemd being a problem.

So let's summarize this:

You = stupid trash
We = smart

Didn't know I was capable of being this childish. What can I say, you bring out my inner child

[Weasel]

why are you then make a fuss about it?

Making a fuss when I just shared my story in this thread? (not with YOU or arokh, btw).

The only fuss here is from incompetent retard like yourself and I'm just replying in kind. See here if you want a recap.

In that post (which was not edited as you can see) you can also CLEARLY see that I fixed the problem and just sharing my story with systemd getting in my way. Obviously, I did exaggerate the time waste, because it was a rant. At no point did I ask for help from an illiterate like yourself, and yet you've gone on for pages and pages about repeating the same bullshit, when that was the very first post I made in this thread, detailing EVERYTHING you needed to know.

Seriously just piss off.

Ups, that backfired. I meant the other way around obviously, as libsystemd has been replaced. Like I said though, doesn't matter in this context. Just an attempt to shit on you some more, which actually isn't necessary as we got plenty to go on.

Also doesn't matter, what matters is that you have no idea why the conflict arose and have convinced yourself it's because of systemd. Stupid is as stupid does.

It is because of systemd, since libsystemd got "replaced" and it has everything to do with systemd (it's even in its name).

This is too funny. Reminds me of the Iraqi general who was claiming Bagdad wasn't invaded at all with American tanks rolling around in the background.

Me and hreindl (or any other sane person that got the conflict you had) would use our brains for about 5 seconds and understand why it arose. Then we would do what's necessary to accomplish the original task without getting the conflict. Not go on a public forum screaming about systemd being a problem.

So let's summarize this:

You = stupid trash
We = smart

Didn't know I was capable of being this childish. What can I say, you bring out my inner child

Bla.

[aht0]

Time to pour some more gasoline and keep the revenue coming in for Michael.

Problems as I see them with systemd

• Big and LOTS of code - translating into increased attack surface due to having more bugs. Amount of bugs would statistically increase with more LOC. coders are humans who make mistakes after all. Caffeine has only so much effect. And don't tell me Linux is inherently "immune" because malware is made for Windows only.
• When you have a use case systemd is not quite designed for, working around it makes it's benefits fade away - you are actually spending more effort implementing solutions than you'd spend if had no systemd to begin with.
• It's taking over more and more components, which, once replaced are left in limbo and undeveloped. Some have been forked and kept current but as often it does not happen. Which is hurting everything else not using systemd but using said components systemd has annexed.
• Debugging it's problems is more complicated because it being bunch of binaries. Peruse the source and it assumes you know your C.
• Annoying shit systemd keeps throwing up because wrong default settings. Mostly in regards of boot delays and network issues. You'll have to intervene manually. Sometimes it 'just happens' (because some dbus update making you either wait 90sec after systemd-logind or making you restart the thing manually). So, you have faster boot because of parallel boot and binaries, which gets bogged down due to bugs, shitty default settings or unforeseen shit breaking the sequence (same systemd-logind example) and putting you into long timeouts.
• Wrong approach to development. Feature creep. Ignoring bugs. Shitty "I can do no wrong" attitude from devs (Sievers). It's code should be seriously audited, overhauled addressing all the bugs people have reported BEFORE starting to add new features again.
• It will eventually make Linux either Windows-like uniform, where differences between distributions are pretty cosmetic or takes it gradually over completely supplanting even the kernel.
• I am of two minds about binary logs. At one side, binary logs are faster to index and search etc. On the flip side, corruption would screw it up instantly.
• systemd replaces significant part of the GNU Linux and creates new APIs. It's not really problem of systemd itself, but once other applications start depend on the said API's you would need systemd to use it. Or start developing shims to emulate systemd. Which might be not that trivial task.
• The problem with systemd is not that it is exactly "bad" in itself. Lots of worse software out there. Systemd is relatively competently programmed. And it's even useful!
  The problem with systemd has always been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU/Linux become a great system: that it wasn't really one system. It was bits and pieces, and you could add them together however you wanted to get something you liked. Systemd is the exact opposite. It is inflexible and clunky, monolithic, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. If it allowed proper flexibility in it's design without forcing it's users to go "systemd-Way" or drop it, everyone would love systemd, because it has plenty of useful features.