@Randys has written a new blog article for Purism:
3 Likes
Please resume Core developments for Librem 5.
2 Likes
Yeah, kind of a real snoozer.
3 Likes
IMO, that article was so generic and bland I couldn’t help but wonder whether it was coauthored by an AI/LLM.
5 Likes
It ain’t saying much but rather than quipping about how no self respecting AI wouldn’t [sic] write anything that bland, I’m going to try and find some positives. Communication is a hard art. I mean, there’s nothing wrong with it and nothing unexpectedly odd or grimace inducing announced. On the contrary, it was a post that reaffirms commitment to develop the system. A hint that there may be a future for these devices. I like that there were no fireworks, oversell or drama. I’ll take it. And lets be clear, I don’t think we are the target audience for that.
5 Likes
This
2 Likes
I find the mention of GNOME and Debian in the article about the Linux kernel development confusing.
Purism’s Approach to Kernel Development
Purism takes a unique approach to kernel development, focusing on privacy, security, and freedom. Here are some ways Purism differentiates itself:
- Upstream-First Development: Purism follows an upstream-first approach, meaning they contribute their changes directly to the upstream projects like the Linux kernel, GNOME, and Debian. This ensures that our improvements benefit the broader open-source community and reduces the maintenance burden of specialized forks.
However, they are not the upstream projects where kernel development directly happens. GNOME does not seem to host a kernel-related source repository. It would be out-of-scope for the project. Debian does not aim to develop a kernel, at least per the Debian Linux Kernel Handbook.
The general policy of the Debian kernel team is that a patch must either fix a bug or add hardware support, and must be based on a change already accepted by the upstream kernel maintainers. The change does not need to have been included in an upstream release yet. This policy allows the team to drop most patches when moving to a new upstream version, rather than having to maintain an increasing series of Debian-specific patches. The recommended procedure for inclusion of patches introducing optional features is to submit to the upstream maintainer.
1 Like
They’ve (in the past at least) used to contribute upstream to other projects than kernel, and that may allude to that in general they’ve done similar things. Or someone just copy-pasted text from a previous boilerplate. That AI, perhaps…? 
[btw. I wonder if we should start a poll and guess how long it takes until Purism comes out with some private/secure AI service of its own?]
1 Like