I have a question how did you deal with device trees, was that public available

Yes: https://source.puri.sm/Librem5/linux/-/tree/pureos/latest/arch/arm64/boot/dts/freescale

Purism are cool people and they have indeed built a smartphone that’s as open as possible. The problem is that it’s slow :( Not really their fault.

all you did was hammer out configs

Yeah, that’s my point, all the software is there already, with a little bit of persuasion and glue it runs fairly well together. I’m not claiming I wrote actual drivers or whatever. What I did was figured out how to adapt the existing software to work on NixOS, so you can just take your desktop NixOS config, add a couple lines to it, and run it on the phone.

Now you have a phone where half the hardware doesn’t work

All hardware on Librem 5 worked with NixOS as I expected. The reason I’m not dailying it anymore is because the hardware kinda sucks, it’s outdated and slow. If I could get the same software stack running on more modern hardware I’d gladly use it. Perhaps the battery life could be improved if the power management was better, but that’s about my only complaint software-wise.

Without a solid BASE, and a DRIVER LAYER, you won’t have a successful project to push a UI of anything

I’m not sure what you mean by “solid BASE”. Do you want to rewrite all of the existing software that implements the “desktop Linux” userspace? Who would be doing this and why, when existing stuff mostly works?

“DRIVER LAYER” in the FOSS world is just Linux. Drivers can live in the Linux tree or as small patches on top of it, with common open interfaces allowing compatibility between software and hardware. Just like they have been doing on the desktop for the past 30 years. The problem is plain: there are no open-source drivers or documentation for most phone hardware. Vendors don’t have this issue because they have access to private documentation and the sources of proprietary drivers. Writing FOSS drivers requires reverse-engineering the proprietary drivers, which is very resource-intensive. The proprietary drivers that are there lock you into a particular Linux version (usually a very particular Linux version, and there’s no way to solve this with any driver layer, at least without sacrificing performance and resource usage) and sometimes have proprietary interfaces with the userspace as well, which aren’t easy to write a compat layer for (if that’s what you’re proposing). And in any case, if you are fine with proprietary stuff running in EL1, why not just run Android?

All this is completely orthogonal to making a DE on top of open standards, which is the point of open standards. For hardware that works with (mostly) mainline Linux, desktop userspace with plasma-mobile/phosh on top work well enough already. For hardware that doesn’t, adding support is a lot of work, not because of any issues with the DE or userspace, but because hardware manufacturers don’t publish the driver sources.

I’ve built and run Mobile NixOS on my OnePlus 6 (without modem, fingerprint or GPU accel support but meh) before it became officially supported (this was relatively easy, compared to most other vendors, but did require a bunch of hacking to get the Linux fork OnePlus provides to work with the Nix kernel compilation machinery and the NixOS userspace).

I have also implemented initial support for running NixOS proper on Librem 5, packaged/fixed some stuff 1 2 3 (and more which didn’t make it to nixpkgs) to make it semi-daily-usable with Plasma Mobile, and daily-used it for a couple of weeks and then on and off for a couple of months.

I know how mobile Linux works, from the bootloader to the kernel to the userspace to the DE to apps that run on it. I also have a cursory understanding of how Android works, enough to know that it’s not feasible to build “a base that replaces AOSP”, let alone make it work with vendor-provided driver blobs and proprietary Android apps (which is what you’re proposing?). What manufacturers actually do is take AOSP, patch it to fit their needs/work with their shitty drivers, and ship it on the device as a bunch of blobs because it’s Apache-licensed.

And abstracting the hardware is what you do when you make drivers

Yes, what I’m saying is that Mobile Linux people are typically doing just that, sometimes also trying to upstream it as well. I don’t see how else they could be “working on abstracting the hardware”.

That is AOSP, which is comparable to your distro

AOSP is more than your distro, it’s like the combination of all the gubbins that make your desktop computer work - rendering layer, compositor, unified device interfaces (like bluetooth or the battery), network management, audio, etc; whereas a typical Linux distro is simply a combination of all these already existing things.

Phones tend to have more specialized and proprietary hardware, so you can’t just take the standard Linux kernel, use it there, and call it a day.

Eh, you sort of can on some phones, e.g. OnePlus 5 and 6; on some others it’s just a couple dozen patches away from working.

But I’d be surprised if the people working on this weren’t aware of that fact, and I hope they are working on abstracting the hardware layers more so that every mobile Linux project doesn’t have to start from scratch every time.

The problem with other phones isn’t “abstracting the hardware” (this is done by the Linux kernel), it’s reverse-engineering the drivers so that they run on whatever kernel you want and use the open standards required by the “desktop linux” userspace. In fact, if you look at the “supported devices” list for all those mobile Linux distros you’ll find a fairly similar set; that’s simply all devices for which manufacturer’s (or reverse-engineered) drivers are available. It’s not like FOSS people are writing drivers specifically for their distro, which wouldn’t work with any other - only corporate Android vendors do that!

solid base

GNU+Linux

driver layer

Linux

and then UI layer.

Plasma mobile

The split is already there, the problem is that most Android phone manufacturers never publish the drivers (let alone make them open-source) and the only way to get anything but stock image running is to just rip parts out of the stock image, which significantly limits what you can put below it (i.e. Linux version) and on top of it (i.e Android Java gubbins). And you can’t “just replace AOSP”, as it’s a huge complicated thing (kind of by design) which allows vendors to tightly couple the drivers to the system image. The idea of all these “mobile Linux-es” is to get rid of AOSP entirely, replacing it with “desktop Linux userspace” (systemd, musl, D-BUS, NetworkManager, pipewire, upower, mpris, libnotify, Qt/GTK, Plasma/Gnome, etc etc etc). A DE is an integral part of this; you can’t build and run Nova launcher just with Wayland and Pipewire but without Dalvik and Android SDK/NDK, and remaking all of that from scratch would be an insanely hard undertaking.

To put it another way,

Get a good base that is removed from Google, THEN do this project.

This project is required if you want to make a “good base”, otherwise that “good base” would just be an empty TTY that you can’t interact with because there’s no on-screen keyboard; besides, that “base” is already there and has been for 20 years, what’s missing is the drivers.

I’m doing Nix consulting-type jobs - it can mean anything from simply packaging some stuff for Nix and making a devShell to refactoring existing Nix-based infra (which can be hundreds of thousands of SLOC) to building entirely new developer UX, CI/CD and even production deployments on Nix/NixOS. I’ve also been paid to implement some cool features into Nix itself, fix bugs, etc. I’m really quite happy with the job, even though it could probably pay more :)

Eh, probably if Guix becomes significantly better I’ll switch to it (from NixOS). I really like how seriously they take user freedom, bootstrapping (only 357 bytes of binary to bootstrap everything else from source!) and consistent user interfaces (scheme everywhere). But unfortunately the package repo is just not big and mature enough yet, and declarative configuration options are not as good as they are with NixOS. My job is also Nix-related, and that’s another major reason I’m staying for now.

No, it’s not. It’s a word predictor trained on most of the web. On its own it’s a pretty bad search engine because it can’t reliably produce the training data (that would be overfitting). What it’s kind of good at is predicting what the result would look like if someone asked a somewhat novel question. But then it’s not that good at producing the actual answer to that question, only imitating what the answer would look like.

I’m surprised it took this long. The world is crazy over AI, meaning everyone and their grandma is likely trying to do something like this right now. The fact it took like 3 years for an actual vulnerability “discovered by AI” (actually it seems it was discovered by the researcher filtering out hundreds of false positives?) tells me it sucks ass at this particular task (it also seems to be getting worse, judging by the benchmarks?)

Touchscreen (and 2-in-1) support in general is quite good, both Gnome and Plasma (two most popular “desktop environments”) support it well. It should be about as responsive as it is on Windows, because the response time generally comes from hardware and not software. However, I must warn you that I’ve had a similar HP 2-in-1 (although a different model) and there simply wasn’t a Linux driver for the touchscreen so it didn’t work at all; all the other tablet-like features worked fine. I would first check on a liveUSB - the touchscreen should work there the same as it will on the installed distro. If it doesn’t work, well, there’s your answer.

If by GNUIX you mean GNU Guix, they yeah it’s good enough. I’ve tried it on real hardware and didn’t find any issues. I would consider switching to it, but my day job is Nix-related so I’m running NixOS to make things easier. The learning curve is really steep for both Guix and Nix but I think their approach is great in the long term and worth investing some time into.

read a filename from the user

Honestly for something repetitive like this I’d suggest trying to avoid user interaction completely. It’s probably better to get that info from the DVD drive itself (blkid -o value -s LABEL /dev/dvd), or if that fails assign a number.

First they came for 486, and I did not speak out - because I’ve never actually owned a 486…

Thanks! I will try and report the results back to you.

Do I have to build all other parts myself before then? (I’m trying to package it for Nix so that other people can also build it more easily)

Are there any instructions on how to build this all to get the ventoy installer binary that can replace upstream? Or is the project not up to this stage yet? I can go without Windows and FreeBSD support.

AppImage suffers from the same problem that Flatpak does, the tool do work offline aren’t really good/solid and won’t save you for sure

I’ve been using my laptop in areas without internet for days. It works fine.

It also requires a bunch of very small details to all align and be correct for things to work out.

I have appimage-run from nixpkgs installed, which handles all those details. They are also not too hard to figure out manually should you need to.

Imagine the post-apocalyptic scenario, if you’re missing a dependency to get something running, or a driver, or something specific of your architecture that wasn’t deployed by the friend alongside the AppImage / Flatpak (ie. GPU driver) you’re cooked.

GPU drivers are emphatically not part of the AppImage. They are provided by Mesa, which is almost guaranteed to be installed.

Meanwhile on Windows it has basic GPU drivers for the entire OS bakes in, or you can probably fish around for an installer as fix the problem

It’s actually the other way around - if you want your GPU to work properly on a new Windows install, you have to fish around for AMD/NVidia drivers. On Linux Mesa is pretty much pre-installed on all distros.

It is way more likely that you’ll find machines with Windows and windows drivers / installer than Linux ones with your very specific hardware configuration.

LMAO, try moving a windows installation from Ryzen+AMD GPU to Intel+NVidia GPU and let me know how it goes (hint: you will have to manually uninstall, and then install a shit ton of drivers, for which you will need internet).

Meanwhile I’m typing this from a (Ryzen+AMD GPU) desktop which has an SSD from my (Intel+integrated graphics) laptop. When I plugged it in, it booted into sway just fine, with complete GPU support and all, and the only reason I had to update my config is to make it more convenient to use on the desktop.

Linux is not the best “apocalypse” OS, but it sure is better than Windows.

There are ways to deal with this. There’s AppImage for GUI apps (that replicates the “just get an exe from a friend on a flash drive”) and lots of bundling programs for non-GUI apps (I use nix-bundle because I use Nix, but there are other options too).

Lots of distro installers work offline too, by just bringing all the stuff you need as part of the installer.

And one major benefit of Linux is that when stuff does inevitably go wrong, it’s infinitely easier to fix than proprietary garbage.