I see what you mean now, but I must say that I really don't agree with these non-ECC horror stories. You have much bigger problems if you have memory corruption.
The point is that there are good file systems that can detect when the storage unit fails, give you an alert and allow you to restore the file from a good backup. Without this feature the corrupted file will just get backed up like any other file and eventually replace the good backup.
The problem with bit rot is that backups doesn't help. The corrupted file go into the backup and eventually replace the good copy depending on retention policy. You need a file system which uses checksums on all data block so that it can detect a corrupted block after reading it, flag the file as corrupted so that you can restore it from a good backup.
What do you mean by init? There's still a binary called init if that's what you want. And RHEL 6 used Upstart, but I don't know if that's more init than Systemd. So yes in theory you can since you have access to the source code and can modify it any way you want. This will be cumbersome in practice.
It is 3.10. But keep in mind that this is only where Red Hat essentially forked their version. Each minor release adds major changes to the kernel, including both hardware support and new features.
Because RHEL includes the source code, which can be kind of an important feature. But apart from that Solaris should be fine. They lost a lost of talent during the Oracle takeover, and I have a number of ZFS support incidents due to that; but to be honest things have been much better starting about a year ago.
The kernel package in particular is one of the things that Red Hat changes a lot, but usually only between minor releases. A small addition such as KVM was introduced in 5.2 for example.
Debian is not always that fast. Just take Gnome for example, sid is still on 3.8 which is getting kind of old by now. And not to mention that they are still in the process of switching to systemd. Debian is great, but the stable release is usually what you want and then you're back in RHEL territory.
I don't think that's going to be a problem. 99+ % of Mac users probably have no idea what a blue and white G3 is, and the rest knows enough to differentiate the two.
Slashdot Mirror
I see what you mean now, but I must say that I really don't agree with these non-ECC horror stories. You have much bigger problems if you have memory corruption.
The ones you mention are American companies and thus does not have to follow European law.
ZFS does not require ECC memory more than any other file system. I have no idea where you got that from.
So how is FreeBSD able to license ZFS by simply importing it into the source tree and Apple is not?
How could the RAM be responsible for damaging a file between the time it was written to disk and when it was read from disk?
The point is that there are good file systems that can detect when the storage unit fails, give you an alert and allow you to restore the file from a good backup. Without this feature the corrupted file will just get backed up like any other file and eventually replace the good backup.
At least you would know that the file was corrupted, so that you could restore it from a good backup.
The problem with bit rot is that backups doesn't help. The corrupted file go into the backup and eventually replace the good copy depending on retention policy. You need a file system which uses checksums on all data block so that it can detect a corrupted block after reading it, flag the file as corrupted so that you can restore it from a good backup.
I have this problem more frequently with desktops and servers during power outages.
What do you mean by init? There's still a binary called init if that's what you want. And RHEL 6 used Upstart, but I don't know if that's more init than Systemd. So yes in theory you can since you have access to the source code and can modify it any way you want. This will be cumbersome in practice.
That's true, although I would suggest that you also don't improperly shut down your laptop. :-)
I really don't like the fast release cycle of many Linux distros, so I used to stick with CentOS or RHEL on my desktops as well.
It's Gnome 3.8, which is a good desktop in my opinion. But you take some time should try it out yourself.
What about RHEL 7? By the way, what filesystem should be used on a laptop?
Any file system should be fine. Go with the default if you're not sure you want something else.
It is 3.10. But keep in mind that this is only where Red Hat essentially forked their version. Each minor release adds major changes to the kernel, including both hardware support and new features.
Because RHEL includes the source code, which can be kind of an important feature. But apart from that Solaris should be fine. They lost a lost of talent during the Oracle takeover, and I have a number of ZFS support incidents due to that; but to be honest things have been much better starting about a year ago.
The kernel package in particular is one of the things that Red Hat changes a lot, but usually only between minor releases. A small addition such as KVM was introduced in 5.2 for example.
It's much easier to handle large scale automation when you're using separate files.
Maybe I'm missing something but what good is the libvirt driver if you don't have anything to connect it to?
Yep, but the problem is that for the next ten years it will _still_ come with glibc 2.17. Some people actually new new apps too.
This is where containers is a good idea. Use RHEL as a stable base system and run something like Fedora in a container for the few apps that need it.
I was going to the FTP site to look at the sources, but apparently they have moved.
Current sources for Red Hat Enterprise Linux 7 have been moved to the following location:
https://git.centos.org/project...
That's a bit cool actually.
Debian is not always that fast. Just take Gnome for example, sid is still on 3.8 which is getting kind of old by now. And not to mention that they are still in the process of switching to systemd. Debian is great, but the stable release is usually what you want and then you're back in RHEL territory.
Absolutely.
Plus, binary blobs in a GPL kernel?
There's a lot of people that uses Linux that does not care about that, most of them using Android.
Wget can be built for either OpenSSL or GnuTLS.
Since I'm not using any of those to make calls to unknown servers, I'm not seeing a problem there.
It's not just that. How do you know you're not making a call to a compromosed server?
I don't think that's going to be a problem. 99+ % of Mac users probably have no idea what a blue and white G3 is, and the rest knows enough to differentiate the two.