Window Maker Live (Linux distro)

[wmlive]

A new version of wmlive based on Debian/Bookworm 12.12 was released yesterday. Apart from improvements over the previous 12.8, it contains quite a few software updates. I've attached the file describing the major new features.

See wmlive.sourceforge.net for further details.

Yes, it's not based on the brand new Debian/Trixie yet because I preferred to create a final version with all the updates available to date. With all the packages from the backports, wmlive 12.12 is not that far from Trixie as one might expect.

Above all, I wanted to make sure that the latest 32-bit variant is as up-to-date as possible because there will be no other from now on.

When I have recovered from the hustle and bustle related to this version, I will start working on the next one, this time based on Trixie.

----------------8<---------------

    WHAT IS NEW IN RELEASE 12.12?

    This release is based on stable Debian/Bookworm release 12.12 and
    contains the backported Linux kernel version 6.12.38 for the amd64
    variant.

    The i386 variant stays on backported kernel 6.10.11 as last official
    i386 kernel provided by Debian.

    Due to Debian's deprecation of the 32bit CPU architecture starting
    with Debian/trixie this will likely be the last wmlive release
    capable to run on Intel compatible 32bit processors.

    Apart from the usual Debian package updates following components
    were updated with newer release versions: palemoon-33.8.2,
    emacs-gnustep-30.1, previous-3.9.  The transmision bittorrent client
    was replaced by qbittorrent.  Additionally, the VPN client riseup-vpn
    was added as a new component.

    Notable package updates originating from Debian's backports
    channel contain amd64-microcode (3.20240820.1 => 3.20250311.1),
    claws-mail (4.3.0 => 4.3.1), curl (8.10.1 => 8.14.1), emacs
    (29.4 => 30.1), handbrake (1.9.1 => 1.9.2), intel-microcode
    (3.20240910.1 => 3.20250512.1), libvirt-daemon-system (9.0.0 =>
    11.3.0), linux-image-amd64 (6.11.5 => 6.12.38), pipewire (1.2.5 =>
    1.4.2), qemu-system (9.1.2 => 10.0.2), and systemd (254.16 => 254.26).

    The separate inclusion of duplicate firmware packages on the
    ISO image has been dropped in order to reduce it's overall size.
    Since the live system image already contains all available firmwares
    installed there is no functional difference from the user perspective.

    Installed systems with space constraints always can later be trimmed
    from huge unnecessary firmware packages using the dpigs command to
    find out the largest disk space consumers.

    This will be the last wmlive release still based on Debian/Bookworm.

[jeffburg]

@wmlive thanks so much for sharing. I really want to use this for my 1 use-case where I am currently using Linux.

I run a Debian 13 VM on my Apple Silicon Mac to run a video streaming server with FFMPEG. Why Debian 13? I tried Debian 12 and had lots of audio issues. Popping and clicking audio that only works for about 10 minutes before going fully silent. I looked into this and I thought it might be because Debian 12 has an extremely old version of Pipewire. So I tried 13 and that fixed it! I was so excited.

https://repology.org/project/pipewire/versions

But I really do want to use WindowMaker because I think it looks great. I installed WindowMaker on my Debian 13 install via Apt. I could log in but it just did not look anything like the screenshot you posted. So I imagine there is extra magic in WMLive to make WindowMaker work more like NeXTSTEP?

Anyway, it looks like Debian 12 can run the newer version of pipewire 1.4.2 via Backports. So maybe I can run Debian 12 and install pipewire via backports. But then the problem remains, WMLive does not have an ARM64 ISO image.

So yeah, not expecting my strange use case to be supported, but I thought I would share what is preventing me from using WMLive to see your thoughts. I am not a Linux expert by any means... and you clearly are so I would like to get your opinion.

Thanks so much,
Jeff

[wmlive]

But I really do want to use WindowMaker because I think it looks great. I installed WindowMaker on my Debian 13 install via Apt. I could log in but it just did not look anything like the screenshot you posted. So I imagine there is extra magic in WMLive to make WindowMaker work more like NeXTSTEP?

Indeed, wmlive contains a whole lot of preconfigurations and a few additional packages that are missing in Debian proper.

The related packages are all available at https://wmlive.rumbero.org/repo/ and, if you add it to your sources.list as outlined there, you should be able to add the missing packages containing the necessary preconfigurations. To begin with, the most important package is wmlive-base as it includes the needed /etc/skel/ containing the modified configuration files. Then there are some theme components for gtk+ and qt5/6 to get the basic NeXT looks in the packages wmlive-pixmaps, wmlive-theme-onestepback, wmlive-theme-twostepsback, wmudmount, qt6gtk2, etc.

I have never tried converting a basic bookworm installation into something more akin to wmlive by using these external packages. So you'd need to try on your own.

By the way, wmlive always already has all latest backport packages installed, including pipewire-audio 1.4.2.

But then the problem remains, WMLive does not have an ARM64 ISO image.

The source tree to build the ISO images already has the capability to create ARM64 images and it is possible to somewhat use these ISO in qemu. But this is where the chaotic world of ARM64 boot mechanisms and loaders rears its ugly head: There is no way to create a single ARM64 ISO matching all different ARM64 platforms out there. There really needs to be something like a unified UEFI or BIOS to remove this pain.

The only ARM64 machine i own is a Pinebook Pro, and i gave up trying to figure out how to make it boot any wmlive ISO. A few people requested a version for raspberry pi but i don't own one and therefore can't even try to get this done. This is a problem someone else with better knowledge and access to suitable ARM64 target platforms needs to solve.

[jeffburg]

@wmlive this is great to hear (about the back port packages)! now I really want to try! Uh, as far as the ARM64 build. Is there a link? And as far as boot loaders go, since it was based on Debian, and just assumed you used the same boot loader. The Debian ARM64 ISO image worked absolutely fine for me.

But I also do understand the frustration of not having a unified boot process. That's like super annoying. I mean, I have been a Mac user with old world rom, new world rom, and then intel EFI (stripped down to the bone on purpose by apple) and now Apple silicon which is like basically not a boot loader lol. So yeah, it would be nice if Microsoft or someone could define an EFI like standard for booting ARM systems.

[wmlive]

@wmlive this is great to hear (about the back port packages)! now I really want to try! Uh, as far as the ARM64 build. Is there a link? And as far as boot loaders go, since it was based on Debian, and just assumed you used the same boot loader. The Debian ARM64 ISO image worked absolutely fine for me.

I have created an ARM64 build just for testing purposes to verify if it actually builds. But as i basically have no real hardware to test it on, besides the awkward Pinebook Pro where i don't succeed booting it via u-boot, i prefer to not release any ARM64 ISO variant of dubious quality just wasting the potential downloader's and also my own limited time.

When i read "works for me" this lets me assume in your case that this applies to an Apple silicon machine. This hardware is unknown to me and therefore i can't help any further. Generally, i know Macs only from hearsay and have never ever owned or even only used one of these in my 30 year IT career stumble.
Out of curiosity i once succeeded hackintoshing an old Thinkpad T60 with Snow Leopard last year but haven't been using it any further than that. Running OPENSTEP on the same machine proved to be much more rewarding.

You might easily try building an ARM64 ISO by yourself, leveraging your existing Debian installation, from the supplied sources. The sources of the wmlive build tree are located on the ISO in sources/wmlive-bookworm-12.12.tar.xz and only need to be unpacked somewhere safe with about 15 GB free disk space inside your existing Debian system. Make sure to have the live-build and apt-cacher-ng packages installed, and then switch into the unpacked build tree folder and just run the following command:

Code Select Expand

# ./mkwmlive arm64 | tee ../wmlive-build_$(today).log 2>&1
The wmlive repo mentioned in my former reply has ARM64 versions of the packages required to build an ISO and will be automatically used during the build process.

The apt-cacher-ng is needed to avoid downloading packages repeatedly when running the ISO build multiple times. This also requires at least 2 GB of free disk space under /var for the package caching with apt-cacher-ng. If the build routine complains about inconsistent proxy settings, ensure to have following line in your Debian system's /etc/apt/apt.conf.d/02_apt-cacher-ng file:

Code Select Expand

Acquire::http { Proxy "http://127.0.0.1:3142"; };
and then reload the service with

Code Select Expand

# systemctl restart apt-cacher-ng
If the build succeeds, i'm almost certain there will still be some issues preventing the ISO from working as intended. But maybe we can work this out together?

Any other issue you might stumble over, just let me know.

But I also do understand the frustration of not having a unified boot process. That's like super annoying. [...]
So yeah, it would be nice if Microsoft or someone could define an EFI like standard for booting ARM systems.

The worst part is the amount of time to invest without any success or return whatsoever trying to get this working. My personal resources regarding time (and finances) are very limited and i really have to choose where to concentrate on.

"EFI like standard"? Reminds me of https://xkcd.wtf/927/

[wmlive]

You might easily try building an ARM64 ISO by yourself, leveraging your existing Debian installation, from the supplied sources. The sources of the wmlive build tree are located on the ISO in sources/wmlive-bookworm-12.12.tar.xz and [...]

Of course, if you haven't downloaded the ISO yet and want to avoid wasting 3 GB's worth of bandwith, just fetch the separate source package https://sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/wmlive-bookworm-12.12.tar.xz from the sourcforge site. No need to waste precious bandwith, time, or disk space.

EDIT: It's a pity the quick edit button disappears after only a too short while after posting. This time frame should be more generous, like an hour or so?

[jeffburg]

hey @wmlive thanks so much for the thoughtful reply. I totally understand about limited resources. I think I gave you the same response about building MathEdit for GNUstep. And yeah, my use case is definitely super niche.

If it's as easy as you say to compile it from source I may give it a shot. If I get time and if it compiles, I will let you know if it boots on QEMU on my Apple Silicon Mac. I still think thats a long shot from supporting real hardware, but it's something.

Thanks again!
- Jeff

[wmlive]

If it's as easy as you say to compile it from source I may give it a shot. If I get time and if it compiles, I will let you know if it boots on QEMU on my Apple Silicon Mac. I still think thats a long shot from supporting real hardware, but it's something.

The interest you are showing managed to further pique my curiosity and i've had yet another closer look at an ARM64 build suitable for at least qemu. Once i get the build into a sufficiently satisfying state for 3rd party scrutinising i will provide you with a private download link. If it turns out to be suitable for your needs then maybe i'll publish it officially as an experimental build.

[jeffburg]

OMG. that would be amazing!

[wmlive]

Hey @jeffburg, have a look at sourceforge.net/projects/wmlive/files/wmlive-bookworm-12.12/aarch64_experimental/ for an ARM64 wmlive ISO.

Unlike Debian/Trixie's, the ARM64 variant of the debian-installer for Debian/Bookworm doesn't offer a graphical installation frontend. Instead, there is only support for a very similar text based installation frontend. To add insult to injury, this text based frontend runs only on the serial console of the system, which is rather a hassle to access on real hardware. Luckily, in QEMU ist is pretty easy to switch between the graphical console and the serial console.

Here are the contents of the accompanying README:

----------------snip--------------
WARNING!

This is a strictly experimental build of wmlive for aarch64/arm64. It has not
been tested or even verified to function on any real world bare metal system.

There are no guarantees or any promise whatsoever for proper functionality.
If you are curious, try this on your own risk and be prepared for failure.

The ISO is configured to boot on UEFI using grub. There is no u-boot support.

It boots and appears to work as expected within a QEMU virtual machine
environment, including installation to (virtual) disk.

The aarch64/arm64 bookworm debian-installer does not feature a graphical
installation frontend but only allows text based installation via the serial
console.

The archive wmlive-bookworm_12.12-arm64.tar.xz contains a copy of the build
tree which was used to create this exact ISO image. Use ist to create a build
according to your own ideas.

Good luck!

[jeffburg]

@wmlive so awesome! I am going to try it! It's downloading now. I have never tried to access to the serial console in QEMU so we shall see how it goes.

[jeffburg]

@wmlive its working. I was able to boot to the live desktop. Now I am doing the install via the serial console.

[jeffburg]

It worked. I will have to see if I can get my streaming setup working now. Thanks so much!

[jeffburg]

Hey @wmlive thanks again so much for going the extra mile for us weird ARM64 people. I updated the guide for my streaming setup, but unfortunately I went with Debian 12 and installing Backports. I was going through the process to set up the WMLive you gave me, but unfortunately, I ran into a problem that I couldn't get around even with the help of ChatGPT. I am not sure if I just made an error or if this is something you know about/a deliberate choice.

But for some reason, WMLive was not resolving "local" hostnames. Apple calls this Bonjour but I am not sure what the open source community calls it. But it works totally fine in Debian. I can ping "My-Other-Computer-Name.local" and it resolves the DNS name and pings it. Vice versa, I can ping "My-Debian-VM.local" and then it resolves and pings. But with WMLive, I was not able to ping other devices on the network.

And again, I am not asking for tech support, or for you to fix my bug. Not at all. I am just telling you the reason I was unable to proceed using WMLive :-/

If you're curious in seeing the full guide I created using Debian, you can go here

https://github.com/jeffreybergier/Retro-Stream-Tutorial

[wmlive]

But for some reason, WMLive was not resolving "local" hostnames. Apple calls this Bonjour but I am not sure what the open source community calls it. But it works totally fine in Debian. I can ping "My-Other-Computer-Name.local" and it resolves the DNS name and pings it. Vice versa, I can ping "My-Debian-VM.local" and then it resolves and pings. But with WMLive, I was not able to ping other devices on the network.

If pinging the IP addresses of devices on the local network works, which i'd expect to within a properly configured local network, then it would suffice to add the hostname/ip-address combination to the Linux host's /etc/hosts file and do a "systemctl daemon-reload" afterwards. I'd have to see how this is done in Debian proper and i fear it will be yet another systemd appropriation of UNIX ways.

Personally, i am fine with the manual old-school approach of editing configuration files with vim.