Cool! Keeping up with platform changes is a challenge for projects like this. I think to be successful beyond initial popularity you need an active community that can do this together. It's draining for just one person - especially once you get big enough that they might actively break things just to mess with your integration. Following maintenance of alternative YouTube clients as well as searx-ng is illustrative.

Not to discourage but be prepared. Best of luck!

https://cadence.moe/blog/2022-09-01-discontinuing-bibliogram

I guess they now have large enough number of users that it would be wise to shift some focus to supply-chain security from growth-hacking.

This is growing pains.

Wishful thinking and stretching the definition beyond meaningfulness with regards to your conclusion. Lies, damned lies, and statistics. Don't delude each other.

Still, I've believed for a long time that the tipping point with an increasing trajectory is around 5% so pretty optimistic about recent trends.

Tricking users into using Snap without realizing it, making them unknowingly vulnerable to exploits like this, would be really really bad and unethical on Canonical’s part.

That is not what is happening at all.

Just so nobody is confused or gets afraid of their install: Getting the Firefox snap installed via Ubuntus apt package does not make users vulnerable to what is talked about here and is just as safe as the apt package version. For Firefox snaps might even be safer since you will probably get security patches earlier than with apt upgrades and get some sandboxing. In both cases you are pulling signed binaries from Canonical servers.

The post is about third-party fake snaps. If you run a snap install command from a random web site or LLM wkthout checking it, or making a typo, then you are at risk. If Ubuntu didnt have snaps, this would be malicious flatpaks. If Ubuntu didnt have flatpaks, it would be malicious PPAs. And so on. Whatever hosted resource gets widely popular and allows users to blindly run and install software from third-parties will be abused for malware, phishing, typosquatting and so on. This is not the fault of the host. You can have access to all the apps out there you may ever want or you can safely install all your apps from one trusted source. But it's an illusion that you can never have both.

People have opinions about if snaps are a good idea or not and thats fine but there shouldnt be FUD. If you are using Canonicals official snaps and are happy with them you dont have to switch.

Yes, Home Assistant has this.

https://rhasspy.readthedocs.io/en/latest/

Works great. My biggest challenge was finding a decent microphone setup and ended up like many do with old Playstation 3 webcams. That was a while back and I would guess it's easier to find something more appropriate today.

Everything in there is relevant and applies to flatpaks too. Being aware of the risks is important when using alternative distribution methods. With power, responsibility.

Terrible headline. Should have just been "Rockchip has...".

Am I showing my age if I say that Tomshardware used to be decent?

Discord </3

Unless you took a backup I guess it's not relevant anymore but if it happens again you can narrow down files last changed around some timestamp like so: find /var -mmin +4 -mmin -5

It's more like busking on the street and then feeling offended about not getting any money despite people liking your music. Maybe you're even inadvertently part of some commercial ad shoot profiting of the city vibes. Or offering free trials of a service and then being upset when nobody converts.

I don't think things you do become "charity" just because others benefit from it and you don't get compensated. The bar is higher than that.

No reason to expect that everyone will be in a position to do that indefinitely, especially when it comes to massive projects that turn into full time jobs.

For sure. No strings attached goes both ways.

The concept is attractive.

Since back before "atomic" and "immutable" were fashionable buzzwords, I've had a few Alpine installations running something like this. Their installer supports it. https://wiki.alpinelinux.org/wiki/Immutable_root_with_atomic_upgrades

I guess I'm also not alone in having been running OpenWrt with atomic upgrades for many years.

Since then been running a ublue fork (Aurora) for a while now. Forking it and running the builds on my own infra instead of relying on their GitHub works after hacking up the workflow files but it's quite redudandant and inefficient with IMO one too many intermediate layers (kinoite -> akmods -> main -> aurora/silverblue/bazzite -> iso) downloading the same things multiple times repeatedly despite spending considerable overhead on caching. It's clear that building outside of their GitHub org is not really actively supported.

Also tried openSUSE microOS (Aeon) a year or two back for a while. I want to like it but find zypper and transactional-update pretty uncomfortable and TBH sometimes still confusing to work with. Installing it on encrypted RAID was daunting IIRC. Rough edges. Enough out-of-date docs on the official site to make Debian wiki look like ArchWiki in comparison.

KDE Linux looks promising but it was still in a very early and undocumented stage last I looked. Great to see the progress.

More recently been looking more at Arkane Linux and been using it for some months now. It's an immutable with Arch base. Much easier to customize and maintain than the ublue options and a lot less time spent triggering and waiting for builds - while having less stuff pulled from third-party servers in the process and an easy way to fork packages by cloning and submoduling an AUR repo. Lot more straightforward to make work without relying on GitHub. If you're looking at rolling your own builds and are comfortable with Arch, I highly recommend checking it out. My fav so far.

https://arkanelinux.org/

https://codeberg.org/arkanelinux/arkdep

Given the self-contained nature of Debian - cloning the Debian sources is enough to do a complete offline build of everything - I think it'd be the most interesting base for a sustainable immutable distro unless you go to the opposite end with "distroless" (no comment). Looking forward to one.

Separate your personal and work computer

nods enthusiastically
Important for security of both the employee and the company. Don't mix business and pleasure. It's the only thing that makes sense!

Put Windows and all work related software on a separate work laptop and use remote desktop from your Linux PC to do your job.

What? No! Keep them separate! This is how people get pwned. Don't backdoor your employers machine from your personal PC or vice versa!

The advantage to using something like terraform is repeatability, reliability across environments and roll-backs.

Very valuable things for a stress-free life, especially if this is for more than just entertainment and gimmicks.

I'd rather stare at the terminal screen for many hours of my choosing than suddenly having to do it at a bad time for one.. 2... 3... (oh god damn the networking was relying on having changed that weird undocumented parameter i forgot about years ago wasnt it) hours. Oh, and a 0-day just dropped for that service you're running running on the net. That you built from source (or worse, got from an upstream that is now mia). Better upgrade fast and reboot for that new kern.. She won't boot again. The bootdrive really had to crap out right now didn't it? Do we install everything from scratch, start Frankensteining or just bring out the scotch at this point?

Also been at this for a while. I never regretted putting anything as infra-as-code or config management. Plenty of times I wish I had. But yeah, complexity can be insiduous. Going for High Availability and container cluster service mesh across the board was probably a mistake on the other hand...

It's not as black and white as they say. Flatpak is not a bad choice per se but not without tradeoffs and they can come with catches like this because of the security model. There is no one-size-fits-everyone here. If you want all your apps to have access to everything your user does and value convenience over the sandboxing, flatpaks might not be the best choice for your situation. Also like for any repo with external third-party uploads, quality varies a lot between apps and maintainers on flathub. Some are excellent and some are in a sorry state. Before installing from fllathub its a good idea to some basic due diligence on the package and maintainer before jumping in.

I agree with the IanTwenty that the UX has room for improvement in making it more obvious what's going on and making it easier to manage customizations and overrides. For the time being, getting comfortable with Flatseal and learning more about Flatpaks seems like the best way for a user to make it work for them if defaults don't work out.

Flatpak has tradeoffs and whatever is on flathub is not guaranteed to always be your best pick. That doesn't make it Bad. Going as far as calling them harmful in general is hyperbole. It can still be a great option for many users.

Is the Flatpak version running inside it’s own “box” and it isn’t getting SU permissions across my whole system?

Indeed it is running sandboxed!

Same principle as running uid 0 inside a rootless container.

You can poke around a shell inside the sandboxed environment with flatpak run --command=bash org.freecad.FreeCAD and tweak access with FlatSeal.

mTLS (mutual TLS) is actually quite common out there. And SSH certificates moreso than public keys.

So clients get issued certificates that they can authenticate with. TLS for HTTPS but both ways. It sounds like this is what you're asking about?

If this is inside the threat model, you put a passphrase on that key and load it in an external process like ssh-agent or gpg-agent. Maybe even move it to a separate physical device like HSMs or crypto hardware wallets (many of which can be used for this purpose btw).

This is also neat: https://doc.qubes-os.org/en/latest/user/security-in-qubes/split-gpg-2.html#notes-about-split-gpg-2

How about using sieve rules? A nice plus is that if you ever move to self-hosted in the future, you can bring it with you.

I know at least Fastmail supports user-configured sieve. I don't have experience with Fastmail myself but in general mostly heard good things.

https://www.cstrahan.com/blog/taming-email-with-fastmail-rules/

http://sieve.info/tutorials

Things I've run into:

1. Out of the box, the lock screen comes on after screen unblanking - late enough that when things aren't snappy you can briefly catch the desktop without reauthing.

2. Sometimes randomly after wake, keyboard input is not recognized in the password field at all. Except for Esc, which in this state appears to crash-restart it and makes it work again

3. With a multi-monitor setup, I have still not been able to properly force the primary monitor. Is an issue because things like notifications and the login input will only show up on a usually turned off projector. This one might be PEBCAK.

I have issues 1 and 3 with XFCE on lightdm, too, though.

Possibly oversimplifying and didn't have a proper read yet: If you trust the hardware and supply-chain security of Intel but not the operational security of Cloudflare or AWS, this would allow you to exchange messages with the LLM without TLS-encryption-stripping infrastructure operators being able to read the messages in cleartext.

This is a form of Confidential Computing based on Trusted Execution Environments. IMO the real compelling use of TEEs is Verifiable Computing. If you have three servers all with chips and TEEs from different vendors, you can run the same execution on all of them and compare results, which should always agree. You will be safe from the compromise of any single one of them. For Confidential Computing, any single one being compromised means the communication is compromised. The random nature of LLM applications makes Verifiable Computing non-trivial and I'm not sure what the state-of-art is there.

And yes it does look like it has overhead.

This seems impossible from a scalability perspective, as even small LLMs require huge quantities of RAM and compute. Did I miss something fundamental here?

Well isn't it the other way around? If the per-user resources are high, the additional sublinear overhead of isolating gets relatively smaller. It costs more to run 1000 VMs with 32MB RAM each vs 2 VMs with 16GB RAM each.

However I guess this might get in the way of batching and sharing resources between users? Is this mentioned?