/tech/ - Technology★

Literally nothing. Hating on it is just a neckbeard meme. Systemd just werks and faggots can't accept that the month they took to actually install gentoo with openRC were futile.

>>810817 (OP)

>whats wrong with systemd?

absolutely nothing. systemd is superior to every init/service manager currently available. anyone that says otherwise is a lying faggot

>>810817 (OP)

It grew far beyond an init system, that's the biggest problem with it, becoming a dependency for pretty much everything.

it takes over dns now too and defaults to google nameservers

nano /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

it apparantly was just "fixed" 4 hours ago and the issue has been open for 2 years.

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1449001

https://suckless.org/sucks/systemd

a summary by examples.

>>810819

>hugely complex blob assuming the function of absolutely everything is the best JUST WERKZ XDD

>installing gentoo is difficult

/g/o away

>>810832

>suckless

cuckmore

>>810833

nice argument fag

>>810837

>gif

>2017

gtfo pls

>>810817 (OP)

> wrong with systemd?

redhat

>>810843

Who are the people who think this shit, and make posts like this?

I cant imagine them, its confusing.

Systemd is a init system that is all encompassing. It is poorly designed in that the logging function is in binary and not able to be encrypted by a standard protocol with ease. This makes system debugging much more difficult. The init system itself requires you to use other tools and does not leave you with options. Such as a dns server in the init system that is not of your own choosing and dbus. There are many, many more bugs within the init and required dependencies for systemd then other init systems such as the recent dns resolver bug that allowed hijacking the whole system. Oh and on that systemd's init and other components are poorly documented. So you would have to go through the source code to see what is happening since there is no manual or the man pages are poorly written.

TLDR; it's pottering crap mystery meat

Bloat and tie-in. I recently added it to an embedded firmware and it required 30M of dependencies and several services wasting ram. I had to switch to squashfs just because of the init system. I wanted to trim it down but it's so tangled you can't. But I had to make the switch because we don't have the time to maintain the init scripts ourselves and distro maintenance is mainly focused on systemd, now.

Examples: if you try to remove systemd-logind (as this system has no interactive logins so I don't want to waste the space/memory), you'll knock out the case buttons as for some reason this component also handles ACPI events. If you try to remove systemd-journald (because every distro agrees it absolute garbage and you'll need rsyslog in a real box, anyway) everything catches fire so you just reduce its impact as best you can.

Also, debugging it is way harder. Rather than a simple bash -ex, you'll need to have strace on the box and attach to pid 1 (after quieting it down) while you trigger whatever service is having a problem. The resulting log you have to sift through is like some sort of joke. It's a couple thousand lines of every esoteric and pointless Linux syscall you can image before you reach anything resembling meat.

>>810858

>30M of deps

Holy shit I boot my entire system on less than that and I don't have a system optimized for size, but for speed. What the actual fuck?

>>810817 (OP)

Look up the SystemD "0day" username bug, and Lennart's response to it.

>>810817 (OP)

Nothing wrong with systemd. It does what it says it does. The init is not exactly that much better than upstart or OpenRC, but the collection of systemd tools do way more. Mainstream distros adopted it because it streamlined things. Less shit to maintain, less technical debt. People are paranoid and think Red Hat pushed systemd for control over Linux ecosystem. That's retarded. Most of the time the tool that gets most development and man power is chosen. Shitload of tools that are used daily by millions of users are almost abandonware in Linux world. That's disgusting.

I hate the opinionated way Red Hat/GNOME manages their projects (WONTFIX, "the users are retarded"), but they step up while others shit out the project and they do 1 commit per year.

There is no conspiracy. Just more people need to step up or shut the fuck up.

Lennart unironically gets fucked in the ass by black men on a regular basis too.

>>810870

>but they step up while others shit out the project and they do 1 commit per year.

You do realise the point of commits is either bug fixing or feature adding right? For a init system there's not many features to add. So the less commits, the less bugs being found and or fixed. For a highly used peice of software such as the init system having huge amounts of bug fixes means the devs fucked up writing their software.

How do you adress having to strace PID 1 before/during boot just to get a debug log? What about pottering declaring a 0 day a "won't fix" feature? What about the bloat that not everyone needs or wants to use something different?

>>810875

Is he an actual faggot?

>>810877

have you ever seen a picture with him and his girlfriend or any other female?

>>810880

No proof.

>>810882

i can't find any record of his google+ post, he must have deleted it. but in it while calling out all open source devs as cis white racist bigot males he makes a special point to say he's not gay. there's reference to it on the gentoo forums

https://forums.gentoo.org/viewtopic-p-7628742.html

>>810876

>For a init system there's not many features to add.

I was talking in general, how people shit on every project Red Hat develops/sponsors. Not strictly init system.

>So the less commits, the less bugs being found and or fixed. For a highly used peice of software such as the init system having huge amounts of bug fixes means the devs fucked up writing their software.

Objectively wrong. ALL software needs to be maintained regularly, especially in Linux ecosystem, since there is so much moving parts. If the software doesn't get at least 4 commits per month it is dead software to me. Maybe the very exception are Suckless-like tools, since they are so bare there is not much to do.

>How do you adress having to strace PID 1 before/during boot just to get a debug log?

Retarded, but I don't care, because it doesn't affect me on a daily basis. You can find some "quirk" for literally everything.

>What about pottering declaring a 0 day a "won't fix" feature?

He is being stupid, but how does that change the fact when you are objectively comparing the current situation of collection of systemd tools with alternatives? Alternatives are still shit for mainstream distros. Red Had did not decide or lie to get others to use systemd.

>What about the bloat that not everyone needs or wants to use something different?

That "bloat" is useful to the distribution maintainers. You are free to use something else.

What I usually hear from people:

<Oh no, b-but the my distro dropped support for other init systems. Wah wah, it is too hard now.

So people want for someone else to dedicate their time to cater to the autism of small minority of users. My advise to those people, do it yourself (install Gentoo). Stop using shit software (GNOME etc). If there is no "shit" software then write it yourself. Can't program? git gud

>>810870

>Shitload of tools that are used daily by millions of users are almost abandonware in Linux world. That's disgusting.

WHY THE FUCK?

Not everything needs to be in a constant state of flux, constantly being tweaked makes something worse, not better, shit that just isnt finished or needs constant bugfixes is worse than something thats feature co mplete and doesnt get any bugs, all else being equal.

There is nothing wrong with development on something being almost dead. Sometimes something is just mostly finished. Its BETTER when its finished and development stops than when it still needed regular changes.

>>810896

>Poettering is being stupid

How do you defend using a bloated init system that you acknowledge to be written by a stupid person?

Only a stupid person would use software written by a stupid person in such a critical role.

>>810901

This is the most retarded thing I have read in a while. It shows that you are LARPer and have done and probably serious development yourself.

There are countless examples of minimal software that is considered finished or at least feature complete that had been maintain just barely and the bugs just keep piling up. The bug trackers are full of 10+ year old bugs that nobody cares to fix.

Linux ecosystem is moving constantly you have to keep up and maintain a bug free software.

>>810901

he's not wrong, alot of shit in gnome is practically abandonware.

i was trying to use ocrfeeder a few weeks ago to try to scan 200 page pdf's, and it totally shit the bed. devs if there are any refuse to fix any bugs. I had to manually patch one thing that was submitted years ago and ignored just to get it working. I ended up just quitting trying to get it working when I couldn't fix it's ridiculous memory leaks that make it unusable on anything bigger than 1 page.

https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=ocrfeeder

>>810905

>There are countless examples of minimal software that is considered finished or at least feature complete that had been maintain just barely and the bugs just keep piling up

are openrc or runit examples of that, then? Since thats what we're talking about.

obviously if new bugs appear, because they werent noticed or the environment changed, they have to be fixed.

>>810902

There are pros and cons to everything. And mainsteam distros decided that systemd has more pros than cons to the alternative. The decision was not pushed, there is no conspiracy. I don't understand why people are upset that systemd is better choice for other people. If systemd is not good enough for you then use something else.

systemd does not affect me negatively on a daily basis. The whole systemd thing is blown out of proportion.

I use a distribution and software that suit my needs. Gentoo, void, alpine etc are NOT good enough for me. If they were better (for me) I wouldn't care there is no systemd.

>Only a stupid person would use software written by a stupid person in such a critical role.

Ad Hominem.

>>810914

>Since thats what we're talking about.

No. Read >>810896

>I was talking in general, how people shit on every project Red Hat develops/sponsors. Not strictly init system.

>>810905

>Linux ecosystem is moving constantly you have to keep up and maintain a bug free software.

Yes there are countless examples. That's because if you get six gorrilion pajeets typing out software on typewriters, you get shit software like gnome or the linux kernel.

Idealy software should be like pouring a metal to craft something, you mold it/decide the intent. You then pour the mold/write the software. Then you let it cool and temper it/you fix all the bugs running it through a debugger or use a language that avoids bugs in the first place like pascal or ada. There's no bugs because it just works if you did your fucking job right.

Young pajeet, software is not meant to have memory leaks and bugs. Just because you and all your other pajeets write shitting street software doesn't mean everyone else does. Strive to use languages and compilers that don't have bugs to write better quality software. That way when things break it's not the 10 memory leaks in your program, but a interface name change for the linux kernel or whatever library you are importing.

>>810921

OK, I didnt read that post.

>ALL software needs to be maintained regularly,...because theres so much moving parts

that is objectively wrong though. your own exception proves it. it only needs to be maintained as often as issues appear, and that varies based on what exactly it is and how complex it is.

>>810817 (OP)

>Can someone explain to me whats wrong with systemd?

It was written under supervision from alphabet agencies and with their money.

Linux is not secure, not as it once was.

>>810923

That is unrealistic. Rust/Ada won't solve the software problem.

I am all for minimalistic, feature complete software. But in reality it still needs to be maintained and nothing wrong with that. How much maintenance it needs depends mostly on shit programming and shit bloated "lets do everything" libraries.

I have been doing so Go programing recently and the Go community mentality is pretty good. People build their software of libraries that are created mostly by rich Go Standard library alone and are vary of huge dependency trees.

>>810944

Memory leaks don't materialize out of thin air. If the software is correct today, it will be correct tomorrow. Correct software only needs to be kept up to date when external dependencies change their interfaces.

>>810944

>it's possible to get a program wrong with Ada or Rust therefore it doesn't matter what language is used and C code written by Pajeets being buggy is a totally unavoidable outcome that we should just accept

>>810862

Yeah, our actual firmware was only 60 megs at the time, so adding 30 megs of fucking garbage didn't sit well with me. But I hadn't set up squashfs yet so I was able to get the space back at least. But the memory I'm losing from running trash like dbus is just wasted.

>>810952

>lets use pointless crutches that reinvent the wheel and shit out pointless "features" because programming languages are not complex enough already

If you need to shit out your software fast or your software is complex use high level language that has GC like Python or Golang. If your software is bottlenecked by GC then git gut.

C is not a good language, but somehow everything else is still same shit or worse.

My personal opinion: What software development should had been: minimalistic, no magic, correct (no edge cases) low level (native code, no VM) language with optional GC and very rich standard library + external libraries that are built on standard library only that do only 1 thing. So instead of using bunch of bloated libs that are unmaintained after some time and shit frameworks you use 50 finished libraries that do only 1 thing and all they have to do is keep up to date with standard library.

>>810953

I'm implying that systemd only needs so much manpower behind it because its in development and its extremely complicated and not feature complete because they want it to have every feature.

Its not what you were talking about in particular, but its important to the topic of the thread that not everything thats development is dead has bugs piling up, and being more actively developed doesnt mean something is better. How actively developed something needs to be depends on if its done or not and how many bugs come up, some things require less active development than others, therfore systemd is not better because its very actively developed.

>>810970

>What software development should had been: minimalistic, no magic, correct (no edge cases) low level (native code, no VM) language with optional GC and very rich standard library + external libraries that are built on standard library only that do only 1 thing.

aka Common Lisp

>>810970

Also code boilerplate is always superior to language "features". The main reason that language "features" get added is to replace 5 programmers with 1 Pajeet. If you need anonymous classes and Java like generics, you should stop programming.

Programming is not about productivity it is about craftsmanship.

>>810982

The only guy that submitted a Lisp solution in the bimillennial coding challenge thread had a runtime nearly 100,000 slower than the fastest C solution and used 3,000 times more ram (1ms @ 32k vs 84s @ 99M). Lisp was a Jewish invention to prevent you from writing good code.

>>810970

C is a great language, I can do almost everything I used to do with assembly in it. Its main weak points are pointer aliasing and limits to information conveyed to the optimizer.

>>810986

>had a runtime nearly 100,000 slower than the fastest C solution and used 3,000 times more ram

As usual, the anti-lisp retard defends his failure to know lisp using ridiculous false memes. Use a compiler instead of an interpreter. SBCL produces native code that's competitive with GCC.

>>810983

Nobody is talking about language "features". We're discussing whether or not a language makes it easier to write correct code or incorrect code. What are the chances that software written in C by a mediocre programmer will be riddled full of bugs? Pretty fucking high.

>>810989

I used SBCL, faggot.

>>810992

Obviously. Not sure who would argue with you on that point. Not sure what is your point?

Do you think people still program in C because they are retarded and wrong? They use it because everything else still is shit, but in a different way.

Enjoy your 1 day compile times for Hello World on Ada/Rust.

>>810996

Cut your shit.

>>811001

Forgot to add. We need alternative to C. Golang comes close in some regard, but it is crippled on purpose by Google. It is not alternative to C, but the design is sane. If it had optional GC and better dependency management for dynamic linking it would do for 99% cases.

>>811002

Kill yourself. This was the fastest run. The same system ran the C version in 1ms.

root@sid:~/src# /usr/bin/time --verbose sbcl
This is SBCL 1.3.14.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (load "810262.cl")

; file: /root/src/810262.cl
; in: DEFUN MAIN
;     (ANALYSE-LIST (CAR LIST))
;
; caught STYLE-WARNING:
;   undefined function: ANALYSE-LIST

;     (FILE-TO-LIST PATHNAME)
;
; caught STYLE-WARNING:
;   undefined function: FILE-TO-LIST
;
; compilation unit finished
;   Undefined functions:
;     ANALYSE-LIST FILE-TO-LIST
;   caught 2 STYLE-WARNING conditions

; in: DEFUN ANALYSE-LIST
;     (NUM-APPEARANCE (NTH CNT LIST) LIST)
;
; caught STYLE-WARNING:
;   undefined function: NUM-APPEARANCE
;
; compilation unit finished
;   Undefined function:
;     NUM-APPEARANCE
;   caught 1 STYLE-WARNING condition

; in: DEFUN FILE-TO-LIST
;     (LINE-TO-LIST LINE)
;
; caught STYLE-WARNING:
;   undefined function: LINE-TO-LIST
;
; compilation unit finished
;   Undefined function:
;     LINE-TO-LIST
;   caught 1 STYLE-WARNING condition

T
* (main "test.txt")

None.
0
0
None.
None.
None.
None.
None.
None.
0
None.
0
None.
None.
None.
0
0
None.
None.
0
0
None.
None.
0
0
None.
None.
None.
None.
0
0
None.
None.
None.
0
0
None.
None.
None.
None.
(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL
 NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL
 NIL NIL)
* (quit)
        Command being timed: "sbcl"
        User time (seconds): 57.80
        System time (seconds): 0.09
        Percent of CPU this job got: 80%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 1:11.94
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 99092
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 18621
        Voluntary context switches: 4
        Involuntary context switches: 75
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

>>811006

go is trash

>>811001

>Do you think people still program in C because they are retarded and wrong?

Most of them, yes. C has valid use cases, but most software developed with C today has no business being in C. C is chosen 95% of the time because:

>unix meme: all my favorite unix tools are C so my program should be in C too

>programmer never bothered to learn anything else

>speed meme: my program needs the performance only C can offer, even though it actually doesn't (a perfect example redditors who think this way: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/)

>zero dependencies besides GCC meme: only a vanishingly small portion of the users will ever built it themselves. Those that do almost doubtlessly have the tools for other common languages available to them

>>811006

Go is useless. Garbage collection excludes it from systems work, static linking excludes it from security work or shell replacement. The only place it fits is as a Ruby replacement and who fucking cares about that niche.

>>811007

>actually timing your interactions with the REPL and loading/compiling the code

This is bait. Nobody is this retarded.

>>811018

That is exactly what I wrote in my post. Some part of Go is a good example what an alternative to C should be. Go isn't that on purpose because it caters to different niche.

>>811020

Tell me how to run it the fastest and I'll do it. But you know it'll still be dog fucking slow, so I understand why you won't.

>>810829

that's not an init system, that's an entire OS at this point.

>>811006

What's wrong with C? It's been good enough for the past 40 years.

>>811030

It basically is. It even infects the initramfs to some degree. I could write a statically linked application with musl loaded by systemd and not even bother mounting root.

>>811031

Hour of Code CS Grads, Pajeets, women, jQuery experts, and tech evangelists can't be trusted with C, so the companies desperate to lower wages by hiring retards want a language that protects the program from the programmer.

>>811033

Am I the only one that sees that as a giant, gaping goatse level security hole?

>>811035

Hmm, that opens up interesting possibilities. Make your project in C and have code quality requirements. As in will compile properly with -Wall. SJW proof your project.

>>811038

Faggot.

* (time (main "test.txt"))

None.
0
0
None.
None.
None.
None.
None.
None.
0
None.
0
None.
None.
None.
0
0
None.
None.
0
0
None.
None.
0
0
None.
None.
None.
None.
0
0
None.
None.
None.
0
0
None.
None.
None.
None.
Evaluation took:
  56.408 seconds of real time
  56.404000 seconds of total run time (56.388000 user, 0.016000 system)
  [ Run times consist of 0.024 seconds GC time, and 56.380 seconds non-GC time. ]
  99.99% CPU
  226,082,508,709 processor cycles
  160,839,792 bytes consed

The test data:

https://mega.nz/#!VPoAWRwQ!MNyWOflyP3HbfCrcCn0WRp008dQJPyixKgBAUphC240

The C code:

root@sid:~/src# time ./me test.txt
None
0
0
None
None
None
None
None
None
0
None
0
None
None
None
0
0
None
None
0
0
None
None
0
0
None
None
None
None
0
0
None
None
None
0
0
None
None
None
None

real    0m0.008s
user    0m0.004s
sys     0m0.000s

Lispfag fucking DESTROYED.

>>811048

Give me something to run, tell me how to run your autistic Jewish bullshit language, and I'll give you the timings.

>>811049

>falls back on "it's jewish because I don't like it"

Typical retard.

>>811050

I don't have to fall back on anything. I'm doing testing and timing and your lispshit is thousands of times slower than C. Anyone can repeat the test and it speaks for itself. Rather than try to improve it, you just whine and bitch. Lisp is a cult.

If you lived through seeing what happened when PulseAudio was introduced, you'll never want to touch anything Poettering makes again.

The problem with systemd is Lennart Poettering. He dismisses valid complaints against his software. He won't fix bugs if he doesn't understand them. He won't fix security issues with systemd and he'll just blame the security problems on other software. He tries to get Linus to push his shit code into the kernel because systemd is so broken it needs kernel changes. He keeps adding useless features no one asks for and then acting like he's some sort of genius for adding DNS to something that started as an init system. He is a complete condescending asshole to people who don't like his software, specially if they have valid complaints that affect security.

There was a bug where you could make a username that started with a number and gain root access to the machine. And Lennart basically went

>lol you're not supposed to be able to do that that's against Linux philosophy someone else screwed up we won't fix it.

Same shit happened when any user could write to system log. And writing garbage to binary system log would corrupt it and just delete the contents of the log without giving you any warning other than your log was gone.

If systemd was not attached to Red Hat, and it didn't have Lennart Poettering involved, it would just be another init system competing with other init systems based on merit. Instead you get sub-par software marketed by embrace, extend, extinguish Red Hat.

/g/ used to be filled with threads talking about how systemd was amazing because of boot times. There were tons of articles talking about how "systemd boots your system in under 2 seconds". It was all Red Hat marketing, and it worked, and systemd doesn't give a shit about boot times anymore. Do you boot your systemd system in under 2 seconds? And look at response to this thread, I make valid complaints against systemd and there will be very angry responses, there always are. Either retarded fanboys who still think they are winning because their boot times are 2 seconds faster or Red Hat shills trying to get you on CIA approved "init" systems.

>another systemd sealioning thread

73 on the hook in 5 hours, good job

>>811060

>Do you boot your systemd system in under 2 seconds?

Yes.

>>811067

So does my runit system.

>>811069

Just install runit-systemd.

I actually got my system to boot from bios loading linux kernel to graphics in less then half a second using openrc.

>>811070

sudo xbps-install runit-systemd
Unable to locate 'runit-systemd' in repository pool.

>>810832

>blob

>lgpl

Wut? You wanna say it's overly big and complex, fine, but it's not a blob.

>>811038

>38 milliseconds to calculate 3 lines of ~25 numbers

>the test cases are 40x30k

author      Language        Time, ms        Memory, bytes       Ranking Points out of 35
809731      c++             12              8760                34.972
810406      c               1               32768               34.971
810496      c               17              568                 34.970
810038      c++             2               706153              34.407
810201      js              179             315392              34.424
810410      ruby            221             794624              33.950
810485      py3             196             5017600             30.470
809276      py3             195             5029888             30.461
810221      py2             340             5091500             30.156
810317      perl            93              5940749             29.880
809861      go              933             9961472             25.055
811038(you)	lisp			58000			99000000			0

>>811077

author      Language        Time, ms        Memory, bytes       Ranking Points out of 35
809731      c++             12              8760                34.972
810406      c               1               32768               34.971
810496      c               17              568                 34.970
810038      c++             2               706153              34.407
810201      js              179             315392              34.424
810410      ruby            221             794624              33.950
810485      py3             196             5017600             30.470
809276      py3             195             5029888             30.461
810221      py2             340             5091500             30.156
810317      perl            93              5940749             29.880
809861      go              933             9961472             25.055
811038(you) lisp            58000           99000000            0

>>811060

>/g/ used to be filled with threads talking about how systemd was amazing because of boot times.

>It was all Red Hat marketing

This is what people actually believe unironically.

<insert picture of laughing anime sloots

>>811076

dont be autistic. "blob" meant "big amorophous heap". or all consuming monster, alternatively. The word wasnt invented or ressurected from dead speech for special use by the linux kernel.

>>811082

>/g/

>the board that constantly shills macfag shit

Not sure what point you're attempting to make.

>>811079

But it's so clean and well designed! It's worth the performance penalty to be using a real language designed by experts with s-expressions.

>>810832

>https://suckless.org/sucks/systemd

That page is filled with bullshit. Can you find a page written by people who actually understand systemd? There are systemd critics who understand it, but suckless is not among them. That page is really fucking awful. I'll pick out a few things.

>Should systemd’s PID be changed from 1 to a negative, or imaginary, number? It now exists before the kernel itself, during a bootup. See also systemd-boot.

This is about systemd-efi-boot-generator, which mounts certain EFI things to /boot. This takes effect after booting. It's a fallback in case you didn't specify /boot in /etc/fstab.

>systemd replaces sudo and su

It doesn't. It provides a command that has some overlap with the functionality of sudo and su, but deliberately chooses to do things differently, meaning it's not a replacement. Debian packages it separately, in systemd-container, which is not installed by default, so I doubt it's as hard to remove as they claim.

>systemd locks down /etc and makes it read-only

It doesn't. It only makes it read-only to systemd-resolved, because a DNS resolver has no business making arbitrary modifications to /etc. This is good security practice. It doesn't affect other processes because it's the current year and Linux knows how to treat different processes differently. See also: OpenBSD's pledge.

>pid 1 does DNS

This does not, in fact, happen in PID 1. It's a separate binary, a separate process, a separate PID.

>>811114

suckless's community are all rejects. The goons of CS. You can ignore them.

The main issues with systemd are bloat and tangled dependencies, playing well with others, the difficulty debugging things going wrong, and the CPU waste of systemd-journald.

>>811069

If you didn't write every line of code in /etc/service/ it's not yours

>>811114

go back to sjwhub lennart

>>811001

Ada compilation times are fine. Only Rust has shit-tier impossible-to-scale garbage times.

Goddamn, the amount of retardation/trolling/shilling/bullshit in this thread...

>>810819

I'm using gentoo without systemd, and I honestly don't see the difference between it and my systemd debian install as far as reliability goes. GNU/Linux has matured a lot in the past few years.

>>811190

Init systems don't really matter much on desktops.

systemd is good in that in makes desktop Linux usage easier, mounting drives, and speeds up boot times. It allows a lot of integration in gnome in particular, but KDE makes use of it too.

However, there are some drawbacks to systemd:

systemd has grown from a simple init (of which there about 5-6 in the open-source world) to a big set of programs that control a lot of things in the OS that inits never really did before. This is a big structural shift for desktop *nix development.

Some people are worried about the security risks this poses, having for example your dns service running in a monolith so close to the core of the OS. systemd has had some notable security bugs.

Some people don't like the "bloat" and "feature creep" as systemd takes over more and more of the OS. They want to keep things clean and simple. Sysadmins get frustrated with systemd for this, often times doing one thing causes another thing to break and there's really no reason why but "systemd".

Some other people believe that in a *nix environment apps should do one thing and one thing well, this is more of a philosophical approach to OS design. Parts of a *nix OS, they believe, should be interchangeable, just like you can change DE's, use gcc or clang, you should be able to use a different init: Sysvinit, upstart, openrc, or systemd if so chose.

Some more people don't like that as gnome and KDE become more reliant on systemd, those DE's are losing compatibility with non-systemd distros and other *nix. Already the BSDs, Gentoo, and Devuan have to patch gnome and KDE components to work without systemd, this is only going to get worse as time goes on.

Some people don't like the lead developer's code or personality. I've never read his code directly or met him, so I can't say. I have read some of his responses to bug reports and found them to be...wanting.

Finally, some people don't like that the major Linux distributions adopted systemd without much discussion or input, in particular the Debian "vote" on the issue was a very poorly worded ballot.

>>811213

I'll admit I originally supported systemd. I was wrong in that support. The thing must look like goatse to the NSA.

>>811213

>some people

>some people

>some people

Some people have a functioning brain in their head. For everyone else, there's systemd. :^)

Also the supposed advantages you list are bullshit.

>>811213

Why are you saying *nix when systemd will never be ported to any bsd ever?

>>811213

>having for example your dns service running in a monolith so close to the core of the OS

but that's not what happens at all.

>>811255

It'll be ported eventually when the BSDs give up with every program requiring systemd.

>>811270

More likely that red hat splits off into its own ecosystem entirely, and there will be linux, bsd, and systemd.

>>811270

You're wrong. They will fork their own software to remove systemd.

>>811292

The BSDs can't even keep up with drivers, there's no way they're going to be able to fork browsers.

>>811213

>>811060

Also this:

>>810942

>It was written under supervision from alphabet agencies and with their money

No matter how well this pile of shit performs, it is a gorillion lines of non-reviewed code, written under circumstances that you should never trust at all.

With Win10 becoming more and more unpopular, the masters had to come up with something to fully backdoor all linux-based systems, as it was forseeable that many folks would not trust Win10. So they sugarcoated this monstrosity with Muh Maintainability and Muh Usability, bribed the right people so that it is now implemented in the top Linux distributions. Poettering is just a useful idiot who guards with his name the real people that stand behind all the suspicious shit that is going on there.

No amount of usability and performance could ever be the justification for how things went. I think many folks are just thinking too well intended. There are people on this earth right now that have the power as well as the intent to backdoor the shit out of every mainstream piece of software. Everything about the sudden rise of cancerd should worry you in this regard.

>>810827

This is really the only issue with it, but people seem to forget how fucking god-awful what it replaced was.

Its a case of people becoming accustomed to eating a steaming pile of shit every day for dinner and then having that replaced with a stale sandwich, except a vocal minority started complaining about how they preferred the pile of shit.

What's wrong with Upstart? As a desktop user, I never got any trouble with Ubuntu when they used Upstart, now with systemd my PC take 3 (extra) minutes to boot because systemd keeps trying to connect to an now inexistent Ethernet connection.

>>811358

Try removing the ethernet connection from your network settings.

>>811213

>reddit spacing

>systemd is good

LOOOOOOOOOOOOOOOOOOOOOL

fuck off lennart

One second. Systemd has this thing where it makes services run as root if User= has a leading number, i.e. "0day", and you can have user units in $XDG_RUNTIME_DIR/systemd/user/. Does this mean you can escalate the privilege of user units with this? Does systemd have a protection mechanism against this (i.e. User is only valid in system units)? What happens if I have a leading number for my account name and I run a user unit?

>>811210

Well, gentoo is running on a headless server, while debian is on my laptop. I just meant that it isn't hard to configure anything, and nothing has really broken on either system. I guess you could say that the opposition to systemd stems more from a philosophical perspective on how the system should work, as opposed to a technical one.

>>811397

According to systemd wisdom, normal users are not allowed to have leading digits in their username. This is in contrast to the Posix spec that says it is fine for user account names to lead with digits.

>>811400

post an issue for it, i'm sure they won't close it as not a bug and blame the rest of linux for it.

>>811401

>>811402

systemd can do no wrong. systemd isn't wrong, the linux spec is wrong.

>>811397

User services can't run as different users. If they could, you could save yourself some trouble by specifying "User=root".

>>811404

What about if you are the user with a leading digit as name?

>>811420

It runs as yourself. No escalation of privilege.

If you specify User=<yourname> it fails. It also does this if your username is valid.

Usernames with leading digits are already incompatible with lots of things. Debian doesn't let you use them, for example.

I think this is bad, but it's nearly as bad as some people make it sound. It can only be triggered by someone who already has root privileges.

>>811299

The BSD's have palemoon and icecat for non-systemd browsers already, maintained by seperate teams. One as a true fork of firefox with the other as a patched edition of upstream. I am actually confused why the BSD's haven't switched away from firefox yet for a default.

>>810817 (OP)

>Can someone explain to me whats wrong with systemd

There is systemd the "init" and systemd the "project".

Systemd the init no one gives a fuck it's replaceable and isn't looking like cancer.

Systemd the project on the other hand is just cancer that spreads into unnecessary part of the OS.

Even security researchers of the hardned linux kernel are fucking worried about it.

Just read this fucking thread and get your head out of the trash

https://lists.dyne.org/lurker/message/20161204.215049.93e768e9.en.html

>There is absolutely no reason to build procps against libsystemd and pull in all that shiny /usr/... namespace which makes systems unbootable in the end.

>By the way, other packages that are linked to libsystemd for no need or even worse:

>- - tor

>- - stunnel4

>- - rpcbind

>- - rsyslog

>- - openvpn

>- - iodine

>Sure. Nice API, isn't it!? Every Tool has its own tools to query special values. Just systemd must infect every standard tool.

>The same I could ask why ls does not display acls (getfacl) or capabilities (getcap and why does ps not show them? (getpcaps)) or fileattributes (lsattr)? Only systemd has to infect all other tools that aggressively.

>And look at the costs. It pulls in all the systemd environment just for a ps!? It breaks several usecases.

>Not to mention, why such daemons like tor or stunnel need to be linked against systemd.

But wait there's more please have a look at the US patent 20150040216-A1 "Systems and Methods for Restricting Application Binary Interfaces" filed by Paul Moore, Dan Walsh and Lennart Poettering on behalf of Red Hat inc.

https://lists.dyne.org/lurker/message/20170630.070231.3eff71f4.en.html

Anyway most of the systemd "features" are only relevant to sysadmins users don't give a fuck about these features.

>>810817 (OP)

is gud jok

>>811401

I'm not a fan of systemD, but who even bothers with posix anymore?

>>811577

If you want your program to work, compiled, out of the box on linux, freebsd, OSX, and openbsd you bother with it. Otherwise just use a toolkit.

>>811278

Honestly, this seems the most likely scenario. Gnome and systemD are too tightly interconnected to have anything else as the plan at this point. That has both good and bad points to it, honestly.

I've been meaning to audit the thing for its value in digital forensics but I also want to learn programming by learning assembler for an IBM mainframe and taking it from there so I don't know when I'll get around to it.

The truth is systemD is meant to replace everything GNU in Linux and effectively do with it what Apple did with NetBSD. I knew this was coming when I started seeing the ratio of Macbooks shown in dev meetings skyrocket. These people cannot be trusted with Linux as they don't understand why the rest of us like it.

>>811581

Gnome was a mistake

>>811594

Probably. I honestly wish Red Hat would just fork and be done with it.

>>811596

If you squint a bit they kinda sorta did, since we now have both GNOME 3 and MATE.

>>810819

This is what NSA posting looks like.

>>812541

This is what a /tech/ expert looks like.

>>811435

>palemoon and icecat

Those aren't fully maintained forks. They just don't have the time to keep up with security. There are no forks of firefox or chromium with the necessary manpower.

>>812565

Palemoon is a fully diverged codebase from mozzila's that is over five years old now. They sure do have the time and manpower especially considering they forked so long ago to avoid the current pozz that sjwfox has with bugs and backdoors.

>>812567

How many of the infinite number of security holes those browsers have do you think they're keeping up on, especially since with a highly diverged codebase, backporting them is hard?

Again: there are no forks of firefox or chromium with the necessary manpower.

>>811308

sounds like a conspiracy theory.

backdooring hardware is easier so why bother with software?

>>812621

what about waterfox?

>>812641

>coming up with even more obscure forks

How many developers does that project have?

>>812567

>>812621

Firefox codebase is a lost cause. Millions upon millions of lines of C/C++ is simply not maintainable for anyone except a large corp. Would be far better to restart with a properly scoped minimal browser written in a sane language that minimises bugs (eg Ada) to get the absolute best result for the small amount of manpower available. Gotta work smarter, not harder.

>>812654

Ok Ada shill,

open an Ada thread where you can demonstrate the beauty of your language. Maybe even give your readers a few challenges and excercises so they can write and share their first Ada programs? I'd do it myself if I knew Ada and if I wasn't Tor posting.

>>812656

Klabnik, please leave.

As we saw from the bimillennial coding challenge thread, the rust/ada/lispfags are all talk. The rustfag failed and ragequit, the lispfag managed to make something literally 100,000 times slower than the best entry, and the adafags did nothing as they don't even know ada.

>>812665

Ada shill here. I'm the seventh anon in that thread who gave the OP a 110% penalty for cancer. Then I gave it no more thought. You're telling me you *don't* have better things to do than completing some anon's homework? :^)

>>812654

Linux is millions of lines and that has no problem being maintained. Firefox is not more sophisticated than Linux is.

>>812683

>Linux has no problem being maintained

I question this. Linux has maintenance support from several large corporations, for one. And I expect that a great deal of driver code in Linux *does* go unmaintained. Ran into all sorts of bullshit for some Intel graphics drivers a while ago in fact.

>>812684

Linus excises any code that doesn't have an active maintainer. The reason why Linux has driver support for the most esoteric devices is because there is a driver programmer who is actively working on it.

>>812686

Not good enough according to those further up the thread who disparage Pale Moon et al. The implicit assertion is that those projects do not have enough manpower to keep those codebases in order, even though they clearly have coders doing maintenance. So what we're really talking about is whether there are enough maintainers working on each bit of code to keep it to an acceptable standard. Excising any code that has no maintainers whatsoever doesn't guarantee that.

>>812702

>Not good enough according to those further up the thread who disparage Pale Moon et al.

I consider these people as brainlets and therefore easy to ignore. I like to think they're under the influence of the Dunning-Kruger effect. I don't even bother insulting them anymore, I just spend my time on posts that show a real dialogue.

>>811319

>but people seem to forget how fucking god-awful what it replaced was.

I don't particularly hate systemd, but I think you are exaggerating here.

service <service-name> start/stop/restart

vs

systemctl start/stop/restart <service-name>

>>814969

I think you're unaware how bad sysvinit was. kill -9 one of the services. Does it even restart?

>>810817 (OP)

lol nothing, it triggers the fuck out of DIY Gentoo tards though.

>>815027

> kill -9 one of the services. Does it even restart?

No idea. I don't see why it would since that's not the restart command.

service <service-name> restart

>>815033

Try to be less autistic. kill -9 is a stand-in for a crash. The point is, they don't recover from errors.

>>815032

Too bad systemd is available on gentoo.

Wtf is all this hate agaist gentoo.

"tards"

"neckbeards"

It's like the thread about web browser, calling people trying to use text browser "manchild" and stuff.

Seriously, that's pure idiocracy.

>>815099

Why would you want the init system to automatically restart anything that crashes? That sounds like a great way for a service to get stuck in a loop crashing and restarting for eternity until the user notices and disables it.

>>810817 (OP)

Its redundant bloat and obfuscation of the boot process.

Init scripts are all that's needed to start services and load modules. Init scripts are literally just plaintext bash scripts. It doesn't get any easier than that. The CIA wants to obfuscate everything because they want nigger cattle that don't know how a system works. They don't want you compiling kernels or looking at source code just be a dumb nigger and run binaries.

>>815229

If you can't backdoor the kernel, what's the next best target? That's right, the management service.