If you check it with Tor Browser in a clean VM, you are not leaking much more than the plate number as such (which I wouldn’t say has the same sensitivity as a password) and the time of lookup. Obviously not safe to use this from your normal smartphone or home IP.
Don’t you have like half of those already…?
Separating the libadwaita toolkit from the Adwaita theme so I can use one without the other
Fully keyboard-navigable file picker dialog. Or make it more straightforward to plug in a new implementation without also having to tear out the drywall.
X11 support
Note the date. This blog post is a few months old. I was expecting new drama on the latest episode of Who Hosted Whom (and does that make them fascist (and does that matter)) until new events but i guess it’s just reruns this week.
deleted by creator
Since this is for remoting in to the Linux box, you might have better success with VNC. TigerVNC, NeatVNC, TinyVNC are all decent, I believe. RDP is a proprietary Microsoft-specific solution. There are VNC clients for Windows too.
There is also Xpra.
This could be a case of XY problem.
The built-in rollback functionality doesn’t hurt either.
More than that I think it’s a prerequisite for doing this.
You could self-host a shared “source of truth” git repo that you access over ssh or filesystem. That can be anything from a USB thumb drive, a small clean server or a container on your existing desktop with ssh access, to an entire Forgejo deployment. Then you only need the “secret zero” of an ssh key to get everything set up and syncable.
If fresh setup is more common, you probably have other parts like package installation and network configuration that you also want to automate. Enter configuration management like ansible or salt, image builders like packer or archiso, “immutable” solutions like Nix or rpm-ostree. Once you get there you typically manage that in git anyway and you could put your dotfiles repo as a submodule and copy them over as part of OS setup.
If it’s just for once in a blue moon, manual ad-hoc copying gets you pretty far.
No matter how you slice it I think you have to either frequently spend time syncing changes or just accept the drift and divergence between machines and the sources.
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.
It’s been continuously improving. There are devices that are a hassle but you’re a lot more likely to have things Just Working compared to a few years ago.
My understanding is that Ampere and others should run perfectly like any old x86 with a normal dist like vanilla Debian mostly due to a lot of hard work from individuals in the wider community.
Much of the time, dtb (device tree) and device drivers are what it comes down to.
For more estoric or finicky hardware, I think the dists with the best ARM support are Armbian, OpenWrt, and PostmarketOS.
Jeff Geerling has been reporting a lot about his experiments. https://www.jeffgeerling.com/
I wrote about getting Debian running on a device based on a popular Rockchip SoC last year. I assume the kernel situation has improved since trixie. https://blog.kumio.org/posts/2025/01/bananapim7-hvm.html
Try running it on something like an older Celeron, a RaspberryPi 3, a PinePhone, or a constrained VM. For me alt+tab can take seconds on GNOME but still be almost instant in Xfce on the same hardware.
I assume it’s from Wayland not performing as well on these platforms combined with fancy animated transitions being enabled by default on G.
It can be about not having to change hardware as much as about habits.
This community is funny.
From what I can tell this is is basically the spiritual evolution of Bazzite, by the same team and built with a similar approach. Yet look at how differently they are received.
Brand identity memes are truly impactful these days. Names and presentation seem to drive majority sentiment.
Remember Serverless? Servers all the way down.
INTERMEDIARY BUILD LAYERS WERE NOT SUPPOSED TO BE GIVEN NAMES
DAYS OF REBASING yet NO REAL WORLD USE FOUND for building on anything above fedora:atomic
Wanted to base your image on someone elses anyway to save some work? We had a tool for that, it was called “FORKING”
“Distroless is built on GNOME OS” “error: /Tree contains both /etc and /usr/etc” - Statements dreamed up by the utterly Deranged.
LOOK at what Devs have been demanding your Respect for all this time, with all the servers and window managers we built for them (These are REAL distros, done by REAL devs)
https://github.com/ublue-os/akmods/commit/70af39999c681566bd1c66f23834daa37b996aaa
https://github.com/ublue-os/main/pull/771
“Hello I would like 1.8 pixels please”
They have played us for absolute fools.
Some things that happen when I go to duckduckgo.com that also go against that:
It’s extremely nosy. They used to do canvas fingerprinting until browsers started prompting about it.
IDK about the claim of directly selling searches to IG and likely it’s a bit more convoluted than that (or OP has malware) but it’s a more believable idea than that of DDG actually being respectful of user privacy. There is absolutely no legitimate reason for DDG to gather this data for the purpose of providing their search service, yet they do.
Your initial instinct was right, you do want to auto-apply security fixes.
unattended-upgrades does allow you to configure this somewhat.
You could try this https://feddit.online/post/1359926#comment_6688858
Doesn’t sound like this is screen blanking as it happens during use but to rule it out you could temporarily disable that with xset -dpms and xset s off on X11. https://wiki.archlinux.org/title/Display_Power_Management_Signaling#Xorg
With your edit that yields a succinct proof that things are nuanced 😉
Right, there’s the immutable root aspect. Guessing the other answer you got fills in the missing piece there and that Silverblue perhaps mounts the system flatpaks on a different r/w filesystem than the read-only /. Check output of mount to see.
At the end of the day it’s up to you if you prefer to keep the system clean and run flatpak unprivileged, or centralize updates under root.
The one catch I can think of with flatpak --user is that it obviously won’t work if /home is mounted with noexec, which is otherwise a good security measure (and IMO not doing that defeats a lot of the security wins of immutable distros). Unless you apply the same mounting strategy to the flatpak xdg user dirs, which is certainly an option but not something everyone will bother with. But then again maybe that’s exactly what you want anyway to make your Flatpak installations smoothly portable across distros.
Without looking into it at all, there are plenty of possible valid reasons why someone would choose to pick a fresh pseudonym for a project like this. I think it’s important that we don’t lose that, socially.
Give it time and let them prove themselves if this is relevant to you.
I haven’t tried this with Cinnamon but with other Desktop Environments you can run your own Window Manager inside it, if that’s something you’d like. That way you can take benefit of background services and desktop integrations of the DE but use any WM you like.
i3 under Xfce or KDE is very common, for example.