https://man.archlinux.org/man/extra/xdotool/xdotool.1.en

https://man.archlinux.org/man/extra/wtype/wtype.1.en

Pipe your clipboard contents through either of those depending on your windowing system. I’d recommend putting that in a script and binding it to a keyboard shortcut.

Go ahead and add --now to that please

Heads up, you can also get postgress to use a socket and mount that through for another speedup if you haven’t already

I’ve been waiting for the “Avoid tolls” option to pop out of existence one day with no public explanation.

deleted by creator

Big if true, do you have a link to follow that development? I’ve been curious about some languages that compile to JS+WASM but I’ve been waiting for something like this to finally cut out the middle man and give me an excuse to learn WASM directly.

This is exactly the reason why I can’t believe that was ever a requirement. I would have crazy respect for webassembly if it could stand on it’s own as it would allow people to completely move away from JS, but if JS is still in the stack in any way it will introduce a (even if it is minimal) compatibility and maintenance cost in the long run.

Even webassembly needs a JS stub loader right now. I still can’t believe that’s a requirement.

Soon people will forget where the concept of a “radio button” came from and why

Been using this slick tool for a while now.

https://github.com/troglobit/inadyn

Easier to configure and better error codes than ddclient in my opinion.

I use it for Data-at-rest Encryption. Not much else though.

This may be a little bias but this is my understanding:

Flatpaks were the solution for reducing the duplication in Appimages and providing an automated way to do security updates. Flatpak got a chance to learn from Snap.

Snaps are basically a proprietary approach to creating and distributing Appimages that were created prior to the current Appimage tooling. They got to learn from the first generation of Appimages and decided to deviate from them early on.

Appimages were a stupid simple approach to a complex issue. Initial tooling was rough though and a lot of people, while they liked the idea, hated the requirements. Basically setting up an Ubuntu 18.04 environment for packaging was the only way to guarantee a truly portable image.

It left room for improvement and so decisions were made to try and fill that room. They were never bad, and devs weren’t really trying to do anything other than simplify the creation and distribution of existing Appimage functionality.

I still think flatpaks are the closest to the ideal solution but again, I’m biased.

deleted by creator

Lol, the nomenclature has always been a bit scuffed. Do you refer to desktop 64bit as x86_64 or amd64? (There’s history behind those…)

Eh, I welcome the iteration. It gives people a reason to practice and hey, who knows, maybe they’ll come up with something neat while rewriting curl or something

Last time I checked the HA app uses the system tool, which just uses Google Home behind the scenes. Apple Home is probably the only other implementation of the pairing tool.

Whoa, hold on now, this take could introduce a new wave of tech scammers that actually sound like they know what they are talking about…

/s

Matter makes sense on paper but it’s not really doing anything more than a standardized interface for MQTT traffic could do and damn Google has a way of fucking up simple stuff. Take a look at their repo for matter. Monolith of submodules and a goofy recursive project structure that requires multiple python virtual environments and external tools to build – to the point where they have another repo just to distribute binaries of the build tools last known to work.

It’s completely unnecessary and impossible to integrate cleanly into any existing system.

Well, technically nothing implements the pairing mechanism entirely right now so yeah, at least the pairing still phones home. I believe homeassistant requires you to use google home to pair the device to it (though that may change, the extension is still in beta)

Yeah, either DD or the dm-crypt trick for filling the drive with crypto-grade randomness https://wiki.archlinux.org/title/Dm-crypt/Drive_preparation