Looks like I could use https://github.com/PNDeb/pinenote-debian-image on my PineNote.
88 karma · joined January 2, 2025
For comparison, I've used PostmarketOS on Pinephone, and it required a lot of fiddly to get a poor experience.
But maybe the simpler usecase of "just reading" has good solutions?
I have this requirement too, since I like to use F-Droid.
My point isn't that there are no such users. My point is that product managers in banks don't care about F-Droid users, since there's so few of us that it's not worth them worrying about.
Many websites are giving up Firefox support, and Firefox adoption is much higher than F-Droid.
If a bank app happens to be okay with F-Droid, it's not because they look out for the needs of F-Droid, it's simply by happenstance.
But I'm not sure about his other stuff.
"Avoid features that add disproportionate cost"
I expect part of the problem here is that it's often not clear what the value of features until it's available to customers.
Even the costs of bloat are unclear. Take his bank website example. Do we really think many bank customers are choosing banks based on their website's latency? Banks compete on things users actually care about, like interest rates or fees.
Lots of software inevitably won't meet our ideal standards, because given the cost of developers it's not worth doing things The Right Way.
Window managers can plausibly already do a lot of what other software can do, yet in practice, popular workflows tend to assume very little from the window manager.
I try to avoid terminal multiplexers in favour of Sway/Emacs/dtach/SSH multiplexing, but I still often reach for tmux.
It's fine to choose your workflow by whatever criteria you decide, but on a post about workflows on a discussion forum, it's reasonable for mvdtnz to continue that discussion and not be laughed at for doing so.
It's nice to have to a set of programs I moderately care about, so when I'm learning another language I can port them to it.
They're unimportant enough that I can comfortably experiment, but important enough that I want to complete the rewrite.
My "blog engine" is a nushell script that uses pandoc and built-in XML support to convert markdown into a site+feed.
NixOS works well for x86-64 and aarch64, but not so much armv7l, as so many consumer routers are.
The PC Engines happens to be x86-64 with decent storage expansion, but for sure if you want to target armv7l, NixOS is not a good choice.
I see the fresh re-install suggestions probably work but that's tedious and risky.
> Nobody actually cares about security for packages that are not in the default install.
Probably an exaggeration, but it's clear there are some packages that are insecure out-the-box.
CoreRAD is about the same thing, but for NDP instead of DHCP.
I could have used systemd-networkd for serving DHCP and NDP, but prefer to use separate modular privilege-separated deamons, especially if I get memory safety too.
https://openwrt.org/toh/tp-link/eap615-wall is the device I use as an AP, which runs OpenWRT.
systemd-networkd + kea + corerad is the software I use.
That's EOL now, so nowadays I'd look to ARM e.g. https://radxa.com/products/network-computer/e52c
I used it for a while, but after I've had it for a few months, and want to improve/diagnose something, I can't easily tell which config I've changed from defaults, and so can't easily diagnose how I might have screwed it up, or predict how changes will impact the rest of the system.
I moved my router to NixOS, where I can now see the ~250 config that covers the custom setup needed for my ISP/LAN.
If asked, I'd still recommend OpenWRT for most techies, since it's easier to get started.
I know how it's taught. Internally it has aspects of long addition, and caching, but I don't do perform that algorithmically.
How then does that map to the physical structure of the brain? Do we know that?
+1, I fall into this category. It's tough.
But is it a problem for the gaming industry? How many sales can they expect from the time poor?
I manage to still play, by choosing conceptually simple games (puzzle, platformer, sports, GTA, some FPS), and playing on the Steam Deck. Portability + instant resume works well for this.
How much of this sort of effort results in that data being used? Are there success stories for these datasets being discoverable enough and useful to others?
> When it was finally my turn, I stammered.
> Watching it back, I cringe a bit. I was wordy, unclear, and unconvincing.
> You can watch my mumbling in the recording
I watched this, and the author was articulate and presented well. The author is too harsh!
Good job for trying to push the boundaries.
+1. From talking to people with those views, it's not that they can't see it, it's that they haven't looked and just figured Nix/Guix is different in the way that apt/rpm/APK are different from each other.
> I would love to see first-class support for BSDs
It's partially here: https://discourse.nixos.org/t/openbsd-nix-is-now-a-thing/255...
Bravo to the EU, NLNet and the NixOS contributors making this possible!
Guix has better ergonomics, but it's own set of downsides.
I expect the underlying idea of holistic declarative systems is sound, and we're awaiting a polished alternative. Maybe it'll reuse nixpkgs under the hood , but replace the name, the tooling, and the language exposed to the user.
Stable code by this definition experiences some stagnation. But the cost of stagnation is worth it for the stability. That's LTS.
Slowly, we'll build enough checks that we can achieve frequent change and still be stable. This is partially here, and "unevenly distributed".
> Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.
NixOS has system-wide tests that run on PRs, and go green if they pass. E.g. upgrade OpenSSH will trigger a suite of VMs to start, each running OpenSSH in different configurations, and checking they work as expected. These run automatically, are visible to contributors/reviewers, and take O(minutes) to complete. They run on automated backport PRs too.
> contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.
Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that meets theirs and and upstream's needs.
Our industry's story for system-level testing, for Linux distributions, is poor. NixOS tests are decent, but need more coverage, and something similar needs to be available to upstream so issues are caught during development.
Meanwhile, LTS releases have downsides:
* Alienating you from upstream: why contribute upstream if you'll only benefit from them in 2 years.
* Having to support stable versions makes refactoring harder. Developers don't want stable to be too different, lest backporting becomes too tricky.
* Maintenance costs is sunk, compared to if we can make rolling release reliable (see above re tests, and easy rollbacks).
https://abseil.io/about/philosophy#we-recommend-that-you-cho... is the same idea but from Google C++ team.
This post is fair.
Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path.
Going on a whim:
* Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable.
* Use flakes.
* Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback.
* On NixOS, don't use user profiles. They won't interop in the way OP hopes.
* Only use nixpkgs. If you absolutely must use another flake, only use popular ones from https://github.com/nix-community.
But until the community give opinionated suggestions, users will stray towards bad practices.
(Also, no need to mix pipewire and jack. Pipewire can emulate jack.)
But some of Shepherd's strengths are in other examples, and it makes sense to evaluate the whole.
A few examples:
* if we want multiple similar services, I'd prefer writing a Guile function than using systemd templates.
* the above Shepherd guile code lives lexically alongside your wider Guix guile code. AST-aware syntax highlighting and refactoring tools would treat them the same. That's pretty neat and beats having two different languages. Guix calls this g-expressions.
This "one language for all your system" is pretty compelling, but Guix's feature set is a bit too far behind NixOS at the moment for me.