Actually it is the same story with TLS 1.3 and TLS 1.2. A bunch of sites still doesn’t support TLS 1.3 (e. g. arstechnica.com, startpage.com) and some of them only support TLS 1.2 with RSA (e. g. startpage.com).
You can try this yourself in Firefox by disabling ciphers (search for security.ssl3 in about:config) or by setting the minimum TLS version to 1.3 (security.tls.version.min = 4 in about:config).
My whole infrastructure is designed so that my homeserver is expendable.
Therefore my most important tool is Syncthing. It is decentral, which is awesome for uptime and reducing dependance on a single point of failure. My server is configured as the “introducer” node for convenience.
I try to find file-based applications, such as KeePassXC or Obsidian, whenever I can so that I can sync as much as possible with Syncthing.
Therefore there is (luckily) not much left to host and all of it is less critical:
So the worst thing that can happen when my server fails is: I need to import my OPML to a cloud provider and I loose syncing for some less important stuff and my homepage is not accessible.
Since I just rebuilt my server, I can confirm that I managed a whole week without it just fine. Thank you very much, Syncthing!
Linux Mint nowadays supports release upgrades, but you have to follow their blog to know when a new major Mint release is out and you have to manually install mintupgrade and do the upgrade.
So it is definitely not caused by technical constraints, as Mint has implemented the difficult part (providing and testing an upgrade path) already. Notifying the user about a new release upgrade shouldn’t be too difficult? E. g. in the most simple form you could probably preinstall a package that does nothing at first, but receives an update once the next Mint release is out to send a notification to the user to inform about a new Mint release.
When it comes to elementary OS, I think they could support in-place upgrades, as they properly use metapackages (unlike Mint, which marks most packages as manually installed and doesn’t really utilise automatically installed packages and metapackages in a way that you would expect on a Ubuntu-based distro), but they probably don’t want to allocate / don’t have the resources to test an official upgrade path.
But again, I don’t understand why it is so difficult for elementary OS to at least provide a simple notification to the user that a new version is out. Even if the users have to reinstall, it is critical to inform them that their OS is about to become end of life. You know, people do things like online banking on their computers …
It’s the first thing I check with every distribution and if it doesn’t have an EOL / upgrade notification, it is immediately out.
It misses one important choice: “I want to get notified of new releases of the operating system and want to have a graphical upgrade path.”
Otherwise people just run their no longer supported OS until something stops working (I’ve seen this countless times …), as very few people follow blog posts or social media feeds of their operating system.
This rules out lots of supposedly “beginner friendly” distributions, such as elementary OS or Linux Mint, as they don’t notify users about the availability of a new distribution release. Elementary OS doesn’t even offer in-place upgrades and requires a reinstallation.
I was in a similar situation not too long ago.
My criteria for another scripting language included that it should be preinstalled on all target systems (i. e. Debian and Fedora), it should be an interpreted language and it needs to have type safety.
Afterall I settled with Python due to its popularity, its syntax and features (type safety since v3.6, etc.) and the fact that it is preinstalled on many Linux distributions. System components often use Python as well, which means that libraries to interact with the system tend to be included by default.
deleted by creator
For servers there’s Docker/Kubernetes/Podman, which is well-established and serves a similar purpose as Flatpak on the desktop. Servers were actually first with the increase in popularity of containers.
90 % or more of my desktop (Fedora Kinoite and Silverblue) apps are Flatpaks already. I only have four rpm-ostree overlays (native packages) left: android-tools, brasero/k3b, syncthing (I could switch to SyncThingy for a Flatpak) and virt-manager/virtualbox
With Flatpak there is “flatpak override” which gives you the ability to grant additional permissions or restrict them even further. E. g. I use it to connect KeePassXC with Firefox or to disallow access to the X server to force almost all apps to use Wayland instead of X. It also allows me to prevent apps from creating and writing into arbitrary directories in my home.
Once I reinstall my home server, all its server software will be containerised as well (five years ago I didn’t see the necessity yet). I am tired of having to manage dependencies with every (Nextcloud) upgrade. I want something that can auto update itself completely with minimal or no breakage, just like my desktops.
Any source for that claim?
At least the Fairphone 3 and 4 use public test keys in production:
Seems like at least the Fairphone 5 finally uses production keys: https://forum.fairphone.com/t/avb-keys-used-in-roms-for-fairphone-5/100314
(Hopefully) obviously /s
Thanks for fixing this issue! I didn’t even know until today that it affected non-Linux systems as well.
Oh no, I thought that was a feature. I came to rely on it to transcribe long tab titles into my text editor. Is there any way to restore the old behaviour in Firefox? Otherwise I’ll have to stick with Firefox 118 or switch web browsers, since Firefox 119 seems to break my longstanding workflow. :(
Any ideas?
They would also need to take responsibility for any security issues related to the chipset. It is also not possible to upgrade proprietary firmware (e. g. for the modem) at all without support from the chipset manufacturer.
Fairphone doesn’t seem to care much about security (they use public keys for signing their OS afterall!), so they may be fine with those compromises.
Qualcomm is interested in selling new SoCs, so even if they actually offer support extensions, their fees are most likely very high to make it unprofitable for manufacturers to go this route.
They won’t do that, because older Pixel phones used Qualcomm SoCs and Qualcomm didn’t support these SoCs for more than three Android versions.
They might technically be able to extend support for the Pixel 6 and up (Tensor SoC), depending on the contract and who, Google or Samsung, is responsible for providing the chipset drivers. But even if it is technically possible to extend support, it is probably also unlikely to happen due to the additional expenses it requires.
Overall it’ll be interesting to see how many phones actually live long enough to see their final update after seven years. Considering I already had to replace the battery on my three year old Pixel 5 once (which initially came with Android 10 and got updated to Android 14). USB connectors and broken screens are also common failure points for aging phones.
deleted by creator
As far as I know, companies don’t have to comply yet with the Digital Markets Act. That’s most likely the reason why the WebKit restriction is still in place.
You can select a local folder in Obsidian for Android and sync the folder with Syncthing. You can even revoke network permissions for Obsidian and it all works completely offline (Flatpak override: --unshare=network / GrapheneOS: don’t allow the network permission).
This is my current setup, even though Obsidian is not FOSS. I like that it stores standard Markdown files in a traditional filesystem hierarchy, instead of what Joplin does with using Markdown files as a database. This means that with Obsidian I can use any text editor or any other Markdown app to access and edit my notes, whereas with Joplin I would have to export them first to standard Markdown and then potentially rename and reorganise all the files and their attachments.
Personally I am excited for immutable distributions, so my suggestion would be Fedora Silverblue or Kinoite. It may be a spin of Fedora, but it works completely differently than regular Fedora. I am using it as my daily driver for over a year already and I am quite happy with it (apart from reoccurring breakages caused by kernel updates, e. g. my AMD desktop currently does not work with kernel 6.4 or newer, but this doesn’t have anything to do with Silverblue).
There are other immutable distributions out there, e. g. Vanilla OS or openSUSE microOS, so if you really want to avoid Fedora, you could also choose trying out one of these. In the case of Vanilla OS I would wait until version 2 is out, because version 2 will be radically different from the first release.
deleted by creator