balsoft

The data seems to be weird/lacking so far, a lot of phones have "10" as "battery endurance in cycles", and some have the "Battery user-replaceable" even though it clearly isn't (e.g. glued on back glass)

PS: sorry I'm an idiot, I misunderstood what "battery endurance in cycles" meant (it seems to actually be "hundreds of cycles"). Also "battery user-replaceable" phones don't have a glued-on back indeed, I was looking at a wrong model.

This is sick! In 5-7 years when I'm looking for a new phone this will come in really handy :)

Hm, this is interesting - I am indeed "outdoorsy" and could only see "white and gold in shadow". I think this might also be because of the highlight on the right suggesting that it's daylight all around and the dress is in deep shadow, and the blue color is also highly reminiscent of "white cloth in deep shadow". This XKCD helped me clear up the confusion and now if I squint I can see both color schemes:

https://xkcd.com/1492/

Eh, this is sure to result in a lot of deaths and destruction, since subway trains don't have any way to strap you in, and are unlikely to handle the accelerations required to stay on rollercoaster tracks. Also remember that one of his first appearances is https://xkcd.com/72 which seems like child's play in comparison - he's sure grown over the years

Neat! Here's a way hackier thing that also works: https://github.com/serokell/nix-pandoc/blob/master/mkDoc.nix#L14

Yep, although I think StreetComplete does at least ask "how many levels in a building", which allows for pretty good approximations most of the time

Install StreetComplete, open it, boom, a lot of easy things to do that will help some people out (especially with regards to opening hours, accessibility, addresses and such).

Once you want to do more advanced edits, install Every Door. It's not as obvious what to do there, but it still highlights issues that need to be fixed and is relatively easy to operate; however, you will need to start looking at OpenStreetMap wiki to take full advantage of it.

Then you can move to more advanced editors, such as Vespucci on your phone (wouldn't recommend doing everything from there), ID editor in your browser or JOSM as a proper app on your computer.

Actually, recently I learned that setting the tree species (or at least genus) can be very useful to some people: https://lemmy.ml/post/31772921

True enlightenment is realizing that variables don't exist, it's all just a sequence of bits in RAM that we assign meaning to as desired.

Ascension is realizing that bits don't exist, it's all just trapped electrons in transistors which we imagine to be bits.

Transcendence is realizing that transistors or code doesn't exist, and it's just some quarks and electrons attracted and repulsed by weird forces, vibrating and convulsing in a soup with entropy constantly rising until the heat death of the universe, of which we make futile attempts to make sense or purpose.

There's no such thing as "fully mapped out". Just open StreetComplete. If there are no tasks left, go ahead and map all the individual trees, or benches, or yield/stop signs, or all the buildings so that they appear good-looking on a 3d render.

The "nix way" to handle this is actually to have all your dotfiles generated and "installed" by Nix as part of your NixOS config (via home-manager), and keep your NixOS config in a git repo that you then nixos-rebuild from (either with nixos-rebuild switch -I nixos-config=. or nixos-rebuild switch --flake ., depending on if you're using flakes or not).

So I’m kinda wary of doing it on an even more critical file

Actually, configuration.nix is not critical to the functioning of the system at all; it is only read at "evaluation time", i.e. when you are using nixos-rebuild. As long as it's under a VCS (i.e. you won't lose the contents by the time you want to nixos-rebuild again), you have nothing to worry about. You can ship a NixOS system without it (in fact that's kind of the default). (unrelated but fun fact: you can also ship a NixOS system without Nix, it's not actually needed for it to run!)

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.