I hate FF since some random morons decided it's a good thing on mobile to use the last used folder for bookmarks, instead of the mobile bookmarks folders.
I have several thousand curated bookmarks. And I only discovered too late the new "feature".
Disrupted my former flow (mark on mobile, sort/categorize on desktop)
They could have made this configurable, but no... those smart asses knew better.
I have that GitHub issue where they initially discussed it for iOS bookmarked and screenshoted, to remind myself how utterly stupid some people are.
I hate every sucker involved.
I use a 1050Ti (needs the closed source driver) with a Debian 13.
Rock solid and the older titles I play even run smooth in 1440p. Not a single crash -- just have to wait if a new kernel arrives and avoid backpirted kernels.
shrug
I don't care:
I can administer with relatively high confidence any Redhat- or Debian-derivate.
Thanks to systems.
Most issues regarding systemd I encountered were due to a halfway adoption (Debian).
Some things like timers are a bit more cumbersome than "the old way", but I wouldn't want to miss the added robustness.
Most things systemd implements lead to _less_ issues.
And writing a systemd unit is pretty easy, contrary to the old bash script mess.
So, no. Keep your Poettering-Bashing to yourself.
I'd rather invest the time in geokking the systemd choices deeper.
Isn't that a selfish view, though? "Works for me,so I don't care that systemd is creating dependencies everywhere for everyone else".
I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives.
Isn't linux about choice? It feels we're going on a downwards spiral where choice is being taken away from us in every domain
> I appreciate that it simplifies some things, but I can't understand that you can't choose which parts of it to install, or even replace parts of it with alternatives.
You can? The system where I'm writing this uses systemd, yet networking is handled by NetworkManager and not systemd-networkd. Time keeping is handled by chrony and not systemd-timesyncd (or whatever the systemd NTP client was called). Etc. Systemd in fact has many components that are optional. Of course, there are also parts of it that are non-optional, just like many other collections of related software.
> Isn't linux about choice?
Linux is "about choice" to the extent that the source code is freely available, and if you don't like what upstream is doing, you have the choice to fork it and do whatever you want. "Linux is about choice" does not extend to upstream maintainers being obligated to cater to every whim of every end user.
Case in point, Devuan: Not being satisfied with the path Debian was taking, they exercised their choice and are now doing their own thing. Good for them! And to the extent this has reduced the frequency of systemd haters starting yet another anti-systemd flame war on the Debian mailing lists, it seems to me Debian has won too. Hooray!
How is it someone's else's fault for that systemd has dependencies or that others depend on systemd?
If I use and like Firefox, and others depend on Firefox, or Firefox depend on others, then it's Firefox fault for you choosing Firefox?
I really don't understand the argument you're trying to make. You had choices before systemd, and you still have choices even though systemd is widespread, what's the problem? It isn't modular enough? Use something else then that is modular.
OK you're missing the historical context here. To make this story extremely short, the author of Systemd was already known for another project that was causing problems to Linux users but was shipped early. And when Systemd was released, it has several issues, too, so some distros like Debian withheld the switch. But at some point the folks at Red Hat decided to tie Systemd to the login mechanism for Gnome. I don't believe there was any hidden agenda here, it was just more logical for them. However, this caused huge headache for package maintainers of non-Systemd distros. There was the whole drama with voting, Debian project leader leaving, Devuan appearing and so on.
I believe most people moved on, but the way it was all done somehow didn't feel right.
Ok, yes, I wasn't aware of the history, I use whatever my distribution uses as default, and been doing that for decades now, as that tends to be less hassle, so been using systemd for a while because of that.
With this new knowledge about the history, I still feel the same as the original question. AFAIK, no one is forcing people/distributions to adopt systemd. It might be easier, and most takes the easiest route, but that's OK, right? That doesn't mean that you cannot make another choice, maybe involving more work, but you can still make that choice, unless again I miss something obvious here.
The problem is mostly that programs started depending on aspects of systemd that are both very complex, and difficult/impossible to implement without ending up with systemd. Systemd's components don't play well with established standards (sometimes not running standalone at all), which contributes to the feeling of having to buy into the whole ecosystem just to use a small part of it, just for that one bit of a certain program that now depends on it.
This has happened with gnome's display manager, and now gnome-shell is threatening to cease functioning without systemd, as well as on systems that systemd doesn't run on such as the BSDs. KDE's new login manager is now doing the same, so in many respects, people's fears have been validated.
Is that "logout" referring to a user explicitly logging out from a desktop environment? I can't imagine it would apply to a closed SSH session, or at least it wouldn't make sense if it did.
> It is now indeed the case that any background processes that were still running are killed automatically when the user logs out of a session, whether it was a desktop session, a VT session, or when you SSHed into a machine.
And the reddit comments include a link to a tmux issue where the suggested solution is for tmux to add systemd as a dependency (https://github.com/tmux/tmux/issues/428). Includes some back-and-forth about how all sorts of software would have to change in similar ways to accommodate systemd, instead of systemd just playing nicely with decades of established practice.
I had no idea about that. Does seem a bizarre choice for systemd to do that.
I admin a whole bunch of headless servers and so am often SSHing to them and running long running jobs. Some of them run VNC sessions, and I certainly wouldn't want a VNC session to kill of other SSH sessions by the same user. At least with VNC, I almost never "logout" - they're often autostarted (by systemd) and just get killed when the machine gets rebooted.
To be clear: systemd works fine to start/stop services. Usually. If you have a working system with systemd, it's rarely worth ripping out and replacing. That's just more risk than reward.
Citing PulseAudio adds nothing here. Distros decided to ship it early, just like systemd later ... that choice wasn’t pushed by Poettering. Dragging in an earlier project without making an actual technical or governance argument is just character framing. It’s not evidence, it’s a smear.
No, I decided to include it to explain the emotional response to Systemd. I didn't mean to offend anyone. That stuff didn't work and broken things were pushed on people again, that's why some revolted.
At the time desktop Linux projects like consolekit were an unmaintained mess, it needed replacements. Systemd also supported cgroups V2 and people really wanted to use that. No conspiracy or underhandedness required.
I don't think anyone would ever object against systemd as a project, it would make as much sense as objecting against, say, GNU Chess. All software has bugs, and they're gradually worked out. But the way it was introduced that made many people upset.
The way it was introduced was that many people could see the value in cgroups V2 and being able to drop unmaintained projects. Maintainers of distros and projects sometimes did this against some users wants, but in my opinion there was just lots of baseless complaining without creating an alternative.
I don't get it. If you install openbsd, you get dependencies that openbsd developers has chosen. You can try to remove every aspect of those choices but at some point it won't be openbsd anymore.
Is the claim here that Red Hat is unnecessary coupling their critical parts of the distribution in ways that other distributions would not do? A few examples here would be nice.
EEE is about taking existing standards/software and making it eventually incompatible with FOSS. That's very different from creating a new thing, and asking people to use that. AFAIK, they're not replacing anything (but maybe I missed something), so I don't see it as the same as what Microsoft did back in the day.
I think it's similar. We have a big powerful company pushing their solution, pushing more and more software to depend on that solution, so people who want to exercise their choice not to have an increasingly uphill battle to do so.
That doesn't seem so different from what Microsoft used to do, as even back then there was always choice if people decided to get together and exercise it, but practically in both cases it's an uphill battle.
Gnome, for example. GDM now needs systemd's userdb.
It is indeed becoming harder and harder to avoid and I understand that this isn't great, but systemd tackles some genuinely hard problems that others don't. Which is to say I don't begrudge Gnome devs for this and personally prefer systemd over current alternatives.
I've looked at OpenRC, RUnit and S6. I haven't recently run any of them "in production", however.
Personally, I am a strong believer that declaring the desired state is a lot easier to get right than actually writing the code to get there. Beyond that, I'm not saying any of these are bad at being what they are, systemd just has more features, some of which I really like. Two examples I'm actively using currently are automount units and socket activation (S6 also has socket activation). I have some remote folders mounted via SSHFS automatically when I access them and this is incredibly useful for my workflow.
Could I find tools to slot into other init systems that do this for me? Probably. But systemd has this neatly packaged up, easy to configure and easy to introspect state.
It uses a folder with a subfolder for every service. Each subfolder contains a script called run. The system runs the run script. If it exits, it waits two seconds and runs it again. Repeatedly. It's very worse–is–better.
There are commands to control the services and check their status. For example, if a file called down exists next to the run script, it won't run it. This is how you disable a service.
It checks for service folders being created and deleted. New folders are started, and deleted ones are stopped cleanly. They can also be symlinks, so you don't need to worry about deleting a running service folder and you can remove a service from init without erasing the scripts you wrote.
The whole system is useful in many situations and not only as pid 1.
Maybe one day I'll invent a runit–based distribution.
Dependencies may be becoming less properties of software, and more so properties of the distro's systemd wiring.
More and more software will assimilate systemd features. Free distros will patch, shim, emulate, flounder. Or in GPT parlance "Dependencies are no longer intrinsic properties of software; they are emergent properties of a distribution's systemd orchestration layer"
Meanwhile, gripes, fears etc,
'Linux' becomes interpreted vs inspectable.
Requires superfluous new literacy
Convolutes logs, tools
Obscures causality
Centralized control above Unix process model
Fair well ps aux, hello systemctl, cgtop, gls
KILL (less lethalized) superceded, replaced by service stop and mask
Surrender chains for events, ie buggy debugging or complexity accretion
General obfuscation beneath the hood
Centralized ... indexed, logs vs text streams
And....
Upstream assumes systemd
Some resist
Costs rise
Optional becomes expected
Accidental incompatibility
And... systemd ingurgitates one by one, policy, supervision, logging, identity, dependency management and the rest of the world... digests it, and from the aether emerges a sweet smiley face, disgorging forth a monolithic mutant avatar, with Linux features.
I'll be quiet happy to be wrong about everything. Feel free to slaughter everything I've written. I don't even oppose systemd - I simply perceive it as a singularity that's drawing everything around me towards it. Wrong would definitely be good, so please don't hold back. I won't seek pardon for the rant though, because true or false, it's honest.
Edit: I was reading through my threads and thought the parent was asking me, though wasn't. I've unintentionally barged in here, but I'll leave the comment anyway, as it references a very big concern of mine.
With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
Want to run xterm? Requires Xorg. rootless Xorg requires udev, udev turned into a systemd component. want to run xterm without systemd? good luck, you are now the maintainer of your own LFS.
The udev developers decided that it made sense to move udev into systemd. If you disagree and want choice, you can fork udev. Actually some people did that, so you can run xterm with eudev instead of udev and thus avoid systemd (though eudev seems hardly maintained now, with the latest release in 2023).
I think it's true that it's an exhausting battle to keep all those parts independent when 95% of the devs/money agree it's better to integrate them. But it wouldn't be fair either for the 5% to put on the others the burden of keeping things independent because of their own preferences...
eudev was just a copy of the udev part of systemd, with some patches to build on musl, and work without systemd.
All of that has been upstreamed now, LFS has instructions on how to build udev from the latest systemd release, without building systemd itself.
Yeah, it’s miserable; xterm shouldn’t require Xorg. It should be agnostic to display system and not force the X monoculture on everyone. Classic Microsoft gestapo tactics: shoehorn Xorg dependencies into tons of unrelated apps and thus curtail user freedom to run xterm with a WinForms or Wayland display system. It’s appalling.
From the project documentation: "The xterm program is a terminal emulator for the X Window System."
The application does not require xorg it requires an x11 server.
It just so happens that until recently xorg was the only game in town as far as Linux x11 servers are concerned.
> With everything depending on systemd interfaces, its an exhausting uphill battle to run anything desktop-like without systemd.
Yes, but this is hardly a unique systemd/Linux problem. I despise TypeScript for various reasons, always preferred vanilla JavaScript over TypeScript. So if I'm met with "Huh, this library is using TypeScript, am I ready to deal with that", I make the choice to not depend on that, even though half of the ecosystem uses TypeScript.
Going against the grain comes with more work probably, but this is also a choice we make, because we have strong feelings and opinions about something.
Languages are confined. I don't speak Rust — yet — so when I want to modify some software that is written in Rust that is a disappointment. However, the effect of software being written in Rust is limited to that software and its libraries. It doesn't infect your system the way systemd does.
You can turn most parts off. Maybe don't talk about stuff you have not much idea about ?
There is point to complain about distros turning it on by default but you could have systemd where systemd just does unit management and not much more.
The hardest part to get rid of would probably be journald as this parasite's log format is just... not good in any metric but it isn't easy to replace either if you want to keep systemd functionality
you can use and like and still complain about things that should be better or were better under old.
systemd solved a ton of headaches but also added few more, like inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS.
> And writing a systemd unit is pretty easy, contrary to the old bash script mess.
We had thousands of lines of "simple" sysv init scripts fixes because apparently even seasoned maintainers or developers of the app can't figure it out. It's huge improvement.
One example: A java app that writes its own pid. The status subcommand relies on the pid existing.
so calling start then status will return that the service haven't started yet. And that is what stuff like for example Pacemaker does so it could just randomly fail under sysv. Under systemd it's all so much simpler
With two “--force” options, that is essentially equivalent to “echo o > /proc/sysrq-trigger”, isn’t it? I would think that one “--force” would have the actually desired effect.
You could do the same in a less invasive manner with daemontools like forever. Not only on Linux, but on BSD as well.
But people need a corporate and worse knockoff shoved down their throats, because DJ Bernstein is independent and we cannot have independent people in software.
I wrote a lot of daemontools wrappers and non-shell forking daemons.
Doing this is really, really error prone and fragile. Why the hell should I have to learn about double forking and PIDfe validation (and process groups and pty-or-not and all those other esoterica that daemontools still requires you to engage with if you want to do something outlandish like “run a program with a graphical component at boot”) just to make something run in the background?
You shouldn't. You should let it run in the foreground and let the system manager switch to the background before running it, if it wants to. This has many advantages, mostly simplicity.
I am not familiar with daemontools but I think it includes something similar to runit, which likes your processes to run in the foreground.
However, the happy path is very, very narrow. It breaks down as soon as you have to deal with:
- Set(e)uid daemons or any background service that needs to run as a different user than the one launching the service.
- Programs that report readiness somehow (the equivalent of the "notify" systemd type). Plenty of services won't crash when they should, so a standard for "it's all the way up" is useful.
- Start timeouts and failures. If daemontools is your only authority of the "status" result, recognizing a started-but-hung service is hard. Even if your service has some other "yes, the binary exists, but is it working?" check, getting daemontools+init to probe that and appropriately react to start timeouts can be fussy.
- Services that themselves spawn subprocesses (either forking or running separate child programs). Parent-process crashes are a recipe for orphaned things running and consuming resources/doing who knows what. You can solve this with a cgroup/namespacing/prctls to control orphan reparenting, but that's super hard to get right. Systemd has a one-liner for "on stop, kill this service and any program that was ever spawned in its tree". Having implemented the equivalent code to KillMode=control-group a in a few different "this has to be really reliable and bug-free" contexts now, having to manually manage this when managing services is a recipe for disaster. You'd think you know when your services will/won't have child processes, but you'd be wrong a lot (e.g. oddball JVM tracing sidecars, Pythons that always run a multiprocessing helper even if they don't use multiprocessing, Redis sometimes forking and doing bgsave, Erlang with its DNS-management child procs, literally anything ever written in Perl, Postgres, and so on. You would think that most managed child processes in big, mature software projects will know to kill themselves if their parent crashes for whatever reason. You would be wrong).
- Inter-service dependencies. Yes, many init systems take that on, but now you have the daemonization system and the init system--separate tools to configure, with overlap and expectations about each other.
- Race conditions around setting up pidfiles/locks when first deploying a service. Sure, once it's installed flock(2) will work fine, but what if you're installing a new distribution of the service and the installer picks a different lock directory from the one in use by the running service?
There are a lot more things I could list, but I'd rather not go back there. Having to manage this stuff by hand was a pretty low point for our field--as fully clued-in as sysadmins felt, we made a lot of mistakes, and made an environment that was deeply hostile to non-expert operators who just wanted to run a service and forget about it.
Systemd's far from perfect, but the challenges of doing this stuff with daemontools and friends weren't just "this is a worse implementation than systemd"; they were "this is existentially harder than using systemd precisely because it follows the 'unix philosophy' and maximizes control of (and thus responsibility for) an area where simple cases are often ... not".
Currently I wouldn't dare to enter the US, while I'm sure I would be relatively safe in China.
And: even before Trump the TSA had elements of despotism. All the while I never heard of Europeans being treated like shit in China -- simply the better hosts!
I keep mentioning that to people when they bring up a quite anti-China narrative (or paranoia). Most people in the western hemisphere are way more likely to be negatively impacted by the US than China.
Europeans, Canadians etc are less likely to travel to China so of course Chinese media spying would be less immediately detrimental than the spying of US companies. But even when traveling to China, it's less likely you'll be treated poorly than when traveling to the US.
We in the US have been so propagandized against China that even relatively progressive people that are completely against the Trump admin think China is an authoritarian hellscape. And while China is obviously not a utopia, I'd be hard pressed to find a metric there that hasn't surpassed our own.
China has no free speech and will start flexing its imperial muscle more now that the US is climbing down from the world stage.
China is alright if you keep your head down and you're not of the wrong ethnicity, locked up in a work camp and not allowed to have kids, or too openly gay or trans and so on.
The history of civilization over the past 5,000 years proves that China has never been an empire of foreign aggression. On the contrary, look at the 300-year-old modern history of the United States. Take off the tinted glasses of racism and savor it for yourself!
China has literally has been an empire most of it's history. It's like the 3rd biggest country on the planet. Just Tibet itself is huge and was absorbed into China not so long ago.
US is regressing on trans rights, abortion, etc. Free speech is under threat with the president “attacking” media institutions. You have daylight murder by federal agents followed by propaganda campaigns to blame the victims themselves or on the Democratic Party to create more political friction.
No one is saying China is perfect in these threads, we’re just saying the US isn’t necessarily better. Two countries can be shitty simultaneously.
Two countries can be shitty but the US hasn’t yet put a million of its citizens in jail because of ethnicity. Maybe going there in the future. That won’t white wash what China is.
It would not be higher in total if you included the estimated number of Uyghurs detained in internment camps. Even considering that, there are a couple other factors that don't make the numbers you presented mean much.
One factor is that the U.S. is the 3rd largest by population and will always skew higher in total prisoners than many other countries.
The other factor which explains the relatively high incarceration rate within the country's population is the investment into policing and reporting. We can take a city like Shanghai for example. They had a population size of around ~24m+ in ~2018-2019 [1] but only had 50k cops [2] (I couldn't find citable numbers for today but the data isn't too outdated). New York City, in comparison, has a current current population size of around ~8m [3] with 33k cops [4].
The 2 countries bigger than the U.S., India and China, also historically have had less investment in law enforcement, especially in rural areas [5][6].
The point was that the US touts itself as a free country while having many perverse incentives and mechanisms oppressing part of its citizenry. There's a veneer on top of it of individual freedoms compared to a state like China but in reality it can be as brutal against its population as any totalitarian state, it's just that the power to subjugate and oppress isn't centralised and is more diffused through its institutions across history.
It's not too far in history that the US was deploying the National Guard to fire live ammo against protesters, American police has military-grade equipment deployed against their citizens, I think it makes it even harder that the oppressive power isn't centralised since to uproot this there are countless battles to be won for any change to happen. It's institutionalised, any big institution is really hard to change.
US is quickly heading the direction of China, but China is much much further along the path of authoritarian hellscape: no free speech at all, no freedom of the press, all social media is heavily censored, and the GFW allows government control of the Internet (yes, I know, VPNs exist, but they can be shut down and aren't even on the radar of the vast majority of the population.) All this was already the case in 2017 when I left China and it's even more controlled now (COVID only increased government controls). You don't see this as a foreigner, but as a Chinese you absolutely do. Trust me when I say it's still, even with the current wanna-be dictator and his white supremist minions, much worse than the US in terms of freedoms.
On the other hand, China doesn't suffer from the US' current bone-headed anti-Science and "climate change is a hoax" nonsense, and have a much clearer understanding of where they need to continue investing in order to become the world leader economically and even politically, which Trump in his stupidity is handing them on a silver platter. So in that sense they are far ahead.
China is also of course much smarter when it comes to foreign policy, though Trump has set such a low bar that even a monkey could do better.
I'd rather not live in either country, but if I had to choose, I'd pick the US and it's not even close.
> I never heard of Europeans being treated like shit in China -- simply the better hosts!
Yeah. Also lets not forget:
- Citizens from most EU countries can now enter China visa free. No ESTA and no other administrative crap. Generally no problem to enter and leave the country as long as you respect the law there.
- The Chinese authority are very cooperative when it is about granting some visting Visa to researchers. Most Chinese research centers and Universities have a some kind of direct link to an office that can bypass some of the procedures.
If you dig into my comment history, i've been pretty pro China (despite a ding i will do every time: China rural areas are decaying faster than in the west. I think the main contributor is the difference between contryside/rural pay (80-100€ when i was there) and city/industrial pay (700-800€ with no qualification at the time)).
I will still add a caveat with what you've said: China make/unmake rules pretty fast, and while not hidden, those are not easy to find and understand (especially when you take into account enforcement). When those rules touch on immigration policy or on societal stuff change, it can surprise you. As a westerner you should always be OK, but this is a country with no rule of law, you should always keep that in mind.
> As a westerner you should always be OK, but this is a country with no rule of law.
Let's be clear: I am not discussing nor defend China internal policies here. I honestly do not care and I am not pro China.
I am pointing a single fact: As a EU researcher, it is easier now to go to China than to go the US for conferences and collaboration. And we do feel more welcome there.
That single fact alone should terrify any US politician with a brain.
Sorry, it wasn't a criticism of what you said, i wanted to add a caveat because what you said was true in 99.9999% of cases, but as China laws application are arbitrary (and their laws change all the time), you still ought to be careful when going there.
I'm guessing my flawed use of an asterisk, resulting in a weird highlighting out of context, confused your interpretation of what I was saying, because I believe we're suggesting the same thing.
How can you loose "important work" of multiple years? -- can't be important and how can somebody _expected to become management_ be so incompetent?
"...two years of carefully structured academic work disappeared. No warning appeared. There was no undo option. Just a blank page. Fortunately, I had saved partial copies of some conversations and materials, but large parts of my work were lost forever."
-- stupid: that drive could have died, the building could have burned down, the machine could have been stolen, the data could have been accidentally deleted...
and all there was: "a partial" backup.
I mean, that isn't even a scenario where he didn't know about the data ("carefully structured") and discovered it wasn't covered by the backup schema (that would be a _real_ problem)
Another problem would be of your churn is so high that backing up becomes a real issue (bandwidth, latency, money, ...). None of that applies.
And yet they reserve a spot in "nature" for such whining and incompetence?
I have several thousand curated bookmarks. And I only discovered too late the new "feature". Disrupted my former flow (mark on mobile, sort/categorize on desktop)
They could have made this configurable, but no... those smart asses knew better.
I have that GitHub issue where they initially discussed it for iOS bookmarked and screenshoted, to remind myself how utterly stupid some people are. I hate every sucker involved.
reply