There's a difference between "hating change" and being uninterested in over-hyped junk with no practical relevance. And yes, I've been to a demo of the HoloLens and seen it in real life. It was crap and even the rabid fanatic doing the demo couldn't make it work properly during his demo. That's Microsoft software again! Make one that actually works well, as well as actually solving problems I have, and I might start to get interested. But right now, it's nothing more than a toy trying desperately to provide solutions to problems which people don't have. It lacks purpose, in addition to being a mediocre implementation of the concept.
Having been reading slashdot for nearly 20 years now, I think it's certainly fair to say I've become less susceptible to hype. Lots of stuff has been hyped over the years and come to nothing. Most of it was crap. I don't hate change, I just don't have interest in over-hyped useless crap anymore. Let it establish itself, and then I might get interested if there's worth in it. I'll leave the rabid fanaticism to others.
Yep, went to a talk/demo three weeks back. Looked interesting and promising, but in reality I was completely underwhelmed. Didn't help that the speaker was a rabid Microsoft fanatic and spent most of the talk going on about how awesome Microsoft were rather than talking about the technology, but the technology itself is nothing particularly special. And most of the usage scenarios and games they had for it were contrived and useless. They also chose to go with an Intel Atom processor in the unit rather than a less power hungry ARM. I really don't need a hot CPU plastered onto my forehead. The power consumption was so bad the guy had a big USB battery pack in the back of his pants!
The overall idea does have some merit. The implementation is respectable but frighteningly expensive and not that impressive overall. I don't think the HoloLens will take off, but the concept might once it is refined somewhat. Given that you can almost do what it does today with a mobile phone in a harness and a front-facing camera, I suspect that other manufacturers will be able to make a better product for a fraction of the price.
Actually, they didn't get over it, at least in some cases. I can't play a lot of the early 3D games. They make me want to vomit and induce violent headaches with only a few tens of minutes of use. Most newer games don't. And I think it's largely due to differences in the FOV and camera positioning. The original Star Wars: Jedi Knight/Dark Forces were almost unplayable for me, as were a lot of others in this era. I stuck them out and suffered, but only in small doses. JKII/III, Mass Effect, and post recent/current games are totally OK (but not all).
A lot of this might be down to my eyes and physiology, but it's also absolutely the case that the individual games are prone to causing this, and those old games were especially bad for it (for me, and I suspect others).
You've posted this exact text to other stories. Please stop. The content is garbage.
Code compiled with GCC is not forced to be GPL and never has been. Your compiled code retains your licence.
Changes you make to the Linux kernel would be required to be GPL if you distribute them, the GPL being a *distribution* licence, but are required to be given to people you *distribute* the changes to only, not the whole world.
If this is for real, and not just a lame troll, you got lousy advice from your "lawyers".
Maybe the Unicode consortium need to supplement the ZWJ character with an SJW character.
In all seriousness, while Unicode is intended to be universal, I don't think that bullshit emojis have a place in it. We have markup in addition to characters, not to mention SVG and other formats which can better represent them. They don't have to be in the Unicode standard.
Nothing special. It was a fresh clean install in both cases. It's even a problem without the NFS home which has older crufty bits in the config. I've seen it on both my work machine and home machine, with Intel Iris and Radeon R9 390 graphics, respectively.
The NFS problems are due to the KDE programs and libraries liking to log verbosely to stderr which gets logged to the homedir. While it's not as noticeable with local discs, it becomes a significant problem with freezes lasting up to a minute with NFS. This is a major usability problem. There's really no need to log this useless junk--this has been a problem since KDE4.
For me kwin crashes for no reason very regularly (10 mins on average); back to i3 for me since Ubuntu 15.10; 16.04 is no better.
It also completely sucks when using an NFS home. Every mouse click seems to want to write some pointless logs or state back to my homedir, freezing everything up. I don't have that problem with i3: it just manages windows and doesn't do lots of unnecessary I/O.
Still pining for the pinnacle of usability and stability which was KDE3.
Most people inside Britain don't find him funny either! I've never been a particular fan, and I don't know of anyone who is. I can only imagine he's connected with the BBC management, and is suitably PC.
I doubt Rowan Atkinson would have the needed personality either. He's not a presenter, he's an actor, and is known for acting roles rather than being himself. One major change with this new series is that they hired actors rather than car nuts who can talk well. The old trio might have scripted parts of their show, but their banter came across as quite natural, and they all knew their stuff even if they didn't focus on it too much. They weren't acting, they were doing stuff with their mates, while being filmed doing it. I think LeBlanc could grow into that, and it would help if he had some more compatible personalities which complemented each other. Evans definitely wasn't that person!
And regarding the "non-PC" attitudes of the old presenters, mentioned elsewhere in the comments. People watch Clarkson because he's an opinionated arsehole, or rather an entertaining and funny opinionated arsehole. It wasn't the sanitised and bland product which is the rest of the BBC's output, and his views likely resonate more with people than they care to imagine. Hell, I have plenty of friends in India and other countries who think Top Gear is the best thing on TV and absolutely *love* Clarkson. This is another demographic the BBC would like to pretend doesn't exist (they should be outraged by his non-PC opinions!), and while they all think he's an arsehole (as do we all), outraged they are not.
It depends entirely upon the type of data. See the examples below. Some data gives a little compression; there's a lot of binary data in my homedir which doesn't compress too well. On the other hand, source code, system logs and mail can compress superbly.
Regarding the "performance penalty", it's generally going to be positive and improve performance. We are talking lz4 here, not gzip/bzip2/xz. It's fast, trading a lower compression ratio for performance. It can compress and decompress blocks in parallel. It can do this much faster than it can read data from disk, so you'll actually improve read and write speeds. And this is on top of ZFS being able to pull data of multiple spindles as the data is distributed over multiple zvols, with redundant copies of data, etc. It's likely not the penalty you think it is. It does multiple rounds of lightweight lz4 compression to reduce the entropy, and it bails out early if poorly compressible.
With compression like this, you no longer need to bother compressing rotated logs. And while the homedir compression is small in comparison, it's gained me an extra 100GiB just for this single dataset, which is not to be sneezed at.
As jedidiah stated, by putting it in the filesystem it's completely transparent. No program reading or writing needs to care; it just works. To add to that, it's not "one size fits all". With ZFS, you can tune it on a per-dataset basis. Here's a (shortened) sample from my NAS. Whitespace stripping due to slashdot, not me.
% zfs get compression
NAME PROPERTY VALUE SOURCE
red compression off default
red/data compression lz4 local
red/data@20150615 compression - -
red/data@20150724 compression - -
red/home compression lz4 local
red/home/rleigh compression lz4 inherited from red/home
red/home/rleigh@20150616 compression - -
red/home/rleigh@20150724 compression - -
As you can see here, lz4 compression is enabled on some datasets, but the default at the root of the pool is off. You aren't limited to lz4, there are other compression options. And in reality, it's much more granular than the dataset level--this is just the default for new files being created in the dataset.
It doesn't assume that. It's not compressing the whole file as a linear stream like it would with gzip or similar; it's chunked by compressing per-block with repeated rounds of lz4 (or whatever algorithm you picked). It will seek to the start of the first chunk containing the start offset you requested, and start decompressing from there. It works just fine and is completely transparent, including memory mapping and everything. It'll likely retain the whole uncompressed block in the ARC until you write it back or discard it.
Depends upon the context. If it's a noun, then "better than" is correct since it's a comparison with another object; if it's a verb, then "better to", e.g. "better to x y z". There's no difference between British and American English here which I'm aware of.
You can with NAT64/DNS64. This is used where a purely IPv6 network needs to access the old IPv4 network. My ISP even offers it as a service to those wanting to go v6 only (I haven't tried it though, I'm happy dual stacked for now).
The growth curve is clearly showing exponential growth here, and we're now well into the rapid adoption phase. Yes, the absolute value is 11% (now 12). but it will continue to grow with increasing speed. It *is* coming. It took a while, but it's a juggernaught which can't be stopped now. We'll all be using it in a couple of years at this rate. All the major ISPs have committed to do this, and network effects will drag the rest along in time.
You have been extraordinarily lucky. No horrible dataloss. And you haven't hit the unblancing issues which make the filesystem read-only after an indeterminate period? Or are you doing a regular rebalance with associated performance loss and hoping for the best?
No. Because it doesn't violate it. And being a monolithic blob is the least of the criticisms which we could make about systemd, when there's an entire book's worth of bad design in there. ZFS was designed by competent and expert professionals, rather than unprofessional prima donnas, and it shows.
It's a fundamentally different design to traditional UNIX filesystems and disk management, but that doesn't automatically make it a monolithic blob. Is Linux LVM a monolithic blob? That's the level your question is at, as well as being flamebait.
Internally, ZFS is layered similarly to a Linux raid/lvm/filesystem setup. Here, you would have raw block devices managed by hardware or software RAID, with LVM using these devices as physical volumes. It would then provide logical volumes upon which you could create filesystems.
With ZFS, you would have block devices aggregated into "vdevs", which would be the equivalent of RAID0/1/5/6 RAID sets. These are the equivalent of LVM physical volumes. Next, you would use one or more vdevs to create a "zpool", which would be the equivalent of an LVM volume group. Finally, you would create datasets in the pool, which are the equivalent of a logical volume plus a filesystem, or a zvol which is the equivalent of a logical volume--a raw block device. So it's cleanly and logically layered. It's using plain block devices as the backing store as for any UNIX filesystem, but it's not creating intermediate block devices as LVM does--it's managing that internally.
The layering is pretty much the same--it's a well separated design. What's different is that ZFS has knowledge of all the layers and can use that to do things much more efficiently and much more robustly. For example, when doing a RAID rebuild ("resilver") it only needs to resync bits of the disk that actually have data on which can dramatically reduce the statistical likelihood of encountering an unrecoverable error. A dumb RAID setup doesn't know that, and will fail if it encounters an error during a full rebuild; ZFS will succeed if those errors were in areas weren't in use. And it can also be instructed to keep more than one copy of data for important stuff, which gives it an even higher chance of rebuilding in the face of corruption. There are a whole pile of other benefits as well, but as an admin the main benefit is that it's a dream to manage on a day to day basis, and you can even delegate management of sub-datasets to other users and groups, so they can snapshot their own data at will, send and recv data, create new datasets etc. The design is clean, well thought out and brings features which are completely missing from anything else.
Simply because it's a *killer feature*. It does things which no native Linux filesystem can offer, even when coupled with LVM and RAID. It takes all of these and replaces them with something that's simply better, more robust and easier to manage. And which is also properly documented with a good number of tutorials and best practices documented clearly.
I'm one of the people who migrated to FreeBSD pretty much because of ZFS, initially for a NAS but now also on other systems. Not the only consideration, but it was the primary one. I used Linux-ZFS to initially use ZFS on Linux and migrate the data from LVM/ext4, but later transferred the disks to the NAS. A simple "zpool import" was all that was required to do so; few filesystems have that level of cross-platform interoperability (ignoring awful ones like FAT). Everything was already mounted in the right places as well!
Linux does not offer anything comparable, so if you want those features then switching operating systems to one which offers them natively makes sense. I'm going to have a play with Ubuntu 16.04 on ZFS in the next few weeks, and might well end up using it, but it's still less mature and well integrated so I doubt it will replace ZFS on FreeBSD for me anytime soon, but might supplement it--I'll at least be able to "zfs send" backups to the FreeBSD ZFS server.
If you're thinking in terms of filesystem size, and since you mention ext4 this appears to be the case, then this is a complete non-issue. ZFS *datasets* are the equivalent of filesystems, and these can grow and shrink freely; the only limit would be an optional maximum size you set on it, i.e. a quota. Otherwise it use whatever free space is available in the pool. This would be equivalent to growing and shrinking an LVM LV, but without any of the manual effort--to do the equivalent of adding or removing space, you simply adjust the quota. Dead simple, and totally safe; the same can not be said about shrinking--adjusting all the fs structures and then chopping the end off the block device with an LV resize is actually quite risky and dangerous in comparison--a mistake could trash all your data.
The other level would be the pool itself. This can be grown by addition of zvols (disk RAID sets, typically). You can't shrink the pool, that's really the only limitation. And it's not a particularly big problem, since the need to do this is rare in a production system. When all your data is in ZFS datasets, you don't fiddle with the system at this level--we're not doing manual partitioning or messing around with LV resizing any more. But that level no longer matters; all your data is simply contained in the pool, and managed in datasets, snapshots, as you see fit.
The kinetic energy of molecules *is* heat (vibration, rotation, motion), absolute zero being the point at which no motion occurs. It's transferred by conduction (as the water collides with other water molecules, and other molecules in the food, such as sugars, proteins, fats, etc.). You'll also have some convection and radiation but these aren't of great significance. The energy transfer is no different than what happens in a pan of boiling water to the food you drop in it. Heat is transferred from the water to the food in contact with it. This is the most basic of physics; I think we covered all this in the first year of high school. You can test it by putting your hand into a pan of boiling water; you'll find it educational and instructive. Or, to be more on topic, put a bowl of water into your microwave, turn the microwave on until the water boils, and then take it out and stick your hand into the boiling water. That's how collisions transfer heat.
Different materials have different absorption spectra, and will be excited optimally at different wavelengths. So for different applications you'll use a product with an optimal emission wavelength for that application. Industrial equipment is designed with specific applications in mind. I doubt that an industrial sealer is particularly good at cooking food, nor that a domestic microwave is as good for sealing, though it's likely you could use them both for inappropriate tasks but with greatly reduced efficiency. A primary constituent of most food is water, which is why that's the primary consideration for a domestic microwave design. (And food which isn't mostly water doesn't microwave well, which is why you get e.g. microwaveable pizza and pies where the dough/pastry base is deliberately bulked out with water to ensure it heats. And is also why the taste and texture is generally crap!) Microwaves can indeed heat by several different mechanisms, but for foodstuffs, it's primarily via induced rotation due to O-H dipoles. The other mechanisms are insignificant.
In terms of bulk heating, you're correct and the effects are completely harmless. And some cell types are used to natural heating and cooling, and have mechanisms to cope with that. But that's also a very simplistic way of looking at things. Consider for a moment about what's happening at smaller scales, both temporal and physical. That is to say transient heating of minute volumes. That could be sufficient to denature a small collection of molecules, and that could be enough to mess up critical cellular processes if it happens in the wrong place at the wrong time. Low probability, certainly. But could it cause problems, yes, when looked at over a long period. Does this happen in practice? That's a much more difficult question to answer. Is even thinking about such details and asking that sort of question wrong? No.
Nice to see my post marked as a "Troll"; good to see my PhD in cell biology and time spent looking at cell signalling pathways for a pharma company are valued by the slashdot collective. Seriously now, did anything I wrote above contradict the article? No. I merely posed some questions and thoughts regarding the details. Your response was unnecessarily flippant. Are you *absolutely sure* you're correct here, and you've considered every factor? We simply can't be that sure. Science, and biology in particular, isn't about absolutes and certainty of that nature.
Water: H-O-H contains two O-H dipoles Ethanol: CH3-CH-O-H contains one O-H dipole
Both molecules will be subject to heating by microwaves. It's not "horseshit", it's fairly basic chemistry. As for changing the frequency, yes it would have an effect since the frequency is related to rotation speed; it would have reduced efficiency.
Slashdot Mirror
There's a difference between "hating change" and being uninterested in over-hyped junk with no practical relevance. And yes, I've been to a demo of the HoloLens and seen it in real life. It was crap and even the rabid fanatic doing the demo couldn't make it work properly during his demo. That's Microsoft software again! Make one that actually works well, as well as actually solving problems I have, and I might start to get interested. But right now, it's nothing more than a toy trying desperately to provide solutions to problems which people don't have. It lacks purpose, in addition to being a mediocre implementation of the concept. Having been reading slashdot for nearly 20 years now, I think it's certainly fair to say I've become less susceptible to hype. Lots of stuff has been hyped over the years and come to nothing. Most of it was crap. I don't hate change, I just don't have interest in over-hyped useless crap anymore. Let it establish itself, and then I might get interested if there's worth in it. I'll leave the rabid fanaticism to others.
Yep, went to a talk/demo three weeks back. Looked interesting and promising, but in reality I was completely underwhelmed. Didn't help that the speaker was a rabid Microsoft fanatic and spent most of the talk going on about how awesome Microsoft were rather than talking about the technology, but the technology itself is nothing particularly special. And most of the usage scenarios and games they had for it were contrived and useless. They also chose to go with an Intel Atom processor in the unit rather than a less power hungry ARM. I really don't need a hot CPU plastered onto my forehead. The power consumption was so bad the guy had a big USB battery pack in the back of his pants! The overall idea does have some merit. The implementation is respectable but frighteningly expensive and not that impressive overall. I don't think the HoloLens will take off, but the concept might once it is refined somewhat. Given that you can almost do what it does today with a mobile phone in a harness and a front-facing camera, I suspect that other manufacturers will be able to make a better product for a fraction of the price.
Actually, they didn't get over it, at least in some cases. I can't play a lot of the early 3D games. They make me want to vomit and induce violent headaches with only a few tens of minutes of use. Most newer games don't. And I think it's largely due to differences in the FOV and camera positioning. The original Star Wars: Jedi Knight/Dark Forces were almost unplayable for me, as were a lot of others in this era. I stuck them out and suffered, but only in small doses. JKII/III, Mass Effect, and post recent/current games are totally OK (but not all). A lot of this might be down to my eyes and physiology, but it's also absolutely the case that the individual games are prone to causing this, and those old games were especially bad for it (for me, and I suspect others).
You've posted this exact text to other stories. Please stop. The content is garbage. Code compiled with GCC is not forced to be GPL and never has been. Your compiled code retains your licence. Changes you make to the Linux kernel would be required to be GPL if you distribute them, the GPL being a *distribution* licence, but are required to be given to people you *distribute* the changes to only, not the whole world. If this is for real, and not just a lame troll, you got lousy advice from your "lawyers".
In all seriousness, while Unicode is intended to be universal, I don't think that bullshit emojis have a place in it. We have markup in addition to characters, not to mention SVG and other formats which can better represent them. They don't have to be in the Unicode standard.
Nothing special. It was a fresh clean install in both cases. It's even a problem without the NFS home which has older crufty bits in the config. I've seen it on both my work machine and home machine, with Intel Iris and Radeon R9 390 graphics, respectively. The NFS problems are due to the KDE programs and libraries liking to log verbosely to stderr which gets logged to the homedir. While it's not as noticeable with local discs, it becomes a significant problem with freezes lasting up to a minute with NFS. This is a major usability problem. There's really no need to log this useless junk--this has been a problem since KDE4.
For me kwin crashes for no reason very regularly (10 mins on average); back to i3 for me since Ubuntu 15.10; 16.04 is no better. It also completely sucks when using an NFS home. Every mouse click seems to want to write some pointless logs or state back to my homedir, freezing everything up. I don't have that problem with i3: it just manages windows and doesn't do lots of unnecessary I/O. Still pining for the pinnacle of usability and stability which was KDE3.
Most people inside Britain don't find him funny either! I've never been a particular fan, and I don't know of anyone who is. I can only imagine he's connected with the BBC management, and is suitably PC. I doubt Rowan Atkinson would have the needed personality either. He's not a presenter, he's an actor, and is known for acting roles rather than being himself. One major change with this new series is that they hired actors rather than car nuts who can talk well. The old trio might have scripted parts of their show, but their banter came across as quite natural, and they all knew their stuff even if they didn't focus on it too much. They weren't acting, they were doing stuff with their mates, while being filmed doing it. I think LeBlanc could grow into that, and it would help if he had some more compatible personalities which complemented each other. Evans definitely wasn't that person! And regarding the "non-PC" attitudes of the old presenters, mentioned elsewhere in the comments. People watch Clarkson because he's an opinionated arsehole, or rather an entertaining and funny opinionated arsehole. It wasn't the sanitised and bland product which is the rest of the BBC's output, and his views likely resonate more with people than they care to imagine. Hell, I have plenty of friends in India and other countries who think Top Gear is the best thing on TV and absolutely *love* Clarkson. This is another demographic the BBC would like to pretend doesn't exist (they should be outraged by his non-PC opinions!), and while they all think he's an arsehole (as do we all), outraged they are not.
You could already do this with SFINAE!
Regarding the "performance penalty", it's generally going to be positive and improve performance. We are talking lz4 here, not gzip/bzip2/xz. It's fast, trading a lower compression ratio for performance. It can compress and decompress blocks in parallel. It can do this much faster than it can read data from disk, so you'll actually improve read and write speeds. And this is on top of ZFS being able to pull data of multiple spindles as the data is distributed over multiple zvols, with redundant copies of data, etc. It's likely not the penalty you think it is. It does multiple rounds of lightweight lz4 compression to reduce the entropy, and it bails out early if poorly compressible.
% zfs get refcompressratio red/home/rleigh system/usr/ports system/usr/src system/var/log system/var/mail
NAME PROPERTY VALUE SOURCE
red/home/rleigh refcompressratio 1.33x -
system/usr/ports refcompressratio 1.60x -
system/usr/src refcompressratio 2.16x -
system/var/log refcompressratio 6.54x -
system/var/mail refcompressratio 4.99x -
With compression like this, you no longer need to bother compressing rotated logs. And while the homedir compression is small in comparison, it's gained me an extra 100GiB just for this single dataset, which is not to be sneezed at.
% uname -srm /boot -name '*zfs*'
/boot/zfs
/boot/zfsloader
/boot/zfsboot
/boot/gptzfsboot
/boot/kernel/zfs.ko
/boot/kernel/zfs.ko.symbols
/usr/src/ -name '*zfs*' | wc -l
FreeBSD 10.3-RELEASE-p4 amd64
% find
% find
120
As jedidiah stated, by putting it in the filesystem it's completely transparent. No program reading or writing needs to care; it just works. To add to that, it's not "one size fits all". With ZFS, you can tune it on a per-dataset basis. Here's a (shortened) sample from my NAS. Whitespace stripping due to slashdot, not me.
% zfs get compression
NAME PROPERTY VALUE SOURCE
red compression off default
red/data compression lz4 local
red/data@20150615 compression - -
red/data@20150724 compression - -
red/home compression lz4 local
red/home/rleigh compression lz4 inherited from red/home
red/home/rleigh@20150616 compression - -
red/home/rleigh@20150724 compression - -
As you can see here, lz4 compression is enabled on some datasets, but the default at the root of the pool is off. You aren't limited to lz4, there are other compression options. And in reality, it's much more granular than the dataset level--this is just the default for new files being created in the dataset.
It doesn't assume that. It's not compressing the whole file as a linear stream like it would with gzip or similar; it's chunked by compressing per-block with repeated rounds of lz4 (or whatever algorithm you picked). It will seek to the start of the first chunk containing the start offset you requested, and start decompressing from there. It works just fine and is completely transparent, including memory mapping and everything. It'll likely retain the whole uncompressed block in the ARC until you write it back or discard it.
I would hope it has a fast monorail system. All the lairs of evil supervillains should have one.
Depends upon the context. If it's a noun, then "better than" is correct since it's a comparison with another object; if it's a verb, then "better to", e.g. "better to x y z". There's no difference between British and American English here which I'm aware of.
You can with NAT64/DNS64. This is used where a purely IPv6 network needs to access the old IPv4 network. My ISP even offers it as a service to those wanting to go v6 only (I haven't tried it though, I'm happy dual stacked for now).
https://www.google.com/intl/en...
The growth curve is clearly showing exponential growth here, and we're now well into the rapid adoption phase. Yes, the absolute value is 11% (now 12). but it will continue to grow with increasing speed. It *is* coming. It took a while, but it's a juggernaught which can't be stopped now. We'll all be using it in a couple of years at this rate. All the major ISPs have committed to do this, and network effects will drag the rest along in time.
I've been on native v6 for three years now.
You have been extraordinarily lucky. No horrible dataloss. And you haven't hit the unblancing issues which make the filesystem read-only after an indeterminate period? Or are you doing a regular rebalance with associated performance loss and hoping for the best?
No. Because it doesn't violate it. And being a monolithic blob is the least of the criticisms which we could make about systemd, when there's an entire book's worth of bad design in there. ZFS was designed by competent and expert professionals, rather than unprofessional prima donnas, and it shows.
It's a fundamentally different design to traditional UNIX filesystems and disk management, but that doesn't automatically make it a monolithic blob. Is Linux LVM a monolithic blob? That's the level your question is at, as well as being flamebait.
Internally, ZFS is layered similarly to a Linux raid/lvm/filesystem setup. Here, you would have raw block devices managed by hardware or software RAID, with LVM using these devices as physical volumes. It would then provide logical volumes upon which you could create filesystems.
With ZFS, you would have block devices aggregated into "vdevs", which would be the equivalent of RAID0/1/5/6 RAID sets. These are the equivalent of LVM physical volumes. Next, you would use one or more vdevs to create a "zpool", which would be the equivalent of an LVM volume group. Finally, you would create datasets in the pool, which are the equivalent of a logical volume plus a filesystem, or a zvol which is the equivalent of a logical volume--a raw block device. So it's cleanly and logically layered. It's using plain block devices as the backing store as for any UNIX filesystem, but it's not creating intermediate block devices as LVM does--it's managing that internally.
The layering is pretty much the same--it's a well separated design. What's different is that ZFS has knowledge of all the layers and can use that to do things much more efficiently and much more robustly. For example, when doing a RAID rebuild ("resilver") it only needs to resync bits of the disk that actually have data on which can dramatically reduce the statistical likelihood of encountering an unrecoverable error. A dumb RAID setup doesn't know that, and will fail if it encounters an error during a full rebuild; ZFS will succeed if those errors were in areas weren't in use. And it can also be instructed to keep more than one copy of data for important stuff, which gives it an even higher chance of rebuilding in the face of corruption. There are a whole pile of other benefits as well, but as an admin the main benefit is that it's a dream to manage on a day to day basis, and you can even delegate management of sub-datasets to other users and groups, so they can snapshot their own data at will, send and recv data, create new datasets etc. The design is clean, well thought out and brings features which are completely missing from anything else.
Simply because it's a *killer feature*. It does things which no native Linux filesystem can offer, even when coupled with LVM and RAID. It takes all of these and replaces them with something that's simply better, more robust and easier to manage. And which is also properly documented with a good number of tutorials and best practices documented clearly.
I'm one of the people who migrated to FreeBSD pretty much because of ZFS, initially for a NAS but now also on other systems. Not the only consideration, but it was the primary one. I used Linux-ZFS to initially use ZFS on Linux and migrate the data from LVM/ext4, but later transferred the disks to the NAS. A simple "zpool import" was all that was required to do so; few filesystems have that level of cross-platform interoperability (ignoring awful ones like FAT). Everything was already mounted in the right places as well!
Linux does not offer anything comparable, so if you want those features then switching operating systems to one which offers them natively makes sense. I'm going to have a play with Ubuntu 16.04 on ZFS in the next few weeks, and might well end up using it, but it's still less mature and well integrated so I doubt it will replace ZFS on FreeBSD for me anytime soon, but might supplement it--I'll at least be able to "zfs send" backups to the FreeBSD ZFS server.
Extensible at *which level*?
If you're thinking in terms of filesystem size, and since you mention ext4 this appears to be the case, then this is a complete non-issue. ZFS *datasets* are the equivalent of filesystems, and these can grow and shrink freely; the only limit would be an optional maximum size you set on it, i.e. a quota. Otherwise it use whatever free space is available in the pool. This would be equivalent to growing and shrinking an LVM LV, but without any of the manual effort--to do the equivalent of adding or removing space, you simply adjust the quota. Dead simple, and totally safe; the same can not be said about shrinking--adjusting all the fs structures and then chopping the end off the block device with an LV resize is actually quite risky and dangerous in comparison--a mistake could trash all your data.
The other level would be the pool itself. This can be grown by addition of zvols (disk RAID sets, typically). You can't shrink the pool, that's really the only limitation. And it's not a particularly big problem, since the need to do this is rare in a production system. When all your data is in ZFS datasets, you don't fiddle with the system at this level--we're not doing manual partitioning or messing around with LV resizing any more. But that level no longer matters; all your data is simply contained in the pool, and managed in datasets, snapshots, as you see fit.
The kinetic energy of molecules *is* heat (vibration, rotation, motion), absolute zero being the point at which no motion occurs. It's transferred by conduction (as the water collides with other water molecules, and other molecules in the food, such as sugars, proteins, fats, etc.). You'll also have some convection and radiation but these aren't of great significance. The energy transfer is no different than what happens in a pan of boiling water to the food you drop in it. Heat is transferred from the water to the food in contact with it. This is the most basic of physics; I think we covered all this in the first year of high school. You can test it by putting your hand into a pan of boiling water; you'll find it educational and instructive. Or, to be more on topic, put a bowl of water into your microwave, turn the microwave on until the water boils, and then take it out and stick your hand into the boiling water. That's how collisions transfer heat.
Your links are all broken.
Different materials have different absorption spectra, and will be excited optimally at different wavelengths. So for different applications you'll use a product with an optimal emission wavelength for that application. Industrial equipment is designed with specific applications in mind. I doubt that an industrial sealer is particularly good at cooking food, nor that a domestic microwave is as good for sealing, though it's likely you could use them both for inappropriate tasks but with greatly reduced efficiency. A primary constituent of most food is water, which is why that's the primary consideration for a domestic microwave design. (And food which isn't mostly water doesn't microwave well, which is why you get e.g. microwaveable pizza and pies where the dough/pastry base is deliberately bulked out with water to ensure it heats. And is also why the taste and texture is generally crap!) Microwaves can indeed heat by several different mechanisms, but for foodstuffs, it's primarily via induced rotation due to O-H dipoles. The other mechanisms are insignificant.
In terms of bulk heating, you're correct and the effects are completely harmless. And some cell types are used to natural heating and cooling, and have mechanisms to cope with that. But that's also a very simplistic way of looking at things. Consider for a moment about what's happening at smaller scales, both temporal and physical. That is to say transient heating of minute volumes. That could be sufficient to denature a small collection of molecules, and that could be enough to mess up critical cellular processes if it happens in the wrong place at the wrong time. Low probability, certainly. But could it cause problems, yes, when looked at over a long period. Does this happen in practice? That's a much more difficult question to answer. Is even thinking about such details and asking that sort of question wrong? No.
Nice to see my post marked as a "Troll"; good to see my PhD in cell biology and time spent looking at cell signalling pathways for a pharma company are valued by the slashdot collective. Seriously now, did anything I wrote above contradict the article? No. I merely posed some questions and thoughts regarding the details. Your response was unnecessarily flippant. Are you *absolutely sure* you're correct here, and you've considered every factor? We simply can't be that sure. Science, and biology in particular, isn't about absolutes and certainty of that nature.
Water: H-O-H contains two O-H dipoles
Ethanol: CH3-CH-O-H contains one O-H dipole
Both molecules will be subject to heating by microwaves. It's not "horseshit", it's fairly basic chemistry. As for changing the frequency, yes it would have an effect since the frequency is related to rotation speed; it would have reduced efficiency.