Well... unless you have some kind of direct-drive setup, you still need the high-RPM performance. Torque to get off the line is great, but if it trails off at higher motor speeds it's not much use. (It's great for a freight truck I suppose. Not for a car.)
Anyway, I'm not disputing your main point; I've seen writeups for several electric cars that have terrific 0-60mph specs/torque figures. And you can see some that plainly have a flat torque curve across their operating range, which means not just awesome torque off the line but also awesome power...
Once you get into the low-wattage incandescent bulbs, you'll find that LEDs actually *are* more efficient. But for large-scale area lighting, fluorescents are still the best. From 10-25W incandescents you will get the same amount of light using only 3-4W of LEDs.
Solar power is not powerful enough to power a car. Solar power efficiency needs to increase by a factor of about 200 before that will be practical. *That* is the main reason solar power is not used in cars today...
(Do the math yourself if you don't believe me. How much horsepower does your car's engine produce? Convert that to Watts (746 watts per hp) and figure out how many solar panels you need to produce that power...)
Powering the house, OK. Surplus electricity for an electric car, doubtful. I've yet to see a PV array of compact size that is capable of powering a typical car.
I drive a 3000lb Sport Compact, with about a 170hp engine. There's 746 watts per hp, so that's 127KW of electricity needed for the equivalent performance. A good PV panel produces 4-6W of power per square foot in full sunlight. My car is about 15 feet long and 5.8 feet wide, giving a total horizontal surface area of about 87 square feet. If the entire surface of the car was covered in PV panels it would produce (at best) around 522W of electricity, about 0.7hp. 522W would certainly power a fair number of electrical accessories, but not a car.
The rooftop of a house is of course larger; I figure my garage roof is 3x the area of the car, and the house is probably 2x that again. So maybe a rooftop PV array can produce 3KW of electricity. Again, that's enough to run a number of domestic appliances, but forget about powering an electric car. Even if this miraculous technology doubles the efficiency of panels, that means 6KW, only 1/20th of what's needed to run a compact car.
I'm totally into solar power for homes, cell phones, and other small electric/electronic devices. But it's never going to be a practical power supply for transportation.
A Bird of Prey would be ok, but how about a couple D7 battlecruisers? And while we're at it, beef up the motor so it can handle more mass, and put a couple laser pointers (green of course) and photosensors on each, so you can play laser-tag while flying them around...
Something I'm not clear on - the articles say "when we're operating at full capacity" which implies to me that this 500 barrels/day is still just a tentative start. How many barrels/day should they see if the full 200 tons/day of waste is processed?
Have you ever registered a trademark? (Apparently not.) I have. You have to provide proof of actual interstate commerce before the mark will be granted. You also have to provide renewed proof after 7 years, otherwise the mark is abandoned.
Not just "name recognition", which implies a nebulous marketing benefit. "Pentium" is a registered trademark, and trademarks have to be used to stay valid. And there's no way they'd abandon any intellectual property, not even a name...
Yeah, I totally identify with this. Reboots were still a pretty infrequent thing for me, and I could use programs like screen to keep my context around if I was just logging off for an evening.
Windows suspend/standby is worthless for this; when the network drivers go to sleep Winsock kills all your connections. (Which, by the way, is a violation of the OSI stack architecture.) And my Win XP laptop has proven to be pretty unreliable after about 2-3 suspend/resume cycles (not to mention the consistent BSOD from the ATI Mobility Radeon driver when I try to use standby/resume. sigh...).
Oh well. You can always customize your.Xsessionrc or whatever to re-establish your persistent telnet sessions and such.
I'm a bit skeptical that running the init scripts in the background will speed things up appreciably. On a box with only a single system disk, spawning a lot of processes at once is only going to thrash the disk and make all of the startup *slower*, especially if those services all start reading their config files, prepping their application caches, etc...
My Windows XP laptop starts up this way, and even after optimizing the disk, startups are slow because of all of the startup programs trying to initialize themselves simultaneously. Yes, Windows has other problems working against it, but the fact remains - multitasking/job control is not the cure for slow system startup.
I never use X on my Linux box, because the startup time to get the X server and a window manager going is too annoying. If you think having that startup in parallel with the regular system init scripts is going to get you logged in faster, you're sadly mistaken. You can't do anything useful until your home directory is mounted anyway, and there's a bunch of network services that you probably need (on my system, named, dhcpd, dhclient, and sshd) before it's worth thinking about.
To me the obvious way to make this fast is to put the boot and root filesystems on a solid state disk. Swap doesn't matter for bootup unless your system is woefully short of main RAM... It's the disk seek time that kills you when you try to start a slew of processes in rapid succession, no matter what your OS.
I play Irish & Scottish fiddle, an ornament is something like a triplet, a grace note, or a roll that is not intrinsic to the melody but played as a variation to augment or ornament a basic note. Grace notes are little more than a flick of a finger over a string. Sometimes in classical music they're written as a 32nd or 64th note. At the tempos I usually play, that means 15-30 milliseconds; a fast 64th note would just turn into a fuzz of white noise on an MP3 track.
Bingo. This fact alone makes the DMCA unconstitutional. By the time the copyright expires, the material will be legitimately copyable but developing the technology to copy it will still be illegal.
Digital format yes, but I would not use any lossy compression like MP3 for archival purposes. I don't use MP3 for general listening either. The fact that its sampling resolution is only 26ms and the music I perform and listen to has ornaments of 50ms or less means that MP3 destroys a lot of fine detail that I worked hard to create. And yes, I can hear the difference, but that's because I am specifically listening for it.
The idea seems to be that the size of DRAM and size of disk are the same. If it were my design, I would leave the disks OFF all the time, and have a large battery in place. Whenever the power switch was turned off, or when AC power was cut, then I'd spin up the disk and flush the RAM out.
There's no reason to have the disks spun up eating electricity and generating heat and noise in normal operation. With today's low-voltage parts, a couple of LiIon batteries could probably keep the entire memory array live for so long you'd never need to flush to disk anyway.
You could do a consumer version using end-of-life slow DRAMs, but it seems that slow DRAM doesn't stay on the market very long after its primary use (PCs) moves on to faster stuff.
With UltraATA topping out at 100MB/sec even the cheapest/slowest available DRAM can keep the interface chugging at full speed 100% of the time. A simple 16 or 32 bit bus clocked at 50 MHz (one 16 bit word per cycle since ATA is only 16 bits wide) will be sufficient.
Throw in a couple batteries (NiMH or LiIon, whatever's cheaper) and you're golden. The amount of power needed to keep the DRAM refreshed is not a big deal...
The question in my mind is whether it would be good enough to use a solid state drive like this all by itself, or whether it should mirror onto a real disk, or whether the memory should just be used as a hardware cache in front of a completely separate disk drive. I think you still get the most bang for the buck by just using it as a big cache for another disk.
That seems rather odd, selecting all records that match a given password. The point of the example is fine, but the example itself is weird.
I used to routinely embed control characters in my passwords (tab, ctrl-C, ctrl-G, ctrl-M, whatever) but then discovered that not all programs performed "raw" input the same way. There's nothing quite so annoying as having your system login program crash (and so deny you access to a system) as you're entering your password, because the program couldn't deal with embedded non-printing characters...
The draft LDAP password policy spec lets you do a lockout after a failed number of attempts, along with an expiration (so the lockout is automatically lifted after a specified idle period). I think that's a decent approach that (a) slows down attackers without (b) making life miserable for users and sysadmins.
Things get trickier when you have a cluster of machines using a distributed authentication service. E.g., you have a bunch of machines using pam_ldap, so all of them are authenticating against a single database. Do you count 3 strikes per client machine, or 3 strikes total in the LDAP database?
Well, that's all great, but the "something you have" is turned into "something you know" by the computer itself. And if all you're doing is logging into a local box so that you can use it to access a remote server or application, then once again you're only dealing in terms of "something you know" (or perhaps, something your computer knows and asserts on your behalf).
It's OK when the electronic security system is just an interface to a physical lock, like an electronic gate control. You seldom/never have interactive command access to the actual computer that operates the lock, so it's relatively safe from hacking. But if you're just logging into a computer for the sake of using that computer, then you can easily extract the transform of "what you have" into "what the computer knows" and propagate it further from there.
Given that AC Propulsion's T-zero has a 300 mile cruising range using LiIon batteries, I'd say we already have as good a battery technology as we need to make a viable electric car today. AC Propulsion
Some of the projects I've contributed to: GCC, Gmake, TCP_Wrapper, Screen, Minix, Linux, BSD, MIT Kerberos, Heimdal, Cyrus SASL, OpenSSL, C-Kermit, etc. etc. etc...
I would never just "Drop off code that I dashed out." Clearly that's not under discussion. The work I contributed has benefited the community at large, but that was not the reason I did the work. I fixed bugs because they inconvenienced me. I added features because I needed them, not because some amorphous community out there whined at me to do it.
re: wannabe software developers - quality was never an issue anywhere in this discussion. Clearly software that crashes or simply doesn't work is no good to anyone.
I think this is a very misguided view of motivation. I've been writing open source software for nearly twenty years now, and in every case the reason I bother is simply because the software I want to use doesn't exist, therefore I write it.
For the developers I've met, the reason is the same - I have a problem that needs solving, there is nothing available that solves it, so I'll write the solution. When I'm done, I post it on the off-chance that it might help someone else down the road. Bragging rights are inconsequential, all I want is to solve my problem and move on.
There are a number of observations made in the paper that seem reasonably close to the mark, but without understanding this most basic motivation, nothing else makes sense.
Yes, we program for ourselves. That's the absolute, undeniable truth. We embark on a project because it is interesting to us. We neglect the documentation for the project because we obviously already understood the problem space, otherwise we wouldn't be writing a solution to it. Dcumentation doesn't serve our needs. It serves someone else's needs. I don't care about someone else's needs, I want to solve my own problem. Period.
If you want me to look at your problem as if it were my problem, you need to give me a good reason to do so, because I have plenty more problems of my own to deal with.
You seem to have the mistaken notion that a developer cares about who else can use the code. That is very seldom the case. If I have a problem (an itch) that motivates me to write a software solution to it, all that matters to me is that it solves my problem (scratches my itch). When I'm done with this solution, I may post it/distribute it freely on the off-chance that it may be useful to someone else. That's as far as my consideration of other users gets, and that's as far as it needs to go, because I've got other work to do, other problems to solve.
Whether or not my software is useful to you is *your* problem. If you want me to look at your problem *as if* it were my problem, you have to give me a good reason. Otherwise, I will continue on my way, merrily solving *my* problems.
Slashdot Mirror
Well... unless you have some kind of direct-drive setup, you still need the high-RPM performance. Torque to get off the line is great, but if it trails off at higher motor speeds it's not much use. (It's great for a freight truck I suppose. Not for a car.)
Anyway, I'm not disputing your main point; I've seen writeups for several electric cars that have terrific 0-60mph specs/torque figures. And you can see some that plainly have a flat torque curve across their operating range, which means not just awesome torque off the line but also awesome power...
Once you get into the low-wattage incandescent bulbs, you'll find that LEDs actually *are* more efficient. But for large-scale area lighting, fluorescents are still the best. From 10-25W incandescents you will get the same amount of light using only 3-4W of LEDs.
Solar power is not powerful enough to power a car. Solar power efficiency needs to increase by a factor of about 200 before that will be practical. *That* is the main reason solar power is not used in cars today...
(Do the math yourself if you don't believe me. How much horsepower does your car's engine produce? Convert that to Watts (746 watts per hp) and figure out how many solar panels you need to produce that power...)
Powering the house, OK. Surplus electricity for an electric car, doubtful. I've yet to see a PV array of compact size that is capable of powering a typical car.
I drive a 3000lb Sport Compact, with about a 170hp engine. There's 746 watts per hp, so that's 127KW of electricity needed for the equivalent performance. A good PV panel produces 4-6W of power per square foot in full sunlight. My car is about 15 feet long and 5.8 feet wide, giving a total horizontal surface area of about 87 square feet. If the entire surface of the car was covered in PV panels it would produce (at best) around 522W of electricity, about 0.7hp. 522W would certainly power a fair number of electrical accessories, but not a car.
The rooftop of a house is of course larger; I figure my garage roof is 3x the area of the car, and the house is probably 2x that again. So maybe a rooftop PV array can produce 3KW of electricity. Again, that's enough to run a number of domestic appliances, but forget about powering an electric car. Even if this miraculous technology doubles the efficiency of panels, that means 6KW, only 1/20th of what's needed to run a compact car.
I'm totally into solar power for homes, cell phones, and other small electric/electronic devices. But it's never going to be a practical power supply for transportation.
A Bird of Prey would be ok, but how about a couple D7 battlecruisers? And while we're at it, beef up the motor so it can handle more mass, and put a couple laser pointers (green of course) and photosensors on each, so you can play laser-tag while flying them around...
You seem to have missed the fact that a fair amount of material that comes out isn't oil, and is in fact used for fertilizer.
Something I'm not clear on - the articles say "when we're operating at full capacity" which implies to me that this 500 barrels/day is still just a tentative start. How many barrels/day should they see if the full 200 tons/day of waste is processed?
Have you ever registered a trademark? (Apparently not.) I have. You have to provide proof of actual interstate commerce before the mark will be granted. You also have to provide renewed proof after 7 years, otherwise the mark is abandoned.
Not just "name recognition", which implies a nebulous marketing benefit. "Pentium" is a registered trademark, and trademarks have to be used to stay valid. And there's no way they'd abandon any intellectual property, not even a name...
What makes you think that? Why wouldn't you want to put a Pentium-M into a desktop machine?
Yeah, I totally identify with this. Reboots were still a pretty infrequent thing for me, and I could use programs like screen to keep my context around if I was just logging off for an evening.
.Xsessionrc or whatever to re-establish your persistent telnet sessions and such.
Windows suspend/standby is worthless for this; when the network drivers go to sleep Winsock kills all your connections. (Which, by the way, is a violation of the OSI stack architecture.) And my Win XP laptop has proven to be pretty unreliable after about 2-3 suspend/resume cycles (not to mention the consistent BSOD from the ATI Mobility Radeon driver when I try to use standby/resume. sigh...).
Oh well. You can always customize your
I'm a bit skeptical that running the init scripts in the background will speed things up appreciably. On a box with only a single system disk, spawning a lot of processes at once is only going to thrash the disk and make all of the startup *slower*, especially if those services all start reading their config files, prepping their application caches, etc...
My Windows XP laptop starts up this way, and even after optimizing the disk, startups are slow because of all of the startup programs trying to initialize themselves simultaneously. Yes, Windows has other problems working against it, but the fact remains - multitasking/job control is not the cure for slow system startup.
I never use X on my Linux box, because the startup time to get the X server and a window manager going is too annoying. If you think having that startup in parallel with the regular system init scripts is going to get you logged in faster, you're sadly mistaken. You can't do anything useful until your home directory is mounted anyway, and there's a bunch of network services that you probably need (on my system, named, dhcpd, dhclient, and sshd) before it's worth thinking about.
To me the obvious way to make this fast is to put the boot and root filesystems on a solid state disk. Swap doesn't matter for bootup unless your system is woefully short of main RAM... It's the disk seek time that kills you when you try to start a slew of processes in rapid succession, no matter what your OS.
I find PDFs to be not much nicer really. They're still an awful lot of bloat when it comes to getting a simple point across.
I play Irish & Scottish fiddle, an ornament is something like a triplet, a grace note, or a roll that is not intrinsic to the melody but played as a variation to augment or ornament a basic note. Grace notes are little more than a flick of a finger over a string. Sometimes in classical music they're written as a 32nd or 64th note. At the tempos I usually play, that means 15-30 milliseconds; a fast 64th note would just turn into a fuzz of white noise on an MP3 track.
Bingo. This fact alone makes the DMCA unconstitutional. By the time the copyright expires, the material will be legitimately copyable but developing the technology to copy it will still be illegal.
Digital format yes, but I would not use any lossy compression like MP3 for archival purposes. I don't use MP3 for general listening either. The fact that its sampling resolution is only 26ms and the music I perform and listen to has ornaments of 50ms or less means that MP3 destroys a lot of fine detail that I worked hard to create. And yes, I can hear the difference, but that's because I am specifically listening for it.
The idea seems to be that the size of DRAM and size of disk are the same. If it were my design, I would leave the disks OFF all the time, and have a large battery in place. Whenever the power switch was turned off, or when AC power was cut, then I'd spin up the disk and flush the RAM out.
There's no reason to have the disks spun up eating electricity and generating heat and noise in normal operation. With today's low-voltage parts, a couple of LiIon batteries could probably keep the entire memory array live for so long you'd never need to flush to disk anyway.
You could do a consumer version using end-of-life slow DRAMs, but it seems that slow DRAM doesn't stay on the market very long after its primary use (PCs) moves on to faster stuff.
With UltraATA topping out at 100MB/sec even the cheapest/slowest available DRAM can keep the interface chugging at full speed 100% of the time. A simple 16 or 32 bit bus clocked at 50 MHz (one 16 bit word per cycle since ATA is only 16 bits wide) will be sufficient.
Throw in a couple batteries (NiMH or LiIon, whatever's cheaper) and you're golden. The amount of power needed to keep the DRAM refreshed is not a big deal...
The question in my mind is whether it would be good enough to use a solid state drive like this all by itself, or whether it should mirror onto a real disk, or whether the memory should just be used as a hardware cache in front of a completely separate disk drive. I think you still get the most bang for the buck by just using it as a big cache for another disk.
That seems rather odd, selecting all records that match a given password. The point of the example is fine, but the example itself is weird.
I used to routinely embed control characters in my passwords (tab, ctrl-C, ctrl-G, ctrl-M, whatever) but then discovered that not all programs performed "raw" input the same way. There's nothing quite so annoying as having your system login program crash (and so deny you access to a system) as you're entering your password, because the program couldn't deal with embedded non-printing characters...
The draft LDAP password policy spec lets you do a lockout after a failed number of attempts, along with an expiration (so the lockout is automatically lifted after a specified idle period). I think that's a decent approach that (a) slows down attackers without (b) making life miserable for users and sysadmins.
Things get trickier when you have a cluster of machines using a distributed authentication service. E.g., you have a bunch of machines using pam_ldap, so all of them are authenticating against a single database. Do you count 3 strikes per client machine, or 3 strikes total in the LDAP database?
Well, that's all great, but the "something you have" is turned into "something you know" by the computer itself. And if all you're doing is logging into a local box so that you can use it to access a remote server or application, then once again you're only dealing in terms of "something you know" (or perhaps, something your computer knows and asserts on your behalf).
It's OK when the electronic security system is just an interface to a physical lock, like an electronic gate control. You seldom/never have interactive command access to the actual computer that operates the lock, so it's relatively safe from hacking. But if you're just logging into a computer for the sake of using that computer, then you can easily extract the transform of "what you have" into "what the computer knows" and propagate it further from there.
Given that AC Propulsion's T-zero has a 300 mile cruising range using LiIon batteries, I'd say we already have as good a battery technology as we need to make a viable electric car today.
AC Propulsion
Some of the projects I've contributed to: GCC, Gmake, TCP_Wrapper, Screen, Minix, Linux, BSD, MIT Kerberos, Heimdal, Cyrus SASL, OpenSSL, C-Kermit, etc. etc. etc...
I would never just "Drop off code that I dashed out." Clearly that's not under discussion. The work I contributed has benefited the community at large, but that was not the reason I did the work. I fixed bugs because they inconvenienced me. I added features because I needed them, not because some amorphous community out there whined at me to do it.
re: wannabe software developers - quality was never an issue anywhere in this discussion. Clearly software that crashes or simply doesn't work is no good to anyone.
I think this is a very misguided view of motivation. I've been writing open source software for nearly twenty years now, and in every case the reason I bother is simply because the software I want to use doesn't exist, therefore I write it.
For the developers I've met, the reason is the same - I have a problem that needs solving, there is nothing available that solves it, so I'll write the solution. When I'm done, I post it on the off-chance that it might help someone else down the road. Bragging rights are inconsequential, all I want is to solve my problem and move on.
There are a number of observations made in the paper that seem reasonably close to the mark, but without understanding this most basic motivation, nothing else makes sense.
Yes, we program for ourselves. That's the absolute, undeniable truth. We embark on a project because it is interesting to us. We neglect the documentation for the project because we obviously already understood the problem space, otherwise we wouldn't be writing a solution to it. Dcumentation doesn't serve our needs. It serves someone else's needs. I don't care about someone else's needs, I want to solve my own problem. Period.
If you want me to look at your problem as if it were my problem, you need to give me a good reason to do so, because I have plenty more problems of my own to deal with.
You seem to have the mistaken notion that a developer cares about who else can use the code. That is very seldom the case. If I have a problem (an itch) that motivates me to write a software solution to it, all that matters to me is that it solves my problem (scratches my itch). When I'm done with this solution, I may post it/distribute it freely on the off-chance that it may be useful to someone else. That's as far as my consideration of other users gets, and that's as far as it needs to go, because I've got other work to do, other problems to solve.
Whether or not my software is useful to you is *your* problem. If you want me to look at your problem *as if* it were my problem, you have to give me a good reason. Otherwise, I will continue on my way, merrily solving *my* problems.