@fahrni Sounds fun though! Hope the drive goes well!

@jaz
@gomez
@siaronj
@philroyle
@lexicaleigh
@morchwyn
@GnomeBones
@alexisbushnell

#TeamTwtCymru

A really tough one 🤦

#Fedle #426 6/6

🟩🟩⬛⬛⬛
🟩🟩⬛⬛⬛
🟩🟩⬛⬛🟩
🟩🟩⬛⬛🟩
🟩🟩⬛⬛🟩
🟩🟩🟩🟩🟩

https://fedle.fedilab.app/share/9986

NASA says it will isolate volunteers from the outside world for a year

｢ The US space agency is set to carry out a simulated deep space mission from no earlier than August 2027 to understand what might happen to its human lab rats during planned crewed missions to the Moon or Mars. ｣

https://www.theregister.com/science/2026/07/04/nasa-says-it-will-isolate-volunteers-from-the-outside-world-for-a-year/5266558

#nasa #space

The Free Software movement never escaped from its origins: the early ‘80s MIT AI Lab. Two things were true in this environment:

• Back when most computers had tens of KiBs of RAM and 1 MiB was a huge amount, programs were simple. Very few programs were so complex that one person could not completely understand them.
• The AI Lab was full of some of the most talented programmers in the world.

This meant that the only obstacles for these people being able to fix bugs and add features to any program were access to the source code and the legal rights to modify it. Once you have those, any program was understandable by that group and they could modify it however they wished.

For the next 40 years, the FSF focused on these two things. The world around them changed. These two prerequisites were never enough for most people (what do 90% of computer users do if you give them even a modest 10,000 line C codebase and tell them they can change it however they like?) and now they aren’t enough even for competent programmers.

When Linus says ‘fork it’ to folks who don’t want LLM-extruded code in their kernel, he knows full well that it is almost impossible to fork a 40 MLoC C (and Rust now) codebase that averages more than one CVE per day and have something useful.

The Free Software movement is struggling now because it obsessed over licenses, which was never a path that would succeed, and ignored the hard problems:

• How do you design environments that enable end users to modify their software?
• How do you engineer software so that it is cheap and easy for a random user to maintain a fork that meets their specific needs?
• How do you foster communities where people want to share improvements, so forks don’t proliferate even when it’s easy?
• How do you create an environment where everyone sees the benefits of user-modifiable code to such a degree that trying to sell anything that doesn’t come with these rights is commercially impossible?

Instead of tackling any of these problems, they created more complex and restrictive GPL variants. And well-paid lawyers found loopholes in them that allowed corporations to keep doing what they wanted (and even pick licenses like AGPLv3 to control ecosystems, because they give the copyright owners so many more rights than everyone else that it’s hard for anyone else to compete). They said ‘don’t worry about the complexity of the licenses, you only need to understand the legal details if you’re creating and distributing derived works’ while completely forgetting that making it possible for anyone to create and distribute modified versions of the programs was the entire point of the Free Software movement.

EDIT: Lots of people are reading this as if it’s about the kernel. I would say that the kernel is the least important part of a system for this. The layers on top, especially anything that directly interfaces with the user or controls their data, are far more important to build around these principles.