/tech/ - Technology★

It's not. It's just computer cancer.

>>1021327 (OP)

It's not botnet in the definition of being a botnet.

It's botnet in the 8chan definition/interpretation of being a botnet.

It's botnet because because it's a unjustified forced piece of software pt into multiple distributions with a lesser gpl license, developed by a corporation who uses non sane per default options or insane designs schemes or again people in debian compiling it with non sane tags.

Install Gentoo.

Not really. It's just big and badly coded, and the developers have made some insane decisions that resulted in even fucking Torvalds yelling at them.

>>1021327 (OP)

It's just a startup script system that only start daemons is separating kernel calls from the rest of the eco-system.

The next step is replacing the kernel.

It's unbelievable how in some respects systemdick improves on other init systems, like sensible unit files and timers, while in other cases it completely shits the bed, like having an unmanageable blob of binary logs or waiting two minutes per service that doesn't feel like shutting down.

How can you fuck up so badly designing a new system with access to 4 decades of prior work?

>>1021333

>It's not botnet in the definition of being a botnet.

Is it networked?

Yes.

Does it have critical vulnerabilities?

Yes.

It can be used to botnet.

>>1021405

>and timers

Timers which force the system to idle for 20 minutes during a shutdown because it doesn't kill what doesn't die within a set time.

>How can you fuck up so badly designing a new system with access to 4 decades of prior work?

<Because it was all flawed.

<Why would you want to use a flawed piece of software as the conceptual foundations of the SUPERIOR NEXT GENERATION INIT SYSTEM?

Boittering's core design philosophy is: I don't give a fuck what you need, I'm doing it my way. I'm also a genius programmer that doesn't make mistakes ever. Bugs are features.

>>1021405

>access to 4 decades of prior work

assumption: systemdick devs were not fresh-faced uni fuckboys who never, ever bothered to learn what Unix is or why it was good. They were. They never bothered to learn from the existing systems because they assumed they were smarter and knew better.

Linux is fucked anyway. Let it go. CoC pozzing in progress. Systemdicks hacking away at the core foundation. Dipshits actively sabotaging core utilities to hamper a stable binary interface (GPL masturbatory purists), not a single useable and stable desktop manager. When win7 is better you know you are fucking the dog.

>>1021405

You can have logs written as plain text if you want to configure it that way.

>Dipshits actively sabotaging core utilities to hamper a stable binary interface

What did he mean by this?

It's not a botnet, it's just stupidity incarnated.

The closest you can get is the fact that is uses google's own dns even when using a vpn, causing massive fucking dns leaks.

There are other such things, like how you can use a systemd function to delete the root filesystem.

Someone really needs to write down a full list of retarded shit this thing has done.

>>1021411

>connection cable connects to the network

>it has cirtical vuls

HOLY SHIT ALL CABLES REALLY ARE BOTNET!

>>1021327 (OP)

Absence of evidence is not evidence of absence.

its giant funnel that ties components together often for no reason

like Windows 10 has its services tied together somehow, so if you try to get rid of things you dont need, it keeps resurrecting them and starting them up, that didnt happen so aggressively or at all with Win7

something similar is happening with systemd, it ties everything together to take control away from you

The issue is less about systemd being botnet, and more about systemd being hard to audit, forced on users, poorly encapsulated, and developed by untrustworthy individuals.

>>1021445

almost true, if you consider antonymous nation state actor dragnet to be botnet (which yes that is not the real definition).

sytemd's timers are for people that somehow never heard of cronjobs, which contrary to systemd's approach of reinventing the wheel, (badly) actually have sort of a standardized way of how to do them between them and are in some cases even transferable between the different daemons that exist. Personally I use fcron with runit, which also doesn't expect my computer to be running all the time to work properly. You have to be an absolute brainlet to not be able to wrap your mind around crontabs, especially with the sheer amount of documentation that's out there.

The funny thing about systemd is that one of the reasons it was claimed to be written for (quicker startup, as if that even fucking matters in any way) it doesn't really fulfill anymore, there are much simpler init systems that are a lot faster in booting and shutting down. It's literally not better at anything, you just have to learn the ass-backwards way the scripting of systemd works which is knowledge that isn't even transferable onto anything else as it only applies to systemd and also might be outdated and pointless any release as the devs of systemd don't deem it necessary to stay backwards compatible.

On top of that, it has a bunch of shit added to it in some flurry of developer ADHD that plain should not be in an init system. Shit that's interestingly also not easily removable, seemingly on purpose. The last one reeks of politics and Red Hat shenanigans, especially observing how aggressively systemd was marketed (I'm aware it's free but it's so aggressively shilled that it reminds of the strategies of the likes of Microsoft in the 90s) and how aggressively it's incompatible on purpose with stuff or doesn't let other projects use parts of it without pulling the whole blob in. That's where the conspiracy theories come in. I think it's much more mundane than that and Red Hat simply made a push to control the Linux userspace and wants to turn it into an unmanageable mess like Windows is to secure support jobs.

Re: The parallel start and deaemon dependency meme: This interdependency programming in inits so that daemons don't fail when specific conditions are not met is solving the problem from the wrong direction. A well written daemon acts gracefully if the resources it needs are not available (yet) and I am personally not aware of a single one that's so garbage that it doesn't. Even OpenVPN patiently waits and retries until a network connection is available. If you find one, you better should seek an alternative instead of writing a mess of an init system around it, or bug the developers and ask them why their daemon is garbage.

Even most normie and pajeet computer janitors seem to start to realize that systemd is kinda garbage but they have now invested time in it and inertia is big in IT, so I guess we'll be stuck for it for a while, no matter how much more garbage it becomes.

you also have to realize that corporate endeavors like red hat live from reinventing the wheel. If they make a product that just works well and doesn't need maintenance, they're out of a job. That applies to any industry and to capitalism in general.

>>1021500

>The funny thing about systemd is that one of the reasons it was claimed to be written for (quicker startup, as if that even fucking matters in any way) it doesn't really fulfill anymore

The optimized startup is to support the whole containerization/microservices fad. In the olden days you basically never reboot your linux box so startup time was irrelevant like you said but since spawning containers on demand became a thing so arose the need for a new init system.

>A well written daemon acts gracefully if the resources it needs are not available (yet)

> If you find one, you better should seek an alternative instead of writing a mess of an init system around it, or bug the developers and ask them why their daemon is garbage.

You're looking at this from guy-in-his-basement perspective. In the corporate world you have no control over shit your boss wants running on 100s of machines. So Redhat providing a robust init system that can handle shitty init scripts is actually providing value to customers.

>Even most normie and pajeet computer janitors seem to start to realize that systemd is kinda garbage

There's a big difference between garbage and solving problems you don't have. It is regrettable that so many community distros did the easy thing (from a packaging/maintainer perspective) and went with systemd instead of something more suitable for home/personal use. They are the ones you should be mad at.

>>1021534

>In the corporate world you have no control over shit your boss wants running on 100s of machines.

that is not true, but if you are a low level pajeet then probably yes.

problem is that if you have running the same thing on these machines for a decade, then vendor decides to push bullshit from upstream, what can you do?

you wait and see.

the vendor gained trust over the last decade, so you rely on his decision.

and so you wait and see.

you make stats of failures, analysis and decide how much money you've lost by their decision.

then you make educated call.

this could take years.

but once the trust is lost, it's hard to gain it back.

problem then becomes, who could replace vendors such as redhat or veritas.

>>1021327 (OP)

>needing to unironically ask

>>1021333

>It's not botnet

>>1021331

>It's not

>>1021338

>Not really.

>>1021443

>It's not a botnet,

/g/ancer

All is botnet. I warned you, but you didn't listen. You should have listened.

Poettering is a glownigger hired code monkey which is why systemdicks was shilled so heavily. No-brained-nigger-cattle who can't into-command-line loved it and stuck it up their ubuntu.

I wrote a fuckin' boot loader. F to the compiler man may all his makes be gdb free.

>>1021815

I can't post the proofs. Glowniggers fsckd my drive.

Terry says they glow in the dark, and I wrote frickin' bootloader