It’s really easy for a law firm in Germany to find out who the IP belonged to, if they have proof that the IP infringed on their copyrighted media.
The law firm looks at torrents and downloads a bit. With the IP, time and media name they can send a cease and desist letter with a fine of hundreds to thousands of euro. Ignoring the letters is not possible.
This is possible because the law firm has contracts with many big copyright holders (Disney, …).
But most of the time the fine is too high, so it’s possible to pay half by getting a lawyer. Basically the copyright holder overestimate how much damages they can get for the distribution of copyrighted material. If I understand it correctly. IANAL.
It’s simple to avoid by binding the torrent client to the network interface of a VPN, but not everyone knows that.
This doesn’t work well in practice when switching between Gnome and KDE. Both change configuration in /home, which might break theming and results in strange behavior.
Logging in with a different user for each desktop environment does prevent such issues. Or alternatively deleting the right folders in ~/.config should fix it too.
Btrfs doesn’t do encryption, so luks is still necessary. LVM isn’t needed since btrfs subvolumes achieve the same in a more flexible way (no fixed size, snapshots).
I’d also like to see an open platform for their source code, but Github is undeniably the preferred platform for most developers, so I understand Mozilla’s decision.
So long as only the source code is hosted on Github I don’t think it limits people to contribute. Bugs and features are still tracked with the existing tools.
This screenshot is the only metric where btrfs is incredibly slow.
Bcachefs random and sequential writes and reads are much slower than other filesystems in this benchmark.
I have no idea how the actual real world performance will be. Bcachefs still misses a lot of features so I’ll continue to follow the development, hopefully including performance improvements.
Bcachefs sequential write performance in this out-of-the-box comparison was coming in at around half the speed of Btrfs while XFS, F2FS, and EXT4 were the fastest.
Filesystems aren’t so simple. Modern advanced filesystems like btrfs, zfs and bcachefs are more than just filesystems.
E.g. they include features like volume management, compression and sometimes encryption. Most features can also be achieved with for example ext4 + lvm + luks, but it’s nice to have all in one system with unified configuration.
tl;dr
Btrfs does more than ext4, which can have a negative performance impact, depending on the use case/metric. Usually the features gained by btrfs outweigh the small difference in performance imo.
I really like Gnome but requiring extensions to work properly is bad design imo.
For example my moms laptop runs Gnome and she doesn’t need much except 3 basic features: a dock, desktop & tray icons. Tray icons are necessary because Nextcloud relies on them to show the sync status, desktop icons are great to have temporary files easily accessible for a presentation.
In my opinion the most frustrating decision of Gnime is to not allow making the “dash” permanently visible, in other words, a dock. I’d argue it’s even an accessibility option because it’s easier to click on something visible than having to open the overview.
It’s frustrating since Gnome is an almost perfect desktop for anyone who wants a simple, working desktop.
Even then I wouldn’t do it. Installing games takes a while too, so it’s not much of a time-saver compared to automatically organizing movies/shows.
And the risk of getting a misleadingly named game with malware is too high. Remembering to sandbox isn’t easy either, after possessing them for a while. Untrusted files should never be on a computer, imo. But I don’t pirate games, so take my advice for what it is.
[…] aren’t there some folks who want flatpak/snap/appimage to basically replace traditional package managers?
There might be people who think that, but that isn’t realistic. Flatpak is a package manager for user facing apps, mostly gui apps.
The core system apps will still be installed by a system package manager. I.e rpm-ostree on immutable Fedora or transactional-update/zypper on OpenSUSE MicroOS.
Snap can do system apps and user facing apps and fully snap-based Ubuntu might come in the future.
But this won’t force people to use them. Traditional package managers will keep existing for system apps and maintainers will proabably keep their gui packages in the repos.