That depends on how you decide which bucket something gets thrown into.
The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.
These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.
Governments triggered this entire discussion with their papers and plans to strengthen cyber defenses. The article states that some experts ask for our industry to be more regulated in this regard.
I am surprised that possible regulations are not even listed as a factor that in the decission to stay with C++ or move to something else.
Sure, COBOL is still around after decades, but nobody ever tried to pressure banks into replaceing that technology AFAICT.
That interface is let any random app take screenshots of anything running on the same server without any way for the user to know it happens.
I am so glad that interface is gone, especially when running proprietary apps.
Usig anything as root is a security risk.
Using any UI application as root is a bigger risk. That's because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.
So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.
Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.
Ideally you run the UI as a normal user and then use sudo to run individual commands as root.
Most of your examples are projects started by a company. The very few remaining are those 0.01% that got lucky.
My point stands: When you start an open source project, there is no need to worry about what companies might like or not. You will not get money from anyone.
The one thing you can learn from sysv init isnthat asking devs to pitncode into their programs or into starter scripts does not work. They will not bother: Those will notmworkmcross platform.
So you need to cebtralize that task. You can either write a wrapper program that sandboxes starts applications in a sandbox or do that whereever the programs as are started anyway.
A separate sandboxing app that starts services complicates configuration: You basically need to configure two things the starter and the service. On the up-side you have the sandboxing code separate. Merging the sandboxing into the program starting the service makes configuration simple but adds moremcode into the the starter program.
So it is basically a decision on what you value more. Systemd decided to favor simpler configuration. The cost for adding the sandboxing is small anyway: It's all Linux kernel functionality that does need a bit of configuration to get rolling, with much of that code being in the systemd-init anyway: It uses similar functionality to actually separate the processes it starts from each other to avoid getting confused by programs restarted and thusnchanging PIDs -- something still a thing in many other inits.
I am convinced that making sandboxing easy does a lot formits adoption. No admin will change the entire startup configuration to add a sandboxing wrapper around the actual service. It is way more likely for them to drop in a override file with a couple of lines and without any problems when upstream changes command line options.
Starting the init system is the task of the root filesystem or initrd, with any boot loader. Systemd-boot happily boot into any init system just fine, just like any other bootloader that can boot Linux will boot into systemd just fine.
Systemd-boot boots kernel images (with efi-loader code embedded) and only offers a menu to pick which kernel file to load. What makes systemd-boot interesting is that it does nothing more than that: It does not read random filesystems, it does not implement random encryption things, does not parse image files and complex theme configuration, ... .
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That's because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: "Systemd is on huge entangled mess of interdependent binaries" :-)
SystemD replaced a variety of Linux init systems across different distros almost 10 years ago now but it is still resented by a significant and vocal section of the Linux community.
No, it is not. It is always the same few people that repeat the same slogans that failed to convince anyone ten years ago. But that does not really matter: In open source the system that can captures developer mind share wins. Systemd did, nothing else came even close.
No need to drag that BS from the archives. It was never correct nor convincing.
We can always use a UX person over at https://github.com/slint-ui/slint :-) Slint is a UI toolkit written in rust, but the UI is defined in a simple custom language that is really easy to pick up.
You could polish up existing demos, to create new ones and could even come up with new widgets.
We try to be a nice community, feel free to drop by and chat if you have questions in our mattermost instance hosted at https://chat.slint.dev/
That depends a lot on how you define "correct C".
It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.
The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.