Half-truths can and slightly inaccurate statements can be construed as either hard-TRUE or hard-FALSE.
On the opposite side of the political spectrum, "nuance" in political discussion is an accepted reality.
Gatekeeping is acknowledged as a problem - we know those who position themselves as arbiters of truth are not beyond scrutiny.
It would be contradictory to know these are true but also believe conservatives are deluded in believing that fact-checking is fraught with bias.
>Indeed, conservatives have long claimed that fact-checking was riddled with anti-conservative bias and even conflicts of interest (as when PolitiFact, one of Facebook’s six United States-based fact-checkers, shot down a critique of a Clinton Foundation initiative without disclosing that one of that program’s principal funders was a major donor to PolitiFact’s parent organization, the Poynter Institute).
In the mid-2000s I once tried installing Windows XP to a 16GB eMMC drive that was in a PCI slot adapter on my main PC. It did install successfully, just as it would on a normal hard drive. It did boot. The only problem (besides it being only 16GB) is it took forever. The PCI slot transfer speeds were slow. The eMMC card itself was slow. I can't recommend doing it, but it does work.
I always thought systemd would be a messy pioneering attempt that would be redesigned later on. Because dependency based parallel boot is a good thing.
* The entire line is more a riff on "It's the Journey That Counts"[1].
* The name systemd is recast as an eponym for all init processes. This is only poetically significant, but essential to interpret the remainder correctly.
* The reference to "real" is obliquely evoking real mode as a proxy term for all boot-time activity (to this day, all x86 CPUs start in real mode, notwithstanding that by the time init is spawned we are most definitely not supposed to be in real mode anymore, Toto)
* Outwith the kernel there remains no more quintessentially Unix process than PID 1. You can take my shell, my text utilities, even make, uucp, and cpio, but you'll pry the general concept of an init from my cold dead fingers
* The traditional language of Unix systems programming is C.
* Rust certainly is one of the few potential successors to C as a systems programming language.
* The ordinal successor to C is D; deliberately playing on the d in systemd as though it stood for something more than the mundane "daemon", because it does: the name is itself a punning reference to a French term, "Système D", meaning, roughly, "one's ability and need to be resourceful in an adverse situation".
* Ergo, both mechanically and allegorically: to truly prove its worth, there must exist a generally usable init written in Rust.
* The hidden reference to real mode now evokes an even loftier goal, viz. writing the entire kernel, bootloader, and BIOS in Rust
* A common form of the meme was/is: "The real treasure is the friends we made along the way". The implication by distinction being most certainly that systemd is a false treasure, and that the systemd project is not a friendly one (a sentiment some may find controversial, but hardly without evidence).
So the statement
The real systemd is the programming language we made along the way
is therefore a meditation on the past and present of Unix boot-time initialisation, but particularly embedding the suggestions that the greatest long-term value of systemd (both as a program and a project) is ultimately as a stepping stone, a collection of teachable moments regarding both implementation and community engagement, and that if Rust wants to be taken seriously as a systems programming language then a viable init process written in Rust certainly seems like a good idea.
Accusations that this is all tantamount to intentional RESF upvote sniping are perfectly cromulent.
What features would a "slimmed down version of systemd" provide that isn't available in various independent tools we used to use (and still use today).
* Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
* journald? Logging tools - including multiple types of syslog daemons - are numerous; use whatever you want. Choice is good. Even journald could be an option some people might prefer If it wasn't monolithically tied to systemd and could be used as a stand-alone daemon.
* cgroups? Other managers exist.
* timedated? Managing the clock was never difficult. The standard solution is to delegate most/all clock management to ntpd. If you had especially unusual needs, you probably had to set it up manually anyway (probably with a tiny amount of sh script).
* udevd? Other hardware managers exist. Some of us prefer the peace-of-mind of a simple static configuration instead of a manager, but you should be able to use udevd if you prefer it; udevd used to work stand-alone, but Lennart added it to the systemd monolith[1] when they were trying to push kdbus into the kernel. -sigh-
* daemon/process management? daemontools, runnit, s6, etc.
* logind? This attempts to create the concept of a "session" as a privilege boundary that is orthogonal to the actual privilege boundary in UNIX: the UID. The entire concept is a terrible security problem waiting to happen. The entire concept of a session is especially stupid considering most people don't actually use the traditional multiuser features of UNIX or this new "session" concept. In the rare situation where someone actually is running an actual multiseat setup, an extra step to install an optional package with these features wouldn't be a burden. The rest of just need a simple login/password prompt that can launch gnome/kde/.xinitrc/whatever at login time, which already existed as {x,g,sd,lx}dm.
If there are features that were only provided by systemd, is a monolithic[1] daemon really the best solution? Or could those feature simply be encapsulated into a small stand-alone package that could work wherever it is needed?
edit:
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
Systemd's real value proposition is its tight coupling. As you pointed out, there were several logging systems, several daemon programs, several hardware managers, a combinatorial smorgasbord of options available.
This means you can't assume almost anything about the distro or setup you're targeting as an application developer. Should I log to /var/log or use journald? Can I bundle a .service file or should I have shell scripts? Can I rely on udev rules or do I need to touch /dev? You can't assume unless you're only targeting Ubuntu.
Systemd is so integrated that programs require minimal porting. The alternative is either supporting everything, which leads to massive bloat, or forcing downstream patches to make the damn thing compile and run. Having a non-modular set of services you can rely on means even small alternative distros like NixOS can support many packages, because those packages require minimal changes.
Consistency across environments is critical. it's why docker is so big - all the wiring lives in one place, and what's inside runs everywhere.
But reducing choices to get consistency and consensus strips away the freedom that Linux offered - you can't uproot and replace components as easily. You can have that freedom or you can have a hassle-free package ecosystem; it's an inherent trade-off.
For resource quotas? Cgroups is a kernel interface. What kind of manager do you have in mind?
> daemon/process management? daemontools, runnit, s6, etc.
None of them can deal with runaway daemons. Some of them can deal with ordering and pre/post conditions and instancing, but not as extensively. Each provides a different subset of systemd's init features.
> Running/waking a program from network activity? inetd (xinetd) has been doing that since the '70s.
Inetd works in entirely different way. Those approaches are not comparable at all. (Systemd can hand off the whole listening socket)
All of the tools you mentioned have different syntaxes. With sd I onlt have to keep a single syntax - ini files - which is incredibly more efficient than ten years ago when I had to memorize a dozen different things to make my system run. I'd rather slit my wrists than write another init script in bash / dash, even for the simplest service.
Mo, they don't. They are merely a prerequisite. It must be reasonably possible to reimplement the module in question and it must be possible to instantiate that alternative implementation instead of the original one.
A counter-example is to have all lodules linked into a single static binary. You may have a beautiful separation berween modules in there, but the static linking makes them an immutable bundle.
I love the concept, and would use it daily if there were features for adding/removing/viewing favorites. This is something that the official API doesn't support, so it's not something I'm faulting this application for. Impressive for sure.
Also +1 on wlqlwlql's dark-mode idea, although a color theme in general might be a better approach (but perhaps overly complicated?).
This might not be addressing your issue directly, but for my browser extension Refined Hacker News [1], once a user is logged-in in the browser site it is fairly simple to "construct" the favorite-ing endpoint URL. The URL endpoint is "/fave" and requires two query parameters: `auth` and `id`. "auth" is a random string that is unique for each story/comment and is generated from the HN server (it's required for authorization of the "favorite" request), and "id" is the story/comment's ID number.
The auth string of a story for "fave" is the same as the auth string for the "hide" and "flag" links (since they are already present, the links' hrefs contain that auth string), and so we can extract the auth string from their hrefs and use it for favoriting and un-favoriting.
The "favorite"/"follow" function is something I was also thinking about. I have some ideas about it - something like an extra feed window where only favorited (and related) things show up.
Regarding color themes - these are super easy to add.
Half-truths can and slightly inaccurate statements can be construed as either hard-TRUE or hard-FALSE.
On the opposite side of the political spectrum, "nuance" in political discussion is an accepted reality.
Gatekeeping is acknowledged as a problem - we know those who position themselves as arbiters of truth are not beyond scrutiny.
It would be contradictory to know these are true but also believe conservatives are deluded in believing that fact-checking is fraught with bias.
>Indeed, conservatives have long claimed that fact-checking was riddled with anti-conservative bias and even conflicts of interest (as when PolitiFact, one of Facebook’s six United States-based fact-checkers, shot down a critique of a Clinton Foundation initiative without disclosing that one of that program’s principal funders was a major donor to PolitiFact’s parent organization, the Poynter Institute).
https://thehill.com/blogs/pundits-blog/media/310849-who-will...