The ssh key to access the private git repo is on the same yubikey as the decryption key (they are technically different GPG slots but I don’t need to care about that, just plug the key in, type in the pin, and it all works automagically)
The process then still is: check out that Git repository, except there’s another step: copy over your private key so that you can decrypt your secrets.
I store my secrets in a separate private git repo and automatically decrypt them with my hardware key (https://github.com/balsoft/nixos-config/blob/master/modules/secrets.nix) so for me it’s literally just plug in my yubikey and nixos-install github:balsoft/nixos-config#hostname
I think NVK is only for newer cards though, right?
And with no real reason
The real reason is planned obsolescence. Your old GPU working is bad for NVidia because it means you’re not buying a new one from them.
This quarrel is the usual political theater intended to distract from all the awful shit happening in the background (dismantling the remains of the welfare state and safety nets, impending environmental & climate disasters, and the ol’ favorite - insane wealth redistribution upwards).
However this time, with an actual fascist in power, all the prop guns on stage are actually real and I wouldn’t be surprised if Elon is deported or even “found dead”. He fucked around and got a fascist elected, I hope he finds out. Either way, this is not something to pay any attention to.
How is nouveau doing for those older cards these days? Are they at least still usable as a display adapter?
It should work. The only practical issues are:
The ideological issue (which you probably don’t care about) is that it pretty much requires proprietary (non-FOSS) drivers which run in kernel space and so in theory have complete access to all data on your computer (but then so does Intel ME). This is the main reason I personally will never use NVidia cards.
While I’m usually all for Free software (as opposed to open-source software),
His problem is the exact reason GPL was created.
Nah, his problem is that Microsoft has much billions of dollars and so doesn’t give a fuck about any licenses on projects by small developers. They simply ignored even the terms of the MIT license (which required MS to keep the original copyright notice, which they didn’t). GPL would’ve done squat here since it also allows for forking (by design), but also because the US legal system is cooked, and people don’t have many rights left when it comes to a dispute with a corpo.
Proprietary = shit. Don’t get me wrong, all software is shit, but at least you can make open-source software suck less for your usecase.
Kinda mobile-nixos, shame it’s semi-abandoned and difficult to get working :(
I’ve stolen a bunch of Git aliases from somewhere (I don’t remember where), here are the ones I ended up using the most:
g=git
ga='git add'
gau='git add --update'
gcfu='git commit --fixup'
gc='git commit --verbose'
'gc!'='git commit --verbose --amend'
gcmsg='git commit --message'
gca='git com
gd='git diff'
gf='git fetch'
gl='git pull'
gst='git status'
gstall='git stash --all'
gstaa='git stash apply'
gp='git push'
'gpf!'='git push --force-with-lease'
grb='git rebase'
grba='git rebase --abort'
grbc='git rebase --continue'
I also often use
ls='eza'
md='mkdir -p'
mcd() { mkdir -p "$1" && cd "$1" }
And finally some Nix things:
b='nix build'
bf='nix build -f'
bb=nix build -f .'
s='nix shell'
sf='nix shell -f'
snp='nix shell np#'
d='nix develop'
df='nix develop -f'
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.
While 3D geometry is more difficult for me than 2D, I could almost immediately tell that the answer is no, there are infinitely many points H that satisfy this. The reason it’s unintuitive is that our intuition about what “perpendicular” means comes from 2D and poorly translates to 3D.
The most intuitive explanation I can muster is this: imagine all possible planes that pass through both A and P. It should be obvious that there are infinitely many of them (I visualize it as a plane “rotating” around the AP axis). Each of these planes intersects the given plane since it passes through A. Think of the intersection line. It never passes through P (unless P is on the plane), so it is always possible to draw a perpendicular line from P to that intersection line. With one exception (when the perpendicular line falls on the A point), the point where the perpendicular falls satisfies the conditions for H. (I think all such points actually form a circle with AP’ as the diameter, where P’ is the parallel projection of P to the given plane, but I’m not 100% sure)
Ah yes, the year of the Linux desktop
(in all seriousness, this is looking really good, my main hope from all this is that hardware manufacturers step up their FOSS drivers game)