Most of systemd's proponents are not people that care about what service management system they use. They defend systemd despite their ignorance of both systemd and the proposed alternatives solely to feel part of the "in group" of people who moan about people who moan about systemd.
People who defend systemd do so because they want their system to work reliably and quickly. It does that. Before you say "so does sysvinit", no it does not. It was janky-but-workable on servers and desktops in the 90s, that basically never did anything except startup and shutdown. Most modern computers aren't like that.
More straw man arguments. You have just confirmed that you have _no idea_ what alternatives exist, that you have _no idea_ what systemd actually does, and you have _no idea_ what my actual stance is in this discussion.
Please don't insult me by insinuating that I think that sysvinit is anything other than a weird esoteric init program which has, in the past and on linux distros, been the supporting piece of a garbage heap of poorly written shell scripts (and which is currently on BSDs the supporting piece of a relatively okay designed heap of shell scripts which implement a silly service management model that I also don't like).
People who grew up on sysvinit based service management and can't handle change (the partially straw man group you are complaining about).
People who only know about sysvinit based service management and systemd and formed their opinions of systemd based on "sysvinit == terrible confusing shell scripts; systemd == config files" (you - as a first impression).
And people who actually know the advantages, disadvantages, and functional details of sysvinit based service management, systemd, and the plethora of other attempts/approaches at solving these issues and can support their arguments in favour of or against systemd with actually reasoned arguments.
The first group is easy to ignore, and a minority. The third group produces the biggest chunk of well informed content on systemd. And the second group seems to think that anyone in the third group who is in favour of systemd, must be one of them, and anyone who is against systemd, must be in the first group (note also: the false dichotomy).
Rather than straw manning your opponents in this discussion while pretending this is a discussion of the pros and cons of "declarative service management", could you instead contribute something useful? Lacking that, maybe just stop trying to contribute?
By saying stuff like this, you aren't going to convert sysvinit users to anything and you aren't going to convince anyone who has genuine criticism of systemd of anything.
The ancient Linux sysvinit-based service management is a strawman, because the scripts available in various distributions were very heterogeneous and many were quite bad.
There are other ancient service management systems that were much more coherent and which did not show any disadvantage in comparison with systemd, e.g. even the sysvinit-based service management of FreeBSD or other *BSD, which were and are much better than the "sysvinit-based" of old Linux.
An example of how a replacement for the traditional UNIX service management can be well designed was the daemontools of Daniel J. Bernstein, written more than a quarter of century ago, long before systemd. There are derivatives of daemontools that are brought up-to-date and they are much simpler and more secure than systemd, while systemd does not have any advantage that can justify its complexity, opacity and interference with other applications.
All the non-systemd service management solutions have the advantage that even if you are not familiar with a computer, it is easy to debug any problem because all the behavior is written in a bunch of text files. With systemd, you can never be sure what happens. The behavior implemented by systemd may change between versions, you might not have the source of systemd or the source of the particular version installed on the computer with problems, the source may be very complex in comparison with traditional shell scripts or with the very simplified scripts of something like daemontools.
Thus claiming that using systemd uses "descriptive" files is not really true, because the uncertainties about what those files describe are much greater than for any other service management solutions.
Even a set of shell scripts, like that of FreeBSD, can be as "descriptive" as the configuration files of systemd, when all the service scripts share a common set of definitions of functions and of configuration parameters.
There is nothing descriptive about `Wants`, `Before`, `After`, `Requires`, `Requisite`, `BindsTo`, `PartOf`, `Upholds`, `Conflicts`, ... we could go on. And we can stop there. (To clarify, _I_ know what these all mean, but certainly I didn't have a clue what they meant until I read the docs about and didn't fully understand the nuances of these until I re-read those docs many times and read the source code.)
But the "declarative"-ness of systemd's configuration files can also be put into question when it's incredibly common to find an `ExecStartPre` containing a shell oneliner.
That being said, my goal was not to start a discussion about systemd here. My goal was to call out the completely unproductive strawmanning of systemd critics by the person I was replying to.
Interesting that you're saying the BSDs use something sysvinit-based. i never saw any runlevel idea there, which i thought was the primary marker of sysvinit? arch used to have an init system that felt very BSD-like. unfortunately they moved to systemd, and i went to void, but not happy with the init system there either. using linux used to be so much easier when "learning an init system" wasn't really a thing yet.
It's incredibly common for people talking about C online or even in books (be that blog posts, side notes, tutorials, guides) to constantly make mistakes like these.
C seems to be one of those languages where people think they know it based on prior and adjacent experience. But it is not a language which can be learned based on experience alone. The language is full of cases where things will go badly wrong in a way which is neither obvious nor immediately evident. The negative side effects of what you did often only become evident long after you "learn" it as something you "can" do.
If you want to write C for anything where any security, safety, or reliability requirement needs to be met, you should commit to this strategy: Do not write any code which you are not absolutely certain you could justify the behaviour of by referencing the standard or (in the case of reliance on a specific definition of implementation defined, unspecified, or even (e.g. -ftrapv) undefined behaviour) the implementation documentation.
If you cannot commit to such a (rightfully mentally arduous) policy, you have no business writing C.
> Do not write any code which you are not absolutely certain you could justify the behaviour of
Doing this for every line is impossibly tedious (people will quickly tire of it), and detecting where the code is actually non-trivial requires a kind of epistemic humility that doesn't come naturally to most.
Better if we can use languages that don't assume such demands are necessary for the compiler to be able to generate performant code.
It is definitely not a language that can be learned by reading blogs.
But the advice really applies to almost everything you do related to security, safety and reliability. In other languages you may have a panic in production or a supply chain issue.
Some people have some bizarre obsession with having absolute and total control over the placement of every single last character in their document while simultaneously not caring about the fact that this placement is sometimes not reproducible and randomly becomes diseased.
My most memorable MS Word experiences are all the times I accidentally put my document into a weird state and didn't notice something was wrong until I've spent 3 more hours on it, at which point I was forced to re-create the document by copy pasting text into an earlier copy.
And the only reason I knew something was subtly wrong was because the weird VB extension I was required to use would stop working correctly. Basically this would happen when some random key element of the document had ended up with a very subtly different style. If I didn't have to worry about the VB extension breaking, I'd just have a document with some weird bug somewhere.
If I wanted a professional looking document, I would use some modern LaTeX variant maybe with Pandoc to generate most of it from something more restricted like Markdown.
If I wanted total control over the content of a page, I would use some kind of graphical publishing software with text and vector graphics.
I have zero idea what kind of Stockholm syndrome you must have to think that Microsoft Office (or any other similar WYSIWYG editor for that matter) is power user software.
It has lots of features, that's for sure. But the features form a Jenga tower. That makes it a toy.
FreeBSD and OpenBSD docs are great, but let's not say they're the pinnacle of docs. I like them a lot more than docs for the average Linux distribution. They're even more polished than Arch Linux wiki. But they still have room for improvement. And improving the Arch wiki is easier in my experience.
* Wiki-style "HOWTO"-based that helps you solve a particular problem (Arch and Gentoo wikis showcase this style well)
* Reference documentation that reminds you how you solved a problem (man pages are great examples here)
* Comprehensive documentation that truly documents the system, but can be a bit more obscure if you're not reading it "cover to cover" - textbook style (This is the older "original" software documentation type, which the BSD docs are an example of)
You are either talking about a license nobody is using (at least I've never heard of it) or misconstruing what the AGPL obligates you to do.
I am going to assume it's the latter.
If you in your house take an AGPL program, host it for yourself, and use it yourself, nothing in the AGPL obligates you to publish the source changes.
In fact, even if you take AGPL software and put it behind a paywall and modify it, the only people who the license mandates you to provide the source code for are the people paying.
The AGPL is basically the GPL with the definition of "user" broadened to include people interacting with the software over the network.
And the GPL, again, only requires you to provide the source code, upon request, to users. If you only distribute GPL software behind a paywall, you personally only need to give the source to people paying.
Although in both these cases, nothing stops the person receiving that source code from publishing it under its own terms.
Meanwhile the solution to this problem in the UK is to reaffirm that you are in fact guilty by default unless by happenstance you are determined not to be by an unfairly chosen panel of blind and deaf mice.
GrapheneOS currently doesn't ship Play Store or Services OOTB. They install as normal apps (albeit with GrapheneOS providing support code to make the fact that these things use/expose custom privileged APIs work correctly). I don't know if the Google TOS would prohibit that, at least I am not aware of any enforcement action against GrapheneOS in this regard. GrapheneOS also doesn't have Google's blessing, meaning some apps like Google Pay won't work on it. To get this, you need to apply to be an OEM.
Really Motorola doesn't need to sell a GOS phone. Motorola just need to sell a phone with the right hardware security features, open source/upstream their Android/Linux patches, and give users the ability to run GOS.
Hopefully they can then give you the option to buy one with GOS preinstalled, but even if they don't. It will be sufficient that it can run GOS.
Unlike Windows, nobody feels they're paying an inherent tax when buying a stock Android phone. I'm sure nobody will mind.
The hard part will be actually supporting the phone for long enough.
GOS is reliant on Google's open sourced Pixel android releases up to and including the 9 series. This is because GOS doesn't have the resources to handle that entire side of things. But I guess part of that is also that GOS doesn't have access to the necessary information to do that stuff properly either.
That's fair, this would still be a valuable development even if Motorola doesn't end up shipping devices with GrapheneOS preinstalled, but if they did I think there's a lot of potential for them to enter the mainstream. A device with GrapheneOS without any [major] caveats (like Play Integrity API, Google Pay not working) would be a game changer.
I can't see such a GrapheneOS existing without explicit Google support. And I don't think Google would support something like that unless they suddenly decided to actually not be evil again.
Google's hardware is just hardware. It is not locked down like the hardware of many other manufacturers. Moreover, it's the only such hardware which also allows you, the user, to lock it down for your own security. GrapheneOS is not just focused around avoiding Google, it's more accurately focused around security and user choice.
The goal is to give you the option to avoid needing to rely on Google's spying or services while not having to compromise on security.
None of these other solutions regularly get included in Celebrite's documentation as being an explicit benchmark of their software's ability to break into phones. And that's almost certainly due to the fact that unless you leverage hardware security features like what GrapheneOS (and stock Android on a Pixel, and iOS on an iPhone) utilises, you have no chance of going against any actual adversaries.
And I'm not just talking about state actors here, even drive-by opportunistic attacks are likelier on a random other phone running some other Android build.
So yeah, you are running Google hardware, that doesn't make you "googled". It's just a sad reflection on the reality of the hardware landscape. If you want the same security as what GrapheneOS offers, you will currently need to use a Pixel.
I'd be curious to see what comes out of their Motorola partnership though.
Why are we degoogling, for what purpose? I couldn't care less about giving them what likely amounts to ~10€ of margin per year on the hardware sale. What I care about is not giving them data which is worth a lot more than that, and to take back control over my device.
When you go with an alternative you lose superior privacy and security offered by GrapheneOS and you just end up leaking more data back to Google and other ad-tech companies than you would otherwise, negating any benefits several times over.
I think it’s very valid. I want to be hardware-independent, not only OS independent. I need graphene to work on a fairphone, jolla phone or whatever other alternatives there are. E/os can do that (to an extent), Graphene can’t for probably very good reason, but still: It‘s not an alternative then.
reply