The fact that systemd continues to get hate, ~15 years after mass adoption, is a cultural phenomenon worth understanding. Benno Rice of freebsd gave a super interesting talk about this: The Tragedy of systemd: https://www.youtube.com/watch?v=o_AIw9bGogo
I can only imagine how long the Wayland haters will be writing blogs once LTS distro start shipping Wayland-first desktops. Looking at the whole upstart/systemd drama, I'm guessing we'll hit the 2k38 bug before they'll find something new to write about.
Not only is systemd strictly better, they had really extended themselves to make migrating services as simple as possible rather than assert you have to follow a new status quo entirely.
Allowing services to incrementally and optionally adopt features was the key part.
but you can adopt incrementally, thanks to XWayland. sure it's not the same, but unlike systemd vs sysv-init, you can't run two windowing systems side by side with equal privileges unless maybe you have two monitors and graphic cards. one has to be the one that controls the screen. and the other must necessarily run as a client inside it. wayland-on-X may have been possible, but it would have limited waylands capabilities and development.
i am willing to bet that there are systemd haters out there that love wayland and would make the exact reverse claim.
> but you can adopt incrementally, thanks to XWayland.
Wayland's weakest point is a11y and automation tools, which XWayland doesn't work for.
> sure it's not the same, but unlike systemd vs sysv-init, you can't run two windowing systems side by side with equal privileges unless maybe you have two monitors and graphic cards. one has to be the one that controls the screen. and the other must necessarily run as a client inside it. wayland-on-X may have been possible, but it would have limited waylands capabilities and development.
You can do both, actually; XWayland can run an X server in a window, and many Wayland compositors will run in a window on top of an X11 server. It's not seamless, of course, but it does work.
You don't understand. Everybody who doesn't like the things I like is the same: bad and stupid. Or maybe you do understand, because suddenly Wayland came up, and since you personally are annoyed by it, now this style of argument is "gaslighting."
It's not "gaslighting" it's just name-calling and argument through insinuation about other people's characters, rather than substance. It's not even ad hominem, because you assume people are arguing in bad faith because of the positions they've taken, not because you know a thing about them.
As a systemd user but Wayland "hater", to me the big difference is that you can adopt systemd without losing functionality - e.g. you can configure systemd to run sysV init style init scripts if you insist and no functionality is lost. The "complaints" in the linked article, are minor and about options that can just be turned off and that are offering useful additional capabilities without taking away the old.
Whereas with Wayland the effort to transition is significant and most compositors still have limitations X doesn't (and yes, I realise some of those means X is more vulnerable) - especially for people with non-standard setups. Like me.
I use my own wm. I could start with ~40-50 lines of code and expand to add functionality. That made it viable. I was productively using my own wm within a few days, including to develop my wm.
With Wayland, even if I start with an existing compositor, the barrier is far larger, and everything changes. I'm not going to do that. Instead I'll stick with X. The day an app I actually depend on stops supporting X, I'll just wrap those apps in a Wayland compositor running under X.
And so I won't be writing blog posts about how much I hate Wayland, and hence the quotes around "hater" above. But maybe I will one day write some about how to avoid running Wayland system-wide.
If Wayland gave me something I cared about, I'd take the pain and switch. It doesn't.
Systemd did, so even if I hadn't liked it better than SysVinit, I'd still have just accepted the switch.
If I one day give up Xorg, my expectation is that it'll be a passive-aggressive move to a custom franken-server that is enough-of-X to run modern X apps coupled to enough-of-Wayland to run the few non-X-apps I might care about directly (I suspect the first/only ones that will matter to me that might eventually drop X will be browsers), just because I'd get some of the more ardent Wayland proponents worked up.
I remember the good old days of xfree86. It was arse but mostly worked OK on a PC. Then this blasted Xorg thing rocked up and it was worse for a while! Nowadays I can barely remember the last time I had to create an xorg.conf.
Wayland has a few years to go yet and I'm sure it will be worth the wait. For me, it seems to work OK already.
> you can adopt systemd without losing functionality
Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Create a unit instead. It's not much but systemd is full of little annoyances like this one.
> [] offering useful additional capabilities without taking away the old.
Once they introduce capabilities, the old quickly becomes irrelevant due to sheer mass of systemd crowd.
After they have introduced timers, it suddenly became clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. The same can be said about syslog/journald drama. Now they decided they want sudo replaced. Up next: something else that you cannot even think of, is already on their radar.
> Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades.
Have you tried?
At least on Debian and Ubuntu, if /etc/rc.local exists and is executable, systemd-rc-local-generator will auto-generate an rc-local.service unit that will run rc.local.
If the unit isn't visible for you, create an /etc/rc.local file. chmod +x it. Then run "sudo systemctl enable rc-local.service". Then try "systemctl status rc-local.service".
If your distro has the relevant generator, you'll see something with a line saying "Drop-In: [some path]". If so, "systemctl start rc-local" should run your /etc/rc.local, and/or it will run after reboot.
In other words, you can easily have /etc/rc.local running on boot.
On Debian and Ubuntu, you can do ls /usr/lib/systemd/system/rc* to see the compatibility options for SysV init that are available to you.
If your distro doesn't ship with an rc.local drop-in and generator, then put this in /etc/systemd/system/rc-local.service:
Then run "systemctl enable rc-local.service". Now, as long as /etc/rc.local is executable, it will be run on startup after your network has come up (you can change the "After" if you want to trigger it based on another condition instead)
> clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking.
Cron is severely limited compared to systemd timers, but nothing stops you from also running a cron. I have anacron running on my systemd setup because I agree it serves a lot of needs perfectly well. It coexists just fine and lets me use a cron for the simple stuff, and systemd timers for things that requires conditions cron can't handle, such as e.g. advanced preconditions.
I believe that last time I tried, systemd had different semantics (no mask/unmask, etc), but memory might fail me here.
Thing is, I don't want to do any of those things. It is not looking healthy to me that a simple unix instance needs dancing around to execute /etc/rc.local. The only solution that looks sane to me is "if /etc/rc.local is present and executable - run it". Yeah, I can understand the security implications of that.
> but nothing stops you from also running a cron
For now. Apple already deprecated and banned cron from running on macOS instances in favor of their absolutely batshit insane launchd (which was the inspiration for systemd, hence the inherited brain damage).
Before long Ubuntu will ship with no cron installed and then just a bit later it won't even be available in packages. Not even as a rust rewrite.
Only if you're running a distro that lacks basic defaults from Systemd. Are you a distro like that? Have you tried just creating /etc/rc.local and seen if it gets executed?
It's not systemd's fault if your distro ships with a broken systemd install.
> "if /etc/rc.local is present and executable - run it". Yeah, I can understand the security implications of that.
That is indeed what happens if you're on a distro with a non-broken systemd install.
> Before long Ubuntu will ship with no cron installed and then just a bit later it won't even be available in packages. Not even as a rust rewrite.
> It's not systemd's fault if your distro ships with a broken systemd install
Technically yes. Realistically systemd fosters insane decisions like ssh socket activation or killing of cron by providing features. Useless, unnecessary, unwanted, unrequested features that solves no real problems.
Wait until they start from scratch by rewriting everything in Rust. This absolutely will happen one day.
We're never going to agree on this. I have plenty of issues with systemd, but as I've shown you, the rc.local support you claimed isn't there, is in fact there, and doesn't require you to do anything, and then the goal posts moved to pure fear over features you don't like and the hypothetical removal of things they have no control over.
That's interesting, but I really would rather write something stripped down with X as the base, though. This might be a good intermediary step, though.
It just feels like the wrong approach to me. Ripping the buffer management/KMS/DRI part out of a Wayland compositor as a starting point is reasonable, but if you pull XWayland along you pull most of Xorg along, with most of the maintenance / legacy hassle that brings.
An X server selectively deprecating older functionality can be lean. There are lots of the protocol you can just ignore, and what's left is fairly easy to implement. Time consuming, but easy.
> An X server selectively deprecating older functionality can be lean.
Is that actually true?
The big problem is that Xlib uses a lot of the dusty corners and the people using X11 apps expect those dusty corners to work. And Xlib is very, very, very badly architected in many places and you still have to do something sane or the apps won't work.
If you get Xcb right, you at least pick up Qt and that gets you probably 80+% of the modern apps.
It really depends on your personal needs, so your mileage may wary, but having run xtruss on most of the X11 programs I use: It's true for me at least.
The key thing is that most modern clients (and Xlib vs. Xcb doesn't matter much in this respect) use exceedingly few features of the protocol.
E.g. you'll find very few modern clients that actually uses the X protocol to draw lines with any complex options. You'll also find very few attempts at using exotic visuals, because most X servers won't support them anyway.
To take a more extreme example: You could probably get away with just ripping out most or all server-side font-rendering support. Most modern X apps use Xrender, and render the glyphs client side and creat a glyph set via Xrender or just render the whole buffer client side.
Removing those will break apps, including some that some people care about (like xterm), but API surface is similar enough that it'd be reatively easy to fix the few apps people care about, or just providing an optional shim for Xlib as a temporary measure.
For own my own use, if I were to write an X server to meet my needs, I'd just not support it - I've checked with xtruss and none of the apps I care about rely on server-side fonts at all, and none of them use any drawing primitives but the most basic line drawing and rectangles either, and all of them are capable of handling an X server that refuses anything but truecolor visuals.
I could rip out large parts of the drawing code from Xorg and all the apps I run would still work just fine...
For other people, of course, this would be a different matter, and that's fine. But I think moving a bunch of that code to an Xlib-compatible library to handle client side as a means to carry over legacy apps would be an option as a means to let people evolve leaner X servers and move shift the hassle of managing legacy code to those who care about the legacy apps.
I mean unless you're going to commit to maintaining xlibre or something, wayback seems like the future for x-based desktops.
> [wayback] is intended to eventually replace the classic X.Org server, thus reducing maintenance burden of X11 applications, but a lot of work needs to be done first.
> With Wayland, even if I start with an existing compositor, the barrier is far larger, and everything changes.
I mean, no one puts a gun against your head to use Wayland, X will be on life support for decades and will likely work without any issue.
But with this stance, no evolution could ever happen and every change would be automatically "bad". Sure, changes have a downside of course, but that shouldn't deter us in every case.
Plenty of evolution can happen. The problem with Wayland to me is that it's not evolution, but a step backward. It's forcing a tremendous amount of boilerplate and duplication of code.
X can evolve both by extensions and by "pseudo extensions" that effectively tell the server it's okay to make breaking changes to the protocol. There are also plenty of changes you could just make and accept the breakage because the clients it's break are limited.
I don't mind breaking changes if they actually bring me benefits I care about, but to me Wayland is all downside and no upsides that matter to me.
By whose definition of sanity? systemd haters often believe that it is sysvinit that was sane while it is systemd who is insane. I am one of those people but being systemd hater I'm obviously wrong because old.
Dude’s been arguing with people since at least 2012 that systemd is a good thing. It took me less than a minute to figure that out by searching his blog.
PulseAudio also drew a lot of disapproval, until Pipewire appeared and finally did the same thing (and more) well.
Maybe systemd (service management, logind, the DNS resolver, the loggig system, etc) will eventually be re-implemented in a way that does not have the irritating properties of the original systemd.
/* I'd say that systemd feels like typical corporate software. It has a ton of features to check all the requisite boxes, it's not very ergonomic, it does things the way authors wanted and could sell to the corporate customers (who are not the end users), not the way end users prefer. It also used to be bug-ridden for quite some time, after having been pushed upon users. It comes from Red Hat (which is now a part of IBM), so you could say: here's why! But, say, podman also comes from Red Hat, and does not feel like such corporate software; to the contrary, end users enjoy it. */
> Maybe systemd (service management, logind, the DNS resolver, the loggig system, etc) will eventually be re-implemented in a way that does not have the irritating properties of the original systemd.
One the topic or an eventual successor, one of the aspects of systemd is how intertwined all of it is.
It’s really hard to replace just one part without either (1) replacing it with another which the same general design, or (2) remove all of systemd entirely.
Take what op is taking about for example. Instead of relying on small, reusable components for sanboxing, it just re-implement all of it into the monolithic service_manager+service_supervisor_sandboxer+…
You can’t even think of replacing the service supervisor or the logging subsystem without replacing all the other parts.
Of course, I won’t deny that this design has its upsides: this monolithic approach ships a lot faster than trying to integrate different components to work together.
Rather, Gnome stopped supporting ALSA directly around 2007, and Firefox did the same in 2017. Yes, you could use alternatives like JACK or sndio. The point was that a new Gnome broke the reliance on ALSA, as a user, you had to migrate off ALSA which you likely had used for a decade before. Naturally, most users migrated to the best-supported option, the distro's default, which was Pulse Audio both on Fedora and Debian.
Hey, now I am interested in more of such softwares overall.
Like imagine a list where we can create a form where people can give them and give reasonings or just something.
What if I can create a github repo and issues regarding this so that we can discuss about them and I can create a website later if it interests but its a really nice thought experiment.
Are we talking more about uh every software including proprietory too?
Are we talking about lets say websites too or services (what if we extend it to services like websites or even products outside of software niche into things beyond too, that's interesting too)
Another interesting point that comes to my mind might be that cryptocoins might be the lowest inverse to this software project in the sense that I believe that there was very little net positive done to all humanity in general, sure the privacy aspects are nice but still, its not worth having people invest their life savings into it thinking that its going to 100x y'know, I have created a whole article about it being frustated by this idea people think regarding crypto as an investment when it could very well be a crypto"currency" but that's a yap for another day.
I really nerded over this and I think I loved it, we need a really good discussion about it :>
My mom and dad live in a country where there is a dictator, and that there has been restrictions to send money there. I'm happy that I can send crypto usdc over Solana and then the cost is basically a few cents to my family
I am all for stable cryptocurrencies but not cryptocurrencies which prey on desperate people wanting 100x returns or promising too much that we all know is BS for hype and not delivering on it.
I myself am a teenager and uh had gotten some 100 ish dollar from winning competitions in crypto space (not that much, but I am proud of it kinda money) and uh I couldn't really get that money if it wasn't for crypto y'know.
If I hadn't made my stance clear, I am all for stable cryptocoins but that is just a very (minor?) part of the amount of things on crypto and all others usually generally harm, sure there are some outliers but here's an article that I had made when I ragebaited so hard one day about some crypto thing that I basically just wrote an article trying to explain my situation
"This whole space is still full of scam. 99% of the times everyone has ulterior incentive (to earn money) but still I mean, it kinda exists and I mean still crypto (stablecoins?) are the only sane way to transfer money without kyc"
This is one of the comments that I had written and I hope I can make my stance clear. I just searched and found that I have written about stablecoins 10 times almost seperately in the article and uh I am all for stablecoin and I think even In my original comment, I may have said that stablecoins are the only thing that is remotely nice about cryptocoins,maybe monero if we are really streching it.
I saw a r/cryptocurrency poll of someone saying that they are 97% for the money and 3% for tech and that point this is almost like polymarket gambling except being even worse and more out of your control, almost giving someone your money if you invest in some memecoin
I kinda (like?) stablecoins (even gold like paxg is good) but not much anything else as a baseline of token for the most part, i myself have usdc in things like stellar/polygon which also have low gas fees for the most part
So what are your thoughts? I hope I can make my stance clear lol,
Yeah I understand what you mean, actually I've been investing in Solana, since it's the one that allows for low cost transactions and I feel like it's the network that's actually being used for useful stuff (stripe, visa are working on building on top) so I made 30% in return. Since cryptos are risky I didn't put much money and only made 50$, But I'm faithful of the development of Solana, stablecoins and the like.
uh, the point I am trying to make is that sure you might invest into solana for less gas fees but the point is that, you used it with usdc, I am not sure if solana requires some minimum balance of solana or smth, i think it does but just because people can pay less fees while paying usdc on solana chain doesn't make me believe that solana's native token price should increase if the gas fees are low...
Like, quite frankly, they are all driven on speculation. Sure there is some aspect of investment but the reason I believe in stock markets or even money is that they grow because people get somewhat more productive over time from all agreggates whether its through tech or just innovation or just learning from mistakes.
Crypto might grow and it might not grow, its certainly more risky and risky might make it more profitable or loss at the same time.
See the thing is, I believe that things are for the most part kinda accurate in their prices and if they aren't, then I shouldn't want to mess around trying to prove the market wrong. Because mostly its kinda an efficient market with robots that can trade in milliseconds but it was efficient even before that.
I am sure that solana's price is effectively weighed in and if its not, then well, i still wouldn't want +/- 30%
Stripe is also building its own chain (tempo) i think.. I am all for stripe having cryptocurrency too but just stablecoin.
Uh, idk man, I see these people making 30% returns and I think wow, but then I see the amount that they put and the time they invest in and they say that they are "learning" which is great but still, my questions is if this is even smth that you can "learn"
Because the thing is that if you can guarantee me 30% returns for 30 years or even guaranteed 30% or even some previous data to back that on historically, that would be great but even historical data isn't enough sometimes which is why I think of productivity as the final benchmark
My brother had like 1$ in polymarket will btc go up or down, he made 100% in an hour, he gave me all the stats of the world of these max smth curves and how they go and I appreciate my brother a lottt but I can't help but I just don't like this where he feels like he needs to earn money on top of money.
Idk maybe its me but i literally can't predict if solana can get hacked tomorrow and it can make it all 0. I saw some project on HN about how Sui, a literal billion dollar coin is suffering through some sort of not well setup nodes and a malicious actor could thereotically stop the byzantine consensus and might even bring the network down lol.
Maybe I am old schooled when I am a literal teenager but here's almost a pipeline that I feel like "investors" get into,
I have thought of actually writing something of my own coin with low fees with just slightly more programmability than nano to integrate it into something like cosmic while having maybe 0 gas fees but honestly, I would do it for the tech not for the money while the money is lucrative too.
If you really want, there are some better ways like how there was this 2048 thingy launched by some crypto that I kinda won for like 0 fees and got like 100 bucks and i had invested nothing in but i think that it ended.
I feel like the only times I made money was when I was lucky but if I am honest, I kinda made like infinity percent the first few times just doing smth i like / messing around but that's not really sustainable or predictable but neither is the 30% imo.
Also uh yeah some coins might require some basecoin like stellar required 0.5 stellar and 1 to get usdc but i doubt that just because of them, smth like stellars price can grow & there is this usdc project whose aim is to make gas fees also in usdc and I hope that those gas fees could be low as that could be extremely useful imo.
To each their own, I don't even trust S&P 500 at this point given how concentrated they are into AI.
Would love it if you could mail me (see my about me!) . I love talking about it!
I hope you can read the article that I shared and I would love hearing your thoughts.
The tech is cool but people have ulterior incentives. When I say not to & to invest in something as boring as world index funds, i legit don't have a ulterior motive for the most part aside from bringing what I believe a reasonable financial opinion to everybody and hearing them out.
Also side note but didn't knew that you couldn't really name gists or atleast I might have the skill issues to not find a way to change the gist name from this 36b4 thing to something better so that it might be search indexed too but idk lol
I mean, I just thought of a way of curating the software list/discussion without bloating hackernews which might make it a bit difficult to find if someone is looking for something similar imo, i can make a ask hn too but I am more than willing for some suggestions if you have any about it :p
I think I agree. I’m curious what software would be in places 2-10. If we’re talking about HN, maybe excel/google sheets? Maybe C++? Recent versions of macOS always seem to get hate, but I think macOS is in a different category.
Yes, it has a higher learning-curve than incrementally extending your constantly growing deploy.sh-script and there are many moments when it's complex and overkill. When you really need it though, no amount of in-house sysadmin-scripts will cover the same functionality with the same quality. The discussions about it online tend to have a very vocal majority of people from the first bucket, not yet realizing that they are slowly growing into the second.
All that said, it's by no means perfect and some critique is well-deserved, just that a lot of the hate comes from armchair-experts who compare it to running things locally on your laptop.
Very similar in fact to systemd, seen in isolation from an application-developer, it's one more thing to learn getting in your way. Seen from the complete system-administrators point of view, it's a consistent way to manage and secure your fleet.
I think excel/google sheets are generally well regarded in online circles. I also don’t see that much C++ hate, at least not the same kind of viceral hate systemd receives.
