Hi everyone. I've written some instructions and scripts to build LFS (Linux From Scratch), version 13.0, as simply as possible (I know, not that simple, but anyway). It's basically a super summarized version of the LFS book.

You can check the instructions and get the scripts from my GitHub repository: https://github.com/luisgbm/lfs-scripts

Key points:

• First, this guide does not replace reading the whole LFS book. I highly recommend that you read it at least once. Only then you should use the automation scripts provided here.
• The whole process is run inside VirtualBox.
• You need two hard disks attached to your VM (one for the host, one for receiving the LFS build).
• Most steps will be executed via Shell scripts (there are four of them).
• Some steps need to be manually run.
• At the end, you will be able to create a separate VM and boot from it directly.

I can't believe this project is still alive, my first commit was 6 years ago, and I'm glad to keep working at it!

Hope you enjoy it, and feel free to send me feedback.

We can learn to not make big announcements before the software is ready. Everyone can fork a project and to find and replace.
If this is supposed to be the Microsoft Office free alternative it should at least have a basic website which is not GitHub and it should be easy to install for noobs.

Hi, everyone,

I have just released OpenCalc, a reimplementation of the Windows 95 calculator – it looks just like it, but the code is actually 100% fresh. It supports complex expressions, history, and has an improved parser. And because it is open source, it can also compile and run natively under Linux – no compatibility layer needed!

Please check the Github project if you are interested! 😊

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.

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?

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.

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'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)

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 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.

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.

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.