/tech/ - Technology★

They're trying to work its tentacles into BSD. Nothing is safe.

Werks on my masheen

>>823975

Say it ain't so!

>>823947

>shitty /pol/ memes

go and stay go

>>824014

What /pol/ meme? That's a transformative work, not a derivative work.

systemd is chemo for the Linux cancer.

>>824074

>systemd is cancer for the linux chemo

Fixed.

>>823928 (OP)

>unironically falling for the "systemd is bad mkay" meme.

costanza.jpg

>>824141

Yes, an event-based init was something badly needed as hardware advanced beyond the '90s.

Yes, it provided an opportunity to address a bunch of left-over poorly-implemented low-level stuff from the '80s.

Yes, doing all of the above provided an impetus to improve other inits such as OpenRC, runit, and Upstart.

It's still completely inexcusable that it is monolithic, buggy, backdoored, poorly documented (de facto not free, as looking over 687K lines of interdependent code isn't feasible), and swallowing up the rest of GNU/Linux.

not the anon who you quoted

>>824151

>de facto not free

Are you retarded?

Are you not free to use, modify and distribute systemd? Software freedom is a de iure condition, and de fact systemd isn't impeding any of those freedoms of you. Just because it has a shitton of source code doesn't mean you can't modify it. Imagine if you said Linux wasn't free because it's well into the tens of millions LoC.

>>824158

The Linux kernel has tons of authors while being monolithic, and as a result has developed very good documentation over the years. Its own developmental arc is tied to the free software ethic, now as ever.

As for systemd, 90% of the code has been written by the top 10 contributors, and poorly documented to boot.

Linux keeps to its own. If I need to deal with kernel stuff, I deal with kernel stuff. If I really wanted to, I could port over most of my OS to BSD because it's mostly POSIX-compliant.

systemd means that, if I want to install GNOME (not that I would in [current year]), I need to entirely replace the init system and install corresponding programs and daemons.

Linux doesn't shit the bed and get fucked over by backdoors from every angle. You've seen how insecure systemd is, and that's just the backdoors not made by the US government (remember: largest client of Redhat is the military). I have no means of controlling this opaque software's actions, even though I know C. Sometimes, you have to seriously wonder if that's intended - that or they're piss-poor programmers who should be fired immediately.

It's not at all the same as the Linux kernel in practice.

Moreover, who the fuck cares about whether software is "de jure" free if it doesn't meet, in your interaction with it, the standard accessibility engendered by the concept of free software? Tivoization is a similar example of why de jure freedom doesn't matter.

One of the two main goals of the US Constitution is to "secure the blessings of liberty". Does that matter one iota if it says so but allows the NSA to search all of my data and remove my privacy when I've done nothing wrong? No. It doesn't serve its purpose. Freedom is always based on de facto conditions, what one experiences in their daily life. A document is a document and nothing more. systemd may adhere to the GPL license's terms* nominally, but it entirely violates the spirit.

*assuming they don't go proprietary in the future once they've consolidated all major distros and made more core software dependent on it

>>824158

Nice tripfag opinion

>>823928 (OP)

Or you know, you can start by writing software.

>>824042

The merit of systemd is that it made it easier for the distro writers to configure their init system. Prove me wrong.

Just gonna leave this here.

https://suckless.org/sucks/systemd

>>824255

But at what cost ?

Nothing is never worth freedom.

>>824264

Systemd is gplv3. The source code is right there. You have all the freedom you need.

>>824265

>Systemd is gplv3.

GPLv3 protects against copyright/legal aggression on freedom and not software design which is normal because it would be a breach on the developers freedom.

>You have all the freedom you need

Because you have a lot of choice for browsing ? You can surely code a browser the size of an OS yourself.

The UNIX design was there for reasons if you don't follow it or something similar you get something that can't be managed by one person.

>You have all the freedom you need.

Yes I do I use runit.

But you already know this ? do ya smartass ?

>>824271

The only freedom are the four freedoms of free software. Systemd gives all four freedoms of free software.

>Because you have a lot of choice for browsing ? You can surely code a browser the size of an OS yourself.

What does this have to do with anything?

>The UNIX design was there for reasons if you don't follow it or something similar you get something that can't be managed by one person.

I don't care. What I care about is the four freedoms, this is the most essential. Everything else is less essential after that.

>>824151

>monolithic

How is it monolithic? Explain in your big boy words what you're required to have besides the init.

You're not required to use:

networkd

multi-user (logind)

You're not even required to use journald, you can simply have it write to memory and be non-persistent, while having syslog be the persistent log store.

You are required to use dbus though, which will be irrelevant once it's mainlined in the kernel and isn't usespace anymore.

>>824276

>>>/reddit/

>>>/4chan/

>>824255

Does it really? I don't mess with systemd much but I do configure services with Runit a lot and it's super simple and straightforward.

>>824314

>>824317

I don't think Patrick has any plans to switch Slackware to systemd, but if that tragedy occurs where do I go? Gentoo? I've mostly avoided the drama by staying with Slackware since v1.0 (for me it just feels more natural switching between Slackware and UNIX at work).

gentoo or openbsd

>>824319

What about LFS? I honestly think that they will some day drive us to make our own distributions or switch to some other OS. My ideal system is:

small enough that I can understand what's going on and fix issues by myself, without waiting for updates from maintainers,

updates only critical security problems - I don't want updating just to have latest versions and break or change everything else in the process,

stable - I expect my computer to be very reliable. If I want to do my work, I don't want to be messing with my init system to get DNS working.

How viable would it be to use LFS as daily driver? Gentoo or Slackware would be a step in the right direction, but custom LFS also looks like a nice project.

>>824276

https://media.ccc.de/v/ASG2017-126-systemd_facebook_a_year_later#video&t=1351

>>824346

I shitposted too fast and it didn't make sense, let's try again.

>see the DNS fiasco

resolved is a stub, many system administrators want such a stub instead of a fully blown server on their systems, and it's totally optional.

timesyncd is a SNTP client, it's a stub, and many system administrators want it instead of a full blown NTP server on their shit. it's optional.

networkd, totally optional.

everything, optional. don't have to use it. don't have to use journald. you don't know what you're talking about it.

>>824333

>glowing praises throughout if you watch the whole video

>a few nitpicks out of context

lmao

>>824151

>backdoored

Wow you are retarded

>>824334

>tripfag

>koolfag

>/threading your own post

There are so many good reasons to commit suicide. Why don't you look into it?

>>824254

>implying there aren't several stable alternatives already

This tack has been tried in every anti-systemd thread I've seen.

>>824319

Funtoo doesn't use systemd

>>824329

LFS is a fun project but honestly you're just making more work for yourself rather than using or modifying an existing distro. If you have the free time though try it out, the manual is essentially copy and paste.

>>824384

>Only once you find out it's there

The service is literally disabled by default in upstream, you shitter. Either your distro enabled it and used it or you're just incompetent. Fuck off.

>>824384

>sure makes it hard to switch

Who said that they have to do the work that you don't want to do, which is only necessary because you have a mental illness? There's certainly no technical reason to do so.

>>824384

>>824425

Also, what you said

>sure makes it hard to switch

Makes absolutely no sense in the context of the OPTIONAL, DISABLED BY DEFAULT DAEMONS.

Want full blown NTP server? Install NTP server. Want an actual resolver instead of stub? Install DNS resolver. Want syslog? Install syslog, configure journald to be non-persistent. Don't want to use networkd? Don't use it, use something else.

None of what you retards are saying makes sense.

And even if you were talking about switching away from systemd, no one is stopping you. There's consolekit fork for logind replacement. There's many more alternatives. Do the work yourself, no one has to do it for you.

>WWWAAAAHHHHHH I DON'T WANT THIS COLOR LAMBORGHINI DDDAAAADDDDDD. GIVE ME A SHITTY TOYOTA RICE BOX. YOU'RE OPRESSING MUH FREEDOMSSSSS.

>>824425

>There's certainly no technical reason to do so.

http://www.cvedetails.com/vulnerability-list/vendor_id-7971/product_id-38088/year-2017/Freedesktop-Systemd.html

>systemd-resolved through 233 allows remote attackers to cause a denial of service (daemon crash) via a crafted DNS response with an empty question section.

>In systemd through 233, certain sizes passed to dns_packet_new in systemd-resolved can cause it to allocate a buffer that's too small. A malicious DNS server can exploit this via a response with a specially crafted TCP payload to trick systemd-resolved into allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.

>In systemd 223 through 235, a remote DNS server can respond with a custom crafted DNS NSEC resource record to trigger an infinite loop in the dns_packet_read_type_window() function of the 'systemd-resolved' service and cause a DoS of the affected service.

And not resolved related but holy shit:

>systemd v233 and earlier fails to safely parse usernames starting with a numeric digit (e.g. "0day"), running the service in question with root privileges rather than the user intended.

Are there any distros that use nosh, and if not, is there any particular reason? It does use a cuck license though. Has anyone tried it?

>>824151

>It's still completely inexcusable that it is monolithic, buggy, backdoored, poorly documented (de facto not free, as looking over 687K lines of interdependent code isn't feasible), and swallowing up the rest of GNU/Linux.

What a retarded post.

When will we get Microsoft iSystem32d. Please Brian, meme it happen.

>>824299

Yes, systemd really did make it easier to configure. You didn't see what kind of init scripts they used in the past with sysvinit. I haven't used runit or systemd directly so I can't compare systemd to runit.

>>824314

We needed a new init system in the first place because it made init configuration a lot easier than sysvinit.

>>824571

This sysvinit "crisis" was manufactured in order to make people receptive to what was going to be presented as the solution to their perceived huge problem. The discussion was framed as a false dichotomy between the ostensibly obsolete sysvinit and the *modern* systemd. Nevermind that there are other init systems such as runit and openrc that address the shortcomings of sysvinit or that none of the argumenta made in favor of deprecation of sysvinit justify the cancerous growth of systemd beyond a mere init system let alone its current scope.

>>824579

Embedded C unicorn here. sysvinit was a total disaster. systemd is less of a disaster and in different ways.

>>824585

Of all people, you should be using MINIX. At least Intel got that part right. MINIX3 was designed from the very start for failsafe, hands-off operation, something Linux isn't (no matter what init system you use).

Either that or QNX.

>>824579

Your confusion is in believing that systemd should only be an init system. Systemd is intended to be the system manager.

>>824603

Distro writers don't debug systemd. The systemd developers debug systemd.

>>824588

Minix is a joke. It's a teaching OS. The only reason Intel is using it is it's 100% controlled by Jews so when they tighten the noose there won't be a risk of someone sabotaging it. It's the same reason SV companies kick out anyone who isn't anti-white even if they're really good.

>>824608

No, distro maintainers and embedded guys get stuck debugging it and it's painful. You have to strace attach to pid 1 before triggering anything as it's all done via messaging. And starting a service is like 1k lines (literally) of esoteric syscalls before the actual service takes control. I have to remove all hardening before any debugging as well as it breaks everything I'd use to debug it. There's no global switch for that, sadly.

>>824334

Fuck you, tripfag. I hope you don't actually use void on the principal that I don't want someone like you in my community.

>>824625

What are embedded software developers doing that they require the use of systemd?

>>824074

Tbh yeah. Systemd is one of the few things that makes Linux usable.

>>824623

Old minix was a teaching OS before Minix 3. Sage for multiposting.

>>824314

See? A bunch of things that don't matter in a production environment. Why would you suspend a server ever?

>>824452

>that's what it broke.

And I'm saying that you are a moron who doesn't know what you're talking about. The services in question are disabled by default by upstream. So either your distro maintainer was responsible for breaking your shit, or you were.

>>824457

I'm not talking about that. I'm talking about the fact that there's no technical reason to use anything besides systemd on something like RHEL or CentOS, maybe Debian if you're working on embedded hardware.

And once again, you retards are screaming at the sky. These services are DISABLED BY DEFAULT by upstream. They are optional, and you have no idea what you are talking about.

Once again, I will repeat: you have no idea what you are talking about. You're kicking and screaming because you are unbelievably autistic, but none of what you're doing is making any difference to anything besides trying to craft an autistic echo chamber with other retards who are just as retarded as you.

How many times do I have to repeat that the services in question are disabled by default by upstream before you get it through your thick as fuck skull, and no one is forcing you to use them?

>>824654

Why are you still here? You know what to expect yet you still come. Don't you know of anywhere else?

>>824655

There's nowhere else but I enjoy making retards feel like the subhumans that they are in the mean time.

>>824657

You're one of them.

>>824658

As are you, in that case. Prove me wrong. Protip: you can't.

But, you do seem to be a bit upset, friend. Is it because you can't prove me wrong, in the posts I made, above?

>>824633

Embedded is a lot less thin today. You'd actually be horrified by some of the things you don't know are on your devices. But for a basic system it's generally going to be a trimmed Debian.

>>824636

It's still basic. It just now has marketing.

>>824659

I don't make outlandish insinuations or treat a site without individual posting history as one that does. I proved you wrong, and found you a new place to hang out: reddit.

>>824666

>Embedded is a lot less thin today

That's fine, but the question still remains. What is it about systemd that embedded system developers require it? I would have thought that something like Runit would be adequate for such a purpose.

>>824674

I make embedded network devices and until recently we had some seriously hacked up sysvinit stuff mixed with python. I just (mostly) finished with a transition to systemd.

First off, let's get the obvious out of the way: embedded wants systemd because many other people they aren't paying help maintain it. Blazing your own trail is very expensive. Debian makes sure that shit works and that's then one less thing we have to do.

The technical problem with other inits is that embedded needs reliability. It might be fine if sometimes your laptop has some fuckup related to init but when you have 50k devices in the field and support is expensive they better work 100%. As an example, race conditions. I have a service that needs to start, be able to start queuing requests, confirm it is now in a started state, then start delivering event callbacks to whatever (shellscript glue, etc.) (dhcpcd also has this issue, if you want to look at something you have access to). If I naively start this via like start-stop-daemon or an init that only handles starting, I have no good way to prevent callbacks firing while it's starting. That could lead to all sorts of fuckups, like logic wanting to stop it while it's starting, or trying to queue an event back before it can accept one. I previously solved this with a wrapper between start-stop-daemon and the callbacks where it'd handle locking, but this was also complicated as I needed some shim to stay running to guarantee the process was still alive and to allow reliably managing it (pid files are completely unacceptable as they are fundamentally unreliable). It was a complicated and dangerous thing to get right, and it's messy. systemd replaces this.

systemd handles a lot of these reliability issues that everyone else gave no fucks about. It's why industry wanted it.

>>824693

That makes sense. Systemd will take care of service dependency tracking. Systemd will also take care of parallel service booting.

My question now is this: do you embedded guys debug systemd itself as claimed by >>824625 ?

Nothing in this thread provides any evidence that systemd is necessary for a stable linux setup.

All the rhetoric appeals to emotion and lacks argument.

Provide an exact example of sysvinit, openrc, runit, and other init systems where they fail. Don't just claim that they are "shit" or "confusing". Those are appeals-to-emotion, not facts. Where and why do they fail.

After you've done that. Provide an example of where systemd fixes that exact problem.

If that isn't done, then this thread is a shill fuck fest of disinformation.

>>824698

Yeah, that post's me, too. I personally debug it. When you start trying to cut it down (size is an issue with it) you run into all sorts of tangled issues with it where it fails silently because something's missing and debugging is a pain in the ass as there's no good way to catch it in the handoff as the state's pretty weird due to all the magic. E.g., you can't just break out to gdb so it's usually gdbing daemons rigged to run standalone and straceing the system as a whole and hoping you never run into anything that requires stepping through the transition. For example, systemd-networkd will silently fail to bring up the network without dbus (but dbus is totally optional :^)), ACPI events like case buttons will silently not fire if you cut out systemd-logind, issues with socket activation require straceing the exec as it can silently pass dead fds to exec when you have non-trivial sockets, etc..

>>824709

>Provide an exact example of sysvinit, openrc, runit, and other init systems where they fail.

Go look how every distribution deals with DHCP option 42, setting NTP servers. This is where the shit hits the fan rubber hits the road for init system design. It involves callbacks, race conditions, and reloads between multiple services where the DHCP server and NTP server can be anything provided by the system.

It is a hopelessly fragile/broken pile of hacks in everything but systemd (you'll find swearing in one distro's sysvinit files for this). It's also broken in Debian with systemd.. This is something that embedded devs have been patching in their releases for decades, but has become significantly easier to get right with systemd.

>>824728

>you'll find swearing in one distro's sysvinit files for this

Don't just say it. Prove it. What distro? Link?

>DHCP option 42, setting NTP servers

That is somewhat helpful, but even doing a web search for "DHCP ntp sysvinit" doesn't provide any actual script. Can you show something instead of just saying words and fettering belief?

>>824764

How about go fuck yourself you lazy nigger. I spoonfed you enough.

>>824319

>but if that tragedy occurs where do I go?

BSD.

Your already using an init system that is practically the same as BSD's.

>>824673

>outlandish insinuations

Nothing is outlandish about my "insinuations." They're what the poster was doing.

>posting history

I don't have to reference "history", he's doing it in this very thread.

>reddit

You are very upset.

>>824709

No one said you need anything to get a "stable setup" moron. People are saying that systemd is the only thing that does it right, but with a few rough edges.

Then you morons bring up totally optional daemons that don't even have to be compiled for systemd to work, as if it means anything.

Even your "based Torvalds" agrees that it does it right. Meanwhile you retards just appeal to Sievers being a jackass as if anyone really cares or is surprised by that.

>>824768

Eat shit and die you pogue. You fucking gave one dumb ass phrase thinking it was enough. I already informed your fucked ass that I did a web search and that no results linked to any scripts. You won't help with that, then gape your ass faggot. Further, you are the one that gave an anecdote without evidence. I requested evidence because why believe a single shitty word coming out of your ass-for-a-mouth.

>>824775

What is someone as lazy as you going to do with that information anyway? You obviously aren't a programmer.

>>824773

>No one said you need anything to get a "stable setup" moron. People are saying that systemd is the only thing that does it right, but with a few rough edges.

I've found contrary evidence.

>I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the power of shell scripting. Systemd threw the baby out with the bathwater, and just makes diagnosing boot problems all that more difficult when you have to start tracing through magic symlinks.

https://news.ycombinator.com/item?id=11602255

This is all some Poettering circle jerk fuck fest and everyone is pushing their way to the front to suck him off.

>>824776

Are you still spewing shit? Why don't you sit yourself down in the stool of shitty words that you keep dropping.

If you provide no evidence, you have no argument. If you have no argument, go fuck yourself on a rusty pole.

>>824777

Yeah and I have a counterpoint with the existence of launchd. Those are some hot opinions from HAKKAR NEWS but they don't matter.

>>824780

You are appealing to my emotions for your opinion to be correct, but I found another person appealing to my emotions for their opinion to be correct. Which do I choose? Why don't you put up or shut up? Find specific evidence where init systems fail and systemd fixes that specific failure.

>>824781

No I'm appealing to the fact that launchd exists as evidence that BSD init/rc is not the final answer, even in that ecosystem. If it were, launchd would simply not exist.

Also, that's a dumbass opinion.

>nginx is so complex why do I have to traverse symlinks to clean up after my failure to configure it correctly

1) You don't have to, simply edit the unit file that you fucked up on which led to a total failure in boot for some reason and 2) the journal and systemd-analyze still fucking work in an emergency mode, so obviously that poster is retarded, but that depends on the mode of failure. If it fails before shit's even mounted, obviously you didn't fuck up an early unit file. I can't even comprehend how badly one has to fuck up to make systemd shit out to emergency shell with a unit file that's not relied on early early.

>>824784

Or to better explain why the poster is retarded, if systemd-analyze or journal is not working, it's most definitely not a systemd problem. More like a "hurr I fucked up fstab" problem, or hardware problem (in the case of root or /var/ or whatever partitions/hardware failing, you have bigger problems than systemd). If it's past that point, then the journal and systemd-analyze will work, so there's no need to "traverse magic symlinks" or whatever bullshit. It will tell you what fucked up, and how.

Classic example of PEBCAK and blaming a tool. Sounds like a retard who would say that systemd "hangs" when fstab is incorrectly configured or hardware has failed, when in reality it just times out, and that timeout is configurable.

>>824784

>>824786

top kek

sounds liek systemd is a worthless addon to linux

fuck you

>>824787

I'd say that with systemd-analyze and the journal, certain boot failures that drop to emergency shell are much, much easier to debug. But you're just a shitposter that fundamentally can't operate his tools correctly or just wants to bitch about "simplicity" and there's really no point to having this thread tbh. It's filled with the same retards, like you, as usual.

>>824790

> boot failures that drop to emergency shell are much, much easier to debug

Heh, no. Most boot failures systemd will fuck up and it takes a while to work around all the different errors that will leave it in a failed state. For example, it often prevents ssh from starting if a drive failed during boot even on headless VPSes.

https://bugzilla.redhat.com/show_bug.cgi?id=1213781

https://askubuntu.com/questions/972647/how-to-make-sshd-start-in-systemd-emergency-mode/972668

This is why everyone got really interested in paravirt watchdogs and serial over the last couple years.

>>824825

WOW! We've got Linus Torvalds posting here! Because how else would another person know unless it was really him!?!1

>>824314

> waiting 5 minutes for PC to shut down because systemd waiting for job to finish

It was 90 seconds at best and haven't seen that bug since they stopped using sighup (inducing tmux autism).

Pulseaudio was a mistake (not for the devs, but the users), but my best guess after Canonical retreat from many areas, RH will stop their NIH syndrome and start consolidate their codebase. I know all of this supposed to make easier to develop sw for linux with the monoculture and some autists got triggered by it, but if one wants larger marketshare, than he have to accept standardisation.

>>824841

How retarded are you?

>Linus Torvalds said:

>"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."

>>824847

Not as retarded as you appear to be.

>>824849

ebin, shouldn't you be in school?

>>824850

I am a fucking grandpa, dumb ass.

>>824641

>linux is only for servers

I bet that new samsung botnet TV goes to sleep (suspend) instead of turning off when user presses "off" button. There are more embedded devices running linux than there are servers. So yes, suspend feature functioning correctly is important.

>>823928 (OP)

lmao just use devuan fags

Nothing is more fun than troubleshooting failed boot while reading binary logs. Oh wait, you can't read it ;--DDDDD

>>824820

That's not a systemd bug, moron. SysVInit in "rescue" did not start SSH either.

Learn to validate fstab before rebooting your fucking server. Defer mounting network filesystems until before the unit that needs it, later in the boot process, where it will not fuck your system. None of that shit is actually a problem, it's only people blaming tools.

>>824931

>Oh wait, you can't read it

Yeah, you can. systemd-analyze and journal are available during failed boot.

Unless your root failed to mount. In which case you have a hardware problem or you're just retarded and can't validate your fstab before rebooting like the moron that you are.

>>824074

>systemd is chemo for the Linux cancer.

b-but anon, there are times that chemo worsens cancer...

what distro doesn't have the autism to compile literally everything but doesn't have systemd and is a rolling release?

>>824963

Debian Unstable, if you replace it by OpenRC.

"systemd-sysvinit" is the package that provides /sbin/init. Get rid of that to use a different init system.

"systemd" is the core systemd package. Remove that to get rid of all traces of systemd. Take care to install a replacement for NetworkManager (if you need one), like wicd, before removing it.

Debian supports three kernels, two of which are not Linux, so I don't expect systemd to become mandatory any time soon.

>>824963

last i checked gentoo isn't pozzed

>>824847

Monoliths gonna monolith.

>>824963

Void.

So honest question. I jumped onto linux because my windows 8 computer finally shit the bed and the laptop was already being held together by electrical tape and dreams so I repurposed an older laptop with Linux mint 18.2.

I've been using it now for a month and outside of having to fuss with some setting early on and reinstalling the OS 2 weeks in because I broke some stuff. I've been perfectly happy with my computer.

I'm not the most tech savvy despite my CS degree and I don't really get more than the surface level of the various arguements for and against systemd.

But I don't like feeling like I'm getting screwed or setting myself up for getting screwed in the future. I wasn't aware that my system had even had SystemD pre-installed until an emulation thread a week ago where someone pointed out that Mint 17 runs off a different init. Until then I had just held off applying the update that was in the update manager for weeks thinking that would have installed it.

This might be a question more about OS preference but I like Mint and is there any problem just downgrading to 17.3? All of the stuff I use should still work right? And is there a WINE repository that doesn't pull in SystemD? I would appreciate any help or advice because while I don't have any negative personal experiences with SystemD, I also don't see a lot of convincing praise for it with the limited understanding of software architecture I possess.

>>825043

>but I like Mint

>using a jewish supported distribution

>not using Trisquel or Ubuntu Mate

>>825043

>using the jewest distro

>(((cinnamon-experience)))

>>825056

>>825098

stop lying and samefagging your lies

>>825043

Realistically your init doesn't matter, anon. If you let the autists tell you what you should use, realistically you're going to be on OpenBSD with only a framebuffer in no time.

>that doesn't pull in systemd

I dunno what you're even talking about with systemd as a dependency for WINE. Someone fucked up a dependency chain somewhere. Or you don't know what you're talking about. It's probably the latter, and this is why it's fucking hilarious when autists espouse their opinions, because people who don't know any better take them seriously.

Use whatever you want. systemd works, and on a desktop you're not going to touch it. The retards are appealing to "simplicity" but the simplicity is a hinderance to complex things like desktops or complex dependency chains.

To really understand why systemd is necessary, take a look at Macfags jerking off to launchd.

http://paul.annesley.cc/2012/09/mac-os-x-launchd-is-cool/

systemd is basically launchd without the XML, and done right.

There's also many rebuttals to the retarded "simplicity" cargo cultists.

In fact, the simplicity morons arguments have degenerated so much that I haven't even had a need to reference any of these blog posts. They're a great start as to why they're wrong:

https://tim.siosm.fr/blog/categories/systemd/

Like the "splitting of PID1" argument, and many more. They're not meant to be taken seriously. They're just zealots.

So use whatever you want. But clearly you don't know what you should even use, so why bother having an opinion about it? Why concern yourself with it?

>>824959

>That's not a systemd bug, moron.

Oh, so that's why RedHat assigned it to the systemd guys who said it was an issue with systemd and took 2 years to do anything about it I guess.

>SysVInit in "rescue" did not start SSH either.

Oh, I guess I was mistaken when I relied on this for my VPSes failing to mount an EBS volume.

>Defer mounting network filesystems until before the unit that needs it

Oh, I guess no one needs writable storage on instance store images during boot.

Thank you for correcting me, wise anon.

>>824329

I would like to LFS a functional thingy ma jig like NixOS or GuixSD, then maybe i'd know what the fuck is going on in my own OS

>>824963

FreeBSD.

>>825112

>I dunno what you're even talking about with systemd as a dependency for WINE

That's actually what I was referring too

>Someone fucked up a dependency chain somewhere

Ok

>Or you don't know what you're talking about.

I don't know where you thought I did. I was pretty clear that I have no real grasp of the topic outside of a surface level knowledge multiple times. But I also state that I'm the type that doesn't like feeling like I'm getting screwed and at the very least I am aware that some major Distros are foregoing their usual inits for Systemd and it's not a universally praised move so I am believably concerned.

>But clearly you don't know what you should even use, so why bother having an opinion about it?

I don't. I'm very clearly someone who isn't as deep into computing and Operating systems as others, I picked an easy beginners distro because I just needed something that works out the box. But I also got fucked by Microsoft for years with updates that removed control from me in certain areas or broke my drivers when they went through so I'm more than interested in undertanding what this thing is and how it can affect my computers. Sure I can just choose not to update stuff with Linux much easier than it was to deny microsoft updates but I also would like to keep my systems up to date since I feel more comfortable doing it that way.

I honestly came here to ask questions because I know I'm ignorant of this topic.

>>825141

>I'm very clearly someone who isn't as deep into computing and Operating systems as others

Was your CS degree very math/theory heavy?

>>825131

https://pdos.csail.mit.edu/6.828/2017/xv6.html

http://minnie.tuhs.org/cgi-bin/utree.pl

http://www.ponyos.org/

https://en.wikipedia.org/wiki/Operating_Systems:_Design_and_Implementation

>>825131

>>825149

Oh, start here: http://www.tldp.org/HOWTO/Bootdisk-HOWTO/index.html , if you just want to roll your own Linux distro.

>>825121

I thought you just said that systemd did nothing about your bug? You can't have it both ways.

>relied on this for my VPSes failing to mount an EBS volume

Yeah, you were. Because you weren't in emergency shell mode.

>Oh, I guess no one needs writable storage on instance store images during boot.

That depends entirely on the dependency chain. If you explicitly tell it to not fail, it's going to shit itself. You should defer loading it until the service that requires it, and then only the service would fail, not the very early boot process.

Again, you're blaming a tool that apparently got a bug fixed but you're angry about it, and there's not one bug in that report, it encompasses a bunch of edge cases. Give me specifics, and I'll tell you where you are terrible at operations. Because it's clear that this is the case.

>>825146

>Was your CS degree very math/theory heavy?

There was a heavy math emphasis yes.

>>824334

faggot

>>825043

If you're a frequent TOR user, I would suggest you to remove systemd from your computer. Who knows how many vulnerability are there just because you're using that stupid (((defected by design))) init.

>>824770

BSD is solid. and you know, actually documented unlike most of the systemd infestation.

systemd is a mostly successful attempt to co-opt the linux ecosystem. nothing good lasts forever I suppose.

>>824603

>>824452

its not real?

http://news.softpedia.com/news/Linus-Torvalds-Block-All-Code-from-Systemd-Developer-for-the-Linux-Kernel-435714.shtml

>>825243

>You should defer loading it until the service that requires it, and then only the service would fail, not the very early boot process.

You don't seem to understand. Most 'enterprise' VPS deployments boot read-only images. They learn their role and assemble the read-write components very early in the boot process as they fucking have to you moron.

>Give me specifics, and I'll tell you where you are terrible at operations.

>I'm too clueless to even know what the problems are but I'm sure I've already got them solved

>>825329

https://www.itwire.com/business-it-news/open-source/65402-torvalds-says-he-has-no-strong-opinions-on-systemd

>Not just installing Android AOSP on your computer and then installing the GNU libs and core utils on it

>>825346

>They learn their role and assemble the read-write components very early in the boot process as they fucking have to you moron.

Yeah, that's shitty architecture. You're orchestrating a deployment, with a fstab mount set explicitly not to fail, and then it fails for some reason, probably because of your shitty infrastructure, and then you blame the tool for not letting you pick up the pieces of your shitty failed deployment manually for some reason.

You're orchestration is fucking retarded, and whatever company you're at is obviously terrible at operations.

>>825366

>>825346

Further, how would you do it right?

You would read the role/configuration from a reliable source of truth (remote URL, network metadata service, hypervisor bridge) and your deployment simply doesn't fail at all, let alone so often that you're remoting into it to pick up the pieces.

How shitty are your operations that you regularly SSH into a fucking machine deployed from a read-only image (probably all with the same read-only SSH host keys lmao)?

Terrible. Git gud, my friend.

>>825367

>>825366

Although, honestly, you don't seem to understand much about configuration management or infrastructure automation so I can see why you're working at a shithole. Don't be so hard on yourself anon. It's okay to blame a tool for your inadequacies or deficiencies of those who built your operation, but don't be angry if someone calls you on the fact that your deployments have to be rescued manually via SSH when they fail to mount a EBS volume, lel.

>>824571

>We needed a new init system in the first place because it made init configuration a lot easier than sysvinit.

No, we needed a process supervisor. The sysvinit was fine and continued to be fine, we just needed something to manage our daemons. systemd was first introduced with "all-in-one init and process supervisor" (wow! that hasn't been done before!) and was promptly shilled everywhere by RedHat and was tangled into their other products so replacing sysvinit with systemd was mandatory if you wanted to use a lot of things. Then they consumed all system managing daemons like udev, dbus, syslog etc. The rest is history.

I propose sysvinit + a process supervisor as a better alternative. It works like magic, the configuration files don't get out of hand (syntax sugar/special config files just like systemd), and the services do not have to daemonize; they can run as foreground processes with stdin set up for signals or data input and stdout/err set up for logging. It's all the benefits of systemd without systemd.

>>825384

Yeah, except process supervision isn't the only thing that systemd "solves." Also, are you retarded? Red Hat switched to upstart at first and didn't even want Poettering to develop systemd any further.

Then Upstart turned out to be a broken piece of dogshit, worse than sysvinit.

>>825366

Maybe one day you'll get to play with the big kids, anon.

>>825436

Yeah, nah, prove me wrong. Also, I was spot on about the duplicate SSH host keys, wasn't I? Nice "enterprise" operation you got running there, retard.

How big boys do it is that they use sane configuration management or infrastructure automation tools, read-only images or not, but you're not going to experience anything like shitting out to emergency.target because you'd use your brain cells to defer mounting of an EBS volume until the service that needs it for R/W it starts running. And definitely not set to nofail in fstab.

Presumably in your "enterprise quality" infrastructure you'd also have centralized logs. Oh wait, I guess not, since you're manually SSHing into your failed deployments to fix them.

Since you insist that you want to be berated like this, I'll continue to make you look like the retarded pajeet that you are. Duplicate host keys tbh. SSHing into it at all, tbh. Good stuff.

Learn to use proper IA and CM tools, dipshit.

>>825436

>>825465

>definitely not setting nofail

Or rather, setting nofail. But realistically, you're not going to mount EBS in a way that will shit out to emergency.target. That's because you don't want remote-fs or local-fs.target to depend on the mount, only the service that needs it for R/W.

Quick example that I found in five seconds using google, maybe this will get your noggin joggin about how to properly unfuck your pajeet infrastructure and use systemd properly:

https://medium.com/production-ready/a-little-story-about-amazon-ecs-systemd-and-chaos-monkey-8bc7d1b5778

>>825470

>linking webdevs on medium who ignore errors to support your position

You are truly the master of the nine nines.

Best programming language to learn for cross-platform (Linux, windows, Linux, maybe android too) standalone executables in the coming decade? New to programming but that would be my ideal language.

>>825518

Linux, Windows, Mac*

>>825519

>>825518

Fuck, wrong thread. Polite sage

>>825384

This sounds really bizarre.

You made a list of a few systemd advantages you could think of, and then you propose alternative software that has those advantages by doing the exact same things as systemd does.

Don't you see the logical end result of that approach?

>>825129

>thinks (((they're))) telling the truth so the anti-semetic userbase won't collapse

>>i don't want to receive money from israel

>not the other way around where they give donations directly to israel

PICK ONE

>>825515

The "error" doesn't happen on anything but XFS. Arguably, the kernel driver is correct, but that's contrary to their use case. If they used any other filesystem, the failure would be properly monitored.

Futher, they could have a daemon that checks for this and properly unmounts, thus being totally self-healing, if I skimmed the article correctly.

>web devs

Just because has docker in their headline doesn't mean it's a web dev topic.

You got shit on anon, just stop. You know you were wrong at this point to argue that it was systemd's fault that you have a terrible operation.

>>825568

>the anti-semetic userbase

That's a minority. Probably a small one.

>>825348

so he doesnt have opinions on systemd, but he does on shit programmers

>>825630

It doesn't matter who's at fault. You do not design your systems to continue after an error, ever, if you want reliability. You're mentally stuck in webdev territory, and worse, are listening to webdevs on reliability when webdevs do not really care about reliability.

>>825630

Also,

>docker

lol

>>825780

Avionics are a good example actually as at least back in the '90s when last I knew anything about their design the critical systems were built in a similar way to what I described. Triple redundant systems where if one failed to agree it was immediately reset (as random output is far more unsafe than no output) and the output was the value from the other two.

If you want real reliability, that's how you engineer away all the random failures. And like I said, this is a similar mindset to what the big boys do with servers.

>>825639

Most people hate the Jews, they just pretend otherwise out of fear of retribution.

>>825756

>You do not want your systemd to continue after an error

It doesn't. It literally crashes the plane with no survivors in that context. The container should be killed if a volume is forcefully unmounted. Only the error is "ignored" by systemd because the XFS driver does not unmount it. It's not really ignored, it can only have the information the kernel gives it, and the kernel does not unmount it, thus the mount is still "active" even though any attempt to read or write will I/O error.

You're grasping at straws on a one-off example that was only illustrative of using mount units and depending on those mount units for the service that requires R/W. Not putting the mount in fstab in early boot like a retard where it will shit out to emergency.target if it fails.

It's clear that you don't understand any of this because you don't actually orchestrate anything sane. You blamed a tool for getting a job done even though your fucked up infrastructure was at fault.

>>825880

Also, it's totally configurable if systemd continues after an error. BindTo in this context ensures that the system explicitly requires the mount and will be killed when it unmounts.

How you continue to try and save face is amusing, but anyone that's not a retard will realize that you're just incompetent.