Tweet
Originally posted by skeevy420
View Post
What shim or wrapper is necessary to use XFS and exFAT?
See, XFS didn't originate on Linux and was ported. Using that logic, does that make the Final Fantasy Tactics port on the Android Store a native PSX game and not a native Android game?
If someone just placed it into a wrapper that works like Wine, or that wraps OpenGL/Vulkan to whatever API is used in the PSX then it's not native.
Like console ports. It's called "port" as a derogatory term because someone took the binary, tossed it in some kind of external wrapper software like Wine and called it a day. This degrades performance as the application is adapted to do OS calls in an order or in a way that is good for the OS it was developed for, but will not be optimal for the OS it is now running in, even if the wrapper remaps them to appropriate OS calls.
Using the Linux userspace is a compat layer to the kernel defense -- then, technically speaking, they are since that isn't much different than getting a closed source program for Linux, like pSX, to work by using old libraries to make a legacy Linux compat layer.
That's not a defense I'd use because "compiled for another OS" is clearly where I draw my line in the sand, but the argument does work. Technically speaking, however, programs using FlatSnaps also fall under that category since they're essentially Linux compat layers on Linux for Linux programs.
That's not a defense I'd use because "compiled for another OS" is clearly where I draw my line in the sand, but the argument does work. Technically speaking, however, programs using FlatSnaps also fall under that category since they're essentially Linux compat layers on Linux for Linux programs.
Native applications make appropriate system calls for the OS they are used in. It does not matter that a Flatpak application is using its own "OS libraries" in its runtime instead of the stuff outside. It's still Linux OS calls to Linux OS libraries, regardless of how they are packaged.
"compiled for another OS" is exactly what needs a shim or a wrapper, as it is making calls that DO NOT exist in this OS and the developer is just redirecting them to the shim or wrapper instead of fixing the code to use the current OS API.
But, "compiled on my OS, by me, yet has a shim" is something I consider native.
What defines if an application is native or not is its system calls. If it's doing alien system calls it's "compiled for another OS" and it is not native, end of the story. The shim is a separate thing that remaps the system calls to those of your OS.
IMHO, it really doesn't get any more "native Linux" than "-march=native -mtune=native"
Those options are just compiling for your current CPU architecture, and that has nothing to do with what OS you are on. You can compile Windows applications too with that (if you use GCC of course).
On this page, the ZoL disclaimer page, it is only referred to as Native ZFS on Linux three times. I guess that makes them triple liars.
"Historical reasons" are worth mentioning
But retarded or not (at least I admit it), it does make some sense -- why would the Linux kernel big money backers actually want ZFS in the kernel? To show how they wasted money over a decade on file systems and volume managers and encryption layers that still aren't anywhere near the level of quality and integration that ZFS offers now?
That said, you want an answer? I have an answer. It makes sense too and does not even require being retarded.
Considering how basically none gave 2 shits about btrfs RAID5-6 (and higher, btrfs was supposed to let you choose your redundancy level and so on), and that even now it's not really ready for production regardless of what fanbois say, I can safely say that none of the ones paying big money gives 2 shits about most of ZFS features at all.
Really, even OpenSUSE and Ubuntu are mostly using btrfs/ZFS as single disk with no data redundancy, just for snapshots and CoW. OpenSUSE VERY recently (a few months ago) added support for multi-device btrfs in their Yast partitioner application.
But why that? Where have all gone those that want something like ZFS in the businness sector? Elsewhere of course. But where? Did they migrate en-masse to FreeBSD? Eh no probably not, as it seems most companies that use ZFS in their own product are migrating to Linux themselves.
ZFS was born in an age where single humongous servers were still a thing, and if you needed big storage you needed a big server.
Then SAN and distributed storage came, with the various Lustre, GFS2, MooseFS/LizardFS, and whatnot, there are many others.
Those filesystems allow infinite filesystem size (just add moar servers), completely ridiculous speed (as more servers participate in sending data for reads and caching data writes), and more, while also doing checksums and redundancy at the array level, you could lose entire physical servers and the SAN would just not care and rebuild.
All the big players have already moved on to them, so the main people still asking for RAID5-6 and data integrity are home users. And we all know none gives a fuck about those damn freeloaders, am I right? Screw the poor, praise the rich.
As for most other businness usage in small, single-server deployments, the client either does not understand or care about anything more than mdadm and LVM, and it's common to get hardware raid cards (real ones, with cache and battery) doing anything more than RAID 1.
Before you start complaining about this... can I ask you Britoid.. what kind of graphics cards do you have?
Comment