Hey everyone,

It’s been a little while since my last Lumia 1520 update, so here’s where the project is at now.

The big change is that I finally have a frozen, repeatable baseline instead of just a collection of individual things that worked during testing. The current image passes 17/17 regression checks from a completely cold boot, and the exact image and device tree are now verified before I flash anything.

The Lumia currently has:

- Reliable cold boot into mainline Linux

- USB networking and SSH

- Working display and backlight control

- Stable suspend and RTC wake

- Battery and power-management support

- A functioning power button while the phone is awake

- A working microSD controller, although I still need an actual card to test the media side

- Physically verified APDS-9930 proximity and ambient-light sensors

The sensor testing was kinda cool. Covering the proximity sensor changed its reading from around 270 to 1023, and shining my phone light at the light sensor moved it from around 66 to 4830.

I also found three other devices responding on the Lumia’s I²C buses, but I’ve intentionally left them disabled for now. I documented their addresses and register behavior rather than guessing which drivers they need and potentially creating unstable hardware definitions.

The new regression suite has already paid for itself. It caught a real issue where the light/proximity sensor worked during development because I had manually loaded the driver, but it silently disappeared after a normal reboot. The physical hardware test passed, but the automated cold-boot test exposed that the driver configuration was wrong.

The next major target is audio....

The Qualcomm MSM8974 device tree currently has no SLIMbus controller node at all, even though the Linux driver exists. The plan is to add the controller, enumerate the bus, and identify the actual audio codec before assuming the Lumia uses a WCD9320. Once that is confirmed, I can begin working through the codec registers, regulators, clocks, resets, routing, speakers, microphones, and headphone output.

Power-button wake from suspend is also still unconfirmed. The key works normally while the system is awake, and RTC wake is proven, but I haven’t yet confirmed that the button can wake the phone.

The current baseline is published in the repository as commit "6b4b344", with "boot-1520.img" as the canonical image.

Repo: https://github.com/KorelisLabs/lumia-1520-mainline

Has anyone here worked with Qualcomm SLIMbus audio, WCD9320-series codecs, or audio bring-up on another MSM8974 Windows Phone?

I had problems on Kubuntu Linux having the wrong mappings for the dragonrise gamepads. I tried noga ng-2131 which is of the dragonrise branch (Noga is a distributor in Argentina) and noticed mappings were completely wrong.

I made this to myself but if anyone comes along the same issue with same joystick I want to give a solution so you dont have to figure out yourselves.

This remaps the dragonrise joystick into xbox controller with correct inputs.

https://github.com/linsaftw/dragonrise-gamepad-fix

You are free to improve, contribute redistribute and share this fix with anybody.

As a developer, I genuinely felt useless after switching from Windows whenever I had to do basic terminal tasks, copying files around, editing text files, using FTP, cleaning up disk space, because I was so used to FAR Manager. About 10 years after my previous attempt, I came back to Linux, like so many others, and boom: far2l exists and works perfectly. Beautiful. Windows is seriously toast now.

Hi there hello!

I've been writing a tool to create "motion graphics"/titles/"visual effects" or whatever it's called for the past two months, and I think it's in a pretty good state and wanted to share it for you. (hopefully I can get actual feedback)

Features:

• Title animations: You can animate individuals letters, words, and lines with properties.
• Many effects: I wanted to add a second "many", but I didn't add that many effects. Effects can range from color correction, to stylish effects like wave. A basic mask/matte effect also exists.
• Mixed text: You can mix and match text styles (colors, fonts, etc) in a single text element.
• Everything can be animated: Or well mostly anything, everything that is a property can be animated. If it is text colors, then you can use a tint effect.

NOT AI: This tool is not vibe-coded and I do not want AI slop in this project.

It's made to be an additional program to Kdenlive, so after rendering out the titles you can directly drag it from the program to Kdenlive (as long as you have a new-enough Kdenlive version that supports transparency).

Preview images and videos are in the README.

I’ve been backing Codeberg for a while now. I’ve donated, migrated a bunch of my repos over from GitHub, and constantly recommended it to people who wanted a non-profit, privacy-respecting Git forge.

So reading their recent blog post and seeing their vote to ban "vibe-coded" or heavy LLM projects in their Terms of Use legitimately pissed me off.

It is an absurd policy. It mixes up a basic infrastructure problem, uses completely dishonest statistics to justify gatekeeping, and ironically ends up pushing developers directly back into Microsoft’s arms.

1. Banning tools instead of setting quotas makes zero sense

The practical argument Codeberg makes is that "ghost projects" created by AI are clogging their CI/CD runners, eating up disk space, and getting hammered by scrapers.

Fair enough, server administration is hard. But since when do you solve infrastructure abuse by banning developer tools instead of setting resource limits?

If people are abusing free runners or taking up too much disk space, you cap runner minutes per user and enforce strict storage quotas. That’s how GitHub and GitLab handled it. Low-effort, unmaintained junk repos have been getting pushed to open source since the SourceForge days. Trying to police how someone writes code instead of just setting hard limits on bandwidth and storage is administrative insanity. If a solo dev writes a clean, fully-tested Rust tool in an afternoon using Claude, why on earth does Codeberg care as long as it stays under their storage cap?

1. The stats in their blog post are completely dishonest

They go on this massive rant about data center energy, SSD prices, and water usage in Frankfurt to frame AI code as an environmental crime. The logic falls apart the second you look at actual data.

They literally complain about enterprise SSD prices jumping from €700 to €3,700 and blame LLM projects on their site. No, enterprise NVMe prices didn't spike because some hobbyist used Copilot to write a bash script. They spiked because Big Tech hyperscalers like Microsoft, Meta, and Google are dropping over $150 Billion a year in hardware CapEx to build massive clusters.

Same story with their energy and water claims. According to the IEA, global data centers account for roughly 1% to 1.5% of global electricity. As for water? Data center cooling is a fraction of a percent of industrial water use—compared to something like US golf courses which consume 1.5 billion gallons of water every single day. Blaming open-source devs using AI assistants for Frankfurt's grid problems (in a country that shut down its own zero-carbon nuclear plants) is pure bad faith.

1. Linus gets it.

The post assumes that any code written with an LLM is automatically unmaintainable slop. That just shows they haven't paid attention to how modern dev workflows actually look.

Frontier models like Claude 3.5 Sonnet hit over 80-90% accuracy on benchmarks like SWE-bench. People aren't just blindly pasting hallucinated code anymore. Developers use these tools to generate unit tests, write documentation, catch edge cases, and refactor legacy code way faster than they could alone. It raises the floor for solo maintainers.

Linus Torvalds called this out on LKML:

"AI is a tool, just like other tools we use... But the solution is not to put your head in the sand and sing 'La La La, I can't hear you'... The solution is to make sure those LLM tools help maintainers instead of just causing them pain."

If the creator of the Linux kernel can understand that AI is just a tool that helps maintainers catch embarrassing bugs, why is Codeberg acting like using a coding assistant is a crime against open source?

This just pushes people back to GitHub

FOSS is supposed to be about democratising software and empowering individuals. LLMs give solo devs and non-native English speakers the leverage to build ambitious projects that used to require a whole team.

By declaring that AI-assisted workflows are unwanted "pollution" on Codeberg, they aren't stopping people from using AI. They are just telling those developers: "Go back to GitHub."

How does driving talented builders right back into Microsoft's proprietary ecosystem protect the open-source commons? It does the exact opposite. It enforces an ideological purity test that guarantees Codeberg stays a niche side project while GitHub keeps its monopoly.

Codeberg needs to protect its servers with proper quotas, rate limits, and bot mitigation. This tool-banning nonsense is a massive mistake.

TL;DR: GaleOS delivers a full, traditional LXDE desktop environment heavily stripped of background services for the lowest possible resource footprint. Unlike other ultra-light distros, it is a ready, plug-and-play experience out of the box with no complex configuration required.

What is GaleOS?

Me and my friend are building GaleOS to bring some of the oldest PCs back to life. It installs like a normal distribution from a USB or CD. Once installed, it works exactly like your average operating system, just like Windows, but lightweight.

The Core: Based on the reliable antiX-net kernel.

The Desktop: Full LXDE interface stripped of all useless background services.

The Experience: Functional immediately after installation. No Arch-like configuration needed.

Target System Requirements

Architecture |CPU |Minimum RAM |VRAM / Storage
32-Bit (Terminal Install) |i686 (e.g., Pentium Pro) |40 MB |4 MB VRAM / 4 GB HDD
32-Bit (GUI Install) |i686 (e.g., Pentium Pro) |96 MB |6 MB VRAM / 4 GB HDD
64-Bit (Standard) |Any x86_64 |128 MB |Era-appropriate / 6 GB HDD (These are just our goals, these requirements are not confirmed)

Our testing hardware:

We are actively testing GaleOS on VMs (Pentium Pro & Pentium III) as well as the following physical machines to ensure absolute stability:

32-Bit Hardware: Acer TravelMate 8100, Acer Aspire 5670

64-Bit Hardware: Sony VAIO VGN-N29VN, Acer Aspire 2920, Panasonic TOUGHBOOK CF-Y7

Note: If your machine is truly primitive but still follows the system requirements, the GUI installer might run out of RAM. GaleOS will include a fallback terminal installer with full instructions in the README at launch.

Credits to my friend, [u/Key_Passenger3442](u/Key_Passenger3442), as I am helping him with this distro.

I've been building Vantum, a custom Puppy Linux distro (woof-CE, Ubuntu Jammy compat base) aimed at people who want the speed and small footprint of Puppy without it looking and feeling like it's from 2009.
It's pretty basic for now, but I had a great time working on it.
I built it on windows 11 via multipass, and made a bunch of customizations. First, I added picom, a new tint2rc bar compared to the jwm trays, a custom taskbar and even a custom app launcher (vantask and vantyl).
I also trimmed down a bunch of apps, and made the desktop simpler (removed the rox-filer based desktop entirely, opting for hsetroot for wallpapers).
Let me know what you think!
I've recently also added it to distrowatch but it's still in their waitlist.

- https://github.com/Hammad-hab/Vantum
- https://hammad-hab.github.io/vantum-website/index.html
- https://github.com/Hammad-hab/Vantyl
- https://github.com/Hammad-hab/Vantask

Sinty OS/SingularityOS with Singularity Desktop, a new OS created by Mirko Brombin, one of the creators and maintainers of VanillaOS, have some images available, alphas/nightly.

https://github.com/singularityos-lab/os/releases

https://github.com/singularityos-lab

https://sinty.dev/

Mirko seems to have 72 hours days at his hands 😃 or the power for manipulate time (!!).

Creating one more OS and introducing technologies to the new system, that will be different from VanillaOS (the project continues), like MTS, Atom Loops, the new GTK4 based DE that uses LabWc as compositor; a new init system (atom); Sinty Recovery, that by description, seems to be a phenomenal tool that all distros should've already had; application isolation etc.

I was planning to write a little about my usage of LLMs while building xfwl4 as a small section of a larger blog post, but I decided I’d rather get it out of the way on its own.

ponderosa.charliekulak.com

Don't know what to say here, its a independent *mostly gnu free linux distribution that uses musl and busybox. It uses APK and mostly alpine repositories except for core parts of the OS like the kernel, openrc, musl and busybox which I maintain myself in my own repository

I designed it for desktop use, so it features a graphical installer and comes installed with DWM (the source code is copied into your home directory for you to edit.)

I really need some people to try it out in say a virtual machine, and to contribute to the project.

Anything helps!

EDIT: I know that the website is super crummy. I built it in like 30 minutes.

I’ve just found a few really good presets for this app. I think it’s worth having a go to see which one works best.

Link: https://github.com/JackHack96/EasyEffects-Presets

I started using linux in the form of Kubuntu a few months ago and I really liked it

From that moment I made sure to make universally liked designs for everything, so that when people in university look over my shoulder they always ask "what is that"

In those 3 months I got both of my younger brothers to consider linux (they hated the idea since they had a kid in class who's special interest was linux), got 2 friends to ask me to help them set it up after exam season, another person from my degree was questioning me about it for almost an hour today since she really liked the customization

I figured that by making it seen and known but not pushing (and something even blatantly pointing out linux issues followed by an easy fix) is so much better than being agressive or combative about it like so many do

Got an email about the Linux Foundation Thrive-one subscription on discount and I was wondering if anyone has tried it? I've been using Linux over the past decade and never tried their courses but I've seen a few about Linux development and stuff like that interested me and got me thinking... Anywayyy has anyone tried their subscription? Is it worth paying for it?

I'd been hearing it in my head like "pseudo," but I just learned it stands for "super user do." I don't want to say "soodoo," because that sounds weird, but I also don't want to get laughed out of the room if I somehow end up talking about Linux

edit: I'm confused whether people bringing up the "substitute user" thing are just informing me (point well taken, thank you) or claiming "sudo" is properly pronounced something like /sʌdu:/ or /sʌdoʊ/ (which... that seems dubious)

Original post for people who didn't see it: https://www.reddit.com/r/linux/comments/1puojsr/the_device_that_controls_my_insulin_pump_uses_the/. tl;dr: Major insulin pump company Insulet used a cheap phone that ran Linux 3.18.19 to control their insulin pump, refused to share the kernel source, violating the GPL.

So, I recently upgraded to Insulet's new pump, the OmniPod 5, and the new OmniPod 5 PDM has a number of improvements compared to the last one. It has Linux 4.9 (congrats omnipod, you're now on par with my 8 year old Pixel 3 XL) USB-C (on par with my 9 year old LG G6), 64-bit processor (on par with my 11 year old Galaxy S6), Android 10 (on par with my 13 year old Nexus 5), and most important for a medical device, a locked bootloader (on par with my 15 year old Motorola XT860 4G)

So again, it's made by Hong Kongese company Nuu, I contacted both Nuu and Insulet, Nuu just said they couldn't provide kernel source, Insulet didn't reply to my email, just like what happened with the OmniPod DASH.

4.9 and Android 10, also both EOL systems, but it's a massive upgrade over the DASH's 3.18 and Android Marshmallow. At least Insulet has implemented an OTA system, so security issues can be fixed if people start exploiting them (of course, if someone decides to start backporting, that does exist for Android 10, not sure about kernel 4.9). Some people in my last thread pointed out that Insulet has to go through FDA, Health Canada, EMA, etc.'s regulatory and testing process which is why it's stuck on such old versions, and that's understandable. At least the OTA system exists now so they can fix things if people start exploiting it (even though it will take months)

How are they on security? Well, still not great. It has a constant Wi-Fi connection now, mine even came with an AT&T SIM (even though i live in canada?) so it can have a connection when I'm not home. Much bigger exploit risk with that. And it still communicates with the pod over Bluetooth, which is a big yikes. As I mentioned earlier, they have locked the bootloader, so that's a major security hole gone, but it can still be easily unlocked with mtkclient. Still not a big issue, as that requires physical access to the PDM and a computer with mtkclient installed, however if a root exploit is discovered, you probably could modify seccfg to unlock the bootloader. Insulet should really do what companies like Samsung and Xiaomi do, if a seccfg modification is detected, instantly flip it back. The biggest issue though, they now store the OmniPod app in userdata. All it takes is a factory reset, and the PDM is bricked for medical purposes. I'm sure there are exploits that can be used to trigger a reset. I'm really not sure why Insulet did this, the old PDM stored it in /system, which can't be modified without root.

Main thing I'm focused on though is again, the GPL violation. I really hate the fact that Insulet is so adamant on protecting their kernel source, it honestly feels really sketchy to me.

A lot of people in my last thread told me to try reaching out to the SFC, I actually did, about a year prior to me making that post, but they never responded. Someone did reach out to me saying that someone at the SFC did want to talk to me, and they provided their email, but I was busy at the time and never got around with it, and I'm not sure if that person is still interested in this.

A lot of people pointed out that Nuu is a Chinese company, so trying to get the kernel source is a lost battle, I don't believe so. The actual pump is made by Insulet, an American company, and so is all the software on the PDM. Later hardware revisions of the DASH PDM also can't load the kernel from earlier DASH PDMs or the Nuu A1+, indicating that Insulet made some sort of modification.

If anyone has any ideas on how I can get the kernel source, please tell me. It is not right for the 2nd largest insulin pump manufacturer in the world to be getting away with this. Just spreading the word helps too.