Somehow I doubt that is going to work on my $70 Seagate 7200RPM hard drive plugged into my $50 motherboard or $20 SATA controller card. However, by all means let me know if it will.
Plus, COW filesystems offer a lot more than just data checksumming.
Agree, as the other reply pointed out as well. And you can do the same with mdadm raid too (though obviously with none of the benefits btrfs/zfs bring for data integrity like checksumming and copy-on-write). Mdadm will also let you reshape an array in place (that is change raid levels or number of disks), though with mdadm that will often result in messing up your stripe alignment and of course it is more likely to eat your data if something goes wrong since if it finds a parity mismatch it has no way to know which copy is bad.
I was just commenting that btrfs tends to have a lot of features that appeal to small system users that you'll actually find missing on zfs, even if it is far less mature overall, and lacking in many enterprise-scale features. It just reflects the emphasis of the developers behind it.
I really can't complain about zfs - it is a great filesystem. However, things like not being able to reshape an array or mix disk sizes in an array are some of the things that hold me back from adopting it. Heck, btrfs will let you switch from raid1 to raid5 without touching any of the data already written - newly-allocated chunks will use raid5 and existing chunks will continue to use raid1 - it doesn't manage arrays at the whole-device level. In practice though you're likely to tell it to rebalance your data of course.
Sure, but with btrfs you can just add one drive and sometimes get its entire capacity added to your array - it works fine with mixed-size disks.
Of course, it might just decide not to boot the next day, and that is the downside to btrfs. It does tend to be a bit more friendly in scenarios where you have a small number of disks, though, which was my main point.
Losing data goes with the territory if you're going to use RAID 0.
In particular, RAID 0 combines disks with no redundancy. It's JUST about capacity and speed, striping the data across several drives on several controllers, so it comes at you faster when you read it and gets shoved out faster when you write it. RAID 0 doesn't even have a parity disk to allow you to recover from failure of one drive or loss of one sector.
That means the failure rate is WORSE than that of an individual disk. If any of the combined disks fails, the total array fails.
(Of course it's still worse if a software bug injects additional failures. B-b But don't assume, because "there's a RAID 0 corruption bug", that there is ANY problem with the similarly-named, but utterly distinct, higher-level RAID configurations which are directed toward reliability, rather than ONLY raw speed and capacity.)
Why would you want to add just one drive to a server with 5x 6-drive RAID6 arrays? Just add another 6 drives at a time.
ZFS isn't ideal for growing like that since it doesn't do rebalancing. Your younger raid arrays will always have more data on them.
Also zfs destroy is very expensive.
Perhaps, but my point was more that if you want to grow ZFS this is the ONLY way to actually do it, as far as I'm aware. You can't add individual drives to individual "vdevs."
The problem is that the feature-list for ZFS is very enterprise-oriented.
Why would you want to add just one drive to a server with 5x 6-drive RAID6 arrays? Just add another 6 drives at a time.
On the other hand, if you have a PC with 3 drives in RAID5, you could easily want to turn that into a 4-drive RAID5 or a 5-drive RAID6 in-place.
Btrfs has a lot of features that are useful for smaller deployments, like being able to modify the equivalent of a vdev in-place. ZFS on the other hand has a lot of features like ZIL that are very useful for larger deployments.
Agree. RTGs aren't actually all that efficient - they're a very primitive form of nuclear power. Their advantage is in their simplicity and longevity, which makes them great for things like spacecraft that need low power for VERY long duration, and where repairs are impossible.
You'd need a pretty big aircraft before nuclear turns into a viable option.
I'm interested in whether this is limited to ONLY proprietary research.
I could actually see an argument for banning export of such research. Do we really want companies finding flaws in widely-used software, keeping those flaws secret from the software vendors and the general public, but then selling details on those flaws to others who could potentially turn around and exploit them? In a sense, this does sound like a munition.
I don't see the same concern with public research. If you disclose a vulnerability publicly, then everybody can fix it, and that strengthens the ecosystem instead of weakening it.
If the ban were limited to proprietary research, I don't see it as a bad thing. Of course, it does nothing to keep companies from selling their findings to NSA contractors and such, but I don't expect the US to lift a finger to ban practices like these.
Diagramming on a whiteboard remotely is a different problem. It's easily solved by pointing the camera at the whiteboard behind you, at least when you have 3 different people in 2 locations. When you have 27 locations and 150 people on the call, what then? A shared whiteboard that everyone fucks up completely in the first 15 seconds because there is not enough whiteboard space?
In my experience the problem isn't getting everybody to not scribble on the board. The problem is that everybody has a 14" monitor and it is just really hard to do anything freehand on such a display. Maybe with graphics tablets and better software it might work.
Even diagramming something solo is a mess in my experience. I tend to end up doing mindmaps or outlines in Word or visio, but the last tends to be pretty painful to do quickly.
Depends on how badly your meetings are organized... no offense. If you structure them properly you can use whiteboards just fine. Works the same with power point. If you can't see the whiteboard than how can you see the power point?
The powerpoint is shared over webex, which is how everybody is connected to the meeting?
I currently am a systems engineer working specifically on email systems design.
And this makes you an authority about Weapons of Mass Destruction how? Even if you were doing email systems design for DuPont or the military, you'd have no authority to cite.
Also, if you were any good as a "systems engineer" they wouldn't have you working on email, that's a lower rung than even web backends. Whoever was responsible for cooking up Saddam's nasties in the 80s wouldn't even hire guys of your caliber as a floor manager, let alone as an engineer.
It happens I could use remote USB port functionality.
(Right now I want to run, on my laptop, a device that requires a Windows driver and Windows-only software. I have remote access to a Windows platform with the software and driver installed. If I could export a laptop USB port to the Windows machine, it would solve my problem.)
So NetUSB is vulnerable. Is there an open source replacement for it? (Doesn't need to be interworking if there are both a Linux port server and a Windows client-pseudodriver available.)
I skimmed the start of the paper. If I have this right:
- Essentially all the currently-deployed web servers and modern browsers have the new, much better, encryption.
- Many current web servers and modern browsers support talking to legacy counterparts that only have the older, "export-grade", crypto, which this attack breaks handily.
- Such a server/browser pair can be convinced, by a man-in-the-middle who can modify traffic (or perhaps an eavesdropper-in-the-middle who can also inject forged packets) to agree to use the broken crypto - each being fooled into thinking the broken legacy method is the best that's available.
- When this happens, the browser doesn't mention it - and indicates the connection is secure.
Then they go on to comment that the characteristics of the NSA programs leaked by Snowden look like the NSA already had the paper's crack, or an equivalent, and have been using it regularly for years.
But, with a browser and a web server capable of better encryption technologies, forcing them down to export-grade LEAKS INFORMATION TO THEM that they're being monitored.
So IMHO, rather than JUST disabling the weak crypto, a nice browser feature would be the option for it to pretend it is unpatched and fooled, but put up a BIG, OBVIOUS, indication (like a watermark overlay) that the attack is happening (or it connected to an ancient, vulnerable, server):
- If only a handful of web sites trip the alarm, either they're using obsolete servers that need upgrading, or their traffic is being monitored by NSA or other spooks.
- If essentially ALL web sites trip the alarm, the browser user is being monitored by the NSA or other spooks.
The "tap detector" of fictional spy adventures becomes real, at least against this attack.
With this feature, a user under surveillance - by his country's spooks or internal security apparatus, other countries' spooks, identity thieves, corporate espionage operations, or what-have-you, could know he's being monitored, keep quiet about it, lie low for a while and/or find other channels for communication, appear to be squeaky-clean, and waste the tapper's time and resources for months.
Meanwhile, the NSA, or any other spy operation with this capability, would risk exposure to the surveilled time it uses it. A "silent alarm" when this capability is used could do more to rein in improper general surveillance than any amount of legislation and court decisions.
With open source browsers it should be possible to write a plugin to do this. So we need not wait for the browser maintainers to "fix the problem", and government interference with browser providers will fail. This can be done by ANYBODY with the tech savvy to build such a plugin. (Then, if they distribute it, we get into another spy-vs-spy game of "is this plugin really that function, or a sucker trap that does tapping while it purports to detect tapping?" Oops! The source is open...)
Not sure what benefit "tampering" would provide. Why would you have to take it apart to extract its secrets, when you can just: steal the person's smartphone/computer and the yubikey, and use them in tandem to authenticate yourself as the user to whatever services they have locked behind it? You can use the Yubikey all by itself, assuming you have exclusive physical access to the device, to make it serve its purpose for you, the attacker.
Sure, but you can ONLY use it while it is under your control if the embedded keys cannot be extracted.
If they can, then you can duplicate the key and return the original, perhaps undetected. That gives you the ability to retain access to whatever was secured.
There is definitely value in tamper-resistant key vaults.
Kleeneness is next to Godelness.
