Precisely. You need some physical media for the encryption key, unless you're doing this entirely unencrypted, a decidedly bad idea. The way I would do this is to stick a 802.11 card, permanently, in each tablet, and issue people a usbkey storage device (www.usbkeydrive.com, for instance... pricier ones available). You could either give this to each employee, or have them check them out the same way they would have checked out a pc card under your plan. These keys are bootable in most machines (the advantage over using a pc card hard drive, which may or may not be bootable depending on your hardware); what you want to do is put on each a small bootable OS, the information necessary to form your VPN or however you're dealing with security, and nothing else. (At this point, you'll wish you could use linux, as it will require a smaller key, and be cheaper. But you'll survive with windows). Of course, there are still problems with this; you're not truly remote booting, just using a read-only boot disk. But it may be sufficient.
The next step up in complexity, as well as power, is to again use a usbkey to boot, but boot into linux. Have it boot from the read-only keychain, use the (unique) information on each key to establish the connection, etc, and then start X-Windows and rdesktop (linux remote desktop client), connecting to a remote windows server. It would be quite easy to secure the tablet so that the linux distribution is secure, and again you have a unique key to secure the connection. From the users point of view, they're working on a local windows machine, although from your point of view they're remotely logged on to another box.
These are just the first two ideas that came to mind. As the parent said, though, you need some kind of local storage for encrypted booting. I highly recommend a usbkey from one brand or another, as they're relatively cheap, absurdly robust, and quite convenient. And once you're allowing even a bit of storage, make it a useful amount, and boot locally off a secured disk, rather than trying to get the hardware to do something it's not supposed to do. Remote booting, keep in mind, just uses some ROM code to boot the computer and then moves control elsewhere. I'm pretty sure you won't find a system ROM or an 802.11 ROM that does what you need; instead, you're going to have to attach a boot ROM of some kind, and a usb key is about as good as it gets.
Oh, one final point, to make this make sense. Most of the usb keys have a read-only switch that can be latched, which makes them appear as read-only mass storage devices to the OS. Once you write the key, you can physically remove the switch (I've done this to several usb keys) to make it quite inconvenient to write to them again. It is possible to write to them either by opening them up and reconnecting the switch, or by writing a custom driver which ignores that the device is read-only (it turns out that, even in read-only mode, the keys I've worked with do honor writes), but neither of these methods is very convenient. It depends just how much security you need.
Well, half that ($60) will get you an aluminum one.. which'll probably cost them $40 to make, so they'll actually make a profit. They say the titanium one costs more than $100 to make, and I really believe them... I've done a bit of titanium machining, and $150-$200 to manufacture that wouldn't surprise me. The aluminum one looks just as sexy as the titanium (both nickel-plated, I think), it's just not titanium and not a numbered edition.
more than 95 percent (by volume in gigabytes) of human-to-computer information input will remain keyboard- and mouse-based
Is this even true today? I doubt it's true of my own work. I own a digital camera. I don't take many pictures; I'm not very photogenic. I figure I take about 50 pictures a month... let's call that one a day, to be conservative. 1600x1200x8, uncompressed (I use a raw format that sends 8-bit intensity data for each pixel, as each pixel in a digital camera is only one color), comes out to very close to 2MB per image. In a given day, I also spend about 8 hours sitting in front of my computer. I type at ~60 words per minute (never said I was fast), coming out to about 160kB/day. Now, I don't use my mouse too much, since it hurts my wrist. But even if it sends 4-byte updates 300 times a second when I'm not moving it at all, that comes out to 35MB a day... hardly a realistic number, but let's run with it. So my total keyboard/mouse input is 36MB a day, at an absurd maximum (I do stop for breath occasionally), while my non-keyboard/mouse input is 2MB/day, at a rather absurd minimum. And just with those numbers, I have (slightly) less than 95% of input being keyboard/mouse based.
I know a lot of people who take more pictures than me. One person taking 10 pictures a day is enough to offset 9 people who take none. A few people use speech recognition... that's relative high-bandwidth input. And I'm sure at least one person in ten thousand has a digital video camera...
So, does anyone think this 95% number is true even today?
I think it would be a bad idea to rely on IDE drives as one's only source of backup. Especially if you aren't planning on using any stripping or parity.
How would stripping help reliability?
Okay, okay. How would striping help reliability, then?
Sun (or at least the people I've spoken to at Sun, who do represent their company) never said that generics weren't necessary. They said, with surprising honesty, that no one had yet come up with an implementation of generics that made sense for the virtual machine. The current implementation of java with generics has been available for around 18 months (externally for what, 12 months?), and has been a compromise implementation, giving a highly requested feature at some cost, perhaps, in the potential beauty of the implementation. The reason that generics weren't included with Java 1.0 is that no one could agree on how to do them; Sun has since realized that they won't be perfect, regardless, but that it's time to push them out the door. Probably, their publication of this stuff is prompted by C# (which uses, more or less, the same flawed-but-usable implementation). But I really do respect Sun's restraint in trying to make it as good as possible.
Compressing pi is not particularly hard. As posted elsewhere, one of the more convenient algorithms for pi is:
pi=sum as j goes from 0 to infinity of 1/16^j (4/(8j+1)-2/(8j+4)-1/(8j+5)-1/(8j+6))
So the data calculated compresses, quite readily, to a representation of the above algorithm (machine code, c code, lambda calc, your choice), plus the number of digits, the number of digits being necessary to restore the file to its original form. Of course, the number of bits needed to store the number of digits is logarithmic, so we get O(logn+c) bits to store n digits of pi.
Most compression algorithms wouldn't be able to do much with it. But most/good/ compression algorithms (with about five exceptions you should be able to think of off the top of your head) take advantage of the special form of the data they're compressing.
I'm a lisper, so I agree with you, but the one thing that xml does more gracefully than s-exprs is properties. {bold weight=200%}Text{/bold} (yes, I'm too lazy to use angle brackets) is simply nicer, in my opinion, than (bold:weight (percent 200) (text "Text")). Not a good enough reason to kill s-exprs, I think, but it is one part of the sgml heritage I occasionally envy.
Yes, I do. I would gladly go to Mars, under the understanding that I couldn't return, if there was about a 90% chance of surviving the first year, and some system in place (say, solar or thermal radioisotope power to melt some ice, split off some oxygen) which gave even a 10% chance of making it further. Yeah, chances are I'd end up dead... but even the chance would be worth it. NASA has demonstrated that progress can be made by being conservative and following reasonable saftey guidelines, but it just ain't as much fun, and it's slower! Not saying NASA's doing it wrong, they're not. But if I really had the option, yes, i'd volunteer. Wouldn't you?
Re:Please, Deep Blue is not AI, chess is a limited
on
Behind Deep Blue
·
· Score: 2
Actually wasn't trolling... just heard that many times, in analyses of the games. And yes, I play enough chess to know that playing white is good... but from a mathematical point of view, it's still *possible* (barring, again, some proof I haven't seen) that black has the winning path, just extremely unlikely based on our experience.
Re:Please, Deep Blue is not AI, chess is a limited
on
Behind Deep Blue
·
· Score: 2
Actually, there are only two possibilities.
- The game is a win for white. - The game is a draw or stalemate.
This is because white has the (rarely used) option to pass first move to black.
The problem is a number of transistor issues. 128 gigabits of memory takes 128 billion transistors, today. And if even one of those transistors is faulty, the whole chip is dead. Speed has nothing to do with it, if the chip is defective (not just unable to clock fast enough). Now, what should really be done is more work on using partially defective memory chips. Linux supports that today, but no other OS that I know of does; and even in Linux, it's not trivial, as you need to test your memory yourself, and map some of the memory as invalid. Now, it would be relatively possible to create a 128 gigabit memory chip (admittedly, a big chip) with maybe 1000 flaws... you can add a small rom to this chip saying which sectors (say, to the nearest kilobyte) are bad, so you could put it into a box and get 127.2 gigabits, without user intervention. Making chips this big is possible, but not easy, with relaxed timing constraints like you describe. It seems like maybe we should be using current DDR ram as L4 cache, and using massive sticks as main memory.
Slashdot Mirror
Precisely. You need some physical media for the encryption key, unless you're doing this entirely unencrypted, a decidedly bad idea. The way I would do this is to stick a 802.11 card, permanently, in each tablet, and issue people a usbkey storage device (www.usbkeydrive.com, for instance... pricier ones available). You could either give this to each employee, or have them check them out the same way they would have checked out a pc card under your plan. These keys are bootable in most machines (the advantage over using a pc card hard drive, which may or may not be bootable depending on your hardware); what you want to do is put on each a small bootable OS, the information necessary to form your VPN or however you're dealing with security, and nothing else. (At this point, you'll wish you could use linux, as it will require a smaller key, and be cheaper. But you'll survive with windows). Of course, there are still problems with this; you're not truly remote booting, just using a read-only boot disk. But it may be sufficient.
The next step up in complexity, as well as power, is to again use a usbkey to boot, but boot into linux. Have it boot from the read-only keychain, use the (unique) information on each key to establish the connection, etc, and then start X-Windows and rdesktop (linux remote desktop client), connecting to a remote windows server. It would be quite easy to secure the tablet so that the linux distribution is secure, and again you have a unique key to secure the connection. From the users point of view, they're working on a local windows machine, although from your point of view they're remotely logged on to another box.
These are just the first two ideas that came to mind. As the parent said, though, you need some kind of local storage for encrypted booting. I highly recommend a usbkey from one brand or another, as they're relatively cheap, absurdly robust, and quite convenient. And once you're allowing even a bit of storage, make it a useful amount, and boot locally off a secured disk, rather than trying to get the hardware to do something it's not supposed to do. Remote booting, keep in mind, just uses some ROM code to boot the computer and then moves control elsewhere. I'm pretty sure you won't find a system ROM or an 802.11 ROM that does what you need; instead, you're going to have to attach a boot ROM of some kind, and a usb key is about as good as it gets.
Oh, one final point, to make this make sense. Most of the usb keys have a read-only switch that can be latched, which makes them appear as read-only mass storage devices to the OS. Once you write the key, you can physically remove the switch (I've done this to several usb keys) to make it quite inconvenient to write to them again. It is possible to write to them either by opening them up and reconnecting the switch, or by writing a custom driver which ignores that the device is read-only (it turns out that, even in read-only mode, the keys I've worked with do honor writes), but neither of these methods is very convenient. It depends just how much security you need.
But there's no support for forwarding calls to a cell phone when you're not home, correct?
You think Jews such as myself want to work on National Jews Go To The Movies Day? I don't think so!
Gee, and I just thought he was being clever. I thought it was a Barton Fink reference. Too much movies for me!
Well, half that ($60) will get you an aluminum one.. which'll probably cost them $40 to make, so they'll actually make a profit. They say the titanium one costs more than $100 to make, and I really believe them... I've done a bit of titanium machining, and $150-$200 to manufacture that wouldn't surprise me. The aluminum one looks just as sexy as the titanium (both nickel-plated, I think), it's just not titanium and not a numbered edition.
--
What more do you want than the first commercial offering linked? That thing is disturbingly sexy... wish I had the dough.
--
Which prompts the question... since when is the gigabyte a measure of volume? Last I checked it was a measure of information.
--
more than 95 percent (by volume in gigabytes) of human-to-computer information input will remain keyboard- and mouse-based
Is this even true today? I doubt it's true of my own work. I own a digital camera. I don't take many pictures; I'm not very photogenic. I figure I take about 50 pictures a month... let's call that one a day, to be conservative. 1600x1200x8, uncompressed (I use a raw format that sends 8-bit intensity data for each pixel, as each pixel in a digital camera is only one color), comes out to very close to 2MB per image. In a given day, I also spend about 8 hours sitting in front of my computer. I type at ~60 words per minute (never said I was fast), coming out to about 160kB/day. Now, I don't use my mouse too much, since it hurts my wrist. But even if it sends 4-byte updates 300 times a second when I'm not moving it at all, that comes out to 35MB a day... hardly a realistic number, but let's run with it. So my total keyboard/mouse input is 36MB a day, at an absurd maximum (I do stop for breath occasionally), while my non-keyboard/mouse input is 2MB/day, at a rather absurd minimum. And just with those numbers, I have (slightly) less than 95% of input being keyboard/mouse based.
I know a lot of people who take more pictures than me. One person taking 10 pictures a day is enough to offset 9 people who take none. A few people use speech recognition... that's relative high-bandwidth input. And I'm sure at least one person in ten thousand has a digital video camera...
So, does anyone think this 95% number is true even today?
--
I think it would be a bad idea to rely on IDE drives as one's only source of backup. Especially if you aren't planning on using any stripping or parity.
How would stripping help reliability?
Okay, okay. How would striping help reliability, then?
--
I could have sworn it was Apple Besktop Dus... oh, well.
--
Before I go through a full install, can anyone confirm if TeX works?
--
Sun (or at least the people I've spoken to at Sun, who do represent their company) never said that generics weren't necessary. They said, with surprising honesty, that no one had yet come up with an implementation of generics that made sense for the virtual machine. The current implementation of java with generics has been available for around 18 months (externally for what, 12 months?), and has been a compromise implementation, giving a highly requested feature at some cost, perhaps, in the potential beauty of the implementation. The reason that generics weren't included with Java 1.0 is that no one could agree on how to do them; Sun has since realized that they won't be perfect, regardless, but that it's time to push them out the door. Probably, their publication of this stuff is prompted by C# (which uses, more or less, the same flawed-but-usable implementation). But I really do respect Sun's restraint in trying to make it as good as possible.
--
Mail.app works for me
--
I know Blizzard is a game company. Who's BNETD?
Compressing pi is not particularly hard. As posted elsewhere, one of the more convenient algorithms for pi is:
/good/ compression algorithms (with about five exceptions you should be able to think of off the top of your head) take advantage of the special form of the data they're compressing.
pi=sum as j goes from 0 to infinity of 1/16^j (4/(8j+1)-2/(8j+4)-1/(8j+5)-1/(8j+6))
So the data calculated compresses, quite readily, to a representation of the above algorithm (machine code, c code, lambda calc, your choice), plus the number of digits, the number of digits being necessary to restore the file to its original form. Of course, the number of bits needed to store the number of digits is logarithmic, so we get O(logn+c) bits to store n digits of pi.
Most compression algorithms wouldn't be able to do much with it. But most
--
Why?
You're right, of course. In addition, I'm quite certain that the winners used at least some overlap between binary and text.
I'm a lisper, so I agree with you, but the one thing that xml does more gracefully than s-exprs is properties. {bold weight=200%}Text{/bold} (yes, I'm too lazy to use angle brackets) is simply nicer, in my opinion, than (bold :weight (percent 200) (text "Text")). Not a good enough reason to kill s-exprs, I think, but it is one part of the sgml heritage I occasionally envy.
How is this different from standard mathematica (which already supports multiple kernels) and the pre-existing paralellization add-on?
Yes, I do. I would gladly go to Mars, under the understanding that I couldn't return, if there was about a 90% chance of surviving the first year, and some system in place (say, solar or thermal radioisotope power to melt some ice, split off some oxygen) which gave even a 10% chance of making it further. Yeah, chances are I'd end up dead... but even the chance would be worth it. NASA has demonstrated that progress can be made by being conservative and following reasonable saftey guidelines, but it just ain't as much fun, and it's slower! Not saying NASA's doing it wrong, they're not. But if I really had the option, yes, i'd volunteer. Wouldn't you?
Actually wasn't trolling... just heard that many times, in analyses of the games. And yes, I play enough chess to know that playing white is good... but from a mathematical point of view, it's still *possible* (barring, again, some proof I haven't seen) that black has the winning path, just extremely unlikely based on our experience.
Actually, there are only two possibilities.
- The game is a win for white.
- The game is a draw or stalemate.
This is because white has the (rarely used) option to pass first move to black.
But you still need an infinite rope to get continual energy.
Pseudo-ops? Labels?
The problem is a number of transistor issues. 128 gigabits of memory takes 128 billion transistors, today. And if even one of those transistors is faulty, the whole chip is dead. Speed has nothing to do with it, if the chip is defective (not just unable to clock fast enough). Now, what should really be done is more work on using partially defective memory chips. Linux supports that today, but no other OS that I know of does; and even in Linux, it's not trivial, as you need to test your memory yourself, and map some of the memory as invalid. Now, it would be relatively possible to create a 128 gigabit memory chip (admittedly, a big chip) with maybe 1000 flaws... you can add a small rom to this chip saying which sectors (say, to the nearest kilobyte) are bad, so you could put it into a box and get 127.2 gigabits, without user intervention. Making chips this big is possible, but not easy, with relaxed timing constraints like you describe. It seems like maybe we should be using current DDR ram as L4 cache, and using massive sticks as main memory.