Since pretty much the beginning, the Linux developers approved, condoned, and encouraged binary, non-GPL modules.
Being a lawyer doesn't make you out of touch. "Linux developers" have never approved of or encouraged binary, non-GPL modules, quite the contrary. Tolerated, or looked the other way is the most you could say. Linus has at times expressed a permissive attitude, but he has also said this. What you need to remember is that it's not Linus's kernel, it's only partly his. Anyone who holds copyright in it (thousands) is entitled to make an issue of illegal distribution if they wish.
Just prepare a detailed description of how to write the fix(es) and post it where some interested party can find it. See, the copyright applies to the code, and that's the easy part... the hard part is knowing what to do and why. That knowhow is yours, you own it, and you can do what you want with it, especially if you happen to live in California.
I wonder where the rubbish claims about predictive power came from. General Relativity has already made many predictions, subsequently verified. Those won't suddenly vanish.
The vast majority of linux users don't raid their root disk, nor do they make regular backups. For these users, the robust recovery capability of Ext4 is cherished. Note: we're talking about the majority of users, this isn't just theoretical. To address the needs/wants of these users, ZFS would need a repair facility beyond what it has, that ZFS will never have because of this weird wanking about how raid repair is all they will ever need. The bottom line is, using ZFS on workstations for most users is just nuts, and will continue to be nuts until ZFS devs get over their fear of proper fsck. Mind you, implementing a proper fsck on ZFS would be a huge project because internally, ZFS is a gigantic rambling mess. That is the real reason that ZFS doesn't have a repairing fsck, not because raid repair is just as good, but because implementing this is hard, and apparently beyond the skill and energy of current ZFS devs.
Can you run into an obscure zfs bug that causes you to unrecoverably lose your entire pool? Yes, of course, which is why you need good backups in every case.
So obviously you understand that in some cases of corruption, Ext4 can recover useful data while with Zfs your only option is to restore from backup. Now try to explain to any Ext4 user who has successfully rescued data (and there are many, including me) why they should give up this safety net in the name of some psychobabble about how raid repair is just as good as fsck repair, if only you had proper backups. Oops.
Just because it isn't called fsck doesn't mean it doesn't have one.
Zfs scrub is just a raid repair, it does not understand the structure of the filesystem and therefore is incapable of repairing inconsistencies, or detecting any inconsistency that does not show up as a raid checksum failure. Zfs scrub is definitely not a repairing fsck, and it is beyond me why zfs boosters like to lie about that, or fool themselves.
the FCC has repeatedly stated time and time again they have no intent of hurting third party open source firmware and they're solely focused on the radio component not causing interference.
"It became necessary to destroy the town to save it"
The main drawback with zfs is, it does not have a repairing fsck and never will have one. The koolaid you are supposed to drink is that raid will fix any corruption, so if anything ever does go wrong, and that would include bugs, random memory bit flips, multiple disk errors (lightning storm anyone?) and any number of other hazards that defeat raid recovery, zfs is just screwed and won't even attempt to get back the data that is most probably still sitting there, mostly intact.
If you need snapshots and remote replication more than you need the comfort zone of being able to repair just about anything that goes wrong, then ZFS is for you, otherwise Ext4 is still the most robust general purpose filesystem around.
The other thing that really hasn't come out yet is, how does ZFS perform compared to Ext4? So far nobody has done proper head to head benchmarks on identical hardware and OS. Soon it should be easy. I'm guessing that ZFS comes in pretty solidly in the rear of the pack.
If you think otherwise, please explain how these results match the theory exactly. If your pet theory can explain that, provide an additional test which shows that your theory has greater predictive power. Until you can do the first, you're a simple crank, and until you can do the latter, you're on the wrong side of Occam's Razor.
Explaining something doesn't make you not a crank. Cranks always explain things, it's just that their explanations are wrong or untestable.
They weren't going to find gravity waves because they weren't looking for gravity waves.
If they had seen gravity waves they would have had no idea what they were but would certainly have regarded them as important. The real reason they weren't going to find gravity waves is that their apparatus was insufficiently sensitive by orders of magnitude.
Any fusion reaction will produce neutrons and if these are moderated and then incident on uranium you can produce plutonium.
One of the notorious characteristics of supposed cold fusion is that it does not produce neutrons. If that leads you to think that there is in fact no fusion reaction, you would find yourself in good company.
The trouble with LENR is we can see it work, but we don't know why or how...
Another problem is that nobody has been able to see it work reproducibly. Or work at all for that matter, in any verifiable way. The crank piece you linked does nothing to change my impression of that. As for military involvement in (let's say it) cold fusion, that does not exactly inspire confidence.
And why are they going thorough the trouble of removing improvements from CFQ?
CFQ was never very good, Lots of quirky behaviour, often being worse than the NOOP scheduler and sometimes stuffing up completely. This is a nice polite way of taking it out behind the barn and shooting it. The new one turns in massive improvements in read latency, respectable improvement in other loads, and little to no regression on any load, besides being thought through and 1,000,000 times better documented than the old steaming pile.
Slashdot Mirror
Since pretty much the beginning, the Linux developers approved, condoned, and encouraged binary, non-GPL modules.
Being a lawyer doesn't make you out of touch. "Linux developers" have never approved of or encouraged binary, non-GPL modules, quite the contrary. Tolerated, or looked the other way is the most you could say. Linus has at times expressed a permissive attitude, but he has also said this. What you need to remember is that it's not Linus's kernel, it's only partly his. Anyone who holds copyright in it (thousands) is entitled to make an issue of illegal distribution if they wish.
No one is combining Linux + ZFS into a single binary. Ubuntu has already said, over and over, that ZFS will be a separate kernel module (zfs.ko)
Nonsense. Loading a module ("linking it") into the kernel makes a single binary, that is unambiguous.
Just prepare a detailed description of how to write the fix(es) and post it where some interested party can find it. See, the copyright applies to the code, and that's the easy part... the hard part is knowing what to do and why. That knowhow is yours, you own it, and you can do what you want with it, especially if you happen to live in California.
Yay for pop physics.
I wonder where the rubbish claims about predictive power came from. General Relativity has already made many predictions, subsequently verified. Those won't suddenly vanish.
What values will the computer learn if it happens to stumble on some Trump campaign speeches?
The vast majority of linux users don't raid their root disk, nor do they make regular backups. For these users, the robust recovery capability of Ext4 is cherished. Note: we're talking about the majority of users, this isn't just theoretical. To address the needs/wants of these users, ZFS would need a repair facility beyond what it has, that ZFS will never have because of this weird wanking about how raid repair is all they will ever need. The bottom line is, using ZFS on workstations for most users is just nuts, and will continue to be nuts until ZFS devs get over their fear of proper fsck. Mind you, implementing a proper fsck on ZFS would be a huge project because internally, ZFS is a gigantic rambling mess. That is the real reason that ZFS doesn't have a repairing fsck, not because raid repair is just as good, but because implementing this is hard, and apparently beyond the skill and energy of current ZFS devs.
Can you run into an obscure zfs bug that causes you to unrecoverably lose your entire pool? Yes, of course, which is why you need good backups in every case.
So obviously you understand that in some cases of corruption, Ext4 can recover useful data while with Zfs your only option is to restore from backup. Now try to explain to any Ext4 user who has successfully rescued data (and there are many, including me) why they should give up this safety net in the name of some psychobabble about how raid repair is just as good as fsck repair, if only you had proper backups. Oops.
Um, what?
zfs scrub
Just because it isn't called fsck doesn't mean it doesn't have one.
Zfs scrub is just a raid repair, it does not understand the structure of the filesystem and therefore is incapable of repairing inconsistencies, or detecting any inconsistency that does not show up as a raid checksum failure. Zfs scrub is definitely not a repairing fsck, and it is beyond me why zfs boosters like to lie about that, or fool themselves.
ZFS does not need a fsck utility because it cannot break like other filesystems.
Excellent sense of humour :)
the FCC has repeatedly stated time and time again they have no intent of hurting third party open source firmware and they're solely focused on the radio component not causing interference.
"It became necessary to destroy the town to save it"
The main drawback with zfs is, it does not have a repairing fsck and never will have one. The koolaid you are supposed to drink is that raid will fix any corruption, so if anything ever does go wrong, and that would include bugs, random memory bit flips, multiple disk errors (lightning storm anyone?) and any number of other hazards that defeat raid recovery, zfs is just screwed and won't even attempt to get back the data that is most probably still sitting there, mostly intact.
If you need snapshots and remote replication more than you need the comfort zone of being able to repair just about anything that goes wrong, then ZFS is for you, otherwise Ext4 is still the most robust general purpose filesystem around.
The other thing that really hasn't come out yet is, how does ZFS perform compared to Ext4? So far nobody has done proper head to head benchmarks on identical hardware and OS. Soon it should be easy. I'm guessing that ZFS comes in pretty solidly in the rear of the pack.
JFS is also pretty fast with large files and mature.
And unmaintained.
If you think otherwise, please explain how these results match the theory exactly. If your pet theory can explain that, provide an additional test which shows that your theory has greater predictive power. Until you can do the first, you're a simple crank, and until you can do the latter, you're on the wrong side of Occam's Razor.
Explaining something doesn't make you not a crank. Cranks always explain things, it's just that their explanations are wrong or untestable.
They would have seen gravitational waves as transient noise...
I seriously doubt that. Those dudes were pretty smart.
-1, Blithering Idiot.
They weren't going to find gravity waves because they weren't looking for gravity waves.
If they had seen gravity waves they would have had no idea what they were but would certainly have regarded them as important. The real reason they weren't going to find gravity waves is that their apparatus was insufficiently sensitive by orders of magnitude.
Any fusion reaction will produce neutrons and if these are moderated and then incident on uranium you can produce plutonium.
One of the notorious characteristics of supposed cold fusion is that it does not produce neutrons. If that leads you to think that there is in fact no fusion reaction, you would find yourself in good company.
My expectation is that LENR will be used for heat production.
It's actually mainly used for hot air production.
The trouble with LENR is we can see it work, but we don't know why or how...
Another problem is that nobody has been able to see it work reproducibly. Or work at all for that matter, in any verifiable way. The crank piece you linked does nothing to change my impression of that. As for military involvement in (let's say it) cold fusion, that does not exactly inspire confidence.
Pretty much.
And why are they going thorough the trouble of removing improvements from CFQ?
CFQ was never very good, Lots of quirky behaviour, often being worse than the NOOP scheduler and sometimes stuffing up completely. This is a nice polite way of taking it out behind the barn and shooting it. The new one turns in massive improvements in read latency, respectable improvement in other loads, and little to no regression on any load, besides being thought through and 1,000,000 times better documented than the old steaming pile.
Enjoy.
Hiring Marissa Mayer was the biggest warning sign of all.
she's on the "powerball winner" side of the aisle, if you catch my drift.
More like "powerbush", if you catch my drift.