You can't believe that "*nix are using the aging ext file system", because they're using much more advanced file systems such as BTRFS ad ZFS, which are not present on Windows, and won't be there soon.
Even your own example is flawed: "symbolic links" aren't a 90s feature, they were in UNIX in 1978, and were added to Windows only in 2009 (and most Windows userspace software still doesn't support them properly). Talk about file system innovation.
The post I was responding to was falsely assuming that the file system support of Linux was antiquated because it didn't support a Windows feature, when in reality that feature is supported, even the native Windows file system is supported including that feature, and a lot of nice features of Linux's file systems aren't available on Windows.
I don't think Debian follows the FHS on x86_64 because it puts 64-bit libraries in/lib and not/lib64. Which is a good thing, the FHS was broken in that respect IMHO.
/bin is for important system files that can be useful to mount the rest of the file system. Only a well-specified set of files goes there, your distribution knows what they are, and you shouldn't ever put anything in there, nor delete anything found there. See them as the equivalent of the hidden files in C:\ on Windows.
/usr/bin contains all the executables that are part of your system. Except those few, fixed ones that went in/bin.
/usr/local/bin potentially contains all the executables that you as a user might want to add to your system, for example stuff that you compiled.
/opt/package name/bin contains the executables found in a specific package, usually a large package with many files which aren't of interest to the rest of the system, and that you downloaded from a third party instead of having it installed as a part of your system's distribution.
Repeat the same reasoning replacing "bin" with "lib" for libraries.
"which" will tell you where any executable in your path resides. 99% of the times, it will be/usr/bin. If it's a third party package, it might be in/opt/product name/bin.
In comparison, Windows scatters executables all over the disk so I'm not sure how Linux is worse exactly.
There is nothing exoteric or baffling with the filesytem of Linux.
It is well-specified. There's a folder for executables, a folder for binaries, a folder for configuration data, a folder for temporary stuff. And its layout hasn't changed for 20 years.
Compare it to Windows, where the file system layout changes from one Windows version to the other, there are no documents specifying most of its organization, and it doesn't matter anyway, because since Windows NT the file system is meant to be only managed by automated installation tools, and even an expert user can not hope to fix it when things go wrong.
What's wrong with/bin and/lib ? They serve a specific purpose, and the files they contain shouldn't be directly handled by a user who gets confused because of the presence of more than a single directory in his $PATH, so who will gain from their "semplification"? Don't tell me the real reason is that Fedora's next-generation self-aware omniscient init system has grown so complex that they're no longer able to support a split/usr installation because of its dependency hell.
Please do not turn Linux into an unmanageable mess as the one Windows has become.
End of rant
Seriously, Windows has had this for over a decade.
You mean, since the last time Microsoft updated Windows' file system? I can't believe they're still using the aging NTFS when other operating systems have advanced file systems such as ZFS and BTRFS.
There's a few experiemental filesystems that can compress the whole partition, but still not individual files.
Correction: there's a next-generation, not experimental file system, BTRFS, that does that and also sports features that Windows 8 is missing. You can compress individual files or folders using the "btrfs filesystem defragment -c" command.
On top of that, if you want, you can use NTFS-3G which will allow you to use the legacy file system of Windows, NTFS, with all of its '90s features *including transparent compression of individual folders*.
I think this guy is right. Software patents aren't much more broken than "hardware" ones, it's only that the unjustness of the patent system is more evident when applied to immaterial things.
Personally I put patents in the category of "reverse socialism", that is all those cases in which the free market approach, which is blindly applied when it means firing workers, lowering wages, relocating production to foreign sweatshops, gets suspended when it's time to protect some elite which supposedly can't afford to sustain competition.
I don't think modern Windows versions have a VESA driver.
That said, the i810 support is being dropped from Mesa, not from the Xorg driver. You still can use the card with new X servers, but you won't get accelerated OpenGL (which was broken anyway, which is why it's being dropped).
It isn't happening, but even if X dropped support for the i810 completely, and you didn't want to use the VESA driver, you could still use an old X server, which is the Linux equivalent of Windows 7 using an XP driver.
It's probable, but I can't find official documents confirming that. Motorola's manuals mark the processor as 16-bit because it has a 16-bit data bus. Similarly, Intel sold the 8088 as an "8 bit hmos microprocessor" for having a 8-bit data bus even though it probably shared its 16-bit internals with the 8086.
A lot of old hardware isn't supported anymore by modern drivers in new linux kernels.
What are you talking about? Linux 3.1 still supports MCA buses and ESDI drives. I don't recall any drivers being dropped without a valid reason.
X.org is dropping support (in userspace) for 3D acceleration on old video cards which never had really working 3D drivers anyway, and those cards will continue to work without acceleration without much performance penalty.
PDFs are hypertexts, so they fit perfectly in the "browser" model. For example, it's nice to have a single browser history spanning across both PDF and HTML pages. And PDFs are everywere, you often stumble upon them while navigating in technical or legal contexts.
While a PDF reader undeniably widens the attack surface for exploits, I don't think this is going to be much more a security hazard than supporting some new extra features of HTML5.
And adding it to Firefox might induce Google to open source Chrome's PDF engine (assuming they haven't licensed it from a third party).
And will all of Windows 8's features be enabled when it's not booted through the secure mechanism? Have we got an official Microsoft statement about this?
People will still be able to install malware by clicking "yes" at the UAC prompts. Exactly as they do today. In fact, they might not even need that, because the users' most precious information is found in the "Documents" folder and not in C:\WINDOWS\System32.
I've never seen a boot virus since BloodyWarrior in 1994. Most viruses today come either through browser plugins or are installed by the user themselves in good faith.
Suppose you're the vendor of a non-Microsoft operating system. You can't assure your customers that they'll be able to install your OS, because Microsoft doesn't give this warranty. Even if your customer is lucky and has an "open" PC, you can't explain to him how to install your own keys, because this procedure is not standardised and Microsoft doesn't specify anything about it (apart from mandating it to be as hard as possible). Therefore, you have (I'm using an euphemism here) a severe competitive disadvantage against Microsoft. I don't know in the USA, but in the EU this probably won't be tolerated.
You can give the user the ability to turn this feature off and install non-Windows OSs if you want, but we don't really care.
They do require the OEMs not to support the easier way of disabling secure boot after the first failure, that is present in the UEFI specification. So they do care, somehow, about making the deactivation of this "feature" as hard as possible. For some reason.
In large part this is driven by people's desire to HAVE locked down hardware where it is perceived as a safer alternative than the crapware infested desktop PC.
The average buyer doesn't even know what crapware is, let alone desire to buy a locked down hardware that is perceived as a safer alternative.
The above average buyer knows that locked down hardware doesn't prevent malware, as spyware applications sold on app stores clearly demonstrate.
- Fundamental motivation is evolution into 64-bit
- - Ability to access a large virtual address space
- - Foresee a future need in ARM’s traditional markets
- - Enables expansion of ARM market presence
- Developing ecosystem takes time
- - Development started ahead of strong demand
- - ARM now seeing strong partner interest in 64-bit
- - -Though still some years from “must have” status
Alas, UEFI and ACPI are being ported to Arm. Most probably to let unmodified Windows 8 binaries run on different Arm boards (and to make Linux run awfully on them ).
It will make writing software for them much easier when their amount of RAM + video RAM will approach the 4 GB limit. Which is probably going to happen soon.
Slashdot Mirror
Even your own example is flawed: "symbolic links" aren't a 90s feature, they were in UNIX in 1978, and were added to Windows only in 2009 (and most Windows userspace software still doesn't support them properly). Talk about file system innovation.
The post I was responding to was falsely assuming that the file system support of Linux was antiquated because it didn't support a Windows feature, when in reality that feature is supported, even the native Windows file system is supported including that feature, and a lot of nice features of Linux's file systems aren't available on Windows.
I don't think Debian follows the FHS on x86_64 because it puts 64-bit libraries in /lib and not /lib64. Which is a good thing, the FHS was broken in that respect IMHO.
Repeat the same reasoning replacing "bin" with "lib" for libraries.
In comparison, Windows scatters executables all over the disk so I'm not sure how Linux is worse exactly.
It is well-specified. There's a folder for executables, a folder for binaries, a folder for configuration data, a folder for temporary stuff. And its layout hasn't changed for 20 years.
Compare it to Windows, where the file system layout changes from one Windows version to the other, there are no documents specifying most of its organization, and it doesn't matter anyway, because since Windows NT the file system is meant to be only managed by automated installation tools, and even an expert user can not hope to fix it when things go wrong.
What's wrong with /bin and /lib ? They serve a specific purpose, and the files they contain shouldn't be directly handled by a user who gets confused because of the presence of more than a single directory in his $PATH, so who will gain from their "semplification"? Don't tell me the real reason is that Fedora's next-generation self-aware omniscient init system has grown so complex that they're no longer able to support a split /usr installation because of its dependency hell.
Please do not turn Linux into an unmanageable mess as the one Windows has become.
End of rant
Seriously, Windows has had this for over a decade.
You mean, since the last time Microsoft updated Windows' file system? I can't believe they're still using the aging NTFS when other operating systems have advanced file systems such as ZFS and BTRFS.
There's a few experiemental filesystems that can compress the whole partition, but still not individual files.
Correction: there's a next-generation, not experimental file system, BTRFS, that does that and also sports features that Windows 8 is missing. You can compress individual files or folders using the "btrfs filesystem defragment -c" command.
On top of that, if you want, you can use NTFS-3G which will allow you to use the legacy file system of Windows, NTFS, with all of its '90s features *including transparent compression of individual folders*.
Personally I put patents in the category of "reverse socialism", that is all those cases in which the free market approach, which is blindly applied when it means firing workers, lowering wages, relocating production to foreign sweatshops, gets suspended when it's time to protect some elite which supposedly can't afford to sustain competition.
That said, the i810 support is being dropped from Mesa, not from the Xorg driver. You still can use the card with new X servers, but you won't get accelerated OpenGL (which was broken anyway, which is why it's being dropped).
It isn't happening, but even if X dropped support for the i810 completely, and you didn't want to use the VESA driver, you could still use an old X server, which is the Linux equivalent of Windows 7 using an XP driver.
It's probable, but I can't find official documents confirming that. Motorola's manuals mark the processor as 16-bit because it has a 16-bit data bus. Similarly, Intel sold the 8088 as an "8 bit hmos microprocessor" for having a 8-bit data bus even though it probably shared its 16-bit internals with the 8086.
On Linux, you can use the VESA driver for the i810.
What are you talking about? Linux 3.1 still supports MCA buses and ESDI drives. I don't recall any drivers being dropped without a valid reason. X.org is dropping support (in userspace) for 3D acceleration on old video cards which never had really working 3D drivers anyway, and those cards will continue to work without acceleration without much performance penalty.
In some countries, unjustly accusing people of having committed a crime is itself a crime.
The 68000 had 32-bit registers, but was universally recognised as a 16-bit CPU at the time.
While a PDF reader undeniably widens the attack surface for exploits, I don't think this is going to be much more a security hazard than supporting some new extra features of HTML5.
And adding it to Firefox might induce Google to open source Chrome's PDF engine (assuming they haven't licensed it from a third party).
And will all of Windows 8's features be enabled when it's not booted through the secure mechanism? Have we got an official Microsoft statement about this?
I've never seen a boot virus since BloodyWarrior in 1994. Most viruses today come either through browser plugins or are installed by the user themselves in good faith.
Suppose you're the vendor of a non-Microsoft operating system. You can't assure your customers that they'll be able to install your OS, because Microsoft doesn't give this warranty. Even if your customer is lucky and has an "open" PC, you can't explain to him how to install your own keys, because this procedure is not standardised and Microsoft doesn't specify anything about it (apart from mandating it to be as hard as possible). Therefore, you have (I'm using an euphemism here) a severe competitive disadvantage against Microsoft. I don't know in the USA, but in the EU this probably won't be tolerated.
Apple allow you to boot other OSes. They do the opposite of what Microsoft are attempting to do here.
They do require the OEMs not to support the easier way of disabling secure boot after the first failure, that is present in the UEFI specification. So they do care, somehow, about making the deactivation of this "feature" as hard as possible. For some reason.
The average buyer doesn't even know what crapware is, let alone desire to buy a locked down hardware that is perceived as a safer alternative.
The above average buyer knows that locked down hardware doesn't prevent malware, as spyware applications sold on app stores clearly demonstrate.
You can read more in the slide 4 from ARM's presentation at http://www.arm.com/files/downloads/ARMv8_Architecture.pdf:
- Fundamental motivation is evolution into 64-bit
- - Ability to access a large virtual address space
- - Foresee a future need in ARM’s traditional markets
- - Enables expansion of ARM market presence
- Developing ecosystem takes time
- - Development started ahead of strong demand
- - ARM now seeing strong partner interest in 64-bit
- - -Though still some years from “must have” status
Anyway, ARMv8 has 64-bit registers, a 64-bit logical address space, a 48-bit physical address space, and 32-bit wide instructions.
Alas, UEFI and ACPI are being ported to Arm. Most probably to let unmodified Windows 8 binaries run on different Arm boards (and to make Linux run awfully on them ).
It will make writing software for them much easier when their amount of RAM + video RAM will approach the 4 GB limit. Which is probably going to happen soon.
Still, lossless codecs are useful for transcoding.
What's "flamebait" in this post? Modded -1 for lesa maestatis Applae ?