Remind me again why we decided to do all this stuff client side?
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.
HN user
cf12d3982688a14f42fa6135aa132a19fa066681726ea941eee3fdba1da9bce6c20ffae74ef46c99f1793b5d24b3d128e98a504d5e3e17ef828f2a3b4e9da45b
Remind me again why we decided to do all this stuff client side?
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.
Microsoft can kick security vendors out the kernel, but they can't sell a product that uses APIs not accessible to other vendors.
ZFS isn't a real competitor given it's not in the kernel and has legal troubles.
Defaulting to degraded is a bad default. Mounting a btrfs device array degraded is extremely risky, and the device not booting means you'll actually notice and take action.
BTW: Even SLES SuseLinux Enterprise says use XFS for data btrfs just for the OS i wonder why
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.
The point of "standards" is that you don't need to target platforms.
Because someone actually did the work that provided what people wanted and needed.
which so far no one else has done
There are Linux distributions that have been certified UNIX, it really doesn't mean anything anymore.
poorly architected OS
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.
Yes, iOS still uses users in the technical "Unix" sense, they're just not mapped to actual physical users, but instead to various services.
Android is in a similar boat. They're still an important way to manage filesystem access of programs.
Eternal shame on Google for not insisting that Android would follow the "PC model" of the user being root on their own machine and DRM ..
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.
I don't see how this article does or even aims for anything but just more toxicity and division.
To members of the Hyprland community, I want each of you to personally step up to make the community better
Jesus complex?
Enable/disable disk encryption or reset a machine on Ubuntu via only the UI.
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
Depending on correct glibc, dependencies being installed with the right settings, environment variables,makefiles being compatible with what your system has,having the right kernel version, 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.
Isn't UDP over TCP a generally bad idea?
Ironically the Alternative Vote system would of likely prevented the Tory parties from having such a bad loss this election (and potentially a majority).
Keir Starmer is a human rights lawyer, would be a bit weird for him to suddenly have no regard for international law where many human rights (ECHR) come from and likely divide his party.
Not saying he's got a backbone, but he's just going for the easier option that keeps his party united.
As opposed to supporting a state that puts you at danger for even knowing crimes committed by the government is better?
Don't tell the Brexiteers
Microsoft loves pushing people to buy macOS devices it would seem.
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.
All it takes is for a driverless car speeding to hit a pedestrian for the industry to be dead in its tracks.
I'm sure emergency services would like that idea
Yeh all you need to really do is just alias sudo in the shell profile and you can steal the users password to elevate to root.
Flatpak/Containers can prevent it but permissions are up to the developer/packager.
in the case of Silverblue
- 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
Ventoy and flash tools should in theory support img files just fine, if anything for virtual machines img files should be easier to boot than ISOs (don't need to emulate a CD drive)
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).
Arguably the only window that needs to be in a hardware plane is the window currently in focus.
Battle between AI and Crypto, what will burn the planet first
Hardware planes will hopefully reduce the latency again as it will allow windows to skip the compositor and allow mapping parts of the framebuffer to a window buffer.
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.
Modern operating systems render to buffers on the GPU and then composite them, which I would guess adds some latency (although likely unnoticeable).
This one sentence just perfectly sums up everything that's broken in the embedded (i.e. everything non-x86) world. Everyone just forks random stuff at random points in the BSP's life time
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.