Should be no problem, I've done this a few times when copying data from one box to the other and couldn't be bothered to move the drives between cases.
Those server cases you use are very very nice, but a bit pricey for me. I prefer to just buy cases with ridiculous amounts of 5,25" bays, like Coolermaster Stacker, much cheaper and with the 4-to-3 bays (with 12 cm fans) can hold 12 drives easily while keeping noise levels down and keeping the drives cool as well despite being packed so close together. I'm hoping hard disk capacity goes up fast enough to meet my storage demands so I won't need a second case:-)
I used to think like that... but my storage server already contains 10 disks (6 PATA's and 4 SATA drives at moment). I'll wait until the price comes down a bit further, then replace some of my smallish 300 GB drives for 1 TB ones.
I seriously doubt we will be needing much from the US in 20 years from now. The US is rapidly making itself irrelevant, not to mention the laughing stock of the world. Here in Europe, we snicker at your stupid patent laws, your incredibly corrupt political system which borders on a theocracy, your gas guzzling cars and RIAA's jihad on their own citizens. I could go on about the lack of gun control, your disrespect for the environment, your unprovoked actions in Irak and general disrespect for other forms of government and human rights. Pretty soon all the US will have left to export is natural resources (food stuffs), entertainment (which we'll just copy), lots of posturing (which we'll just ignore) and law school graduates (which we won't be needing).
IMHO firewalling should never be application controlled. What's the point of a firewall when random program X can just poke a hole into it? When I see BitTorrent asking to listen on a port, then I will give it permission via a 3rd party program I trust (my firewall). If I say "NO", then there is no recourse for that program, it simply won't get access, period. I should be in control, so if I want to have a program working optimally, I can weigh the risks of having the application being accessible from the outside world
You wouldn't believe the amount of applications these days that phone home, literally every major application tries to access the internet periodically (be it to check for updates, check if your registration is valid, or to send over all your personal surfing habits and credit card info). Adobe PDF Reader is good example. I open a PDF, and the program wants to access the internet... what for? To annoy me with updates I don't need (if it ain't broken, don't fix it)? I don't think so.
I always thought that IPv6 is over the top and I also questioned the sanity of having every little device in my home directly addressable from the (hostile) outside world. Going from 32 bit addresses straight to 128 bit addresses (which increases packet overhead immensely) never sounded like a very good idea to me, let alone the fact that 128 bit addresses are incredibly cumbersome to deal with and agreed by almost everyone to be a ridiculously huge jump (more addresses than atoms in the universe or something like that?)
Perhaps I'm just a bit too conscious about these kind of things, but I think that for a lot of realtime applications protocol overhead must be kept to an absolute minimum.
I don't think I will ever trust any other appliance than my firewall to be directly accessible by anyone from anywhere. For me the point is moot, there will be NAT in my home simply because I see no reason to expose myself to potential problems. If I need to access my refrigator, I can get around my own firewall in various ways that require decent authentication.
Well I'm not sure what the Kernel developers are thinking, but I think they feel you shouldn't by-pass layers of communication, ever, and I think they're right.
So you shouldn't write a disk-optimizer program that fiddles (from user space) with the layout of a file system (definitely not while it is online) -- it's kind of pointless as such a program would be specific to a single file system and would not work on any other types.
Instead, in the file system API, functions should be defined to query file system layout, and to give instructions as to how to alter the layout. The file system itself can then perform these actions (or just ignore them if they're too lazy to implement that part of the API). When they do, they can even perform journalling on the actions so there's not even risk of losing any data while the disk is being restructured.
The advantages are numerous; a complex program to optimize disk layout would work with any file system implementing the disk layout API -- no need to write another one for a different system. They don't even need to be affiliated with the file system designers (or even have knowledge of the file system, although some general knowledge of file system will help their program:-)). Furthermore it would be more consistent for the end-user, no more seperate tools for resizing different filesystems, different optimizing tools, and so on. So I guess that instead of trying to cut accross layers, we should be asking the Kernel developers to extend the layer user space programs are supposed to use so we can do fancy tricks with file systems in userspace.
Then make an interface for it. Take file system defragmentation for example.
An external tool, with knowledge of the file system layout can only safely defragment a file system (without cooperation of the file system) when it is offline. However, the file system itself can defragment itself even when it is online and being intensively used because it can update certain cached block pointers in internal structure as it moves stuff around making it totally transparent to the user.
If an interface was defined whereby an external program can ask the filesystem for free areas of space, and ask it certain other details like offset/length pairs for a specific file so it can see the layout of the file on disk, then it can calculate somekind of optimal layout, and give the filesystem instructions to move blocks from one location to another (completely safe and wrapped with journalling code). With enough thought, such an interface could be universal for almost every file system, and the defragmentation tool would then be functional for all file systems implementing this interface. My own filesystem (http://en.wikipedia.org/wiki/Smart_File_System) incorporated a journalled online defragmenter which could be triggered and monitored externally, and I was planning on exporting the internal functions it uses somehow so someone else could write a defragmenter which did a better job than my own straight-forward implementation:-)
ZFS to me sounds like a file system that just tries to do it all on its own without really looking at the bigger picture and benefits of layering things like RAID and Volume Management. Sure it can happen that you want to have a certain actions cut accross layers (volume resizing is a good one, which has to be done seperately for the file system and the volume in the right order with LVM2) but I think for those actions you'd be better off extending the interface you use to communicate with the layer above or below you so such actions become part of the standard way of communication -- for example, if Linux file systems had a universal interface for telling a file system to resize itself, then LVM2 could take those actions automatically when you resize volumes. It's tempting to build all this stuff directly into the filesystem, but layering the system makes it far easier to maintain, less bug-prone AND can make things more consistent for end-users that don't have to deal with a different system for each filesystem. ZFS likely rolled their own though because at the time the tools we have now weren't as mature and the need to support volumes across networks and other specialized needs that filesystems don't normally deal with.
Welcome to the new world then, where the AACS can sue ANY IPv6 address and claim that it just so happens to be their "secret number" and you must Cease & Desist immediately. Of course they won't have to proof that or anything, you just have take their word for it.
I use numbers a lot, to avoid getting sued, I now ask the AACS permission for every number I use. It's cumbersome, but hell I don't want to get sued. I wonder what a lifetime license for the first 10 billion numbers is gonna cost me.
That's assuming all hardware will start incorporating such protection schemes, which is extremely unlikely. What you fail to realize is that unless there is some law against (in their country) manufacturers can do whatever they please. Do you think for example that all other computer hardware will disappear when Microsoft forces Windows to only run on Trusted hardware? Not by a long shot, the market for unburdened hardware (for running Linux for example) will be large enough to make a profit of (and quite a big one if all other vendors are so stupid to pull out of it).
Perhaps you can mandate such draconian restrictions in the US, but I highly doubt that every hardware vendor will artificially restrict their products because of some law in some foreign country (DMCA) which was lobbied for by for-profit organizations in some foreign country (RIAA/MPAA). Producing unrestricted hardware will likely prove to be quite profitable since consumers, although stupid at first, won't often make the same mistake twice. Sure, maybe Sony camera's will come with restrictions, but I'm sure some other company with no vested interest in media will be happy to produce one that has none.
I still have nightmares from the last application I had to make "secure" because the original designers didn't know the first thing about security; I can just imagine now how bad it could get when you apply this to entire OS that is only now adding security as an after thought.
What does file size have to do with wasted space? Only the amount of files has any bearing on it (for most filesystems), as the wasted space on average is #_Of_Files * Block_Size / 2. So on of my 300 GB drives which holds around 300.000 files, with 4k blocks that is a waste of about 0.6 GB. Not that I care about it, but filesize has little to do with it (1000 files of 4096 + 1 bytes are just as wasteful as 1000 files of 1 byte).
Filesystems that pack multiple tails of files together in a single block nicely reduce this waste, but its only really useful on drives with lots and lots of small files, which is something that is less and less used (news and mail were notorious for using lots of tiny files, but most solutions these days either store multiple messages in a larger file or use some kind of database for storage).
I also wouldn't be so sure that having larger blocks when paging uses smaller blocks is only a small loss. It still means that writing a 4 kB page (to a 16 kB disk block) involves a read where before it involved no reads at all. For most harddrives that means an extra rotation or two of the media before you can move on to something else.
Anyway, what's really interesting is something I found out years ago; hard drives take almost no penalty for reading blocks of data of 16 kB (and the modern ones can go to 128+ kB easily) as opposed to reading just 512 bytes when doing random accesses to the drive. The problem with using such large blocks (in memory for paging, or just for caching) is that memory efficiency goes down significantly when (often) only part of that block of 16 (or 128) kB is actually relevant (for caching a frequently used small file, or for paging back an idle loop of an idle application running in the background). It is far more efficient with smaller blocksizes because less memory is wasted on stuff that just happens to be loaded because of its proximity to the actual data you really need.
And that's where Java really shines. It has gone out of its way to design API's that are suitable for cross platform use; sometimes those have their limitations when you really need to do something specific on a platform, but in 99% of the cases they are more than sufficient to get the job done (and getting better all the time -- take a look at Swing's FileSystemView class for example, which is very nice:))
With.NET you are tempted frequently to use calls to DLL's directly, instantly tying your code to a single platform; their API's are full of Windows specific tidbits and are generally inferior to what is available (standard or distributed under a free license) for Java. I should know, as my employer specifically hired me to convert their existing C# product to Java so they can reach some of their larger potential customers.
What's funny is that a lot of people don't realize WHY there aren't any good integrated development environments for languages like PHP, Python and Ruby. Java for example has Eclipse, which does things with refactoring that most people don't even believe are possible these days. The reason however that the IDE's for Java can do this kind of stuff (and get away with it, by creating code that does the same as before with hardly any side-effects) is because for a large part Java was designed that way. It is designed so it can be extensively analyzed at compile time. Types are resolved at compile time. Which (overloaded) method is called is already known at compile time determine by the STATIC (not runtime) types of its parameters. No magic happens during runtime.
Fancy languages like PHP, Python and Ruby with lots of 'convenient' features, like resolving their types at runtime, make it impossible for IDE's to do extensive refactoring without running the risk of introducing major side effects or simply breaking the code completely. For example, in Java (with full source code available) I can determine at compile time which (public) methods could possibly be called (apart from reflection use), even if the method is overloaded it is possible to statically determine which one could possibly be called and which one can't.
Same goes for the declaring and strict typing of fields and variables. Because this information is known at compile time, IDE's can make use of that knowledge to refactor code, but also to make suggestions and provide other helpful features. You'll never have an IDE that comes even close to what's available for Java for languages that resolve so much of their internal state at runtime.
Read up on arithmic encoding. Basically it works by creating a huge floating point number. For example, let's say you want to encode a stream like this: "ABBBBABBBB". Statistically, A has a 20% chance of occuring, while B has a 80% chance of occuring. With Huffman you could encode this (obviously) as 0111101111, which takes 10 bits. Huffman encoding being limited to bits has no way to take advantage of the fact that the "B" occurs 80% more often than the "A".
With Arithmic encoding however you'd encode each character according to the exact probability it has of occuring and write it as a fractional number between 0 and 1. For example, if you want to encode an "A", you'd pick a number between 0.0 and 0.2 (the lower 20% of our number); if you want to encode a "B", you'd use a number between 0.2 and 1.0 (the upper 80% of our number).
What you keep track of during encoding is the upper and lower bound of this number. So, when I want to encode the first "A", my lower bound is 0.0 and the upper bound is 0.2. The next character to encode is "B". We already now the range we can pick from is 0.0 - 0.2, but to encode a "B" we need to pick a number in the upper 80% of this range, so 0.04 to 0.20 (picking a number between 0.0 and 0.04 would encode another "A").
The next letter, another "B", would use a range 0.072 - 0.200. The 3rd "B" would narrow the range to 0.0976-0.2000. The 4th "B" narrows it to 0.11808 - 0.2000.
At some point, the upper and lower bound will have a few most significant digits in common that cannot change anymore. When this occurs, you can start writing these out as part of your compressed stream. For example, when we encode the 6th character (the 2nd "A"), the range becomes 0.118080 - 0.134464. The first two digits (0.1) can't change anymore now, so we can write them out, and just continue narrowing the range further for subsequent data to be compressed.
At some point, there'll be no more data to be compressed, and you then just pick a number (as convenient as possible) between the upper and lower bound you have established, write it out and end the stream. The process is the same when doing this with binary floating point numbers.
Yeah, operating systems have been doing that for probably 30 years now, including Windows versions before Vista. What matters is the size of the memory footprint. On Vista it is considerably larger for the base operating system, which in turn means it will run out of memory faster and will have to start using swap faster. It also means you will start having trouble with apps becoming slow when you switch back to them faster than on a system with a smaller memory footprint.
It doesn't help either that 2k/XP/Vista have a brain-dead disk caching system that will actually push programs to swap to make more room for disk caching, even when the disk cache is already using like 80% of all your memory. This is why I just turn of swap. Given sufficient memory (which is not too hard these days) I can run everything I want, and literally never have to wait for an app to be loaded back from swap, not even when I come back to machine after a few days.
The preparing to delete part is for windows to first scan everything you are going to delete, so it can display a proper progress bar... if it didn't do that you wouldn't know how long the delete operation is gonna take (which was I think the behaviour in Win 3.11 or Win95).
So it comes to, do you prefer getting the delete done as fast as possible, but with no indication of how long it will take, or do you prefer to first gather some info, so you can then see how long it is going to take for the actual delete part...
Of course, Microsoft being Microsoft treats all users as completely stupid and backwards, and instead of telling the user what it is ACTUALLY doing, it tells you stuff like "preparing to delete"...
They can't be serious... I use keyboards which cost me $5, costly? My ass. These keyboards will last for years, and basically I dispose of them when I cannot be bothered to clean them anymore. I don't buy into the wireless crap, or the crap keyboards with 15 extra buttons and an integrated calculator I don't need.
Furthermore, this system has the same problems as voice-input -- it can do silly things if other stuff is going in the room. It doesn't seem to allow for you to "move" the keyboard (as it then wouldn't know anymore which key you are pressing). There's no feedback from the keys... and best of all: how does it know I'm holding down a key? Sure, tapping makes noise, but lifting my finger doesn't.
I also find it highly amusing this "technology" is patented, and yet again, there's no working prototype.
Slashdot Mirror
Ah, so just encrypt stuff 300 times with a random 1024-bit number :)
I assume you mean 200 DVD's -- the exact reason why I just use hard drives for backup :)
Those server cases you use are very very nice, but a bit pricey for me. I prefer to just buy cases with ridiculous amounts of 5,25" bays, like Coolermaster Stacker, much cheaper and with the 4-to-3 bays (with 12 cm fans) can hold 12 drives easily while keeping noise levels down and keeping the drives cool as well despite being packed so close together. I'm hoping hard disk capacity goes up fast enough to meet my storage demands so I won't need a second case :-)
I used to think like that... but my storage server already contains 10 disks (6 PATA's and 4 SATA drives at moment). I'll wait until the price comes down a bit further, then replace some of my smallish 300 GB drives for 1 TB ones.
I seriously doubt we will be needing much from the US in 20 years from now. The US is rapidly making itself irrelevant, not to mention the laughing stock of the world. Here in Europe, we snicker at your stupid patent laws, your incredibly corrupt political system which borders on a theocracy, your gas guzzling cars and RIAA's jihad on their own citizens. I could go on about the lack of gun control, your disrespect for the environment, your unprovoked actions in Irak and general disrespect for other forms of government and human rights. Pretty soon all the US will have left to export is natural resources (food stuffs), entertainment (which we'll just copy), lots of posturing (which we'll just ignore) and law school graduates (which we won't be needing).
You wouldn't believe the amount of applications these days that phone home, literally every major application tries to access the internet periodically (be it to check for updates, check if your registration is valid, or to send over all your personal surfing habits and credit card info). Adobe PDF Reader is good example. I open a PDF, and the program wants to access the internet... what for? To annoy me with updates I don't need (if it ain't broken, don't fix it)? I don't think so.
Perhaps I'm just a bit too conscious about these kind of things, but I think that for a lot of realtime applications protocol overhead must be kept to an absolute minimum.
I don't think I will ever trust any other appliance than my firewall to be directly accessible by anyone from anywhere. For me the point is moot, there will be NAT in my home simply because I see no reason to expose myself to potential problems. If I need to access my refrigator, I can get around my own firewall in various ways that require decent authentication.
So you shouldn't write a disk-optimizer program that fiddles (from user space) with the layout of a file system (definitely not while it is online) -- it's kind of pointless as such a program would be specific to a single file system and would not work on any other types.
Instead, in the file system API, functions should be defined to query file system layout, and to give instructions as to how to alter the layout. The file system itself can then perform these actions (or just ignore them if they're too lazy to implement that part of the API). When they do, they can even perform journalling on the actions so there's not even risk of losing any data while the disk is being restructured.
The advantages are numerous; a complex program to optimize disk layout would work with any file system implementing the disk layout API -- no need to write another one for a different system. They don't even need to be affiliated with the file system designers (or even have knowledge of the file system, although some general knowledge of file system will help their program :-)). Furthermore it would be more consistent for the end-user, no more seperate tools for resizing different filesystems, different optimizing tools, and so on. So I guess that instead of trying to cut accross layers, we should be asking the Kernel developers to extend the layer user space programs are supposed to use so we can do fancy tricks with file systems in userspace.
An external tool, with knowledge of the file system layout can only safely defragment a file system (without cooperation of the file system) when it is offline. However, the file system itself can defragment itself even when it is online and being intensively used because it can update certain cached block pointers in internal structure as it moves stuff around making it totally transparent to the user.
If an interface was defined whereby an external program can ask the filesystem for free areas of space, and ask it certain other details like offset/length pairs for a specific file so it can see the layout of the file on disk, then it can calculate somekind of optimal layout, and give the filesystem instructions to move blocks from one location to another (completely safe and wrapped with journalling code). With enough thought, such an interface could be universal for almost every file system, and the defragmentation tool would then be functional for all file systems implementing this interface. My own filesystem (http://en.wikipedia.org/wiki/Smart_File_System) incorporated a journalled online defragmenter which could be triggered and monitored externally, and I was planning on exporting the internal functions it uses somehow so someone else could write a defragmenter which did a better job than my own straight-forward implementation :-)
ZFS to me sounds like a file system that just tries to do it all on its own without really looking at the bigger picture and benefits of layering things like RAID and Volume Management. Sure it can happen that you want to have a certain actions cut accross layers (volume resizing is a good one, which has to be done seperately for the file system and the volume in the right order with LVM2) but I think for those actions you'd be better off extending the interface you use to communicate with the layer above or below you so such actions become part of the standard way of communication -- for example, if Linux file systems had a universal interface for telling a file system to resize itself, then LVM2 could take those actions automatically when you resize volumes. It's tempting to build all this stuff directly into the filesystem, but layering the system makes it far easier to maintain, less bug-prone AND can make things more consistent for end-users that don't have to deal with a different system for each filesystem. ZFS likely rolled their own though because at the time the tools we have now weren't as mature and the need to support volumes across networks and other specialized needs that filesystems don't normally deal with.
Welcome to the new world then, where the AACS can sue ANY IPv6 address and claim that it just so happens to be their "secret number" and you must Cease & Desist immediately. Of course they won't have to proof that or anything, you just have take their word for it.
I use numbers a lot, to avoid getting sued, I now ask the AACS permission for every number I use. It's cumbersome, but hell I don't want to get sued. I wonder what a lifetime license for the first 10 billion numbers is gonna cost me.
Sure, you have my permission to post my credit card number and its expiration date and the code on the back of the card. Feel free, really.
Perhaps you can mandate such draconian restrictions in the US, but I highly doubt that every hardware vendor will artificially restrict their products because of some law in some foreign country (DMCA) which was lobbied for by for-profit organizations in some foreign country (RIAA/MPAA). Producing unrestricted hardware will likely prove to be quite profitable since consumers, although stupid at first, won't often make the same mistake twice. Sure, maybe Sony camera's will come with restrictions, but I'm sure some other company with no vested interest in media will be happy to produce one that has none.
Yes, I can imagine the lawsuits now when that kind of thing happens, and it won't be in favor of the producer of the camera.
I still have nightmares from the last application I had to make "secure" because the original designers didn't know the first thing about security; I can just imagine now how bad it could get when you apply this to entire OS that is only now adding security as an after thought.
Filesystems that pack multiple tails of files together in a single block nicely reduce this waste, but its only really useful on drives with lots and lots of small files, which is something that is less and less used (news and mail were notorious for using lots of tiny files, but most solutions these days either store multiple messages in a larger file or use some kind of database for storage).
I also wouldn't be so sure that having larger blocks when paging uses smaller blocks is only a small loss. It still means that writing a 4 kB page (to a 16 kB disk block) involves a read where before it involved no reads at all. For most harddrives that means an extra rotation or two of the media before you can move on to something else.
Anyway, what's really interesting is something I found out years ago; hard drives take almost no penalty for reading blocks of data of 16 kB (and the modern ones can go to 128+ kB easily) as opposed to reading just 512 bytes when doing random accesses to the drive. The problem with using such large blocks (in memory for paging, or just for caching) is that memory efficiency goes down significantly when (often) only part of that block of 16 (or 128) kB is actually relevant (for caching a frequently used small file, or for paging back an idle loop of an idle application running in the background). It is far more efficient with smaller blocksizes because less memory is wasted on stuff that just happens to be loaded because of its proximity to the actual data you really need.
With .NET you are tempted frequently to use calls to DLL's directly, instantly tying your code to a single platform; their API's are full of Windows specific tidbits and are generally inferior to what is available (standard or distributed under a free license) for Java. I should know, as my employer specifically hired me to convert their existing C# product to Java so they can reach some of their larger potential customers.
Fancy languages like PHP, Python and Ruby with lots of 'convenient' features, like resolving their types at runtime, make it impossible for IDE's to do extensive refactoring without running the risk of introducing major side effects or simply breaking the code completely. For example, in Java (with full source code available) I can determine at compile time which (public) methods could possibly be called (apart from reflection use), even if the method is overloaded it is possible to statically determine which one could possibly be called and which one can't.
Same goes for the declaring and strict typing of fields and variables. Because this information is known at compile time, IDE's can make use of that knowledge to refactor code, but also to make suggestions and provide other helpful features. You'll never have an IDE that comes even close to what's available for Java for languages that resolve so much of their internal state at runtime.
With Arithmic encoding however you'd encode each character according to the exact probability it has of occuring and write it as a fractional number between 0 and 1. For example, if you want to encode an "A", you'd pick a number between 0.0 and 0.2 (the lower 20% of our number); if you want to encode a "B", you'd use a number between 0.2 and 1.0 (the upper 80% of our number).
What you keep track of during encoding is the upper and lower bound of this number. So, when I want to encode the first "A", my lower bound is 0.0 and the upper bound is 0.2. The next character to encode is "B". We already now the range we can pick from is 0.0 - 0.2, but to encode a "B" we need to pick a number in the upper 80% of this range, so 0.04 to 0.20 (picking a number between 0.0 and 0.04 would encode another "A").
The next letter, another "B", would use a range 0.072 - 0.200. The 3rd "B" would narrow the range to 0.0976-0.2000. The 4th "B" narrows it to 0.11808 - 0.2000.
At some point, the upper and lower bound will have a few most significant digits in common that cannot change anymore. When this occurs, you can start writing these out as part of your compressed stream. For example, when we encode the 6th character (the 2nd "A"), the range becomes 0.118080 - 0.134464. The first two digits (0.1) can't change anymore now, so we can write them out, and just continue narrowing the range further for subsequent data to be compressed.
At some point, there'll be no more data to be compressed, and you then just pick a number (as convenient as possible) between the upper and lower bound you have established, write it out and end the stream. The process is the same when doing this with binary floating point numbers.
It doesn't help either that 2k/XP/Vista have a brain-dead disk caching system that will actually push programs to swap to make more room for disk caching, even when the disk cache is already using like 80% of all your memory. This is why I just turn of swap. Given sufficient memory (which is not too hard these days) I can run everything I want, and literally never have to wait for an app to be loaded back from swap, not even when I come back to machine after a few days.
> man mount
Mount options for ext3
(....)
commit=nrsec
Sync all data and metadata every nrsec seconds. The default
value is 5 seconds. Zero means default.
So it comes to, do you prefer getting the delete done as fast as possible, but with no indication of how long it will take, or do you prefer to first gather some info, so you can then see how long it is going to take for the actual delete part...
Of course, Microsoft being Microsoft treats all users as completely stupid and backwards, and instead of telling the user what it is ACTUALLY doing, it tells you stuff like "preparing to delete"...
You use multiple wallets as well?
Furthermore, this system has the same problems as voice-input -- it can do silly things if other stuff is going in the room. It doesn't seem to allow for you to "move" the keyboard (as it then wouldn't know anymore which key you are pressing). There's no feedback from the keys... and best of all: how does it know I'm holding down a key? Sure, tapping makes noise, but lifting my finger doesn't.
I also find it highly amusing this "technology" is patented, and yet again, there's no working prototype.