Seconded. OP, if you can write Markdown, Hugo will turn it into a website.

I think Android updates intentionally made the Pixel C slower. It was a noticeable process, up to the point they stopped supporting it. I’d downgrade to an earlier version, but there’s such poor support in Lineage, I’m barely able to run the version that’s on there now.

Such a shame, because it’s still an amazingly beautiful device.

I’m 100% with you. I want a Light Phone with a changeable battery and the ability to run 4 non-standard phone apps that I need to have mobile: OSMAnd, Home Assistant, Gadget Bridge, and Jami. Assuming it has a phone, calculator, calendar, notes, and address book - the bare-bones phone functions - everything else I use on my phone is literally something I can do probably more easily on my laptop, and is nothing I need to be able to do while out and about. If it did that, I would probably never upgrade; my upgrade cycle is on the order of every 4 years or so as is, but if you took off all of the other crap, I’d use my phone less and upgrade less often.

The main issue with phones like the Light Phone is that there are those apps that need to be mobile, and they often aren’t available there.

ntfy is in the app store, so you don’t have you side load it. I don’t know how many iOS apps use ntfy, but many Android OSS apps will ask you over which notification system you want to work.

I was just clarifying that this isn’t one of the XKCD proliferation cases. Apple and Google’s push notifications are proprietary and give them full access to your notifications. Unified Push is the OSS alternative, and this KDE enhancement doesn’t createa another one: it uses the defacto standard OSS push notification specification.

The fact that ntfy is in the Apple app store makes me suspect there must be some number of iOS apps that can be configured to use Unified Push.

since all apps are designed to run well on budget phones from 5 years ago, there’s no reason to upgrade.

5 years, maybe, but any more is stretching it. And not getting system upgrades anymore is problematic. Unless you own a particular model of phone, de-Googled Android can be hard to come by.

For example, I have a 7-year old Pixel C. By the time Google stopped using system updates for it, I wasn’t wanting them as every release made the device slower and more unstable. After some effort, I was finally able to install a version of Lineage, which itself has problems including no updates in years. There’s a lot of software that is incompatible with my device, both from Aurora and FDroid.

Android isn’t Linux; Google doesn’t care about maintaining backward compatability on old devices, much less performance, and there’s no army of engineers making sure it is because there’s a served running in walled-up closet no one can find.

Google deprecates features and ABIs in Android, apps update and suddenly aren’t backwards compatible.

5 years, maybe. The entire industry is addicted to users upgrading their phones, and everyone gets a piece of that pie. There’s no actors, except perhaps app developers, who have any interest in keeping old phones running. Telecoms upgrade their wireless network - the internet connection in my 8 y/o car, and half its navigation features, died the day AT&T decided to stop supporting 3G; Phone makers make no money if you don’t buy new phones; and maintaining backwards compatibility costs Google money which they’d rather siphon off to shareholders.

I meant the server can deliver notifications via ntfy:

https://docs.ntfy.sh/examples/#home-assistant

Yeah, I don’t think the mobile app communicates with the server over anything but the web API.

It turns out, in this case it isn’t. This is about a KDE library (service?) that uses Unified Push, which is a standard implemented by servers like ntfy, Nextpush, and Gotify. If you use any f-droid apps, you’re probably already using Unified Push. Home Assistant uses it for mobile notifications, too.

It is, probably, the third biggest notification protocol after Google’s and Apple’s, only it doesn’t route through their servers or provide them with more of your data to harvest and sell.

Unified Push is a good thing. It looks like KDE just makes it accessible to KDE application developers through the KDE libraries.

Thanks for the input

You’re welcome!

I haven’t used assembly in a long while, so I know where to look to understand all the instructions, but I can’t tell right off the bat what a chunk of assembly code does.

Oh, me neither. And that’s not what I think is necessary; what’s important is that you can generally imagine the sorts of operations which are going on under the hood for any given line of code. That there’s no magic “generate a hash for a string” CPU operation, and that, ultimately, something is going to be iterating over a series of memory locations and performing several math operations on each to produce a numeric output. I think this awareness is enormously valuable in developers, and helps them think about the code they’re writing in a certain way, and usually in a way that improves their code.

Algorithms, I am terrible at these because I rarely use them.

You use them all the time! Anything longer than a single operation is an algorithm.

Nobody is going to ask you to write a search function; however, being aware of Big-O notation, and being able to reason about time and space complexity, is important. On the backbend, it’s critical. It’s important if you’re a front end developer - I blame the whole NodeJS library fiasco on not enough awareness of dependency complexity by a majority of JS developers.

I tend to work in finite state machine which is close to algorithms, but it’s not quite it.

I’d absolutely call FSM work “algorithms”, and it sounds as if the projects you’re working on is where these fundamentals are most important. Interfaces between hardware components? It’s the most fraught topic in CIS! So. Many. Pitfalls. Shit, you probably have to worry about clock speeds and communication sheer; there’s absolutely a huge corpus of material about algorithms for handling stuff you’re working with, like vector clocks. That’s a fabulous, interesting field. It’s also super tedious, and requires huge attention to detail which I lack, so in a way I envy you, but an also glad I’m not you.

College.

I’m one of those folks who believes not everyone needs a degree, and we need to do more to normalize and encourage people who have no interest in STEM fields to go to trade schools. However, I do firmly believe computer programming is a STEM field and is best served by getting a degree.

There are certainly computer programming savants, but most people are not, and the next best thing is a good, solid higher education.

Sure. I’m just saying, I think OP is looking for something that doesn’t require either buying the book again or pirating it.

And I think they want a solution that’ll index audio books, too. An LLM that’ll listen to, transcribed, and index audio books.

I should know more about what’s happening under the hood.

You’ve just identified the most important skill of any software developer, IMO.

The three most valuable topics I learned in college were OS design basics, assembly language, and algorithms. They’re universal, and once you have a grasp on those, a lot off programming language specifics become fairly transparent.

An area where those don’t help are paradigm specifics: there’s theory behind functional programming and OO programming which, if you don’t understand, won’t impeded you from writing in that language, but will almost certainly result in really bad code. And, depending on your focus, it can be necessary to have domain knowledge: financial, networking, graphics.

But for what you’re taking about, those three topics cover most of what you need to intuit how languages do what they do - and, especially C, because it’s only slightly higher level than assembly.

Assembly informs CPU architecture and operations. If you understand that, you mostly understand how CPUs work, as much as you need to to be a programmer.

OS design informs how various hardware components interact, again, enough to understand what higher level languages are doing.

Algorithms… well, you can derive algorithms from assembly, but a lot of smart people have already done a ton of work in the field, and it’s silly to try to redo that work. And, units you’re very special, you probably won’t do as good a job as they’ve done.

Once you have those, all languages are just syntactic sugar. Sure, the JVM has peculiarities in how its garbage collection works; you tend to learn that sort of stuff from experience. But a hash table is a hash table in any language, and they all have to deal with the same fundamental issues of hash tables: hashing, conflict resolution, and space allocation. There are no short cuts.

It’s listed as the “profile” in the screenshots you’re listing, but that’s the ruleset you’re altering.

I used nft or iptables, and my interaction with ufw has been sparse, and mostly through the UI, because the rulesets the GUI generates are incomprehensible. There should be a command in ufw to report which profile is active.

I’m going to guess this is a dead-end, since you’ve been using the CLI and I have to believe it uses the active profile by default, unless you tell it otherwise. However, in the GUI, if you edit rules in a profile it doesn’t automatically apply to your current ruleset. And if you alter your current ruleset, it doesn’t automatically persist it. So, even if you change a rule on the Home profile, and the Home profile is active, it doesn’t automatically get applied to the running ruleset; you have to take another action to apply it.

Mind you, that’s all through the UI; I’ve never used the ufw command line, so this is (again) probably a red herring. I find ufw to be obtuse at best, because of the Byzantine rulesets it generates.

Are you using the GUI?

Make sure you’re applying them to the active profile.

Huh. It’s a little off in some details, but does a pretty good neckbeard.

I’ve been using Arch for several years, including off-beat offshoots like Artix, and have never once compiled a kernel on it. The last time I compiled a kernel was a couple of decades ago when I was running Gentoo.

Arch is mainly a precomputed precompiled binary distribution; AUR is where you get the compile from source packages, and that’s the community repos.

Arch users may have a reputation for acting superior, and I’ll admit that they Arch wiki justifies a lot of “look it up yourself” mentality, must because it’s so comprehensively good. But I think GPT misses the mark on a couple of points, like extra fingers on a Stable Diffusion person.

I use it for everything, but then, I wrote it. All of the desktop secret service tools have desktop dependencies (Gnome’s uses Gnome libraries, KDE’s pulls some KDE libraries) and run through DBUS; since I don’t use a DE, it’s a fair bit of unnecessary bloat. And I don’t like GUI apps that just hang around in the background consuming resources. I open KeePassXC when I need to make changes to the DB, and then I shut it down. Otherwise, it hangs out in my task bar, distracting me.

Rook is for people who want to run on headless systems, or want to minimize resources usage, or don’t use a desktop environment (such as Gnome or KDE), or don’t run DBUS, or don’t run systemd. It’s for people who don’t want a bunch of applications running in the background in their task bar. KeePassXC providing a secret service is great, but it’s overkill if that’s most of what it’s providing for you, most of the time.

I don’t think took is for everyone, or even for most people. It’s for people who like to live mostly in the command line, or even in VTs.

KeePassXC can’t be run in headless mode, and the GUI is tightly coupled to the app. You have to have all of X installed, and have a display running, to run it.

Here’s the runtime dependencies of KeePassXC:

linux-vdso.so.1
libQt5Svg.so.5
libqrencode.so.4
libQt5Concurrent.so.5
libpcsclite.so.1
libargon2.so.1
libQt5Network.so.5
libQt5Widgets.so.5
libbotan-3.so.5
libz.so.1
libminizip.so.1
libQt5DBus.so.5
libusb-1.0.so.0
libQt5X11Extras.so.5
libQt5Gui.so.5
libQt5Core.so.5
libX11.so.6
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
/lib64/ld-linux-x86-64.so.2
libgssapi_krb5.so.2
libproxy.so.1
libssl.so.3
libcrypto.so.3
libbz2.so.1.0
liblzma.so.5
libsqlite3.so.0
libdbus-1.so.3
libudev.so.1
libGL.so.1
libpng16.so.16
libharfbuzz.so.0
libmd4c.so.0
libsystemd.so.0
libdouble-conversion.so.3
libicui18n.so.75
libicuuc.so.75
libpcre2-16.so.0
libzstd.so.1
libglib-2.0.so.0
libxcb.so.1
libkrb5.so.3
libk5crypto.so.3
libcom_err.so.2
libkrb5support.so.0
libkeyutils.so.1
libresolv.so.2
libpxbackend-1.0.so
libgobject-2.0.so.0
libcap.so.2
libGLdispatch.so.0
libGLX.so.0
libfreetype.so.6
libgraphite2.so.3
libicudata.so.75
libpcre2-8.so.0
libXau.so.6
libXdmcp.so.6
libcurl.so.4
libgio-2.0.so.0
libduktape.so.207
libffi.so.8
libbrotlidec.so.1
libnghttp3.so.9
libnghttp2.so.14
libidn2.so.0
libssh2.so.1
libpsl.so.5
libgmodule-2.0.so.0
libmount.so.1
libbrotlicommon.so.1
libunistring.so.5
libblkid.so.1

I don’t know why it links to a systemd library. Here are the runtime dependencies of rook:

linux-vdso.so.1
libresolv.so.2
libc.so.6
/lib64/ld-linux-x86-64.so.2

Don’t get me wrong: KeePassXC is one of my favorite programs. But don’t leave it running all the time, and it can’t be run on headless systems.

I may ping you on the zigbee stuff. I have the exact same set-up, except that I went with ZWave. I recent came in possession of a few ZigBee devices, and have been unable to get them to work.

I tried, half-heartedly, and gave up because it’s not that important, but I have a half dozen of these ZigBee widgets so I should probably figure it out.

This is what recommend as well. The various KeePasses all to pretty good jobs of merging databases, in case of sync conflicts, and you can utterly ignore whether you’re online or not. Plus, there’s a really fantastic tool, written by a veritable genius of a developer, that lets you use a KeePass DB as a secret service on your desktop.