As one of them, I agree. It's easy to jump to the first thing you notice (something superficially wrong to point out), I often do this. And it's hard to think beyond that and engage with the ideas instead.
But then again, that's why we try to write elegantly so readers don't stumble on the words and instead think about the meaning behind them.
Has bugs, is way too complex for the given functionality, and is completely unneeded in the first place--yes, get rid of the damn thing. Unless of course you enjoy getting "your" system OWNED and dominated by bad actors.
My custom distro beats the brakes off junkware like Ubuntu and (lol) Windows in startup time and responsiveness, and has all of the functionality I need, with half the code and as a result much fewer gaping security holes.
Computer security is an absolute nightmare these days. Intelligent people should be simplifying things and stripping everything down to the bare minimum, instead of stacking more crud on top of endless crud.
Those who fail to SECURE their systems and workflows will one day in the near future be surprised as shit to find that the entire "cloud" has been hacked and destroyed by worms and their system trashed right along with it. At that time, the world will be divided into two camps: computer owners (me and my kind) and non computer owners (everyone else.)
Who cares? If you don't take computer security seriously, you won't be computing much longer. Before it's over with, mine will be the only opinion still in existence. It's called "natural selection."
>is way too complex for the given functionality, and is completely unneeded in the first place--yes, get rid of the damn thing. Unless of course you enjoy getting "your" system OWNED and dominated by bad actors.
This is a rather nonsense statement. Polkit (or something like it) is needed if you want to have those macOS-style "program A wants to have permission to access privileged resource B" security prompts in the GUI. It's about as complicated as any similar solution needs to be for that use case. Perhaps you find these to be annoying and you disable them so they always succeed, but with that you've effectively given every program permanent suid root access. Definitely simpler, but can you say it's less of a security nightmare? I wouldn't. Yes there are risks of vulnerabilities in any security layer, but without them you've got no security layer at all.
If those checks always fail, you've now lost that functionality to do anything requiring elevated permissions and made your system less useful. You could get it back by installing a suid root tool like sudo/doas but that opens the same hole again that elevates these problems from a crash into a CVE.
I don't want or need popup permission prompts. If something needs to run as root, I run it as root from the console, as God intended. In the process I am assuredly avoiding all sorts of potential security vulnerabilities, such as this polkit code which is not installed on my system. Now get off my lawn.
Computer security really isn't THAT much of a nightmare for an average user. How many people do you know that got hacked lately, for any reason other than not using 2FA, or installing random garbage?
If you don't own cryptocurrency(That is more critical because it can't be reversed), you're probably way more at risk for physical theft than cyber crime.
In fact I think we are more secure than ever before because browser sandboxing actually works worth a crap, unlike 10 or so years ago.
The more you strip out of a system, the more manual work you need to do, and the closer you get to just a fancy version of a pencil. Technically, every line of code is a security risk.
But a lot of things just... are barely worth it when ultra simplified, and you start spending more time than you save at a certain point.
This bug is pretty bad, and I could see distros getting rid of it, but only with plenty of thought and analysis and maybe a replacement. They clearly put it there for a reason. Lots of stuff seems to need it.
And unless you use sandboxing or multiple accounts for different things.... if you have attackers running as your user, you are already screwed.
You're part of the second group I mentioned: the one that won't be computing much longer.
> Computer security really isn't THAT much of a nightmare for an average user.
"Average user" and "common idiot" are one and the same. Common idiots never see danger coming until it's too late.
> How many people do you know that got hacked lately, for any reason other than not using 2FA, or installing random garbage?
It's not about what has happened, it's about what easily CAN happen, and therefore WILL.
By the way, 2fa being forced down everyone's throat is not for your benefit. Notice how they never will allow you to use a voip number for 2fa? How could TPTB track your every move via GPS if you use voip?
> If you don't own cryptocurrency(That is more critical because it can't be reversed), you're probably way more at risk for physical theft than cyber crime.
LOL. Crypto is a scam. Bitcoin is going to crash to zero, and you're going to lose everything. Next TPTB will introduce their own Officially Approved digital currency, which is specially designed so that your account can be locked or restricted or emptied with the click of a mouse button, and so that you cannot possibly ever avoid any taxes.
You've got some tough lessons to learn about how the world works.
Meanwhile my use of physical, hard currency will keep me free and at liberty forever.
> In fact I think we are more secure than ever before because browser sandboxing actually works worth a crap, unlike 10 or so years ago.
If by "secure" you mean "in Google's firm grasp", you are correct. If you really meant "in control over your own computer", no, you are not.
Try patching Chromium to remove all the spyware and malware as I have done, and note how you and your browser are now treated as Enemies of the State by the Big Corp controlled internet.
> The more you strip out of a system, the more manual work you need to do
Freedom isn't free, nor is security.
> But a lot of things just... are barely worth it when ultra simplified, and you start spending more time than you save at a certain point
How would you know? You've never even tried to escape from the Goolag.
My system beats the brakes off yours in virtually every metric, especially speed and security, and has been worth every hour spent working on it.
> if you have attackers running as your user, you are already screwed.
You mean like the attackers you willingly give root access to your machine by allowing them to regularly stream arbitrary binary code to "your" (their) computer, and regular user access via metrics and update checks and every other sort of outgoing network connection on their schedule and not yours, any one of which could trigger a buffer overflow and code injection event? Yes, you are screwed six ways from Sunday.
If the world ever gets bad enough that I have to hide from Google and TPTB, your customized system will probably be contraband. In which case, I wouldn't want something like that, because I... don't want to go to jail, and I am rather certain they could find out if they wanted to.
Probably by machine learning looking for houses with an absence of pings to certain servers and using old fashioned police work from there.
Keeping that scenario from ever happening is a political issue. Perhaps it is in part technical too, but ultimately, people should not have to live like fugitives. For the same reason they shouldn't have to wear a guy fawkes mask in public.
And if someone does need to, they probably don't consider themselves to be free.
I may have never tried to get away from Google, but we did grow up poor enough to not have the latest tech for quite a long time.
It would be nice if it was possible and convenient, but a lot of things are still way behind.
When you add up all the details... it's probably more of a luxury than being rich in the gilded age, and it's accessible even to people like me who don't even make minimum wage when you take into account all the Ubers and Lyfts and crap.
With simple technology, one mistake and it's all gone. It doesn't help you out at all. Remember how this stuff was done 15 years ago? Nobody ever would trust computers for anything important. We all used pens and paper every day.
Every person I know who cares about privacy seems to need tons more analog tech than I do.
Lose your phone? Too bad, there was no Google page with which to track it and remote control it. Lose your wallet? Hope someone turns it in. There was no Tile.
Cooking and need to set a timer? Better wash your hands first and be careful not to forget in the time it takes to do so, or you'll make a mess and transfer germs when you touch the timer.
It would be a LOT of work to set up replacements for all of this while preserving privacy.
These things are only a few minutes per day, but collectively they are a big lifestyle change.
Eventually, open source will catch up. But it is slowed down by the fact that the FOSS community.... likes to shit on such things and doesn't want them to exist at all, and prefers ongoing manual involvement, and shits on most zero conf stuff, because they're so absolutist about security and minimalism.
You don't have Firefox or any browser? How are you posting? W3m? I would imagine that these have an enormous amount of bugs and security issues if parts of basic Linux programs are riddled enough with them by your standards.
That's worked pretty well e.g. for OpenBSD. Their code isn't perfect, but they've evaded lots of bullets simply by removing things they don't deem necessary.
I think I've evaded many bullets exactly the same way.
More code and more complexity -> more bugs, more holes. It's pretty simple.
Deprecated on Linux. But I for one can’t consign them to the dustbin of my memory, because on my Mac, they are not deprecated, while the `ip` command that replaces them on Linux does not exist. With this part of macOS being derived from FreeBSD, I don’t know whether that makes FreeBSD a savior or a villain.
Personally I blame all of the major Unix-derived operating systems (Linux, macOS, BSDs), as none of them show any interest in standardizing any APIs or commands invented this millennium. The subset that’s common to all of them is frozen in time, and is slowly being replaced by new bits that aren’t. From epoll/kqueue to eBPF, containers/jails to seccomp/pledge, DBus/XPC to init systems… from low-level network configuration (ifconfig, ip) to high-level network configuration (whatever that is this month).
At first I wanted to say that while this is inconvenient, it is better for the larger ecosystem because we explore the problem space more. But the more I think of it, the more I see it as just a superficial exploration, not deep operating system research.
It's still used in some user spaces, and the Linux kernel supports the system calls for net-tools still today, because of the Torvalds Prime Directive, "though shalt not break userspace".
The FreeBSD POLA design principle makes sure fundamental tools don't disappear or worse double over the years. Linux distributions differ vastly from vendor to vendor.
Since it was just an example, I don't think refuting this particular item will nullify the opinion. The idea, I think, is that there are always more pieces in a state of deprecation and replacement at any given time in Linux land than in FreeBSD land.
I think that's just due to the pace of development. The BSDs are resource constrained, so they have to pick and choose what to work on. That is both a good thing and a bad thing. Here the benefit is less churn. On the downside, they're just catching the Wayland train recently. On the up side, by catching it late they didn't suffer a lot of the growing pains.
At what cost? Thats not the enirety of systemds complexity curve.
Your systemd unit file is backed by pages and pages of docs that must be comprehended to understand and hack on. Unix developers have all they need from the script. Furthermore, its all in context of existing unix concepts and thus your unix experiance is paying dividends.
Now you're just exaggerating. Are you really saying spending 5-10 mins skimming through a couple of man pages is that hard? Are you saying that a lot of documentation is a bad thing? (I thought FreeBSD fans liked to harp about their handbook..) And besides, there are already hundreds of systemd unit files on your system that you can easily copy and make relevant changes for your own services. Not having to deal with finicky shell features is a major advantage IMO.
I think the disconnect we're having is your inability to perceive complexity. And I don't blame you, it's not easy to quantify. I suggest you start with, Out of the Tar Pit by Ben Moseley. I'm not knocking on documentation, it's a vital property that I consider when adopting new technology.
What I'm saying is that systemds documentation currency (if you accept my metaphor) is spent on covering its accidental complexity and it's voluminous. If you disagree with me, that's fine. This is just my experience as a linux user that's had to deal with systemd.
If your claim is that systemd man pages are well written documentation then I think you're exaggerating and I'll wager you've relied on stackoverflow examples or tutorial blogs to solve your systemd issues--because I have. The reason for this is because the number of concepts and abstractions that you have to piece together to solve your problem is massive. But yeah, it's just a 5 line Unit file. I prefer strawberry kool-aid, thanks.
I genuinely don't see what's so complex about a service unit file. It's a simple INI file that has multiple sections that describes the service, tells what command to run and specifies any dependencies. It's literally the same thing that init scripts do except in a much more concise and efficient manner. And as I said before, there's a ton of systemd service unit files on any Linux system that you can take a look at and use as inspiration for your own services. Taking a little time to learn the ways of systemd is not a huge burdensome task like you're making it seem to be. I don't see why you think everyone should conflate systemd with complexity.
And about the voluminous documentation, well man pages are supposed to be comprehensive and cover every single aspect of the tools being described. They're not there to just be an intro to systemd for new users and administrators. If you want something like that, look no further than the "systemd for Administrators" series of articles written by the systemd author himself. https://github.com/shibumi/systemd-for-administrators/blob/m....
> I genuinely don't see what's so complex about a service unit file
It't not the unit file that's the problem, it's the mountains of junk, low quality C code written by an obnoxious, arrogant twit named "Linux Puttering" who has proven for 15+ years he couldn't care less about code quality or system reliability.
Besides the anecdotes shared by others over the years about the horrible experiences they've had with systemd, I have one of my own to share. When developing my own distro to escape the bloated, laggy hell that is Ubuntu, I started the build on my existing Ubuntu system. I found out the hard way that accidentally double mounting virtual filesystems on the target volume causes systemd to crash the system after about 60 seconds, with no possible way to recover. On MY system, with no junky ass systemd, making this error harms nothing at all and can be easily fixed.
The people who talk about "buggy, hacky" shell scripts appear to be some of the same type of people who shrink in horror from the idea of compiling their own kernel, or working at the command line. (i.e. not really "hackers" at all.) There is nothing at all wrong with using shell scripts for startup. It is in fact the simplest, and IMO most elegant way of doing the job, and no it isn't buggy or hacky in the least. The file system is the database and unit file and the already existing shell is the interpreter.
My system starts much more quickly than Ubuntu and is much faster and more responsive in daily use also, so the "startup time" excuse is a myth, and practically all of the other contrived examples people use to justify the use of systemd can be done BETTER using shell scripts in conjunction with small, light weight, single purpose utilities built the UNIX WAY.
It's "just an INI file" but you would have to understand what the thing that's interpreting does. All the stuff that the OP described as a positive - dependencies, auto-restarts, socket activation - somewhere there's a codebase that's implementing all that, and you can't just understand your "config file", you have to understand what that codebase is actually doing with all of its concepts. Elsewhere in this thread someone writes about how great it is that systemd is using a cgroup namespace to keep track of each process instead of a PID, and maybe that is great, but it's yet another new concept that you have to understand to understand how any of this works. Etc.
You could say that a shell script is a config file for bash, and you have to understand bash to understand what it's doing. But a shell is both simpler than systemd, and something that anyone working with Linux already understands.
The equivalent comparison with init scripts would be all the documentation and complexity of every program invoked by the init scripts, not just by sysvinit or rc's documentation and complexity directly. systemd just has most of that built in. And if you're using socket units, the order of what order to start things is essentially outsourced to the kernel, so that's a bit of a simplification.
Try building and maintaining a linux distro without systemd, especially for a large organization that needs to write their own init scripts. And especially when a large number of the devs in that org aren't shell experts, or don't understand the difference between /bin/sh and /bin/bash. And so on.
Here's another example: https://lwn.net/Articles/701549/ before systemd, for complex NFS setups, the sysadmin _had_ to write the init scripts per-site or per-machine. With the solution in the article (systemd generators) one set of unit files shipped by the distro solves the problem for over 99% of users, including most of the aforementioned complex setups.
The unsaid thing here is Linux is largely not used by sysadmin/unix types. Devops has driven this bloat so that people new to the field can just not have to learn any fundamentals about the OS they're building their tools on. For rapid "move fast and break things" VC nonsense, this is a great match. For efficiency, correctness, and long-term maintainability and security, it's a nightmare.
FreeBSD has a lot of documentation, which is something people like about it.
I think it actually shows a problem, which is that BSD is designed for all your machines to be special snowflakes with individual names, edited config files, etc instead of being mass managed declaratively. So you need to know how to do everything because you’re the one doing it.
Our research company hosts 15 PB of data on what we call Single System Imaged FreeBSD with ZFS. All systems pull the complete OS from one managed rsync repo during production hours. Doing this for ten years, never ever any problems. Config files are included using the hostname to differentiate between servers. Adding servers doesn't add manual labor, it's the borg type of setup which handles it all.
Is there an automation for "before updating ports, you need to read every single entry in UPDATING in case one of them has a command you need to run after"?
Why is there a chapter on custom kernels under "common tasks" that assumes you're going to have a C compiler and kernel source on your machine and want to installkernel on that same machine?
But they only provide fixed functionality, while shell scripts allow for practically unlimited customization.
As for 500 lines - take a look at proper rc scripts, eg the ones in FreeBSD. They are mostly declarative; it’s nothing like Linux’ sysv scripts, which were in some ways already obsolete when first introduced (runlevels? In ‘90s, seriously?)
Yeah, this conversation seems a bit like people arguing past each other. But it's a result of the fact that the story on Linux was stuck for so long (e.g., sysvinit on Debian, Upstart with some sharp edged hacks on Ubuntu). Systemd as the solution seems to have sucked out all the air out of the room: either it's great and people are idiots, or it's the worst thing on the planet and people using it are sheep.
If you need extra customization capabilities, just run a shell script via the ExecStart= parameter and boom, you have all the power of systemd and the shell combined.
You can even do one better since systemd can natively run rc scripts. If you're on a systemd based distro peak at /etc/init.d. You can even manage services with /etc/init.d and the service command.
The amount of effort systemd went through to make existing software work is genuinely heroic.
For the same reason it’s a good thing in other contexts. It’s the main reason Unix got popular - because it can be made to fit whatever requirement you have.
Yeah, sorry, I'm blaming more on Poettering than is really fair. But firewalld is closely coupled with the overall systemd architecture and the projects are interconnected.
The biggest problem I find with Firefox under Sway is that its child windows don’t get sane window types. The most significant place where this goes horribly wrong is notifications: whenever a notification arrives, bam! it’s a full tiling window that steals focus and probably takes half the screen, shuffling everything else around, rather than being marked as a notification window, which would make it float in the requested position, get no decorations, and not get focused. And there’s no good way of targeting them properly to work around this: they’re just Firefox windows with an empty title; but so are download prompts and one or two other things. Still, I decided to favour the notifications (at the cost of download windows and the likes) in my current compromise:
I’ve been thinking I should confirm that there’s a bug report for this at some point, though I can’t imagine it’s unknown. But now I look, I actually can’t find anything about it on Bugzilla (though I can find a complaint about it on Reddit two years ago). There is an unacknowledged report about the About Firefox window not floating (https://bugzilla.mozilla.org/show_bug.cgi?id=1681158), which I expect is connected. Hmm. Oh, and https://bugzilla.mozilla.org/show_bug.cgi?id=1590909 which is fundamentally about this very notification issue, completely unacknowledged after two years. Hmm. Better file something.
Airtel is so big they use roaming for their customers. If you have a SIM from Bengaluru and go to Delhi you'll see the little R indicator. That suggests the Airtel business in each state manages at least parts of their network independently. And so the MitMs could be deployed non-uniformly.
India used to be and still is split into several telecom regions with different spectrum leasing, operations and governance.
Until around 2009-10, when you are traveling out of state, you had to pay roaming charges. Worse used to be metro cities within their own states as they used to be different telecom circles. I used to pay roaming charges when going to Chennai from rest of Tamil Nadu. Even the operators were different sometimes. E.g. there was no Hutch (now Vodafone) originally in rest of Tamil Nadu and they operated only in Chennai. Similarly RPG (later Aircel which went bankrupt couple of years back) had 2 networks - RPG in Chennai and Aircel in rest of Tamil Nadu. It used to be a mess.
No operator had pan-India operation as every small operator had their own fiefdoms and the big operators like Airtel used to pay roaming charges to those operators for their subscribers to get signal.
