Parallax Propeller would be a good CPU for this. It has ready-made libraries for PS/2 peripherals and LCDs, including video output if you'd need that. A project like this would run on a few dozen milliamps at 5V. A single solar battery charging a car battery could easily supply a few full classrooms of those.
Well, the interface would be on an FPGA, so probably PCI express would be the simplest things to implement. Do note that power scales with bandwidth, so you want only as much bandwidth as you need and no more. The win is that I/O transaction latency is negligible compared even to an SSD -- you don't waste power waiting for things to happen.
To suck a gold ball through a garden hose you're producing a lot of vacuum but very little air power. Most power is then wasted: with a huge pressure differential the turbine stalls. On a Dyson the turbine stalls much earlier than on your golfball sucker, but then turbine isn't all that different from a wing. Low stall speed means inefficient blade when operating at nominally high speed. What you want from a vacuum is high air power.
Sure high vacuum is nice when you got a clog, but that's a tradeoff that IMHO Dyson engineers got right for a change. Clogs are rare events. If you don't abuse the vacuum, the intake nor the hose shouldn't ever clog, it's pretty much your fault for sucking up stuff that's too big to fit. Otherwise, at high air power, there's decent airflow that picks up dirt and does the job it's designed to do.
I find that Dyson is optimized for cleaning carpets using the main beater brush. It is, conversely, pessimized for the lower flow, higher vacuum attachments. To a point where I think you'd be much better off with another vacuum for attachment use. There's no simple way around it short of having two turbines and a clutch to route motor power between them based on circumstances. You literally need one turbine for high flow, one for high vacuum (like when using attachments on a car carpet). Many vacuums optimize for high vacuum at lower flow, and thus they perform nowhere near whey they could for high flow carpet cleaning with the beater brush. No vacuum cleaner can claim to tackle both equally well, because, well, nature just doesn't work that way when all you have is one bog-standard turbine.
Perhaps there's some blade design magic to be done on a turbine to make it perform better across a wider range of flows and pressure differentials, but so far it doesn't seem to have reached the vacuum cleaner market. All I can think of at the moment is some localized added airflow on the blades themselves (through holes going into the blade), but that makes the turbine more complex and simple sheetmetal aluminum turbine discs won't work anymore.
Waitaminute, you scoff at a mere factor of 8 difference for a memory system that gives you two orders of magnitude higher bandwidth and 4+ orders of magnitude lower latency for that 5W delta from idle to active power? If you need performance, throwing hard drives into a RAID system to get higher IOPS and bandwidth will overshoot the DDR3L SDRAM's power consumption when you've got 6 hard drives, and you're still nowhere near the performance you get from SDRAM, even if we're talking only about the baseline performance you get when you allocate 5W to the active use (over refresh). If you want to burst as much power into those RAM chips as they'll take, you can be extracting performance that will match tens of kilowatts worth of hard drive power consumption.
The R910's memory access architecture is not designed for hard-drive-like storage. It's hugely wasteful, power-wise, because it interfaces all that memory with a CPU that's reading the memory in cacheline chunks. When you treat RAM as a hard drive, you're reading it in larger chunks, and you can design things to isolate individual chips so that large buses that span dozens of chips don't have to dissipate power due to switching. Not only that, but wiring on regular DIMMs might not be power optimal for that use either, because the bus is shared among so many chips. Low power memory architecture likely wouldn't work with off-the-shelf DIMMs, you need an isolation register in front of every couple SDRAM chips -- certainly less than what fits on a DIMM stick.
The provisioning figures must be conservative and worst case. Feel free to compare the power consumption between sequential read of terabyte of RAM vs. random accesses where each cacheline read hits different row or page. The precharge energy and burst penalties alone will eat into your power budget like no tomorrow, from what I can figure out from the datasheet. I do use DDR3 in a design but it's vastly underutilized and only there because it's cheaper and easier to get than DDR2, so I'm far away from peak power anyway.
Async IO wouldn't add complexity if the programming languages were not stuck 4 decades in the past when it comes to dealing with event-response style of processing. That's precisely why I sneer, it's the inverse network effect. Nobody uses them because they are a pain, thus we all suffer spinning rings/beachballs where the OS is loading stuff page-by-page simply because it doesn't know upfront what pages a memmapped chunk of data or executable will need next.
I do agree about seeks having a minimum duration, but the most glaring problem is when seeks are done to read single pages scattered around an area that could be read in the entirety in as long as it takes to do one or two of those seeks. It's my experience that such seek storms happen when a long disused application has been slowly paged out to disk and now there's hardly anything left of it save for popular shared library pages. The problem is so bad that on both Windows 7 and OS X when this happens, killing and restarting the application is actually faster than waiting for it to be paged back in when there's a seek overhead interspersed between each pagein. In a bad case you end up waiting for 30 seconds or more as the OS laboriously pulls in maybe 100MB of data at a rate that was state of the art on PCs back in the 90s. There's no mechanism AFAIK (not in Windows 7, not in OS X) to mark them up at runtime as to which page usually brings up what other page -- here we need both code and data pages, and that information is transient, there's no way to prelink anything. An application could provide self-generated hints both for how it does explicit file access but also access to data, if that was shown to be somehow better than the OS collecting the data at runtime.
As for the buffer cache: duh, I was merely saying in what high transaction rate scenario a database wouldn't necessarily benefit all that much from SSDs.
The problem is that with Windows, the buck stops at the executable stuff, and even that doesn't encompass plugins and extensions (just look at startup of any modular software package like Acrobat, Eclipse, LibreOffice, Qt Creator).
The programming model doesn't have to be very complex; besides, the basic GUI paradigms call for this very event driven paradigm anyway, it's just that storage is not normally deal with that way. It's not even about what can execute in parallel -- hard drives are serial random access devices, you're not parallelizing anything, just reordering and coalescing serial accesses. Just look at what any run-of-the-mill application does when you fire it up. First it opens and then reads/mmaps a whole bunch of files. That's just to get the executable ready to run. Then it opens and reads even more files -- that's the configuration, plugins, extensions, etc. It'll also perhaps access some mapped out registry pages, perhaps wake a few partially paged out other processes it may interact with, etc. The deal is: a lot of those things do not have to happen in a fixed order, they can be reordered (not parallelized!) by the OS, there's a fixed set of join points where results of the previous operations have to be ready to proceed. Such join points can be made more granular if the developer so wishes (before diminishing returns kick into gear). Parallelizing things is hard, because suddenly there's a whole class of problems that don't exist in serial execution. What I talk about is merely reordering serially executed requests, that's all -- well, first you need to have some requests instead of just one.
Nope, the problem is that software is and was designed as if the hard drives were SSDs, but they weren't. So SSDs do solve a software architecture problem, and a prevalent one. That problem isn't limited to accessing storage, though, and once you solve it, SSDs are not a must have on the run-of-the-mill desktop anymore.
I think you've run into their production run that had a well known issue. I'm not apologizing for them, just stating facts. It's not normal performance, and you're not the only one who had that issue. I find it incredulous that most customers wouldn't even bother trying to figure out what's wrong -- it was a simple problem with the inner-to-outer cyclone seal (the ring in the middle of the bottom of the canister that seals the upper cyclone dirt collector cylinder to the bottom cover of the canister, IIRC).
I guess people won't spend a couple minutes trying to imagine how the damn thing works -- namely that the outer cyclone spins out the big dirt, and the fine dirt gets spun out by the inner cyclones, with the final cleaning done by the foam prefilter and HEPA postfilter. If big dirt gets to the inner cyclones, they obviously don't have capacity to spin that out (they're tiny!), so the prefilter gets clogged up in short order.
The prefilter, in my case, collects occasional hairs and a fine sprinkling of dust that we clean twice a year if we won't forget. The HEPA has been swapped once, probably for no good reason since it's rated for the life of the vacuum. The exhaust side sure looked clean, even if the intake was black -- I think quite a few of that black was graphite from the brushes.
I give Dyson demerits for awful handling of the customers who had this issue -- they pretended the problem didn't exist. If I run into that issue and had to deal with their crap, I'm sure I'd have sour aftertaste, but then I'd have probably figured it out and fixed it myself before getting in touch with anyone. I do usually break warranties. I think every new thing I buy gets torn to pieces soon after it's taken out of the box. How else will one stay current in engineering?;)
When it comes to Dysons, I think that the ball models are a bit underengineered due to smaller plumbing and smaller motor. The best performance is to be had from full-size uprights -- if you see them in a store, simply select the one that has largest piping and largest canister volume. That's all there's to it.
1. Yeah, the pipe is big, but a bigger pipe means slower airflow. Sure it has lower losses in that pipe and the pipe won't clog as easily with large stuff. What it will clog with is fine particulates that will build up over time because air flows too slow. There's a tradeoff between self-cleaning ability of a pipe and its diameter and thus propensity to clog in presence of large particles ("junk"). If you have big junk on the floor, you're supposed to use a shop vac. That one is designed to deal with big junk. If you're OK with carrying around a shop vac, don't buy a Dyson *or* Kirby, duh, but decide what the heck is it that you want. A shop vac is putting that big pipe to a good use. A Kirby, well, just wastes space with that big pipe.
2. The filter. The filter is a joke. Bag anything in a vacuum is a joke in 21st century. You're not supposed to, you know, get dirty while emptying it. In a Dyson you can go up to a couple dozen cleanings between having to clean the canister.
3. The air whatever test: I don't know what the tool purports to test, but sure as heck it doesn't test suction power. Power measured in, you know, units of power, like Watts. Suction power is quite important, because it gives an idea of how much work the air could do (at most) to extract dirt. Generally speaking, the mechanical suction power will always be less than the electrical power consumed from the outlet. So if you have a 7 amp Kirby and a 12 amp Dyson, the Kirby won't ever have the same potential of developing suction power as a Dyson has, unless the Dyson is much less efficient at converting electrical to mechanical power of the air flow (suction). Power in the airflow is given as pressure * flow rate. A tool better be calibrated in Watts if it purports to measure airflow (suction) power.
4. You can't compare apples to oranges. Dirt extraction isn't all about airflow, nor even all about air power. It's a combination of the beater brush performance *and* air power (suction power). All I know is that I had various contemporary vacuums in the 200-500 USD range, all made between 2000 and 2010, and compared to Dyson animal (large canister) they were rather subpar performers.
SSDs are, in case of a typical desktop system, a hardware solution to a software problem. The software problem lies squarely with braindead legacy APIs that last made sense in the 80s. Those are exposed by seemingly every operating system out there. The issue is as follows: when an application accesses storage, it has no way of telling the operating system what are its plans besides the very next access*. The OS can't plan any hard drive access patterns nor do any sort of large-scale elevator access coalescing because, for the most part, it only knows about the very next access a thread wants to do. Using threading as a workaround to this issue is just silly, you don't need multiple threads, just better async and queuing APIs, and programming languages that can actually deal with them.
Say you know that you want to read the entirety of, say, a dozen configuration files, and also want to read some known byte ranges on other files. It's not simple or even possible, as things currently stand, to tell the OS: here's all that I want to do, wake me up when it's all done. There are asynchronous APIs, but those are not in widespread use because widely deployed C-like programming languages are a very poorly suited to dealing with such problems. As in: the code becomes a royal mess. That's why many GUIs get blocked by every file access and whatnot: it's messy to code an event driven application in a C-like language. Clean, linear-flow code becomes fragmented across functions/methods or case sections. Ugh.
On top of that, all higher-level APIs: those that encapsulate file- and network access, almost universally hide the low level operations and do not allow any sort of asynchronous operation from the caller. Just look at every single damn database library: it's all blocking access! Compression libraries: blocking access! File format libraries (scientific, GIS, office, XML, make your pick) -- same thing. There's no way to use such a library to essentially queue a bunch of requests with the OS, that the OS can then elevator sort on, etc.
Same goes for the runtime linkers/loaders: there's no provision, usually, for any sort of parallelism in queueing the file access requests to the OS. The linker/loader will deal with one file at a time: open it, read some of it, process, rinse and repeat, in spite of knowing a priori a large number of such requests that could all be optimally accessed.
Sure, a realtime database system that needs to have lots of random *read* transactions probably must have an SSD, there's no way around it. A realtime system with mostly random writes can use a log, though, data from the log can be fed back to the database pages after being elevator sorted and coalesced as appropriate, trading off battery-backed RAM for HD performance.
*Let's discount the file access hints as those don't make much of a dent in typical use.
I smell FUD, and that's kinda bad in view of the power consumption figures being explicitly stated in *easily* publicly available datasheets
Let's see how much supply current is needed to self-refresh a 1 terabyte of DDR3L SDRAM.
Let's look at 8 gigabits MT41K1G4 chips from Micron. The chip takes 28mA max at 1.35V. That is 37.8mW per 8 gigabits. A terabyte has 8000 gigabits, or 1000x as much -- that's 38W or about as much cooling as a CPU found in someone's desktop PC might dissipate.
If powering and cooling one CPU is "substantial power supply and cooling", then, well, obviously we've got different points of view on this stuff.
Do notice that those chips dissipate more power only if you access them, so 38W is the idle state but even if you *do* access them, you don't dissipate all that much more -- you'll be probably only accessing a couple of chips at a time. The worst case all banks interleaved read current on those chips is 320mA, so if you access 4 chips at a time, that's still only 1.8W of extra power on top of refresh power.
Of course the logic used to piece together all the chips into a storage device will also use up power, but that logic is in idle low-power state when the chips are not being accessed, so it's a big deal.
A decent "regular" vacuum is, for me, a Dyson, and those cost right there. The cheapest used one that doesn't run on batteries could be had for about $200 (in a decent shape, for less if it's in bad shape). A new Dyson from the DC Animal family will run about $400. If Dyson ever made a robotic vacuum, it'd probably cost $1000 or more. I can't imagine a decent robotic one costing much less. Do note that a decent vacuum cleaner must have good beater brushes and a powerful, two stage cyclone-based air filtration system with a HEPA filter on the output (or three stage w/o HEPA). It can all be scaled down in size, but it will be loud as hell, and will run hot.
It's no biggie to have a 1kW turbine and a double (Dyson standard) or even triple cyclone in an enclosure the size of a Roomba, but I don't know where the heck will the batteries fit. The shaft will probably turn at 20k to 30k RPM, otherwise the motor and turbine would be too big. It might need a muffler on the exhaust, seriously, otherwise the whine will make your teeth hurt.
Never mind that you'd probably want 250Wh battery capacity at a minimum (so that it can vacuum for 10 minutes). With derating for battery life in hot operating conditions, 300-350Wh is more like it. That battery would probably cost a good chunk of change all in itself.
It'd be OK to use it when you're not in at home, but you wouldn't want to be around that thing when it's doing the job. Roomba is, performance-wise, a joke. If you want to know how bad it is, if you're cleaning your carpets using one, borrow a Dyson and see how much crap it'll pick up.
Air resistance is pretty much negligible -- it affects the structural and thermal engineering of the spacecraft, but it's a small figure in the overall energy budget of leaving Earth. All you really care for is orbital velocity, that's where all the energy goes. Once you've got enough velocity, your orbit is a parabola and you're free. When you're looking at a fuel budget for any spacecraft, for the first approximation you need to look at the change in velocity and the available specific impulse of the engine, and put that into the rocket equation. Air resistance can be safely neglected at that point, it'll IIRC change things by less than 10%.
This is changing, and changing quickly. SpaceX is revolutionizing this industry -- right now, as we speak, and for costs that are pretty much unheard of. They would very gladly give you an orbital ride in a year or two, for money that makes the space shuttle costs seem, well, astronomical in comparison.
There is no such thing as "working" hard when you make more in a year than a middle class person makes in their entire lifetime. Human performance doesn't scale up that far, we're talking multiple orders of magnitude. On the way down from middle class you can of course slack as much as you want, but on the way up -- you know, a day only has 24 hours, no matter how bright you are, you can only do so much before you start, effectively, exploiting others.
I've done a few rolls of 60 ISO 60x60mm (start to finish, developing the negative and enlargements myself) and that's sure as heck a different medium. The largest enlargement I could make is approx. A4 paper size, and it looked pretty damn stunning in spite of a very amateurish process and conditions. That was back in elementary school, I haven't touched it for 2 decades since:(
I do understand that definitions don't mean much, but presumably metallurgy and material science has ways of dealing with such problems -- again, timescale and temperature is what matters. Room temperature is of course a fantasy for hard drives, I'd conservatively do any gas leakage estimations at +70C surface temperature for the cover -- then you can be pretty damn sure you won't have a big recall in a couple of years:)
And since partial pressure of helium in our atmosphere would IIRC pass for 1st stage vacuum, I wouldn't worry about the inside having any practical amounts of helium left. It will be evacuated, for all purposes.
Slashdot Mirror
Parallax Propeller would be a good CPU for this. It has ready-made libraries for PS/2 peripherals and LCDs, including video output if you'd need that. A project like this would run on a few dozen milliamps at 5V. A single solar battery charging a car battery could easily supply a few full classrooms of those.
Well, the interface would be on an FPGA, so probably PCI express would be the simplest things to implement. Do note that power scales with bandwidth, so you want only as much bandwidth as you need and no more. The win is that I/O transaction latency is negligible compared even to an SSD -- you don't waste power waiting for things to happen.
To suck a gold ball through a garden hose you're producing a lot of vacuum but very little air power. Most power is then wasted: with a huge pressure differential the turbine stalls. On a Dyson the turbine stalls much earlier than on your golfball sucker, but then turbine isn't all that different from a wing. Low stall speed means inefficient blade when operating at nominally high speed. What you want from a vacuum is high air power.
Sure high vacuum is nice when you got a clog, but that's a tradeoff that IMHO Dyson engineers got right for a change. Clogs are rare events. If you don't abuse the vacuum, the intake nor the hose shouldn't ever clog, it's pretty much your fault for sucking up stuff that's too big to fit. Otherwise, at high air power, there's decent airflow that picks up dirt and does the job it's designed to do.
I find that Dyson is optimized for cleaning carpets using the main beater brush. It is, conversely, pessimized for the lower flow, higher vacuum attachments. To a point where I think you'd be much better off with another vacuum for attachment use. There's no simple way around it short of having two turbines and a clutch to route motor power between them based on circumstances. You literally need one turbine for high flow, one for high vacuum (like when using attachments on a car carpet). Many vacuums optimize for high vacuum at lower flow, and thus they perform nowhere near whey they could for high flow carpet cleaning with the beater brush. No vacuum cleaner can claim to tackle both equally well, because, well, nature just doesn't work that way when all you have is one bog-standard turbine.
Perhaps there's some blade design magic to be done on a turbine to make it perform better across a wider range of flows and pressure differentials, but so far it doesn't seem to have reached the vacuum cleaner market. All I can think of at the moment is some localized added airflow on the blades themselves (through holes going into the blade), but that makes the turbine more complex and simple sheetmetal aluminum turbine discs won't work anymore.
Of course it's not meant for a laptop duh ;)
Waitaminute, you scoff at a mere factor of 8 difference for a memory system that gives you two orders of magnitude higher bandwidth and 4+ orders of magnitude lower latency for that 5W delta from idle to active power? If you need performance, throwing hard drives into a RAID system to get higher IOPS and bandwidth will overshoot the DDR3L SDRAM's power consumption when you've got 6 hard drives, and you're still nowhere near the performance you get from SDRAM, even if we're talking only about the baseline performance you get when you allocate 5W to the active use (over refresh). If you want to burst as much power into those RAM chips as they'll take, you can be extracting performance that will match tens of kilowatts worth of hard drive power consumption.
The R910's memory access architecture is not designed for hard-drive-like storage. It's hugely wasteful, power-wise, because it interfaces all that memory with a CPU that's reading the memory in cacheline chunks. When you treat RAM as a hard drive, you're reading it in larger chunks, and you can design things to isolate individual chips so that large buses that span dozens of chips don't have to dissipate power due to switching. Not only that, but wiring on regular DIMMs might not be power optimal for that use either, because the bus is shared among so many chips. Low power memory architecture likely wouldn't work with off-the-shelf DIMMs, you need an isolation register in front of every couple SDRAM chips -- certainly less than what fits on a DIMM stick.
The provisioning figures must be conservative and worst case. Feel free to compare the power consumption between sequential read of terabyte of RAM vs. random accesses where each cacheline read hits different row or page. The precharge energy and burst penalties alone will eat into your power budget like no tomorrow, from what I can figure out from the datasheet. I do use DDR3 in a design but it's vastly underutilized and only there because it's cheaper and easier to get than DDR2, so I'm far away from peak power anyway.
Async IO wouldn't add complexity if the programming languages were not stuck 4 decades in the past when it comes to dealing with event-response style of processing. That's precisely why I sneer, it's the inverse network effect. Nobody uses them because they are a pain, thus we all suffer spinning rings/beachballs where the OS is loading stuff page-by-page simply because it doesn't know upfront what pages a memmapped chunk of data or executable will need next.
I do agree about seeks having a minimum duration, but the most glaring problem is when seeks are done to read single pages scattered around an area that could be read in the entirety in as long as it takes to do one or two of those seeks. It's my experience that such seek storms happen when a long disused application has been slowly paged out to disk and now there's hardly anything left of it save for popular shared library pages. The problem is so bad that on both Windows 7 and OS X when this happens, killing and restarting the application is actually faster than waiting for it to be paged back in when there's a seek overhead interspersed between each pagein. In a bad case you end up waiting for 30 seconds or more as the OS laboriously pulls in maybe 100MB of data at a rate that was state of the art on PCs back in the 90s. There's no mechanism AFAIK (not in Windows 7, not in OS X) to mark them up at runtime as to which page usually brings up what other page -- here we need both code and data pages, and that information is transient, there's no way to prelink anything. An application could provide self-generated hints both for how it does explicit file access but also access to data, if that was shown to be somehow better than the OS collecting the data at runtime.
As for the buffer cache: duh, I was merely saying in what high transaction rate scenario a database wouldn't necessarily benefit all that much from SSDs.
The problem is that with Windows, the buck stops at the executable stuff, and even that doesn't encompass plugins and extensions (just look at startup of any modular software package like Acrobat, Eclipse, LibreOffice, Qt Creator).
The programming model doesn't have to be very complex; besides, the basic GUI paradigms call for this very event driven paradigm anyway, it's just that storage is not normally deal with that way. It's not even about what can execute in parallel -- hard drives are serial random access devices, you're not parallelizing anything, just reordering and coalescing serial accesses. Just look at what any run-of-the-mill application does when you fire it up. First it opens and then reads/mmaps a whole bunch of files. That's just to get the executable ready to run. Then it opens and reads even more files -- that's the configuration, plugins, extensions, etc. It'll also perhaps access some mapped out registry pages, perhaps wake a few partially paged out other processes it may interact with, etc. The deal is: a lot of those things do not have to happen in a fixed order, they can be reordered (not parallelized!) by the OS, there's a fixed set of join points where results of the previous operations have to be ready to proceed. Such join points can be made more granular if the developer so wishes (before diminishing returns kick into gear). Parallelizing things is hard, because suddenly there's a whole class of problems that don't exist in serial execution. What I talk about is merely reordering serially executed requests, that's all -- well, first you need to have some requests instead of just one.
Nope, the problem is that software is and was designed as if the hard drives were SSDs, but they weren't. So SSDs do solve a software architecture problem, and a prevalent one. That problem isn't limited to accessing storage, though, and once you solve it, SSDs are not a must have on the run-of-the-mill desktop anymore.
I think you've run into their production run that had a well known issue. I'm not apologizing for them, just stating facts. It's not normal performance, and you're not the only one who had that issue. I find it incredulous that most customers wouldn't even bother trying to figure out what's wrong -- it was a simple problem with the inner-to-outer cyclone seal (the ring in the middle of the bottom of the canister that seals the upper cyclone dirt collector cylinder to the bottom cover of the canister, IIRC).
I guess people won't spend a couple minutes trying to imagine how the damn thing works -- namely that the outer cyclone spins out the big dirt, and the fine dirt gets spun out by the inner cyclones, with the final cleaning done by the foam prefilter and HEPA postfilter. If big dirt gets to the inner cyclones, they obviously don't have capacity to spin that out (they're tiny!), so the prefilter gets clogged up in short order.
The prefilter, in my case, collects occasional hairs and a fine sprinkling of dust that we clean twice a year if we won't forget. The HEPA has been swapped once, probably for no good reason since it's rated for the life of the vacuum. The exhaust side sure looked clean, even if the intake was black -- I think quite a few of that black was graphite from the brushes.
I give Dyson demerits for awful handling of the customers who had this issue -- they pretended the problem didn't exist. If I run into that issue and had to deal with their crap, I'm sure I'd have sour aftertaste, but then I'd have probably figured it out and fixed it myself before getting in touch with anyone. I do usually break warranties. I think every new thing I buy gets torn to pieces soon after it's taken out of the box. How else will one stay current in engineering? ;)
When it comes to Dysons, I think that the ball models are a bit underengineered due to smaller plumbing and smaller motor. The best performance is to be had from full-size uprights -- if you see them in a store, simply select the one that has largest piping and largest canister volume. That's all there's to it.
Kirby has serious issues:
1. Yeah, the pipe is big, but a bigger pipe means slower airflow. Sure it has lower losses in that pipe and the pipe won't clog as easily with large stuff. What it will clog with is fine particulates that will build up over time because air flows too slow. There's a tradeoff between self-cleaning ability of a pipe and its diameter and thus propensity to clog in presence of large particles ("junk"). If you have big junk on the floor, you're supposed to use a shop vac. That one is designed to deal with big junk. If you're OK with carrying around a shop vac, don't buy a Dyson *or* Kirby, duh, but decide what the heck is it that you want. A shop vac is putting that big pipe to a good use. A Kirby, well, just wastes space with that big pipe.
2. The filter. The filter is a joke. Bag anything in a vacuum is a joke in 21st century. You're not supposed to, you know, get dirty while emptying it. In a Dyson you can go up to a couple dozen cleanings between having to clean the canister.
3. The air whatever test: I don't know what the tool purports to test, but sure as heck it doesn't test suction power. Power measured in, you know, units of power, like Watts. Suction power is quite important, because it gives an idea of how much work the air could do (at most) to extract dirt. Generally speaking, the mechanical suction power will always be less than the electrical power consumed from the outlet. So if you have a 7 amp Kirby and a 12 amp Dyson, the Kirby won't ever have the same potential of developing suction power as a Dyson has, unless the Dyson is much less efficient at converting electrical to mechanical power of the air flow (suction). Power in the airflow is given as pressure * flow rate. A tool better be calibrated in Watts if it purports to measure airflow (suction) power.
4. You can't compare apples to oranges. Dirt extraction isn't all about airflow, nor even all about air power. It's a combination of the beater brush performance *and* air power (suction power). All I know is that I had various contemporary vacuums in the 200-500 USD range, all made between 2000 and 2010, and compared to Dyson animal (large canister) they were rather subpar performers.
SSDs are, in case of a typical desktop system, a hardware solution to a software problem. The software problem lies squarely with braindead legacy APIs that last made sense in the 80s. Those are exposed by seemingly every operating system out there. The issue is as follows: when an application accesses storage, it has no way of telling the operating system what are its plans besides the very next access*. The OS can't plan any hard drive access patterns nor do any sort of large-scale elevator access coalescing because, for the most part, it only knows about the very next access a thread wants to do. Using threading as a workaround to this issue is just silly, you don't need multiple threads, just better async and queuing APIs, and programming languages that can actually deal with them.
Say you know that you want to read the entirety of, say, a dozen configuration files, and also want to read some known byte ranges on other files. It's not simple or even possible, as things currently stand, to tell the OS: here's all that I want to do, wake me up when it's all done. There are asynchronous APIs, but those are not in widespread use because widely deployed C-like programming languages are a very poorly suited to dealing with such problems. As in: the code becomes a royal mess. That's why many GUIs get blocked by every file access and whatnot: it's messy to code an event driven application in a C-like language. Clean, linear-flow code becomes fragmented across functions/methods or case sections. Ugh.
On top of that, all higher-level APIs: those that encapsulate file- and network access, almost universally hide the low level operations and do not allow any sort of asynchronous operation from the caller. Just look at every single damn database library: it's all blocking access! Compression libraries: blocking access! File format libraries (scientific, GIS, office, XML, make your pick) -- same thing. There's no way to use such a library to essentially queue a bunch of requests with the OS, that the OS can then elevator sort on, etc.
Same goes for the runtime linkers/loaders: there's no provision, usually, for any sort of parallelism in queueing the file access requests to the OS. The linker/loader will deal with one file at a time: open it, read some of it, process, rinse and repeat, in spite of knowing a priori a large number of such requests that could all be optimally accessed.
Sure, a realtime database system that needs to have lots of random *read* transactions probably must have an SSD, there's no way around it. A realtime system with mostly random writes can use a log, though, data from the log can be fed back to the database pages after being elevator sorted and coalesced as appropriate, trading off battery-backed RAM for HD performance.
*Let's discount the file access hints as those don't make much of a dent in typical use.
s/it's a big deal/it's not a big deal/. Slashdot, seriously, make a time-limited edit button, will you?
I smell FUD, and that's kinda bad in view of the power consumption figures being explicitly stated in *easily* publicly available datasheets
Let's see how much supply current is needed to self-refresh a 1 terabyte of DDR3L SDRAM.
Let's look at 8 gigabits MT41K1G4 chips from Micron. The chip takes 28mA max at 1.35V. That is 37.8mW per 8 gigabits. A terabyte has 8000 gigabits, or 1000x as much -- that's 38W or about as much cooling as a CPU found in someone's desktop PC might dissipate.
If powering and cooling one CPU is "substantial power supply and cooling", then, well, obviously we've got different points of view on this stuff.
Do notice that those chips dissipate more power only if you access them, so 38W is the idle state but even if you *do* access them, you don't dissipate all that much more -- you'll be probably only accessing a couple of chips at a time. The worst case all banks interleaved read current on those chips is 320mA, so if you access 4 chips at a time, that's still only 1.8W of extra power on top of refresh power.
Of course the logic used to piece together all the chips into a storage device will also use up power, but that logic is in idle low-power state when the chips are not being accessed, so it's a big deal.
Borrow a Dyson and see how much crap the Roomba leaves behind -- if you have a carpet, that is. Perhaps it's usable on hard surface floors.
A decent "regular" vacuum is, for me, a Dyson, and those cost right there. The cheapest used one that doesn't run on batteries could be had for about $200 (in a decent shape, for less if it's in bad shape). A new Dyson from the DC Animal family will run about $400. If Dyson ever made a robotic vacuum, it'd probably cost $1000 or more. I can't imagine a decent robotic one costing much less. Do note that a decent vacuum cleaner must have good beater brushes and a powerful, two stage cyclone-based air filtration system with a HEPA filter on the output (or three stage w/o HEPA). It can all be scaled down in size, but it will be loud as hell, and will run hot.
It's no biggie to have a 1kW turbine and a double (Dyson standard) or even triple cyclone in an enclosure the size of a Roomba, but I don't know where the heck will the batteries fit. The shaft will probably turn at 20k to 30k RPM, otherwise the motor and turbine would be too big. It might need a muffler on the exhaust, seriously, otherwise the whine will make your teeth hurt.
Never mind that you'd probably want 250Wh battery capacity at a minimum (so that it can vacuum for 10 minutes). With derating for battery life in hot operating conditions, 300-350Wh is more like it. That battery would probably cost a good chunk of change all in itself.
It'd be OK to use it when you're not in at home, but you wouldn't want to be around that thing when it's doing the job. Roomba is, performance-wise, a joke. If you want to know how bad it is, if you're cleaning your carpets using one, borrow a Dyson and see how much crap it'll pick up.
Air resistance is pretty much negligible -- it affects the structural and thermal engineering of the spacecraft, but it's a small figure in the overall energy budget of leaving Earth. All you really care for is orbital velocity, that's where all the energy goes. Once you've got enough velocity, your orbit is a parabola and you're free. When you're looking at a fuel budget for any spacecraft, for the first approximation you need to look at the change in velocity and the available specific impulse of the engine, and put that into the rocket equation. Air resistance can be safely neglected at that point, it'll IIRC change things by less than 10%.
This is changing, and changing quickly. SpaceX is revolutionizing this industry -- right now, as we speak, and for costs that are pretty much unheard of. They would very gladly give you an orbital ride in a year or two, for money that makes the space shuttle costs seem, well, astronomical in comparison.
Ah, the mythical CEO strawman ;) In theory you're completely right. In practice: such people don't seem to exist.
There is no such thing as "working" hard when you make more in a year than a middle class person makes in their entire lifetime. Human performance doesn't scale up that far, we're talking multiple orders of magnitude. On the way down from middle class you can of course slack as much as you want, but on the way up -- you know, a day only has 24 hours, no matter how bright you are, you can only do so much before you start, effectively, exploiting others.
I've done a few rolls of 60 ISO 60x60mm (start to finish, developing the negative and enlargements myself) and that's sure as heck a different medium. The largest enlargement I could make is approx. A4 paper size, and it looked pretty damn stunning in spite of a very amateurish process and conditions. That was back in elementary school, I haven't touched it for 2 decades since :(
I do understand that definitions don't mean much, but presumably metallurgy and material science has ways of dealing with such problems -- again, timescale and temperature is what matters. Room temperature is of course a fantasy for hard drives, I'd conservatively do any gas leakage estimations at +70C surface temperature for the cover -- then you can be pretty damn sure you won't have a big recall in a couple of years :)
Nope. That's the beauty of membranes. That's why your kidneys work.
And since partial pressure of helium in our atmosphere would IIRC pass for 1st stage vacuum, I wouldn't worry about the inside having any practical amounts of helium left. It will be evacuated, for all purposes.