Yeap, you now get logs from all stages of the boot process, and you notice logs going bad or getting manipulated. It's a huge step forward for Linux, especially for people that look at logs every day. They can finally trust the logs to be correct and complete.

And it is not even a change: I have never had real unix servers with plain text logs in 30 years working with them. Proper computers have always stored logs in databases or whatever. That's actually a legal requirement in many parts of the world for many kinds of servers.

Ok, thanks for the summary.

You do not even need to patch it out. It is basically an extra entry in the user db (think: /etc/passwd). Just don't fill it in and you are done, just like your location and a ton of other stuff you can put there if you want to.

Nobody can read it outside your system either... it's a defined place when (not if -- not anymore) something wants to store that information. Better have a properly protected defined place ready than have 10 different programs request that info separately and store it all over the place.

I'd go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.

It's a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.

There is no regulation at this time. There may not be regulation ever. Before there is any regulation we will see nudging into the "right" direction. Suggesting that companies define a memory safety roadmap could be considered as the very first nudge, or maybe not:-)

All I wanted to say is that ignoring the possibility of regulation in such a text seems a bit short-sighted to me.

GPL effects "derived works". So if your code is derived from proprietary code, you can not use GPL, as you would need to re-license the proprietary code and you can't do that (assuming you do not hold the copyright for the proprietary code). LGPL and permissive licenses are probably fine though.

Now what exactly is a "derived work"? That is unfortunate up to interpretation and different organizations draw the line in slightly different places. We'd need people to go to court to get that line nailed down more firmly.

Then how do you not see the point of a distributed sourceforge?

But this is no forge, it is just a git repo.

Again, have you even opened the webpage?

Yeap, I even put a repo into it. That's why I am so certain that it is useless.

Hosting a git repo is not a problem. Having an discoverable forge is. And this does not help with that in any way.

So github is not a problem?

Something can not be a solution independent of whether or not something else is another problem or not.

And regarding crypto, show me where in the code it forces you to use crypto. Show me the rad command that inhibits you from doing a normal git operation by bringing up crypto.

There is lots of needless crypto(graphy) going on all over the place. It is entirely useless for code hosting in a git repo.

Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

There are non-UI applications with similar problems though.

Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.

Censorship is about you being limited in the actions you can take to express yourself. It is not about cushioning you from the consequences of those actions from the people around you.

You obviously were allowed to take action: The contents was apparent upon on a forum and here as well. People reacted to your actions: Admins removed your contents and blocked you and I am telling you that your understanding of wayland as well as politics is limited.

Deal with it.

None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.

So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.

Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.

supply chain attacks are a serious problem that needs addressing.

Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states "no warranty" for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing "found" that do not really effect my code and bogus merge requests to upgrade dependencies for no reason... this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.

If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)

For your own projects, it might be worth considering a move away from GitHub. (I've been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.

That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.

Not at all: I listed the arguments you will get for that question of yours. They all are bogus, as I tried to explain between the parens.