It’s not bad design, it’s definitely intentional, however I agree that it’s probably not for having backdoors, but for convenience. Average people forget their passwords all the time, and with encryption that level of carelessness is fatal to your data if they have not saved it somewhere, which they probably didn’t do.
Very few devices are rooted and usually you cannot get root without fully wiping your device in process.
I’m pretty sure the system is not flawless. Probably it’s harder to find an exploit in the OS than it was years ago, but I would be surprised if it would be really rare. Also, I think a considerable amount of people use the cheapest phones of no name brands (even if not in your country), or even just tablets that haven’t received updates for years and are slow but “good for use at home”. I have one at home that I rarely use. Bootloader cannot be unlocked, but there’s a couple of exploits available for one off commands and such.
I don’t think there’s a factual answer to this question.
My take on it though is why would they delete it? They can make use of it in various ways, and in new ways every once in a while, and it’s not like as if you could prove it in court or even just find out that they didn’t delete your data.
I agree that sqlite is slower through the network than a database server that was made with that in mind, but I think in your case the majority of it was something different.
I’ve recently read in the Jellyfin docs about problems with fs locks on an NFS share, and the point is that NFS does not enable locks by default or something like that, and you have to configure it yourself.
That depends. More of the popular ones don’t encrypt the secret keys, they can just be read out with root access or even with the use of ADB (the pull command), not even speaking about reading the memory contents while booted to a recovery.
Some even uploads the keys to a cloud service for convenience, and they consider it a feature.
are there applications where zfs/btrfs is more or less appropriate than ext4 or even FAT?
Neither of them likes to deal with very low amounts of free space, so don’t use it on places where that is often a scarcity. ZFS gets really slow when free space is almost none, and nowadays I don’t know about BTRFS but a few years ago filling the partition caused data corruption there.
In case of ZFS and bcachefs, you also have native encryption, making LUKS obsolete.
I don’t think that it makes LUKS obsolete. LUKS encrypts the entire partition, but ZFS (and BTRFS too as I know) only encrypt the data and some of the metadata, the rest is kept as it is.
Data that is not encrypted can be modified from the outside (the checksums have to be updated of course), which can mean from a virus on a dual booted OS to an intruder/thief/whatever.
If you have read recently about the logofail attack, the same could happen with modifying the technical data of a filesystem, but it may be bad enough if they just swap the names of 2 of your snapshots if they just want to cause trouble.
ext4 certainly has its place, it’s a fine default file system, there’s really no problems with it.
But others, like ZFS and BTRFS, have features that you may want to use, but ext4 doesn’t do: fs snapshots, data compression, built in encryption (to a degree, usually only happening for data and some of the metadata, so LUKS is often better IMHO), checking for bitrot and restoring it when possible (whether it is depends on your config), quotas per user group or project, spanning multiple disks like with RAID but safer (to a degree), and others.
It’s not about someone, it’s about something. A lot of us aren’t (only) using Linux as a server OS, but for desktop too, and desktop usage involves running much more different kinds of software that you simply just can’t afford to audit, and at times there are programs that you can’t choose to not use, because it’s not on you but on someone on whom you depend.
Then it’s not even only that. It’s not only random shit or a game you got that can edit your bashrc and such, but if let’s say there’s a critical vulnerability in a complex software you use, like a web browser, an attacker could make use of that to take over your account with the use of a bashrc alias.
Where did they say that they were comfortable doing that? I don’t see a word or an acronym of it.
Sometimes you must do things that you are not comfortable doing, but you just can’t avoid it. Doing that for the ISP (who need to set up the cable into your home and the gateway) is not the same as doing that for e.g. netflix or facebook.
I would be interested in a proper solution, but recently I have found a way to make custom icons for specific Konsole instances. Maybe you could use a similar approach.
I have made a copy of the program’s desktop file and placed it in /usr/local/share/applications/ with a slightly different name, and given it a new icon. Then I have made a new window rule, that sets this desktop file for windows that start with a title having a specific pattern, and made Konsole to start with that title using an undocumented command argument I have found on their bug tracker.
This is very hacky and I don’t like it, can’t wait until it breaks, but it’s all I have found.
An alternative way may be to make a symlink to Konsole and start it through this symlink, and somehow identify the window by the executable path… but window rules don’t support that. Maybe through some other way? KWin has a scripting API… hmmm…
But a problem you’ll probably have to deal with when setting the title is that the program can set it’s title any time, and at least some of them (including Konsole) routinely do that, in that case based on the selected tab’s title. There’s a setting to turn that off… but as I have experienced, it doesn’t do what I expect, if anything. Maybe by listening to title changes you can force your will, if that is possible.
Yes, it is not as decentralised as you have thought. I thought this is a fairly known fact. If you need something truly decentralized, I2P is probably the way.