Native OpenZFS encryption definately coming to FreeBSD, (and all the other OSes that use OpenZFS). I played with native ZFS encryption on Linux last summer, (August 2017), and it was pretty stable then. But, details of ZFS send & receive, (raw verses un-encrypted), were still being worked out. And based on the ZFS on Linux github bugs, there are lots of corner cases being resolved.
So, in some regards be happy OpenZFS on Linux is dealing with all the bugs. Whence they are squashed, the other OSes like FreeBSD, will get stablized and well documented native OpenZFS encryption.
Just remember, this is at rest encryption. Not a pancea for all security issues.
I wish Linux would separate the BTRFS development tree from the production tree. Then work for stabilizing Mirroring and other current normal features of BTRFS. Use the development branch to add new features like the forever pending RAID-5/6.
A long time ago, (2011?), I used BTRFS as my root file system for 2 of my 4 Linux computers. Not for most of the features. My main goal was to get sub-volumes, so I could perform OS updates on a writable snap shot. For me, that worked perfect and the times I had to backout a Gentoo update, it was not a killer. (My prior scheme was dual root partitions that I alternated updating. Before that, occasional full restore!).
But, BTRFS never stablized. People were loosing data, or having serious mount problems, (fortunately not me). I saw BTRFS going into wonderland of compression, encryption and copy-on-write, (reflink), for individual files. That sounded like a nightmare to manage and maintain. The biggest reason I hated BTRFS, was that I could not tell sub-volume sizes using simple tools, like "df -h". Quota limits would have also been nice, but sizes were more important for me at the time.
So, in 2014 I started looking at ZFS on Linux. Implementing it on one of my Linux computers, (a minature media server), worked great. Got my sub-volume sizes and quota issues 100% resolved. Plus, got some great features, like LZ4 compression, (which at the time BTRFS did not support compression). And a reliable development group, releasing updates every few months. Now for years, all my Linux computers use ZFS. Have not lost 1 byte, (and I run monthly scrubs to verify), to the file system. Perhaps a native Linux file system would be faster, but I want my sub-volumes, (aka ZFS datasets).
With OpenZFS used and developed on 4, (soon to be 6 or 7), OSes, I feel more confident that it will be more reliable, (even on Linux), than BTRFS or possibly B-Cache.
(And for those wondering, the OpenZFS Tier 1 OSes are FreeBSD, Illumos and similar OpenSolaris derivitives, and Linux. MacOS might be considered Tier 1, but also could be Tier 2 since little development is performed on MacOS in regards to OpenZFS. The newer ones are OSv, MS-Wiindows and possibly ReactOS, under development to support OpenZFS.)
Both my newish miniture media server and pretty old desktop use AMD, on purpose, to avoid Intel's lies. And to encourge competition. (It does help they were also not too expensive...)
Unfortunately my laptop has Intel inside. Mostly because good or in-expensive AMD laptops did not exist in early 2014 when I bought it. Of course it's taken a huge performance hit when I do the Gentoo Emerge update. So my next laptop will almost certainly be AMD. And if not, it must not have Intel hyper-threading with security issues. (Or I will simple disable Intel's hyper-threading like OpenBSD does.)
One of the things holding RISC-V back, is a single board computer, usable as a simple desktop. Something like a Raspberry PI, with;
- at least dual core CPU, potentially with a quad core option
- reasonable amount of memory, 1GB or more, (or DIMM slots)
- multiple USB ports
- storage, (SATA, SDXC or fast USB port for external storage)
- network, (WiFi, Ethernet, or a fast USB port for network dongles)
- video, (or PCIe slot for video card)
- Some expansion, (like PCIe, or more than 1 USB port that is a funnel of I/O bandwidth...)
This would let people test out software, and run through debuging instructions. Ideally it would have both 32 bit and 64 bit instruction sets, but starting with a 32 bit only might be acceptable in the short term.
I personally want to see a simple RISC-V 64 bit single board computer like above. Maybe it does not have to be a full blown motherboard with normal features, (like sound, and several PCIe slots), but if it's usable it would let me test out software. Then I can submit bug reports for compiler issues, and OS related quirks or out right bugs.
Neither Meltdown nor TLBleed affect AMD and AMD's Ryzen processors, as far as we know now...
So any benchmark of an Intel CPU without those security mitigations, (if needed), would be showing that they still want to abuse security for the performance gain. Something AMD appears not to want to do.
Kudos for getting Gentoo mentioned for good reasons. I used Gentoo on my old netbook and media server, both of which were 32bit and slow. Except Gentoo made them work great.
Today I simply continued to use Gentoo on my desktop, newish laptop and new media server, all 64bit and running great. Even the dreaded Gentoo Updates are no problem today. I use alternate boot environments to overcome the weird problems. (Orginially my ABEs used BTRFS snapshots, now I use the much more stable and feature rich OpenZFS.)
Agreed on all except, I'll take another's comment on seLinux as something to consider. It may have it's uses.
Additionally, I'd add this;
- Reduce the number of security holes, bugs, quirks and whatnot, (but not at loss of reliability), over new features.
We don't need stinking new features! (I am looking squarely at you, Gnome 3! It should have been Gnome-NG, or something else, not 3.x.)
Everytime a new feature is added, it's possible that it added new security holes, bugs, quirks and reduced reliability. Let's end the madness
and decline new features until the software is secure, stable and suitable for it's intended task. (Copyright pending for SSS=Secure, Stable
and Suitable:-)
I am not wearing some wimpy Tyvek coveralls, (I have them for less critical things like Galagar's watermelon explosions). The real key to surviving a systemd shit storm, is fireproof nomex and a hard helmet.
Competition is a good thing. Without AMD, and all the people who helped keep them alive, Intel would have sat on things like this.
In the long run, Intel parts are likely going to be better. They have more money, more chip desigers, and un-fortunantly more customers, (some that will pay outragous prices).
Had a job where one time we installed a dozen or so low end RAID disk arrays. They had 8 slots but only 4 populated. So, RAID-5 was our only real choice, (given the application space requirement). The array vendor did supply a mixture of disk drive manufacturers, but it still did not help.
We ended up with a lemon model, the IBM 3.5" 9GB SCSI. They started dying. Whence the root cause was determined, (bad batch of drives), we asked our array vendor to replace them all. Perhaps 40 more disks. They balked big time, so we threw our weight around, (the 800lbs gorilla gets action). Then we took a week to replace them, one per RAID-5 set at a time.
To be fair, perhaps only 1/3 of the arrays had 2 of the faulty disks. None had 3 per array, (if I remember correctly). The rest got fixed with just one disk replacement.
Tests Show Workers At Hanford Nuclear Facility Inhaled Plutonium, (which is Radioactive)
There is no non-radioactive plutonium. (Just gota love double negatives!) In someways, it should have listed the exact isotope, like Pu-239. Some plutonium isotopes produce difference levels of radiation, like Pu-238. That's used in RTGs, nuclear batteries. Though to be fair, I have no clue which isotope, (if any), is less bad to breath.
In general I agree. We should have laws protecting drivers, (and even other pedestrians), from actions of people too distracted to see danger.
Don't know if it can ever be clearly determined that the cell-phone was the cause. But, this is getting me more and more wanting a front and back viewing camera for my car. One with a removable memory card. So when something happens, (and it's not my fault...), I can use the video to show what happened.
Yes, FreeBSD is what I call a long term supported, server style OS.
(That's not to imply it can't be a desktop OS. I used Solaris 2.5.1, 2.6, 8 and 10 on SPARC for my desktop, for over 10 years...)
iXsystems took over the old PCBSD and now calls it TrueOS. Still based on FreeBSD, and intended as a desktop OS. Still a bit raw. And probably does not have the driver support Linux has, but if Linux goes messy, (SystemD everywhere!), then I will have to consider migrating from Gentoo to TrueOS.
One thing I absolutely love, is ZFS. (And yes, on Gentoo Linux it's rock stable.) This gets me so many features, like alternate boot environments for software upgrades, home filesystem snapshots for easy file recovery, simple disk mirroring, and data / RAID verification.
In my opinion, (not that it maters to most), is that SystemD needs to slow down and fix all known existing problems. Make it rock stable.
Then, go back and figure out what SystemD missed for security and reliability. And fix those issues.
Last, plan, (yes, I know, profanity is not supposed to be used here), what features should be added to SystemD next.
In general, Linux, (I use Gentoo on ZFS root without SystemD), should be, and is quite stable and usable as is. No need to change anything, except perhaps fix security issues.
Agreed. Even though somethings about the Allwinner look good on paper, I prefer a product that is a bit more stable and well supported.
One other note, the Allwinner is from a Chinese source. I do not trust them yet to produce flawless products. (If Intel, AMD, Broadcom, and other western suppliers can't get things right, I doubt newer companies from China can do so.)
What is this, the 100th IoT device with security flaws? Or is that the 1,000th IoT device?
Recently I have been thinking about this, (I know, no one is supposed to THINK any more), and perhaps using open source replacement firmware would be the saving of many of these devices. Similar to DD-WRT is today. With clear, open software, developers could make suggestions and submit bug fixes to get this stuff fixed.
Plus, there could be usability flaws in the IoT devices as well.
We can leave the cheap hardware production where it is, (since people buy that crap). But, put the software development in the hands of real people. Not rank amatuers. (Note I was in software development and had millions of satisfied users. We won't mention how many dis-satisfied users:-).
My personal hope is that this airship includes some heavy lift functions too.
I mean it would be OK if it had a luxury passenger area, but ideally not just a limited amount of passengers.
Slashdot Mirror
Gnome 3 pushed me over the edge to convert from Gnome 2.x to XFCE.
Now any personal desktop / laptop uses XFCE, simply to avoid the mess of Gnome 3.
Long live choice!
Native OpenZFS encryption definately coming to FreeBSD, (and all the other OSes that use OpenZFS). I played with native ZFS encryption on Linux last summer, (August 2017), and it was pretty stable then. But, details of ZFS send & receive, (raw verses un-encrypted), were still being worked out. And based on the ZFS on Linux github bugs, there are lots of corner cases being resolved.
So, in some regards be happy OpenZFS on Linux is dealing with all the bugs. Whence they are squashed, the other OSes like FreeBSD, will get stablized and well documented native OpenZFS encryption.
Just remember, this is at rest encryption. Not a pancea for all security issues.
I wish Linux would separate the BTRFS development tree from the production tree. Then work for stabilizing Mirroring and other current normal features of BTRFS. Use the development branch to add new features like the forever pending RAID-5/6.
A long time ago, (2011?), I used BTRFS as my root file system for 2 of my 4 Linux computers. Not for most of the features. My main goal was to get sub-volumes, so I could perform OS updates on a writable snap shot. For me, that worked perfect and the times I had to backout a Gentoo update, it was not a killer. (My prior scheme was dual root partitions that I alternated updating. Before that, occasional full restore!).
But, BTRFS never stablized. People were loosing data, or having serious mount problems, (fortunately not me). I saw BTRFS going into wonderland of compression, encryption and copy-on-write, (reflink), for individual files. That sounded like a nightmare to manage and maintain. The biggest reason I hated BTRFS, was that I could not tell sub-volume sizes using simple tools, like "df -h". Quota limits would have also been nice, but sizes were more important for me at the time.
So, in 2014 I started looking at ZFS on Linux. Implementing it on one of my Linux computers, (a minature media server), worked great. Got my sub-volume sizes and quota issues 100% resolved. Plus, got some great features, like LZ4 compression, (which at the time BTRFS did not support compression). And a reliable development group, releasing updates every few months. Now for years, all my Linux computers use ZFS. Have not lost 1 byte, (and I run monthly scrubs to verify), to the file system. Perhaps a native Linux file system would be faster, but I want my sub-volumes, (aka ZFS datasets).
With OpenZFS used and developed on 4, (soon to be 6 or 7), OSes, I feel more confident that it will be more reliable, (even on Linux), than BTRFS or possibly B-Cache.
(And for those wondering, the OpenZFS Tier 1 OSes are FreeBSD, Illumos and similar OpenSolaris derivitives, and Linux. MacOS might be considered Tier 1, but also could be Tier 2 since little development is performed on MacOS in regards to OpenZFS. The newer ones are OSv, MS-Wiindows and possibly ReactOS, under development to support OpenZFS.)
Agreed.
Both my newish miniture media server and pretty old desktop use AMD, on purpose, to avoid Intel's lies. And to encourge competition. (It does help they were also not too expensive...)
Unfortunately my laptop has Intel inside. Mostly because good or in-expensive AMD laptops did not exist in early 2014 when I bought it. Of course it's taken a huge performance hit when I do the Gentoo Emerge update. So my next laptop will almost certainly be AMD. And if not, it must not have Intel hyper-threading with security issues. (Or I will simple disable Intel's hyper-threading like OpenBSD does.)
One of the things holding RISC-V back, is a single board computer, usable as a simple desktop. Something like a Raspberry PI, with;
- at least dual core CPU, potentially with a quad core option
- reasonable amount of memory, 1GB or more, (or DIMM slots)
- multiple USB ports
- storage, (SATA, SDXC or fast USB port for external storage)
- network, (WiFi, Ethernet, or a fast USB port for network dongles)
- video, (or PCIe slot for video card)
- Some expansion, (like PCIe, or more than 1 USB port that is a funnel of I/O bandwidth...)
This would let people test out software, and run through debuging instructions. Ideally it would have both 32 bit and 64 bit instruction sets, but starting with a 32 bit only might be acceptable in the short term.
I personally want to see a simple RISC-V 64 bit single board computer like above. Maybe it does not have to be a full blown motherboard with normal features, (like sound, and several PCIe slots), but if it's usable it would let me test out software. Then I can submit bug reports for compiler issues, and OS related quirks or out right bugs.
I am surprised!
That this is not a weekly occurance. (Well, weekly Public occurance...)
That would be;
Neither Meltdown nor TLBleed affect AMD and AMD's Ryzen processors, as far as we know now...
So any benchmark of an Intel CPU without those security mitigations, (if needed), would be showing that they still want to abuse security for the performance gain. Something AMD appears not to want to do.
Thank you for the clear, concise post.
Kudos for getting Gentoo mentioned for good reasons. I used Gentoo on my old netbook and media server, both of which were 32bit and slow. Except Gentoo made them work great.
Today I simply continued to use Gentoo on my desktop, newish laptop and new media server, all 64bit and running great. Even the dreaded Gentoo Updates are no problem today. I use alternate boot environments to overcome the weird problems. (Orginially my ABEs used BTRFS snapshots, now I use the much more stable and feature rich OpenZFS.)
Yes, agreed. I think the original Init System could be improved. And something with more features, like parallelism, (Solaris 10 and later have that).
How dare you attack the great and perfect Emaos! Oh wait, you said Emacs? Never mind. Please return to your normal programing.
Agreed on all except, I'll take another's comment on seLinux as something to consider. It may have it's uses.
:-)
Additionally, I'd add this;
- Reduce the number of security holes, bugs, quirks and whatnot, (but not at loss of reliability), over new features.
We don't need stinking new features! (I am looking squarely at you, Gnome 3! It should have been Gnome-NG, or something else, not 3.x.)
Everytime a new feature is added, it's possible that it added new security holes, bugs, quirks and reduced reliability. Let's end the madness
and decline new features until the software is secure, stable and suitable for it's intended task. (Copyright pending for SSS=Secure, Stable
and Suitable
I am not wearing some wimpy Tyvek coveralls, (I have them for less critical things like Galagar's watermelon explosions). The real key to surviving a systemd shit storm, is fireproof nomex and a hard helmet.
Competition is a good thing. Without AMD, and all the people who helped keep them alive, Intel would have sat on things like this.
In the long run, Intel parts are likely going to be better. They have more money, more chip desigers, and un-fortunantly more customers, (some that will pay outragous prices).
One comment.
When Linux goes SystemD for the entire OS configuration and there are no more non-SystemD distros out, we will then need an alternative OS.
Gee, I make it sound like SystemD is a virus? Maybe it is based on how fast and far it's spread...
Agree competely.
Had a job where one time we installed a dozen or so low end RAID disk arrays. They had 8 slots but only 4 populated. So, RAID-5 was our only real choice, (given the application space requirement). The array vendor did supply a mixture of disk drive manufacturers, but it still did not help.
We ended up with a lemon model, the IBM 3.5" 9GB SCSI. They started dying. Whence the root cause was determined, (bad batch of drives), we asked our array vendor to replace them all. Perhaps 40 more disks. They balked big time, so we threw our weight around, (the 800lbs gorilla gets action). Then we took a week to replace them, one per RAID-5 set at a time.
To be fair, perhaps only 1/3 of the arrays had 2 of the faulty disks. None had 3 per array, (if I remember correctly). The rest got fixed with just one disk replacement.
The title should have read;
Tests Show Workers At Hanford Nuclear Facility Inhaled Plutonium, (which is Radioactive)
There is no non-radioactive plutonium. (Just gota love double negatives!) In someways, it should have listed the exact isotope, like Pu-239. Some plutonium isotopes produce difference levels of radiation, like Pu-238. That's used in RTGs, nuclear batteries. Though to be fair, I have no clue which isotope, (if any), is less bad to breath.
In general I agree. We should have laws protecting drivers, (and even other pedestrians), from actions of people too distracted to see danger.
Don't know if it can ever be clearly determined that the cell-phone was the cause. But, this is getting me more and more wanting a front and back viewing camera for my car. One with a removable memory card. So when something happens, (and it's not my fault...), I can use the video to show what happened.
Yes, FreeBSD is what I call a long term supported, server style OS.
(That's not to imply it can't be a desktop OS. I used Solaris 2.5.1, 2.6, 8 and 10 on SPARC for my desktop, for over 10 years...)
iXsystems took over the old PCBSD and now calls it TrueOS. Still based on FreeBSD, and intended as a desktop OS. Still a bit raw. And probably does not have the driver support Linux has, but if Linux goes messy, (SystemD everywhere!), then I will have to consider migrating from Gentoo to TrueOS.
One thing I absolutely love, is ZFS. (And yes, on Gentoo Linux it's rock stable.) This gets me so many features, like alternate boot environments for software upgrades, home filesystem snapshots for easy file recovery, simple disk mirroring, and data / RAID verification.
In my opinion, (not that it maters to most), is that SystemD needs to slow down and fix all known existing problems. Make it rock stable.
Then, go back and figure out what SystemD missed for security and reliability. And fix those issues.
Last, plan, (yes, I know, profanity is not supposed to be used here), what features should be added to SystemD next.
In general, Linux, (I use Gentoo on ZFS root without SystemD), should be, and is quite stable and usable as is. No need to change anything, except perhaps fix security issues.
Agreed. Even though somethings about the Allwinner look good on paper, I prefer a product that is a bit more stable and well supported.
One other note, the Allwinner is from a Chinese source. I do not trust them yet to produce flawless products. (If Intel, AMD, Broadcom, and other western suppliers can't get things right, I doubt newer companies from China can do so.)
This is a prime example of why systemd is the annoyance it is, new code is never bug free.
I prefer the older init systems that at least have modular designs and tend to be less buggy.
Perfect comment. Even applies beyond simple E-Mail.
What is this, the 100th IoT device with security flaws?
:-).
Or is that the 1,000th IoT device?
Recently I have been thinking about this, (I know, no one is supposed to THINK any more), and perhaps using open source replacement firmware would be the saving of many of these devices. Similar to DD-WRT is today. With clear, open software, developers could make suggestions and submit bug fixes to get this stuff fixed.
Plus, there could be usability flaws in the IoT devices as well.
We can leave the cheap hardware production where it is, (since people buy that crap). But, put the software development in the hands of real people. Not rank amatuers. (Note I was in software development and had millions of satisfied users. We won't mention how many dis-satisfied users
My personal hope is that this airship includes some heavy lift functions too. I mean it would be OK if it had a luxury passenger area, but ideally not just a limited amount of passengers.