sigmoid.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A social space for people researching, working with, or just interested in AI!

Server stats:

574
active users

#UPSTART

0 posts0 participants0 posts today
Replied in thread

@mcc @dalias @whitequark @becomethewaifu

It didn't replace van Smoorenberg init+rc. It replaced Upstart. The existence of Upstart is the part of history that many people forget or gloss over.

van Smoorenberg init+rc always was a straw man. The Debian committee included it, but everyone acknowledged at the time that the main contenders were systemd, Upstart, and OpenRC.

Replied in thread

@CursedSilicon @gettie mostly because #systemD (and it's competitiors) took all the right lessions:

  • Start less
  • Start more in parallel
  • Resolve dependencies to avoid waiting times

And basically everyone (#OpenRC, #Upstart, etc. Even #LaunchD [the #init for #macOS that is literally the SystemD but before SystemD and by Apple] and #SMF [#Sun's SystemD for #Solaris] did that to allow for boot times in secinds, not minutes…

youtube.com/watch?v=o_AIw9bGog

Replied in thread

@BoydStephenSmithJr @dvandal @david_chisnall @strlcat

This reasoning is based upon a fallacious dichotomy. In the real history, Upstart existed and had a strong competing maintainership, to the level that the #Debian TC itself was nearly split down the middle on #RedHat/#Canonical lines, and the choice was *never* between van Smoorenburg init+rc and systemd.

It was between #Upstart and #systemd, the latter indeed being a reaction to the former, with #OpenRC as a late entrant.

Replied in thread

@fabiscafe @okapi OFC @chesheer 's criticism is understandable on #FreeBSD given that #SystemD is inherenty focussed and intertwined with #Linux (just as it's Inspiration, #LaunchD, is intertwined with #macOS's Darwin/NeXTstep kernel).

  • The problem is after some hefty "init wars" with like #Upstart and others SystemD became the de-facto standard, and the "(statistical) rounding errors" of #BSD users got sidelined, in part because BSDs looked at that mess and went like "Nyet, SysVinit is fine!" and continued their fiddling around...

And sadly there's nothing they (or anyone else) could've done unless they had multiplied suddenly and being able to keepcthe old tech stack maintainable.

OFC I wish for more diversity in solutions, but #Linux being #streamlined is what makes #portability across distros easier and boosted adoption as well as providing massive gains in solutions like #DXVK, #Proton and #Wine in general.

  • And TBH most "#TechIlliterates" aka. "#Normies" frankly don't give a shit what OS they use. All it needs to do is serve them their eMails and allow them to 'consoom themselbes happy' as in watching YouTube, Play games, etc.
BSD.cafe Mastodon Portalchesheer (@chesheer@bsd.cafe)So, known parties tirelessly work to make Linux a new Windows. Gnome announces even harder dependency on systemd. GDM will depend on systemd userdb infrastructure. gnome-session will use systemd service manager instead of its own code that "has received very minimal attention in the 17 years since it was first written". As per article, even now they do not test Gnome in non-systemd environments. It's like a writing on the wall. https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/ #Gnome #Linux #systemd
Replied in thread

@cstross

I enjoyed how spot-on you accidentally were. (-:

Interestingly, people still argue today (as you've probably seen in these threads) as if it were van Smoorenburg rc that was the other choice for Debian et al. back in 2014; which was in reality either Upstart or OpenRC. It's a very persistent erroneous dichotomy.

Replied in thread

@cstross

Right more than you know in one respect; but wrong in another.

#systemd came from #RedHat, not Microsoft; and the upstart was not Linux but a software package from #Canonical that was literally named "Upstart". (There's a whole backstory about the copyright licence that Canonical initially granted.)

Amusingly, Windows NT's Service Controller, its WININIT, and its Session Manager are three distinct things; not like systemd's architecture at all.

@nuintari @stefano no, it's not inherently bad because if #SysVinit and all the.otherbthings were fine, noone would've even considered adoping #systemd.
infosec.space/@kkarhan/1126601

Claiming "it's #RHEL's fault" also goes way too short, cuz they - like #SUSE and #Canonical - do weird stuff all the time.

OFC you can get non-systemd distros and for #embedded applications, the tradeoff of "space" vs. "complexity reconfiguring" stuff does make even a classic init script sufficient (i.e. some #InternetOfShit device that isn't expected to constantly switch WiFi networks doesn't need a config more complex than the config
txt from #RaspberryPiOS)...

Infosec.SpaceKevin Karhan :verified: (@kkarhan@infosec.space)@nuintari@infosec.exchange @pid_eins@mastodon.social @OS1337 Again: I disagree as both #SMF and #LaunchD do more than just #init amd like #systemd are a whole collection of utilities and not a single massive binary. In fact, #journalctl is an evidently better way to debug issues and fix problems with #services / #daemons than having to parse #Syslog through dozens of filters or spechalized tools. Similarly, if #gstreamer & #ALSA / #OSS / #PulseAudio weren't shitshows, we'd not see the need for #PipeWire!