I actually prefer that visual metaphor more. The locked box makes me unsure about what unlocks it, just seeing the wrong tool leaves more options open.

Or “we poorly implemented security controls for a system, it must have been so smart to have data leakage”

There are cases of but also on going programs.

Their building a Prison System ™️ regardless, open source (e.g. Linux) just offers SOME protections.

We have to do more regardless, but it’s still all part of the good fight in my book

I wonder what entails “fully protected”. Encryption? What kind? Etc

Bad form. Breaks SLSA some. Breaks some CVE tracking tools too.

If the patch introduces a vulnerabilty or breaking issue how would it be tracked?

Cars are useful where rual living makes sense. The sense breaks down fast if you dont need to pass acres of fields.

Because IF it is superuseful tool and you are being paid to dev then you will have to explain why. Like if a framer showed up to a construction site and refused to use power tools

Honestly zfs, btrfs, and lvm really do this so well i forget that traditional partitions exists

Im.very into “AsCode” and pretty comfortable with vi bindings. So the two extremes where i document (random notes with no structure needed and formally verified documentation ) it works for me.

I can preview the markdown, use vale rules to enforce style and vocab, do mermaid.js diagrams, link my UML to stuff, etc.

Then check into git to do version control or just to save it off local.

The silence of two hours ago lol

Chill brother. Like i get it, and FOSS advocates should lead with meaningful alternitives first imho, but there definitly seems to be some https://joplinapp.org/

I personally prefer vscodium and nvim myself for notes but that isnt a one for one comparison to obsidian (in either direction) imho

https://joplinapp.org/

Seems interesting

Im a VSCodium kind of guy myself

Qubes is really cool but it uses VM instead of containers, and for its use case you basically have too. Containers isolation at almost no cost come from actually share the underlying kernel and hardware. That isnt isolated enough for data domain seperation thay qubes is built around.

That is one reason i have multiple clusters actually, and the confidential container effort is actually light weight VMs with tools to intergrate them with the network of the host correctly (and multikey memory encryption to fully enforce the boundary). I havent goten around to deploying an app like that yet myself though

Is the driver not coded up like an APU?

I run most of my software in containers. Firefox is in a flatpak. My terminal shells are all containers using distrobox. My homelab services are all containers. My few VMs (i run a few vituralized rke2 clusters, sometimes a test version of my baremetal harvester cluster, and test versions of my desktops)? Also running in containers. My desktop OSs are also containers (ublue, SteamOS, and SUSE Elemental).

The future is now old man! :p

But honestly linux namespaces and overlay filesystems are the bees knees. Create reusable layers of filesystems, use just the ones needed for a given app/service. Expose just what a service or app needs to for a given function. You end up with an extemly portable, and consistent system that has cleaner seperations of concerns. For basically free. From an app dev perspective you remove a whole matrix of supported configurations to worry about (distro/version/packages installed/etc).

How have tests gone so far?

also cool concept, you can actually get eBPF XDP to compile to FPGA on some smart NICs even further pushing it away from the core system if it works!

No problem!

That is a runtime that some flatpaks use as well.

Gnome and KDE as projects are a bunch of things, from login managers, to compositers, desktop UIs, and user application (like Gnome “System Monitor” or KDEs “Plasma System Monitor”).

You can actually mix and match some pieces and they just work, but especially the user apps because both teams put in work for interoperabilty or Freedesktop standarization.

So you can have an app that uses KDEs shared libs and an app that uses the Gnome projects libs on the same issue with rarely any issue. Even more so with flatpak since the all of the files those apps see are in what is called an overlay filesystem, so your kde apps get a layer of files jist for KDE apps to build off of and gnome apps get a layer of files just for them to use. In flatpak these are called runtimes. That is what is being updated here.

You cam write code that does almost anything, execution is a different thing.

I have my shared data on Longhorn, so for services that’s just longhorn as a PVC on rke2(k8s) and for clients I expose the NFS for mounts from a longhorn PVC to them to mount to.