I would guess easier reactivity and state management on the client. You don't have to do things the jQuery way in manually having to sync your DOM to your data on changes/api data.
1,619 karma · joined January 1, 2018
I would guess easier reactivity and state management on the client. You don't have to do things the jQuery way in manually having to sync your DOM to your data on changes/api data.
Because XFS is far quicker for server-related software such as databases and virtual machines, which are weak points on btrfs due to its COW model.
which so far no one else has done
worth noting Microsoft had a solution a few years ago that would of prevented this issue from happening, Windows 10X, due to atomic updates.
> In Linux, software doesn't even get that option. Nothing ever gets kernel access except the kernel itself. Root is not kernel access.
root has kernel access, even if the kernel restricted it, it can write to the disk and change the boot process.
also worth nothing that a popular form of software distribution on Linux is curl http://randomscript.sh | sudo sh which is arguably worse than anything on Windows.
Android is in a similar boat. They're still an important way to manage filesystem access of programs.
To be fair to Google, banks don't usually allow you to download and generate EMV tokens to perform card transactions on your PC, which places a different set of security requirements (legal requirements too) on Android phones for things like Google Pay to exist.
> To members of the Hyprland community, I want each of you to personally step up to make the community better
Jesus complex?
You've been able to do both on Windows and macOS for other a decade now without touching a terminal.
or repair a broken install etc
Apart from having a bingo at what dependencies you bundle, AppImage makes no effort to actually solve this, where as Flatpak and Snap do. The reason glibc, environmental variables, dependencies is important is because the Linux desktop is not a single distribution etc, nor is there one arbiter keeping ABI stability.
You venture out onto a distribution that is not what the AppImage was built on and you see what a wild ride it is of if things are working or not. Incompatible curl versions, glibc, mesa, etc.
AppImage pretends to work like .exe on Windows, or .app on macOS, but it doesn't share anything similar with them at all. Both Windows and macOS have stable userspaces where things don't change, Linux on the other hand...
For refence, Flatpak solves this via freedesktop runtimes and Snap solves this by installing Ubuntu containers.
Not saying he's got a backbone, but he's just going for the easier option that keeps his party united.
Windows really does have the potential to be ideal for professionals, the things macOS does that make it better are all small but Microsoft just seems to paramount on sabotaging their operating system.
I really feel sorry for OEMs that really don't have a choice but to ship Windows and have to stomach this shit being associated with their products.
Flatpak/Containers can prevent it but permissions are up to the developer/packager.
- Pushes the use of containers for apps, /usr is read-only (mostly). in most cases Flatpak and Podman/Docker/Distrobox/Toolbox
- Makes reproducible builds, your /usr is the base fedora image + whatever you have explicitly configured to add, the latter part makes it very easy to customise the base OS and undo changes (which are tracked), or share changes with others.
- Updates are atomic, you pull the power cord during an update? no bueno will just boot the old deployment. Additionally, because the system is always in a known and immutable state, updates should always work without any kind of dependency/package issue, your swapping one /usr for another.
- Makes malware harder as /usr is read only and you can use composefs to make sure content isn't changed, not really that secure though given any malware can just infect the initramfs
Modern Linux ISOs are a sort of hacked hybrid ISO/IMG, where keeping support for burning to CDs (the ISO part) has some trade offs (such as workarounds needed for persistence storage, multiple partitions).
I believe there's some work on Linux already for them, but I'm not so sure on Windows. I would be surprised if macOS doesn't already use them in some capacity given Apple's obsession with delegating everything to firmware on a co-processor.
A few years ago I did some work that involved building a custom Android image for a SoC manufacturer that's common in TVs.
The BSPs were provided over FTP as split up archive files, held together by bash scripts and had 100s of .patch files scattered all over the place. I am not sure if still the case, but there was also GPL-affected code (kernel patches/modules) that the were certainly not being open sourced at the time.
For each Android point update there was a new set of archives and painful rebasing of the changes we had made on top.
I know there have been changes since, with GSIs etc, but these to me just seem like band aids on the problem.