Remotely administering solid-state storage is no different than remotely adminstering spinning storage, just less chance of failure, so less visits. The data size you require can easily fit in a single rackmounted disk array. Vendors like E-Disk sell highly reliable solid state drives in IDE and SCSI, up to at least the high 10's of gigs in size per disk, 2.5 and 3.5 in form factor.
I can't speak to specifics, I haven't started digging around BlueTooth yet, but don't be so quick to deny it's hackability based on the market drivel you've repeated. 802.11X protocols also had various mentioned feautures to make them secure - and as long as everyone just runs their factory cards/drivers/software/settings, it's secure. But if your security relies on someone not re-writing the software, you're SOL. Check out http://802.11ninja.net, where some freinds of mine have some software the defeats just about everything that 802.11X offers security-wise. With that software and the right card, you can DoS a base station, join a supposedly "secure" network, launch a man-in-the-middle attack (you become the base station to the network's users), and yes, even recover the weak crappy keys that the protocol uses for encryption and do al the same irregardless of that encryption.
So again, the question is not what market drivel buzzwords someone said about the technology - technically if 802.11 had implemented all their buzzwords correctly they would be secure too - it's about whether they really did it *right*, or they left it poorly implemented and vulnerable. So far history is on the vulnerable side.
Heh, of course I should mention that such drives can cost up to $1000/GB for the low-end models up to 8GB in size. I'm sure the cost/gig goes down on the larger drives, but I wouldn't expect this 155G Ultra320 monster to go for any less than $78K, probably higher:)
If you're willing to fork out the money, there's several manufacturers who have been puttng out genuine static ram drives for a while. They have microsecond access times, sizes up to 80-ish GB last I saw, IDE and SCSI interfaces, and can have sustained bandwidths limited only by the bus speed. They also consume less power, generate less heat, and don't fail as often because there's no moving parts. They solved the limited write cycle problem by having the drive logic remap blocks of data to spread the write wear around the drive. FOr a bleeding edge example, check out E-DISK's soon-to-be-available Ultra320 drive (they're released other similar drives before, just not at this performance level):
Size: up to 155GB Access time: 33-48 us (microsecond) IOPS: 9500 - 50000 per second Burst data rate: 320 MBps Sustained data rate: 230 MBps Full Erase (Security feature, press a button): around 26 seconds. ECC error correction, MTBF around 2 million hours, 10 year data integrity. Write life-cycle of in excess of 100 years at 100 GB of writes per day.
It doesn't work like a revision control system, it works like an edit-history. The "diffs" if that's what you want to call them are extremely minimal. It's reasonable to store the entire edit history of a document keystroke for keystroke. There can always be an export option if you want to export to a "normal" and much more compacted text file with no history.
Among the "never implemented, but thought about seriously and planned to do at some point" list of features that would have made it killer were:
1. Storing history data contextually, so that the history for a given area of the text tends to be located very near to that text in the savefile on disk.
2. Segmenting the file into blocks, such that only the 512-byte blocks of the file which are updated by an edit operation (cut, paste, keystroke, etc) are re-saved on each mini-save, reducing save cpu/io load.
3. A block-mapping header, so that the blocks on disk can be out-of-order from the real data (so that inserting text in the middle of the file doesn't "push" the character stream through the rest of the file causing unneccesary block writes).
If I ever added all that in, the mini-auto-saves would be writing only handful 512 byte blocks on each save in normal cases.
I wrote a GTK+ text editor that saves the document on every keystroke with a frequency limiter so that you don't save more than once every 5 seconds. It used a background thread for the saving so the user interface didn't hiccup, and every save file contained a complete undo/redo history to the beginning of the document's life. It had no save buttons, only "open" and "close". I never finished it because it was plaintext-only anyways, so nobody was ever gonna use it.
Actually microkernels with multiple servers and virtually everything in userspace are at this point a pretty old concept. Most of the CS world already "been there, done that, moved on". I don't want it to sound like this reference is the only motivation for my opinion, but in any case a good read is the old tannenbaum vs torvalds debate on microkernels that's archived on kernel.org, from way back in the first days of linux. The point is that a lot of the supposed gains of a microkernel architecture can also be accomplished in a monolithic kernel with proper code layout and interfacing, since they're really more semantic than anything. You're paying a rather large runtime penalty in performance and complexity for something that can be mostly dealt with at coding/compile/link or even insmod time.
I think you have volts and amps backwards there. All USB ports supply +5V, the only that changes from port to port depending on the controller/hub/etc is the available amperage. Considering that it's a AAA battery we're talking about charging, I'm sure even the lowliest USB amperage would be sufficient. Right now I have my Motorola i1000plus (Nextel walkie-talkie cellphone) charging from a ubs hub port, using a custom cable I spliced up that puts the USB's +5V signal into the bottom of the phone, it powers and charges my battery just fine. [BTW if you like that idea and don't want to make one yourself, they sell something similar on ThinkGeek]
First off, on an annual basis 1/10th of an FTE is probably excessively high. That's 4 hours a week devoted to being the support guy for this OSS product by reading mailing lists and maybe doing a little patching. When new releases are deployed or new security bugs found or whatnot, you *might spend* 4-8 hours that week, but I bet most weeks and even most years it takes far less time. Another thing to consider is that some of this time spent supporting (and learning to support) a peice of OSS can be amortized with the costs of supporting other software. In other words, once you get one guy trained in the workings of the OSS world (where to find FAQs, how to address people on technical mailing lists, simple source patching, etc), he can apply those skills across the board. Proactive support in the form of watching for new bugs and security reports gets clumped together by BugTraq et al.
If I were in your position of making the support cost analysis, I'd probably put it at more like 2 hours/week on average the first year, and dropping to 1 hour/week on average the remaining years. This should place it around the same $$ as the commercial options. This is assuming this is the only OSS around. If the same department picks up a few more OSS support tasks, they can lump them into this one guy and drive his cost per peice of OSS even lower.
Perhaps rather than a new business model, large companies should create new positions called "OSS Support Engineer", and hire linuxy geeks who know this world to sit in and be their in-house mediator between their developers/admin and the mailing lists and authors of the OSS.
Nice device, but would it have been all that hard for them to replace the AAA battery with a rechargeable one and let it recharge from the +5V on the USB connector?
I know all about reverse engineering software. It's hard, and not giving away the source makes a big difference. If you throw enough resources at it you might glean a small amount of data, but it's a monstrous task to really get the original source back and understand it like you would with the original source. As a testament to this other than my opinion: why do you think the Wine guys haven't already reverse-engineered all the core windows dlls and made wine work perfectly? They do do thinsg like that, but it is very rough and unpredictable work. They've been hacking on Wine for a long time and it's still fairly unusable except for a few key things that have been focused on.
I've been using RAV Antivirus (specifically their sendmail+libmilter option for linux) to scan my company's mail as it passes through our linux/sendmail mail server. It's done a great job of picking out windows viruses. It's not open-source, but their pricing is very reasonable. I think for scanning 2 domains (their minimum) was $300 initially to purchase it, which comes with 1 year of virus database updates, and $60/year after that to keep getting updates. They don't care about the volume of scanning, just how many email domains you're scanning for. Check them out at http://www.ravantivirus.com.
Oh get it off it. Linus kicks ass, it's a very good thing that it's his rules. Anyone else's rules we'd have a bloated slow crufty mess by where we are now in the kernel's evolution. Because it's GPL, and because there are other knowledgeable kernel people capable of maintaing alternate trees, it doesn't harm us that one person takes control in a dictator fashion, and helps a lot when 99% of the time he makes the right decision.
It's just like how in political science they tell you the best form of government is a benevolent dictatorship, and that its fatal flaw is what the hell can you do about it when the dictator becomes un-benevolent. Linux is a benevolent dictatorship, and if he ever gets stupid or mean, someone with another fork of the tree will take over as the "good" tree, so we don't face those worries.
I mostly agree with you, but there are exceptions. Nvidia is a classic case where you can't very well argue that they should opensource their drivers. Your arguments are valid for the peices of their driver code that basically copy memory around and access chip registers, but there's another very large part of the driver which handles OpenGL acceleration stuff. Working with the same OS, and having a clone of NVidia's hardware, a competitor would still be seriously lacking in performance, conformance and stability if they didn't have Nvidia's driver. That driver has a lot of voodoo in it for efficiently doing 3d graphics that's not entirely directly related to accessing hardware I/O on the card.
In situation's like Nvidia's, where if ATI saw their driver source code they could readily apply lessons learned to their own driver and reap benefits, it makes sense for nvidia to keep it closed.
Anybody can order tech specs from Ford or GM for their cars. It may not be detailed enough to help you compete with them, but it's plenty detailed enough to do extensive repairs and modifications.
Wrong. I *can* do whatever I want to a 2003 ford mustang. I can remove the muffler, modify the camshaft... hell I can strap a rocket on the back if it pleases me. Obviously the manufacturer won't honor my warranty once I cross certain lines, and obviously because of laws for the common good, I won't be able to legally drive it on public highways after a certain point as well. But at any stage in whatever process, Ford will be more than happy to supply me all the technical data and help I need when it comes to how their car is designed and built - although some of the more advanced manuals come at a reasonable cost.
If TiVo were the same, then they should allow me to turn the box into a linux unreal tournament machine or an X.10 controller or whatever the hell else I want to do with it, and provide specs and documentation as neccesary to boot. They would of course void my warranty and/or tech support when I open the case or make invasive software changes - and at some point down the mod path they may no longer allow me to subscribe to their services, and may even disclaim to me that it's no longer legal for me to hook my TiVo up to a cable/satellite network (however dubious that may be) - but they wouldn't stop me from doing whatever I wanted with the hardware in my own home.
E. Starting three months after the entry of this Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of interoperating or communicating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (i) implemented in a Windows Operating System Product installed on a client computer, and (ii) used to interoperate, or communicate, natively (i.e., without the addition of software code to the client operating system product) with a Microsoft server operating system product.
I assume this to mean that the Samba guys will get legal access to the SMB protocol specs and other related stuff. Likely could include the native Exchange server protocols too, since Outlook Express talks that protocol and has shipped integrated with the OS.
A lot of SCSI cards support this, and it does work with almost any OS. The problem is that "works" means that both hosts can see and access the block device. This doesn't in any way provide any of the synchronization neccesary to support a shared filesystem. For that, you need software like Global FileSystem. Apparenlty GFS was a GPL project, then it went commercial with Sistina, but there's now an OpenGFS Project that's picking up from the last GPL release and trying to make it work well.
In any case, the hardware is easy, lots o fhwardware supports multiple hosts hitting a block device - the hard part is some sort of shared filesystem and/or block-level locking stuff.
Offtopic? It may be colorful, but pointing out that both competitors in a performance test are slow is certainly on-topic. Next time try Troll, Flamebait, or any other mod rating that's synonymous on Slashdot with "I don't agree with you"
Slashdot Mirror
Remotely administering solid-state storage is no different than remotely adminstering spinning storage, just less chance of failure, so less visits. The data size you require can easily fit in a single rackmounted disk array. Vendors like E-Disk sell highly reliable solid state drives in IDE and SCSI, up to at least the high 10's of gigs in size per disk, 2.5 and 3.5 in form factor.
I can't speak to specifics, I haven't started digging around BlueTooth yet, but don't be so quick to deny it's hackability based on the market drivel you've repeated. 802.11X protocols also had various mentioned feautures to make them secure - and as long as everyone just runs their factory cards/drivers/software/settings, it's secure. But if your security relies on someone not re-writing the software, you're SOL. Check out http://802.11ninja.net, where some freinds of mine have some software the defeats just about everything that 802.11X offers security-wise. With that software and the right card, you can DoS a base station, join a supposedly "secure" network, launch a man-in-the-middle attack (you become the base station to the network's users), and yes, even recover the weak crappy keys that the protocol uses for encryption and do al the same irregardless of that encryption.
So again, the question is not what market drivel buzzwords someone said about the technology - technically if 802.11 had implemented all their buzzwords correctly they would be secure too - it's about whether they really did it *right*, or they left it poorly implemented and vulnerable. So far history is on the vulnerable side.
Heh, of course I should mention that such drives can cost up to $1000/GB for the low-end models up to 8GB in size. I'm sure the cost/gig goes down on the larger drives, but I wouldn't expect this 155G Ultra320 monster to go for any less than $78K, probably higher
If you're willing to fork out the money, there's several manufacturers who have been puttng out genuine static ram drives for a while. They have microsecond access times, sizes up to 80-ish GB last I saw, IDE and SCSI interfaces, and can have sustained bandwidths limited only by the bus speed. They also consume less power, generate less heat, and don't fail as often because there's no moving parts. They solved the limited write cycle problem by having the drive logic remap blocks of data to spread the write wear around the drive.
FOr a bleeding edge example, check out E-DISK's soon-to-be-available Ultra320 drive (they're released other similar drives before, just not at this performance level):
Size: up to 155GB
Access time: 33-48 us (microsecond)
IOPS: 9500 - 50000 per second
Burst data rate: 320 MBps
Sustained data rate: 230 MBps
Full Erase (Security feature, press a button): around 26 seconds.
ECC error correction, MTBF around 2 million hours, 10 year data integrity.
Write life-cycle of in excess of 100 years at 100 GB of writes per day.
It doesn't work like a revision control system, it works like an edit-history. The "diffs" if that's what you want to call them are extremely minimal. It's reasonable to store the entire edit history of a document keystroke for keystroke. There can always be an export option if you want to export to a "normal" and much more compacted text file with no history.
Among the "never implemented, but thought about seriously and planned to do at some point" list of features that would have made it killer were:
1. Storing history data contextually, so that the history for a given area of the text tends to be located very near to that text in the savefile on disk.
2. Segmenting the file into blocks, such that only the 512-byte blocks of the file which are updated by an edit operation (cut, paste, keystroke, etc) are re-saved on each mini-save, reducing save cpu/io load.
3. A block-mapping header, so that the blocks on disk can be out-of-order from the real data (so that inserting text in the middle of the file doesn't "push" the character stream through the rest of the file causing unneccesary block writes).
If I ever added all that in, the mini-auto-saves would be writing only handful 512 byte blocks on each save in normal cases.
I wrote a GTK+ text editor that saves the document on every keystroke with a frequency limiter so that you don't save more than once every 5 seconds. It used a background thread for the saving so the user interface didn't hiccup, and every save file contained a complete undo/redo history to the beginning of the document's life. It had no save buttons, only "open" and "close". I never finished it because it was plaintext-only anyways, so nobody was ever gonna use it.
Actually microkernels with multiple servers and virtually everything in userspace are at this point a pretty old concept. Most of the CS world already "been there, done that, moved on". I don't want it to sound like this reference is the only motivation for my opinion, but in any case a good read is the old tannenbaum vs torvalds debate on microkernels that's archived on kernel.org, from way back in the first days of linux. The point is that a lot of the supposed gains of a microkernel architecture can also be accomplished in a monolithic kernel with proper code layout and interfacing, since they're really more semantic than anything. You're paying a rather large runtime penalty in performance and complexity for something that can be mostly dealt with at coding/compile/link or even insmod time.
Why eventual port? They're switching Machs right now, why not switch to l4ka right away?
The linux kernel guys pay attention to these thigns and code for them by hand. Hence their badass performance
I think you have volts and amps backwards there. All USB ports supply +5V, the only that changes from port to port depending on the controller/hub/etc is the available amperage. Considering that it's a AAA battery we're talking about charging, I'm sure even the lowliest USB amperage would be sufficient. Right now I have my Motorola i1000plus (Nextel walkie-talkie cellphone) charging from a ubs hub port, using a custom cable I spliced up that puts the USB's +5V signal into the bottom of the phone, it powers and charges my battery just fine. [BTW if you like that idea and don't want to make one yourself, they sell something similar on ThinkGeek]
voltage regulators are very small ICs, I'm sure it could be fitted.
First off, on an annual basis 1/10th of an FTE is probably excessively high. That's 4 hours a week devoted to being the support guy for this OSS product by reading mailing lists and maybe doing a little patching. When new releases are deployed or new security bugs found or whatnot, you *might spend* 4-8 hours that week, but I bet most weeks and even most years it takes far less time. Another thing to consider is that some of this time spent supporting (and learning to support) a peice of OSS can be amortized with the costs of supporting other software. In other words, once you get one guy trained in the workings of the OSS world (where to find FAQs, how to address people on technical mailing lists, simple source patching, etc), he can apply those skills across the board. Proactive support in the form of watching for new bugs and security reports gets clumped together by BugTraq et al.
If I were in your position of making the support cost analysis, I'd probably put it at more like 2 hours/week on average the first year, and dropping to 1 hour/week on average the remaining years. This should place it around the same $$ as the commercial options. This is assuming this is the only OSS around. If the same department picks up a few more OSS support tasks, they can lump them into this one guy and drive his cost per peice of OSS even lower.
Perhaps rather than a new business model, large companies should create new positions called "OSS Support Engineer", and hire linuxy geeks who know this world to sit in and be their in-house mediator between their developers/admin and the mailing lists and authors of the OSS.
Nice device, but would it have been all that hard for them to replace the AAA battery with a rechargeable one and let it recharge from the +5V on the USB connector?
I know all about reverse engineering software. It's hard, and not giving away the source makes a big difference. If you throw enough resources at it you might glean a small amount of data, but it's a monstrous task to really get the original source back and understand it like you would with the original source. As a testament to this other than my opinion: why do you think the Wine guys haven't already reverse-engineered all the core windows dlls and made wine work perfectly? They do do thinsg like that, but it is very rough and unpredictable work. They've been hacking on Wine for a long time and it's still fairly unusable except for a few key things that have been focused on.
I've been using RAV Antivirus (specifically their sendmail+libmilter option for linux) to scan my company's mail as it passes through our linux/sendmail mail server. It's done a great job of picking out windows viruses. It's not open-source, but their pricing is very reasonable. I think for scanning 2 domains (their minimum) was $300 initially to purchase it, which comes with 1 year of virus database updates, and $60/year after that to keep getting updates. They don't care about the volume of scanning, just how many email domains you're scanning for. Check them out at http://www.ravantivirus.com.
Oh get it off it. Linus kicks ass, it's a very good thing that it's his rules. Anyone else's rules we'd have a bloated slow crufty mess by where we are now in the kernel's evolution. Because it's GPL, and because there are other knowledgeable kernel people capable of maintaing alternate trees, it doesn't harm us that one person takes control in a dictator fashion, and helps a lot when 99% of the time he makes the right decision.
It's just like how in political science they tell you the best form of government is a benevolent dictatorship, and that its fatal flaw is what the hell can you do about it when the dictator becomes un-benevolent. Linux is a benevolent dictatorship, and if he ever gets stupid or mean, someone with another fork of the tree will take over as the "good" tree, so we don't face those worries.
I mostly agree with you, but there are exceptions. Nvidia is a classic case where you can't very well argue that they should opensource their drivers. Your arguments are valid for the peices of their driver code that basically copy memory around and access chip registers, but there's another very large part of the driver which handles OpenGL acceleration stuff. Working with the same OS, and having a clone of NVidia's hardware, a competitor would still be seriously lacking in performance, conformance and stability if they didn't have Nvidia's driver. That driver has a lot of voodoo in it for efficiently doing 3d graphics that's not entirely directly related to accessing hardware I/O on the card.
In situation's like Nvidia's, where if ATI saw their driver source code they could readily apply lessons learned to their own driver and reap benefits, it makes sense for nvidia to keep it closed.
Anybody can order tech specs from Ford or GM for their cars. It may not be detailed enough to help you compete with them, but it's plenty detailed enough to do extensive repairs and modifications.
I've got karma to burn, keep opressing me.
Wrong. I *can* do whatever I want to a 2003 ford mustang. I can remove the muffler, modify the camshaft... hell I can strap a rocket on the back if it pleases me. Obviously the manufacturer won't honor my warranty once I cross certain lines, and obviously because of laws for the common good, I won't be able to legally drive it on public highways after a certain point as well. But at any stage in whatever process, Ford will be more than happy to supply me all the technical data and help I need when it comes to how their car is designed and built - although some of the more advanced manuals come at a reasonable cost.
If TiVo were the same, then they should allow me to turn the box into a linux unreal tournament machine or an X.10 controller or whatever the hell else I want to do with it, and provide specs and documentation as neccesary to boot. They would of course void my warranty and/or tech support when I open the case or make invasive software changes - and at some point down the mod path they may no longer allow me to subscribe to their services, and may even disclaim to me that it's no longer legal for me to hook my TiVo up to a cable/satellite network (however dubious that may be) - but they wouldn't stop me from doing whatever I wanted with the hardware in my own home.
Flamebait -3? It's not flamebait, it's sackofshitbait. Come out Come out wherever you are Michael.
I assume this to mean that the Samba guys will get legal access to the SMB protocol specs and other related stuff. Likely could include the native Exchange server protocols too, since Outlook Express talks that protocol and has shipped integrated with the OS.
I'll even say that without going anon: What he said. Michael, you're a sack of shit on a power trip.
A lot of SCSI cards support this, and it does work with almost any OS. The problem is that "works" means that both hosts can see and access the block device. This doesn't in any way provide any of the synchronization neccesary to support a shared filesystem. For that, you need software like Global FileSystem. Apparenlty GFS was a GPL project, then it went commercial with Sistina, but there's now an OpenGFS Project that's picking up from the last GPL release and trying to make it work well.
In any case, the hardware is easy, lots o fhwardware supports multiple hosts hitting a block device - the hard part is some sort of shared filesystem and/or block-level locking stuff.
Offtopic? It may be colorful, but pointing out that both competitors in a performance test are slow is certainly on-topic. Next time try Troll, Flamebait, or any other mod rating that's synonymous on Slashdot with "I don't agree with you"