Sup guys I just pwnd j00r linix boxens with tweet lol

...

...

Thread unlocked again, sorry.

It's just saying that the command is small enough to fit in a tweet.
It's really no wonder that foss fags produce nothing useful when they're this stupid.

nice reality bubble trips.
Enjoy your AIDS, er, I mean NSA.

I am really afraid of the future for Linux.
It seems like once Linux got popular with the cool kids, everyone from Trannies to NSA had to jump on and start fucking it. It's almost like it was a buffer to protect BSD from all that shit.
Personally I don't give a rats shitball what OS people use, in fact it's mlulzy af that most people use Windows. Vast wasteland of sheep to plunder. But I dirgress. "Sekret Klub" is a meme, but I do prefer to use something "different". Not for "difference's" sake, but a system tailored to what I want. Linux is on the precepice. The waves of shit are getting higher. I actually have GConf on my system. I don't use it but it "has to be there" freedesktop.org are motherfuckers. I wish they were never born. Don't get me started on Licknerd Pottofshit.
My current OS is like a waifu. If she gets systemdicks I will have to leave her.
But switching to BSD is scary.
Can you help me, OP?

Debian still has support for other init systems. I don't think Slackware will lose it any time soon.

gayest post on tech

Oh no a dos bug that requires user level access. Pro-tip: if you have user access you can probably do way more cool shit than waste your time dosing the box.

...

It's not so much the command itself, but rather the nondeterminism of the software and the fact that any unpriveleged user can cause this much chaos.

Nice, like what?

lmao open sores

I'm not OP, but I started with Slackware in 1995, because I was interested in Unix. If the situation was like today, I'd have passed entirely on Linux and just stuck with DOS, or switched to OpenBSD much sooner.
I think your biggest hurdle will be hardware drivers. It doesn't have as many as Linux, especially not Nvidia or other closed things. Try it out by installing on a separate USB disk first, to see. Check the faq on website first, it's very good. There's also a nice book. If you're already used to the command line, it shouldn't be very difficult. It's just a matter of becoming familiar in how OpenBSD does things.

You can list files for example

TY user.
Another thing maybe you could answer.
I'm on Slackware current, so I treat it like a rolling release. Been a few months like this and I really like it. D
Do you use current on OpenBSD?
If so how do you like it, if not, do you find it a PITA to install from scratch every 6 months?

Sekrit club is not a meme; mass adoption really does ruin systems because they get swamped in stupid demands by idiots.

tedunangst.com/flak/post/this-is-why-software-sucks
harmful.cat-v.org/Blog/2013/12/23/1/

Not that guy but I have no issues of doing install once a month. Basicly I just grab the sources and leave the box to compile comeback and reboot. Finally just run sysmerge. It just werks

Fuck once a six month I meant

REEEEEEEEEEEEE FUCKING NORMIES AND THEIR NEEDS

SOFTWARES SHOULD ONLY CATER TO MY HIGHLY SPECIFIC AUTISTIC NEEDS

I normally just use OpenBSD stable branch, and then upgrade when new release comes out. You can also install from scratch, but the installer lets you upgrade in place as well, and it's pretty convenient for me that way.
I did run the current branch for some time several years ago (it fixed some hardware issues). That was pretty easy too, because I just grabbed the binary snapshots every now and then and did the same "upgrade" thing with those. Didn't have to compile anything. But normally I just use stable, because I don't like to mess with my OS that much.

So you're running stable I guess?
Well, how long does that take estimated on a mobile core2duo? Even overnight would be OK I guess, but do you have to be connected to internet that whole time?
Do you keep your user files/configs/etc/ on a separate partition, or just don't worry about it?
And also if you or anyone runs on a Thinkpad, how is power management?
I would like to run cool and low freq as possible most of the time.

Thanks to you and
for answering because it's hard to find discussion like this on a formal forum-type site.

How is TrueOS in terms of nvidia/amd graphics support?

you fucking hipsters never change

If yoiu knew anything about Linux you'd kow that's not the issue.
Did you run Debian in 1998? Then you know very little about how much it has changed. Linux is turning to shit. The desire to move away from it has absolutely nothing to do with popularity/rates of adoption/useability.
In short, you don't know what the fuck you're talking about.

It just works

It's funny that most people whine about a software not being able to do enough and when finally it is they whine about adoption rates.

Of course this is Holla Forums and the majority of people who piss their pants at the sight of "normies" are very high. Likely, these are the same faggots who tool their system to such extents they should make their own OS, but they don't because they don't know anything more than the average "normie".

Funnily enough almost all the security tooling you could need for a computer could be done on any OS except maybe systemDicks Linux :^) with a firewall, an anti-virus, and some common fucking sense. But of course it's all the normies causing these problems and not my inability to use common sense security measures REEEEEEEE.

Hardware has changed a lot in the past 20-30 years. It's not very fun to write OS anymore, at least not if you want it to fully support modern hardware. Even Terry Davis has set limits for himself, or it would be an impossible task (and a stupid one to even contemplate, since there would be no fun in it whatsoever).
Meanwhile you have threads here about 8 or 16-bit computers made from wire-wrapped components, or even modded arcade boards. Those are what computers used to be about: fun, relatively simple & accessible for hobbyists, and a good way to learn. In other words the opposte of modern computers, where you need a 1000-page spec sheet just for the CPU alone, and let's not even get into GPUs, USB, etc.

Then stop whining when operating systems are designed to work universally and then have problems due to complexity and size.

you need to step up your game if you're gonna bait anyone.

Boy, you sure are dumb. You probably also think you can just start a business and sell OS that competes with Windows, and not get instantly crushed. Have fun wasting all your time and money for nothing.
Meanwhile, I'll just use old 8 and 16 bit computers for fun hacking, because the new stuff isn't worth my time or energy, except to use a a shitposting platform or access a couple websites I need to for adminstrative reasons.

no you are just stuck with your run of the mill lowest common denominator choice.

Enjoy your botnet and the NSA laughing at your porn wincuck.

Does this mean no one is testing every parameter of every command with a large number of different values? That kind of thing can and is automated by competent developers and testers. Anyway, surely this must mean there are thousands of similar vulnerabilities in systemd?

Awesome shit man.

You're a fucking faggot. Kill yourself.

I'm glad I've stuck to FreeBSD

This is the state of Holla Forums today.

It has nothing to do with twitter, the article in OP is clickbait faggotry and a excuse to bash systemd. I gotta give it to him though, he was dedicated enough to find a bug to make the post. For that alone gets my respect.

You do realize that a single malformed ping packet can bring down an entire Windows system, right? The problem with systemd is that it makes Linux more like Windows and brings in these Windows-like issues.

This. I still don't understand how twitter comes into this.

So now everyone gets to see you have no actual arguments, only emotion like the little baby that you are mentally (even though you're probably an adult).

Yeah the divine and pure gnunix never had issues like that.
fanboys are so retarded holy shit

You are the testers, if you run potteringwares.

I seriously hope you've never owned a system which you've had to maintain all by yourself.

Only if the system has piss poor security. Go on, find a free shell somewhere (they exist) and go and do "way more cool shit" then.

Or do you mean mining bitcoins? Enjoy having to timeshare with a thousand other users. Proxying your traffic? There are a more free proxies out there than you can shake a stick at.

Christ, Holla Forums though I'm pretty sure this is just one moron being loud, learn at least the basics of security.

Is this bait?

Please offer examples next time and you might be taken seriously.

Notify shits the bed on a fucking empty string? Are you serious?

How long has this been around for?

My core2duo laptop compiles -current in about an hour. Only thing you would likely want to connect to the internet for is updating sources over C V S. You can also just updating using snapshots which only takes a couple minutes. Thinkpad power management just werks. I get worse battery life than with linux.

Fuck off redhat employee

That compile time estimate does not include xenocara, I update it less often.

It is what it is, 90% of the things he says there have nothing to do with the bug.
I don't give much of a shit about systemd.

Still waiting for that "way more cool shit", wunderkind.

Total bullshit. If you are the centerpiece of a large community you are part of something bigger than yourself and need to lose the ego. Look at the LibreBoot fiasco. Now we have to use coreboot.All that because of one tranny faggot who couldn't let go and think about the bigger picture. Is RMS a fucking atheist commie Jew who has a mental love affair with Emma Goldman, an anarchist Jew deported from the USA back in 1920? Yes. Is his idea of free software and freedom 0 able to transcend that? Yes. We don't need a future of walled gardens and what you are trying to justify is a walled garden of the ego. The main developers can scream, you way of making comments is total shit and needs to die, but this is just so much intellectual laziness on the part of guys like Linus. Just run an automated script to reformat the comments to the community standard before check-in and stop being such a fucking prima donna, holy shit. The free software movement is more important than a few egos.

While I agree with your idea maybe you should get started on losing your ego namefag.

This, although it's not so much the amount of users as the competence of the average user: a community of pajeet-tier users will beget pajeet-tier software and viceversa.

I mean, it doesn't hurt to expect some minimum competence and common sense from your users, instead of having to wipe their asses and spoonfeed them.

Thats the joke

Fucking autistic neckbeards. They made Lunix so hard and ugly. Fuck them. Only my use case matters, so everyone should cater to me, the average tech-illiterate user.

Why is CLI still supported? It's archaic and hard. It should be phased out in favor of more modern, intuitive, simple to use GUIs. Only dinosaurs use terminals, shells, and scripts anyway. And why do programs need so many complicated settings and configuration files if the defaults have always worked for me?

PS: ssh sucks balls. I use TeamViewer instead so I can view the desktop and use the mouse, plus it's way easier to set up. :^)

Voice control or gtfo

pleb

Shit like this happens on a weekly basis in systemdland. Has been the case since the first version.

This. Early y2k linux actually worked even though it had issues with hardware support.
Nowadays it's such a broken piece of crap, it's beyond pathetic. Even the kernel itself is fucked, although the greater part of the issue is in the software ecosystem.

Maybe redox, genode or fuchsia will save us. One can only dream.

https:[email protected]/* *//how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d

Gets btfo in this article.

Yet again, anti-systemd retards don't know what they're talking about.

anti sysd shills btfo

It does seem seem like the OP post found a bug and took the time to rehash all the same retarded and wrong arguments against systemd.
Like the "requires a reboot to upgrade" bullshit.
Nah, just requires a re-exec. State is serialized and deserialized with the re-exec.
Shit like that, it's clear that we're dealing with autists vs people actually deploying systemd like Cisco and Facebook, who never experience the issues that the autistic "critics" say they will.

The "no you're projecting" defense? Pathetic.

zozzle

He's got good points about the tone and vagueness of the original complaint, but I don't think he's addressing the fact that problems like this should be minimised for system-critical services. By that, I mean systemd should fork out just a little more so that the meat of it can be restarted without rebooting the entire machine. For as long as PID 1 is not a naïve process reaper, they're playing a dangerous game. Anything else should be forked.

He does say

systemd actually does plenty of forking already. It could be better, and Strauss acknowledges that, but the original post describes it as a fatal flaw rather than something that hasn't been perfected yet.

Are you unable to fucking read?
All of systemd can be restarted without rebooting.
You can re-exec PID1. The state is serialized, and all events are waiting for you on the other side of deserialization thanks to the same methods that allow them to agressively parallelize boot.
What does systemd-notify having a slight security bug have to do with the implication that systemd cannot be upgraded without rebooting, anyways? It's total bullshit, but it has nothing to do with the fuck-up itself.

Maybe you autists should stop repeating shit you heard from the other big anti-systemd autist, the Musl developer, without verifying the claims.

Since 2015
github.com/systemd/systemd/commit/d875aa8ce10b458dc218c0d98f4a82c8904d6d03
Only a problem as a result of
github.com/systemd/systemd/commit/5ba6985b6c8ef85a8bcfeb1b65239c863436e75b

But, again, to be clear, this bug isn't terribly irredemable. It's only being made a big deal of because the autist who found the bug saw fit to rehash every other retarted criticism of systemd in his 'report' of it, because he seems to have brain problems.

Systemd shills everyone.

What are you going to do, GDB it and call execve?
You can't rely on a crashed program to be able to fix itself.

Because if you could just restart that one fucking component when it crashed (or when the bug was fixed) it wouldn't be nearly as big a deal.

Nice unfounded assumptions

This is true for the local denial of service vulnerability, not so much for anything else.
systemd (PID1) and every other daemon like logind is restartable, PID1 itself through a re-exec.
If it has crashed, everything continues running until reboot. Of course, that will be a dirty reboot.

Again, these are not issues people run into regularly. For all the bitching about 'muh complexity' and the grave warnings from this retard and the Musl developer, you'd think PID1 would be causing havoc the world over and bringing networks to a standstill. Except that doesn't happen.
You're drudging up the same bullshit in the article, fed to you by a fucking retard who thinks that the magic 'modularity' fairy can make crashing obsolete in the context of a service manager.
This is not to mention that the flip side of modularity, the overall complexity of interactions and authoritative issues if you took everything out of systemd's PID1 besides 'management', which is what the OP's article wants.

The modularity fairy doesn't exist, and everyone who claims it produces stable, simple software does has never done it. One only has to look at Hurd to see how hard it is.
And note, none of these criticisms are ever levied towards Solaris or OSX. No, it's always the fucking autists whining and telling outright lies about systemd.

It's only restartable by killing every running process i.e. by rebooting. Kill yourself shill.

And one only needs to look at his suggestion of "rewrite it in Golang/Rust" to see that he's a fucking retard with an axe to grind, let alone the repetition of outright lies in the article.
Of course, it's so simple, systemd just needs to be written in a language with a GC or something younger than when the project started, that should solve all the problems.

No, systemd can be re-exec'd without killing everything. That assumes it's still running.
In fact, assuming there's no weird changes like the recent vconsole or tty change, a user won't even know that PID1 has been re-exec'd. And even that was fixed in systemd, you'd never know that yum/dnf re-exec'd systemd in the background unless you looked at the logs.

s/running/correctly operating/
It's kind of useless letting something re-exec when the most urgent use-case for that feature (i.e. when it stops working) isn't covered.

Yeah. Even broken clocks are right twice a day though.

The most urgent use case is upgrading.
No one fucking experiences crashed PID1. Despite the assertions from the autist who wrote the OP article, yourself, and the Musl developer, it does not happen.

Tell me, when you modularize everything out of PID1, how does it magically make everything immune to crashing? How does it magically solve authoritative problems?
You now have almost a dozen moving parts with information the service manager needs, with a shitload of complex interactions and "non-standard" interfaces that autists complain about.

Yeah, nah.

This article is just a retard who happened to find a bug and didn't report it in good conscience.

I really fucking hope that someone does the same to his heap of shit Content Manager System written in C++. Maybe someone should have told him to use Rust.

It does not. It merely makes it recoverable.

Relative rarity is not a good enough reason to ignore an obvious fix to a large class of potential problems.

Pretty sure these complaints are valid if there are existing standards. If not then nobody cares.

Only if you're a 400 pound linux user who just switched over from Windows or OS X cancer and want to throw UNIX out of the door.

You can't restart PID1 stupid

Ah, but it doesn't.
See, it merely guarantees that the DoS of PID1 will be done through non-standard interfaces and complex interactions.
This isn't a fix, you fucking retard.
In the article above, it clearly points out that in every case where there are existing standards, systemd uses them.

Linux isn't UNIX, and systemd is 'modular' in its own right. As I said, the only things that aren't 'out of' PID1 are information the service manager itself needs to, ya know, manage services.

You can daemon re-exec systemd. Pretty sure it's done by default in latest Fedora, probably last version as well.
Re-execs with the upgraded libraries and executable and preserves state.

Either way it's pointless to argue at this point because it's the same fucking thread with the same retards as usual.

What the fuck are you trying to say? Nobody cares how "standard" a DoS is, only how recoverable and preventable it is.
Then s/fix/workaround/ and try re-reading.
So? If there's something to be complained about, then listen to the complaint. If not, then there's no point getting worked up about the complaint.

Though, off the top of my head, systemd timers do not follow the existing standards for crontabs, so stating that systemd follows existing standards where possible is demonstrably false.

Which modularity would not solve.
We're talking about information the service manager needs at this point.
Modularizing and taking out all of the things in PID1, which autists like you don't even know what's in there because you are fucking incompetent, is not a workaround.
No one's getting worked up. I'm simply explaining to retards like yourself why the modularization fairy does not exist, especially in this context.
Systemd timers are in the service manager context. Crontabs are not declarative, so it would not work like that. In addition, you just suggested adding more potentially unstable shit to parse into the libraries for PID1.
Ironic, really.

Timers are not part of a service manager. That is why cron exists as a standalone entity.

Services are managed by a service manager. A timer can start a service, but it does so by asking the service manager.

There is no reason systemd cannot do the same.

I fail to see how they're not declarative. They are declarative in the same way that systemd service files are declarative, which is to say that if you ignore the command they're running, the entire file is completely declarative.

...immediately after having suggested that it should fork. Well done.
Make your mind up though, are you for or against parsing things in PID 1?

Crash recovery is done by everything from firefox to postgres, there's no reason it's not possible. I'm not saying it's an ideal solution, but storing state in /dev/shm wouldn't do any harm.

I like how your argument is systemd is so reliable that it crashes SO OFTEN that restarting PID1 becomes necessary.

Timers are what a service manager practically does. It's just a nifty feature that can replace cron, but doesn't have to. There are many cron daemons, and even compatibility layers that can read crontabs and generate a declarative timer in the format that systemd expects, instead of having different formats.
Are you for or against parsing thing out-of-process that might return unexpected values to PID1?
It's clear that you don't even know what 'parsing' entails in this context. It's why nobody should take people like you seriously.
It's almost like you don't even know what the fuck we're talking about here.
When PID1 crashes, you're done. The whole system comes down. Technically, in this situation, systemd experienced DoS thanks to input it did not expect. In fact, it did probably the best thing, which is not crash in this situation, which would've been an immediate dirty reboot.
Again, no point arguing any further. It's clear that you are fucking retarded and have no idea what's going on here.

systemd can already serialize and de-serialize state, I already detailed daemon-rexec to you. You can keep claiming that the modularity fairy exists all you want, it's not going to make anyone who knows what they're talking about listen to you. At least, I hope not, because it'd make things worse, and you'd be rambling that you were right all along.

re-exec is mostly for upgrading.
Again, PID1 doesn't crash, or systems would be coming down with it. In this case it was just a DoS, which needed a potentially dirty reboot after being affected.

Just another day on Holla Forums. And then I'm reminded that I'm probably arguing with NTTEC street shitters.

Not to mention that this situation is exactly what you wanted. There was an executable that parsed and it gave the value to PID1 over a socket. It happened to be an unexpected value after not taking into account previous changes, when making the change that zero-length notify messages were okay.

freedesktop.org/software/systemd/man/systemd-notify.html
github.com/systemd/systemd/commit/d875aa8ce10b458dc218c0d98f4a82c8904d6d03
github.com/systemd/systemd/commit/5ba6985b6c8ef85a8bcfeb1b65239c863436e75b

I'll give you some homework. How would the modularization fairy fix the increased complexity locking, concurrency, communication when it comes to information the service needs when you 'split up' shit out of PID1. As it stands, it's currently single-threaded because it needs to deal with none of this.

Protip: it can't. It will dramatically increase complexity of PID1 by orders of magnitude, just with the """"""simple"""""" act of doing what the autists ask.

I'm half-tempted to write a bot that mimics your posts so you don't have to go through the trouble of spamming threads with them yourself. Shouldn't be hard since you have two stock phrases and not much else.

Not him, but I wrote a bot that posts on Holla Forums just for fun. Its not that hard, I used BeutifulSoup for getting replies of text to send to Chatterbot

I'd post it but I fear it'll end up being abused by spammers

why didn't you write it in c? oh right because you can't.

Wat, this should have been detected immediately with afl. Are they really running shit as root that haven't been tested against afl?

>https:[email protected]/* *//how-to-throw-a-tantrum-in-one-blog-post-c2ccaa58661d

Interesting, let's see what coverity says:
scan.coverity.com/projects/systemd
Well, 0.08 defect density is pretty good. Wait, 7 high severity defects? They haven't run a scan for half a year? It started out with 828 FUCKING DEFECTS, which would result in a defect density of AT LEAST 2.5 and most likely notably higher?

Why is this shit on my system? That's worse than my code and my code doesn't run as fucking root.

Why didn't you poo in the loo? Oh right because you can't.

Your code doesn't run at all because you are just larping as a programmer.

If you're not programming in C you're just larping.

nice meme

F
O
R
K

I've said that countless times, how hard is it to remember? Do you have the attention span of a gnat?

You're the only one that has brought up parsing. I haven't said a single word on the subject. I don't know what wild delusions you're pulling this from but the argument you're having and the argument you think you're having are worlds apart.

This is not crash recovery. Crash recovery would be updating the stored state at the earliest possible opportunity.

Complex locking, concurrency and communication like "systemctl start multi-user.target"?
There's no need for "complex locking and concurrency" just because a service manager is separate from the init daemon. That has never been the case.
Can you demonstrate that complexity?

On another note, is all concurrency "complex" to you? A lock is about the simplest and easiest to use device for getting around concurrency issues and if you think it's complex you need a lot more practise.

>github.com/systemd/systemd/commit/d875aa8ce10b458dc218c0d98f4a82c8904d6d03
So he adds a commit that supports zero-size messages and doesn't immediately think "I should write a unit test for that"?
That's just laziness.

At least learn a modicum about the technology you're trying to shill before outing yourself so grandly.

To elaborate on the forking, since you might be dense:
systemd --system --deserialize 50├─ systemd --user├─ systemd-logind├─ systemd-udevd└─ systemd-journald
Why can this not become:
systemd --system --deserialize 50├─ systemd --system├─ systemd --user├─ systemd-logind├─ systemd-udevd└─ systemd-journald
--system even exists already:

Am I a shill for forking?
Am I a shill for systemd false-flagging for anti-systemd?
What are you trying to say?

Thanks Mint 17.1, Mint 18 is supposed to use systemd tho.

That's not complex. Again, systemd is single threaded, it needs to deal with none of those so far.
Except, there does, when you consider systemd's use case. Just listen to the ramblings of retards like yourself and what you want them to do, which they'll never do because you actually don't know what you're talking about, and you'll see that all of the vague requests all lead to PID1 complexity increasing dramatically.

How did you not know that when PID1 goes down so does the rest of the system? Are you just larping as a Linux user or are you truly this incompetent?

Great counter argument.

Just another typical poster in these threads that thinks a bot is anything special.

The only one whose dense here is you, really.
You strike me as a FreeBSD faggot. Did I hit the nail on the head?

Forking for crash recovery, with the service manager in non-PID1 is also very complex. Much more complex than anything systemd does right now.
To do so, as I said, you have to introduce a bunch of complex interactions between two instances now, PID1 and the manager, and any and all executables that are seperate. You're still going to have unexpected input.

Again, you've solved nothing. All you've done with the modularization fairy is increased complexity.

You know what solves the problem, even before it existed? An OS that doesn't have systemd or other lennart crapware. It's so easy, if you just avoid the bad stuff instead of trying to compromise or adapt for it.

Then feel free to user another operating system or make your own distro.
No one has to pander to your autistic ramblings.

This. Install Gentoo.

That's the idea.

Pray tell?
Oh, you mean you pulled that all out of your ass after stringing together a bunch of hypotheticals that you associate with arguments sometimes made by people who you think are like me. In other words, none of your rant there was even close to a coherent argument, let alone a valid point.
Because once you fork, you've moved away from pid 1! How hard is that to understand? I'm seriously doubting your linux knowledge here if you didn't even know that much.
Other than having been in charge of a PFsense firewall before, never touched it.
[citation needed]
Okay, how is the initial startup where PID1 hands off the desired target to the service manager a "complex interaction"? It doesn't even need to know the result of that interaction. It doesn't even need to do anything but reap processes at that point.
If it does, prove it! There's no reason a non-pid1 service manager can't do everything the current pid1 does with the exception of reaping processes.

modularization fairy modularization fairy modularization fairy modularization fairy modularization fairy modularization fairy!
Does that feel good?

You still have completely failed to even hint at how the complexity might be increased in any concrete way.

I wish someone said this before the entire internet started using Javascript.

No, that's not the idea.
You have no idea whatsoever what kind of complexity is involve in splitting out the rest of what's in PID1. You don't even fucking know what's in PID1, because you are incompetent. It's exactly how you wanted it to be, an executable parses the message and gives it to the manager. It happened to give the manager an unexpected input, which caused DoS, but it didn't bring the system down.
You're in this very thread, making the same exact calls to 'muh modularity magic will solve everything and make it less complex.'
'JUST TAKE EVERYTHING OUT OF PID1 AND PUT IT SOMEWHERE ELSE IT'S SO SIMPLE.'

Okay, so this is the crux of the argument. It's why you are totally ignorant of anything going on under the hood, and why your opinion amounts to dogshit. I will give you a serious answer:
You cannot split systemd this way. There is no way to set `PR_SET_CHILD_SUBREAPER` on a non PID1 process. They would have to report to PID1.
What you're asking for is, basically, magic. You're trying to pray to the fucking modularity fairy because you have a mental illness. Get it through your thick fucking skull, dipshit.

You increase complexity of systemd dramatically by having to tack on concurrency, locking, and additional communication by championing the calls made by retards who have no idea what they're talking about.

This isn't even getting into the question of, who will reap systemd? It will have to have a permenant copy of its state, and all services. This is impossible to maintain and guarantee that the state is complete, correct, and uncorrupted.

How systemd is now, is much simpler than what you're suggesting.

This situation, in which an executable parsed and then passed the message to systemd, is exactly what you wanted. And you still fucking complain.

When are you faggots going to get it through your thick fucking skulls that systemd is not the boogeyman that the autists want you to believe it is? Hopefully it's right after you realize that most retards opining on systemd and how you should 'JUST SPLIT IT UP' with a fucking magic wand are actually asking for more complexity, not less.

And just before you reply, no, you either keep return codes in systemd or you increase complexity again through unnecessary communication.
And, again, you cannot set `PR_SET_CHILD_SUBREAPER` on the newly spawned systemd process. All reaping functionality would need to be in PID1, return codes and state would need to be communicated, dramatically increasing complexity from the current status quo, and complexity would again be increased by having to reap systemd itself, having to preserve state, and having to guarantee that state.

So again, no. Next time you try to opine on shit you don't understand, try not to listen to autists who jerk off to Rob Pike.

I'm sure a lot of people warned about the dangers of forcing javascript. It was pretty common to test web pages in Lynx back in the 90's and even early 2000's.
But of course their warnings fell on deaf ears, just as people who warn about stuff like systemd. But at least with the later you can switch OS and avoid it entirely.

And yet some pajeets on here are trying to convince us that we can trust our machines to run the code written by these bozos

It is

I noticed this when I was writing for the Win32 API a few months ago. Seriously, how the fuck do people do this for a living and not want to kill themselves? I spent more time looking up tedious arbitrary boilerplate than I did writing code

I agree that the Win32 API is terrible, but how is it related to hardware complexity? Microsoft's madness is manmade.

Following thi retarded autistic logic:
How to crash any Linux system with a tweet
rm -rf /

Therefore linux sucks, use windows

Oh, you poor thing. I am glad you didn't have to go through this.

gb2readingcomprehension101

IE7? Lucky you.

Not an argument

hasn't worked in years, fam.
you want

Joke's on you I use Runit.

Not sure why Poettering is always posting here trying to defend his broken software

not an argument

Not an argument.

The actual arguments are up thread.
I'll summarize them for you:
1) systemd already does what the autists want them to do: an executable parsed and then passed the message to systemd.
except, systemd wasn't expecting empty input, thanks to a commit before from 2014. this was the cause of the DoS, not systemd parsing unexpected input itself, an oversight.
2) you drastically increase complexity needed by going the route autists want them to go, despite the fact that they claim their method is a net decrease in complexity.
3) you cannot guarantee complete and correct state of the manager if you split off everything, like the return codes and reaping, into a seperate process.
4) you cannot set `PR_SET_CHILD_SUBREAPER` on the non-pid1 process if it crashes, for example, so you'd have to introduce all of this complexity into PID1, which is far more complex than anything systemd does, or plans to do.

everything iffy is parsed with systemd generators. it's clear that you, and autists like yourself, have no clue what the fuck you are talking about.
as evidenced by the fact that the thread got real quiet when real talk was posted above.

A better metaphor would be a guy in the rain who needs shelter. He comes across a huge prosperous city that has everything he needs but turns it all down and dies in the rain because he can "be free".

There is no-one on Holla Forums who would be so autistic as to defend systemd this desperately. Hello and goodbye Lennart.

not an argument.
feel free to try again any time.

WEW

not denying your delusions?
why wouldn't I fuel them, instead?
not only are you incompetent, and don't really deserve to be posting on this board because you're probably a javashit pajeet, but obviously delusional.

but, again, not an argument.
feel free to try again.

The anti-systemd 9gaggers are some serious fucking cringe material.

There's a reason why tools, construction equipment, and military hardware are built as seperable components: because everyone has to be able to work on them, understand them, and reason about where the failures are. systemd did not take this route and the only people able to understand what it's doing are those that work on it. We shouldn't need the devs on a mailinglist to explain what's going on, it should have been obvious. This is a bad situation to be in with pid 1.
Every opportunity they had to make it easier to understand they rejected. For example, by using bound sockets rather than loopback, dbus messages can't be traced by people with tcpdump/wireshark experience. How many people even know how to trace dbus messages without going searching for docs, show of hands?

Yeah and that physical analogy doesn't apply.
You can fully understand what systemd's PID1 does. Go take a look. I doubt you can read C though, let alone write it.
Are you fucking retarded?

$ sudo tcpdump -D | grep dbus
7.dbus-system (D-Bus system bus)
8.dbus-session (D-Bus session bus)
$ sudo tcpdump -i dbus-system -w dbus.pcap

Also, as has already been explained, you can't 'JUST MODULARIZE IT LOL.'
You don't want systemd? install a distro that doesn't use systemd.
It's that simple, you fucking retard.

Christ, now even retards that can't use tcpdump yet claim they can are talking shit. This thread is just sad.

Everything can be modularized. You have the kernel source, if something prevents it, change it. But you have no hope of doing that do you as you don't have the skill, and the kernel code offered by the systemd team was so shit it got rejected.

or you could leave loonix to the babbies and use a real os that doesn't load blobs into the kernel :^)

...

You would not be able to afford the entrance fee to that world, skiddie.

holy shit anti-systemd fags are fucking stupid

disk operating system bug?

...