choobacker

Looks like I could use https://github.com/PNDeb/pinenote-debian-image on my PineNote.

This looks great. Is there by out-of-the-box usable e-reader that supports SSH? Air still has some manual steps/maintenance.

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 will not bank with HSBC because their app will not work if you install things from outside the Google App store

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.

I agree with his issues with dependencies.

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.

+1. I think that about summarises it.

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.

Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.

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.

+1.

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.

Size is a limiting factor for so.e hardware and architecture too.

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 had a look more into this. https://www.reddit.com/r/openwrt/comments/114kv0y/weeding_ou... has some people with the problem that I'm trying to avoid.

I see the fresh re-install suggestions probably work but that's tedious and risky.

Good job on raising that issue. TIL SSTP.

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.

systemd-networkd sets up a LAN interface, which Kea then serves DHCP for.

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.

For wireless I started with the PC Engines miniPCI cards, but moved to a seperate AP for wifi6, and because hostapd was not fun.

https://openwrt.org/toh/tp-link/eap615-wall is the device I use as an AP, which runs OpenWRT.

Tracking config via VCS is great, but the automatic changes is what then makes it tricky to understand what you've actually configured.

There's hardware that has the form factor of a router, but is powerful enough to run an ordinary Linux machine. PC Engines, various ARM64 SBCs.

Me too. My TP Link EAP605 is an AP running OpenWRT. Works well.

Not that I'm aware of.

systemd-networkd + kea + corerad is the software I use.

I use a https://www.pcengines.ch/apu2.htm with a separate wifi access point.

That's EOL now, so nowadays I'd look to ARM e.g. https://radxa.com/products/network-computer/e52c

OpenWRT is pretty great at offering features and security for consumer devices. Glad to see a release!

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.

Do we know how the human brain performs addition?

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?

as a working parent I might only have 30 minutes here or there where I’m able to play. When I get back to a game after a couple of weeks off, I can’t remember what I was doing, or what the controls are. It’s just not fun.

+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.

It's impressive that volunteers are stepping up to archive this. I understand the desire to keep this open data available.

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?

Nice write up!

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.

Some people can't seem to see why Nix and Guix are in an entirely different class from traditional package managers

+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...

It's good to see EU funding for open source, and for getting software easy to build, as Nix does.

Bravo to the EU, NLNet and the NixOS contributors making this possible!

Those Debian tests are great. Good coverage, run on PRs. A little obtuse in parts, but still great.

Yes, the ergonomics are poor. I endure them for the results, but the ergonomics should be better.

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.

If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.

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.

To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system.

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.

I'm a NixOS user and contributor.

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.)

I agree systemd's is easier to understand, and I'm a happy systemd user.

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.