What the fuck? Lossy compression has nothing to do with the quality of data retrieval on a hard disk. If you've got data corruption, it'll affect any sort of file (and `flac -t` will tell you when a file is corrupted). a 320kbps MP3 stored with no intermitent data corruption from 2001 will have exactly the same bits and quality that it did in 2001. (Encoders have gotten better. A 320kbps MP3 from 2001 might sound worse than the song from the same source being encoded as 320kbps MP3 *today*, but that hs nothing to do with magical degradation.)
The new file system is just a bag of bytes for names. You can store ë just fine, any way you want it (though UTF-8 and composed are probably the best options).
Maybe more accurately, the Windows ABI being the universal one thanks to Wine. DirectX can be hit-or-miss, especially if you don't have gallium drivers on your system.
Carmack always used OpenGL for his game engines too, a tradition maintained in Doom 2016 as well, despite being developed and released after his departure. The Vulkan version even runs well in Wine.
It comes at a severe price, if that's what you're expecting. The WRT54G is obsolete enough that most aftermarket firmware have not supported it in years.
Random reads and writes work fine, assuming it's sanely implemented. ZFS only compresses per-block (normally up to 128KiB). Reading and writing those blocks doesn't depends on other blocks in the same file. It's not even difficult to have a file on ZFS whose blocks have different types of compression applied to it. Works fine.
2.6.39 was actually the one that directly preceded 3.0;)
Nothing particularly special about 2.6.32 compared to the others, but it just happened to be one release in which all the major enterprise distributions landed on for one release cycle (Debian 6, RHEL 6, SLES 11,...). That fact alone just kind of drove to keeping it maintained officially, and everyone on those distributions could stay happy with new upstream kernels of that series without breaking any sort of compatibility on their systems (eg, any kernel modules installed).
2.6.32.70 should. 80386 support was dropped in 3.5.y and further.
Please note that no mainstream distro has supported the 386 in the past couple decades. You'll have to be building all your own stuff to get it working.
CentOS tracks RHEL completely. For as long as Red Hat supports RHEL6, CentOS 6 will be updated. (New Red Hat-maintained versions of 2.6.18 still show up in CentOS 5 updates, even.)
GRUB doesn't do stages anymore. That would be a "rescue>" prompt. It's a little better, and can usually help to save from minor configuration mishaps, though not useful for more major oopses (maybe you changed file systems and forgot to update GRUB, now the boot.img doesn't understand how to read the file system...). It also gives a lot of pause to the thought of "Oh crap, what are GRUB's commands?"
Entirely this. In my opinion grub 2 is where they really went off the rails. When you have a set of configuration files that configure the set of scripts that generate the _actual_ configuration, something has gone horribly, horribly wrong.
Those scripts and configuration files sprang into existence well before GRUB 0.97 even. In GRUB 2, they're still not required and the configuration file is not hard to hand-write if you don't want the auto-OS detection and config generation said scripts provide:P
I'd add the ability to run Windows binaries in emulators, but they can't access other programs than themselves. If that was a problem, add a phantom disk image so it could see other files that you place in the phantom disk image. Imagine each Windows emulated program saw their own personal c:/ , and it and you can populate it with files.
So... Wine with a new WINEPREFIX for each program?
I figure if the software you download can't get out of the Windows emulator or its own personal filesystem, it can't mess with your OS or the rest of your filesystem. If it can't record your keystrokes unless you have the window actively open, a keylogger can't get you either. The problem is that we probably don't have perfect Windows emulation. Another problem is you have to be able to trust your drivers or that is a possible vector to an attack.
Run Wine in a Docker image? That's pretty well-sandboxed. and easy to set up.
Wine is a compatibility layer for Windows applications. It must emulate all of Windows' bugs and undefined behavior to the best possible extent, even containing a whole bunch of case statements to change its behavior when different versions of Windows are set via winecfg (not unlike Windows' own compatibility mode, which tends to just have every version of every DLL ever in WinSxS to solve the problem...).
To Wine, Windows bugs are features, and applications depend on them. Maybe it will never be perfect, but Wine's philosophy is basically "If it works in Windows, it should work in Wine" -- even if that comes down to an application running in Windows 95 but not later versions, Wine will try its best to keep that Windows 95 app running, even if you have to set the Windows version to 95 via winecfg. If the app doesn't run, it is a Wine bug.
It still does, so long as you're selective of the software you run on it. You could run a totally modern kernel and X.org (or Wayland) on an original Pentium with 32MB of RAM, but in no way should you expect to run GNOME or LibreOffice or Chrome or Firefox on it, at least not without glacial loading times.
But more frequently, PCs from 10-15 years ago still in service just aren't that starved on resources anymore. They'll chug along slowly, but they can still get the job done, and nobody is really surprised when they're capable of it. Hell, if you have half a gig of RAM, you can probably still run full GNOME and LibreOffice and all without major issues.
Slashdot Mirror
What the fuck? Lossy compression has nothing to do with the quality of data retrieval on a hard disk. If you've got data corruption, it'll affect any sort of file (and `flac -t` will tell you when a file is corrupted). a 320kbps MP3 stored with no intermitent data corruption from 2001 will have exactly the same bits and quality that it did in 2001. (Encoders have gotten better. A 320kbps MP3 from 2001 might sound worse than the song from the same source being encoded as 320kbps MP3 *today*, but that hs nothing to do with magical degradation.)
Of course it's still Ubuntu. It's just not Linux. It's GNU/kWindows.
The new file system is just a bag of bytes for names. You can store ë just fine, any way you want it (though UTF-8 and composed are probably the best options).
Yes, 2.0 supports Windows 8 and 10 compatibility, both 32- and 64-bit. Actually, Wine 1.8 was the first to include Windows 10 compatibility ;)
Maybe more accurately, the Windows ABI being the universal one thanks to Wine. DirectX can be hit-or-miss, especially if you don't have gallium drivers on your system.
Carmack always used OpenGL for his game engines too, a tradition maintained in Doom 2016 as well, despite being developed and released after his departure. The Vulkan version even runs well in Wine.
Apple had it first as well.
It comes at a severe price, if that's what you're expecting. The WRT54G is obsolete enough that most aftermarket firmware have not supported it in years.
Random reads and writes work fine, assuming it's sanely implemented. ZFS only compresses per-block (normally up to 128KiB). Reading and writing those blocks doesn't depends on other blocks in the same file. It's not even difficult to have a file on ZFS whose blocks have different types of compression applied to it. Works fine.
2.6.39 was actually the one that directly preceded 3.0 ;)
Nothing particularly special about 2.6.32 compared to the others, but it just happened to be one release in which all the major enterprise distributions landed on for one release cycle (Debian 6, RHEL 6, SLES 11, ...). That fact alone just kind of drove to keeping it maintained officially, and everyone on those distributions could stay happy with new upstream kernels of that series without breaking any sort of compatibility on their systems (eg, any kernel modules installed).
2.6.32.70 should. 80386 support was dropped in 3.5.y and further.
Please note that no mainstream distro has supported the 386 in the past couple decades. You'll have to be building all your own stuff to get it working.
CentOS tracks RHEL completely. For as long as Red Hat supports RHEL6, CentOS 6 will be updated. (New Red Hat-maintained versions of 2.6.18 still show up in CentOS 5 updates, even.)
What happened to PHP 6.0? Are they skipping a version just to one-up Perl?
GRUB doesn't do stages anymore. That would be a "rescue>" prompt. It's a little better, and can usually help to save from minor configuration mishaps, though not useful for more major oopses (maybe you changed file systems and forgot to update GRUB, now the boot.img doesn't understand how to read the file system...). It also gives a lot of pause to the thought of "Oh crap, what are GRUB's commands?"
Entirely this. In my opinion grub 2 is where they really went off the rails. When you have a set of configuration files that configure the set of scripts that generate the _actual_ configuration, something has gone horribly, horribly wrong.
Those scripts and configuration files sprang into existence well before GRUB 0.97 even. In GRUB 2, they're still not required and the configuration file is not hard to hand-write if you don't want the auto-OS detection and config generation said scripts provide :P
I'd add the ability to run Windows binaries in emulators, but they can't access other programs than themselves. If that was a problem, add a phantom disk image so it could see other files that you place in the phantom disk image. Imagine each Windows emulated program saw their own personal c:/ , and it and you can populate it with files.
So... Wine with a new WINEPREFIX for each program?
I figure if the software you download can't get out of the Windows emulator or its own personal filesystem, it can't mess with your OS or the rest of your filesystem. If it can't record your keystrokes unless you have the window actively open, a keylogger can't get you either. The problem is that we probably don't have perfect Windows emulation. Another problem is you have to be able to trust your drivers or that is a possible vector to an attack.
Run Wine in a Docker image? That's pretty well-sandboxed. and easy to set up.
:)
(I'm serious, they have no way to delete an account)
There are technical reasons for it, but if you really want to clear your history of editing you can always do this: https://en.wikipedia.org/wiki/...
It is not a sign of a cult.
Wouldn't that break every time a Windows Update comes through?
I haven't heard of this behavior before. That would prove problematic I'd think :P
Wine is a compatibility layer for Windows applications. It must emulate all of Windows' bugs and undefined behavior to the best possible extent, even containing a whole bunch of case statements to change its behavior when different versions of Windows are set via winecfg (not unlike Windows' own compatibility mode, which tends to just have every version of every DLL ever in WinSxS to solve the problem...).
To Wine, Windows bugs are features, and applications depend on them. Maybe it will never be perfect, but Wine's philosophy is basically "If it works in Windows, it should work in Wine" -- even if that comes down to an application running in Windows 95 but not later versions, Wine will try its best to keep that Windows 95 app running, even if you have to set the Windows version to 95 via winecfg. If the app doesn't run, it is a Wine bug.
And how do you talk SQL over some form of socket? You need a driver.
It still does, so long as you're selective of the software you run on it. You could run a totally modern kernel and X.org (or Wayland) on an original Pentium with 32MB of RAM, but in no way should you expect to run GNOME or LibreOffice or Chrome or Firefox on it, at least not without glacial loading times.
But more frequently, PCs from 10-15 years ago still in service just aren't that starved on resources anymore. They'll chug along slowly, but they can still get the job done, and nobody is really surprised when they're capable of it. Hell, if you have half a gig of RAM, you can probably still run full GNOME and LibreOffice and all without major issues.
He has the freedom to throw a tantrum. You, and everyone else, also have the freedom to distribute a version of Emacs with LLVM support.
It cannot possibly be abandoned in any sense of the word if it is still actively supported and sold.
Quite a lot of databases don't allow to specify a field as an unsigned integer. YouTube probably runs on one of them.
Can the requirement be worked around by advertising the aspect as 6:6? (What does "at least" mean for aspect?)