>
> Karl,
>
>I beleive the word you're seeking is auditing
>
No actually, I meant journaling as in ext3, etc. As long as we're overhauling things, I figured this could be a very useful feature for servers. I alluded to this only breifly in the third paragraph.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
As long as they authored all of the code, they can re-release the source under any liscence they want. It's that simple.
This is how some code is distributed in a GPL form and a BSDL form. The authors just take their source code and slap a different comment section at the top. It may or may not be put under the GPL as the last step before release. In any case, as long as they authored 100% of the code, they can remove one liscence and slap on another. OF course, this doesn't affect previously released code. ("Oops! Just kidding, delete that GPLed code from your HD" doesn't hold water.)
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Is the tripwire database file itself similar to "off-the-shelf" databse formats, or did they design thier own database format from scratch?
Their database seems like the greatest potential gain for the community. The hashing of files is pretty simple, given the number of crytographically strong open-source hashes out there. The UI/customization end of tripwire seems like it would be relatively straightforward to design. It seems to me that most of the room for real software engineering is in the database file format.
People have already created driver-level crypto filesystems, but has anyone ever proposed a driver-level tripwire filesystem? Of course, you would need to tell the fs whcih files and directories to keep track of or you would be swamped with change logs.
Has anyone ever proposed a secured journaling filesystem? While we're replacing/overhauling the Linux filesystem, we might as well add secure functionality. (Assuming we don't cause a false sense of security.) Setting a file attribute flag to secure could cause any changes to the file or directory (including mv and cp) to be logged in a compact format. Any changes in the secure-log flag for all files in the fs would also have to be logged. In ultra-paranoid environments, one could even securely log file reads. (It's not that much more work to include this in a new driver.) Use an itterative one-time password scheme to watermark the logs (even a 64 bit hash would be relatively secure, because of the number of hashes that would need to be matched to change logs very far back in time). The easiest way to sign the hash is just to encrypt it with the one-time password. You keep the first one-time password on a locked floppy, along with a copy of the executable for checking the logs and computing the hashes of the files stored in the logs (add a hash to the logifile only when something changes). With the first password, you can compute the second, with the second you can compute the third, etc. This means that you can decrypt all of the hashes of the logfile if you have the floppy.
On the other hand, if the filesystem driver keeps only the current one-time password, then any attacker will be detected if s/he alters the logs for any time earlier than when they broke in. (Since creating the correct hashes requires knowing the password for that time, and passwords for earlier times cannot be computed from passwords for later times.) You can keep snapshots of the logfile if you like, but they are not necessary for intrusion detection. One only needs to first check the integrity of the logfile, then trace through the changes according to the logfile. Any discrepincies between a file and it's last recorded hash indicate file corruption or a security breach. People could "turn back the clock" on the filesystem by changing the files back to a previous state and deleting any logs since, but any subsequent changes to the fs would be logged with the wrong one-time-password and this would be detected.
First pos.. wow that took a while to write and revise! I'm surprised you actually read this far.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
One advantage of virtualization is that the hardware yo simulate doesn't need to exist in reality. For instance: a graphics card that is sent higher-level information (as in the driver passes whatever it gets from X directly to the card) would greatly speed up the graphics display of Linux inside Linux. I'm sure there are many other cases where "pass-through" drivers (the driver sends the data it gets diretly to hardware, verbatim)would be usefull.
Merging Wine into this situation, it would be usefull to use a pass-through driver translate (guest machine) Windows API graphics calls to X graphics calls on the host machine.
Writing "pass through" drivers should be easy as cake for any OS. Then the work becomes writing the libraries to translate the APIs.
Thus, one could create a hybrid system of virtualization (like a pass-through app that replaces the kernel) and API duplication (libary to translate the kerenel and library calls to host OS calls). Thus, you can work from both ends of the spectrum. Use Wine for what it does well (speed)
and use plex86 for what it does well (sandbox, compatibility by using the original API handlers). If the Wine implementation is poor at something, then let Windows handle that part inside of plex86. Given this approach, plex86 would eventually allow you to mix and match Wine and M$ (sandboxed) solutions. Of course, this also extends to other OSes.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
My best guess is that he has an iOpener or WebSurfer he wants to make into a firewall.
How well locked-down is the QNX configuration on iOpeners? Can you modify the OS from within the OS, or do you have to download the "normal" version onto a computer with a flash writer and
overwrite the original installation? Is there such thing as the superuser in QNX? Does the superuser account exist on iOpeners? Anybody cracked the password yet?
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
You're referring to fiber optic gyros. My understanding is that they look at the interference pattern of light beems traveling in opposite directions arround a ring and you can easily figure out how fast it's rotating.
Ring laser gyros are a similar technology. These may be based on dopler shift. I'm not too sure about how these work.
There are also quartz oscilating gyroscopes. I believe Cadilac uses these as yaw rate sensors in thier traction control systems. Baically, you use the piezoelectric effect to drive oscilations in one direction. The coreolis effect will cause oscilations in a second deirection if the device is rotated.
I worked with silicon oscilating gyroscopes last Summer. They are similar to quartz olscilating gyros, except that electical attraction is used in driving the oscilations. There are a lot of really cool details that go into designing these things. Unfortunately, my NDA keeps me from saying much more. Work with this stuff if you get the chance. A lot of really cool engineering goes into them, IMHO.
Pendular integrating gyroscopic accelerometers are another very interesting sensor. The Germans used them in thier V2 rockets in order to kill the engine at a specified velocity (this is where the integrating characteristic of the acceleromiter pays off). AFAIK, all US strategic missles use PIGAs.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
The Boston Museum of Science has a stationary version of this. If you move your eyes side to side fast enough, you can see the image made by the verticle line of flashing lights. It sounds like a hoax, but I've seen the image. I guess your brain lets the timing of your eyes vary until you see a recognizable image, at which point your brain automatically syncs your eyes to teh image. The MIT COOP (bookstore) used to sell a stationary version of this as well, but I never put enough effort into reading theirs.
Offtopic: Is it just me, or is there an extreme concentration of MIT people on/. ? Oh well, back to 6.170.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Boston.com and The Washignton Post both report that Commander Brian Duffy had to dock the shuttle without the aide radar (broken since Thurs.), so the crew used stellar navigation and a hand-held laser system.
I watched the launch on space.com. I thought I remembered them having thermal issues with APU number 2, so it was shut down before the other two APUs. Anybody else catch this? When was the last time they did a compete design audit on the shuttle? Granted it's a very complex system, but it seems that they have more problems than I would be comfortable with.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Has anyone archived the SDMI materials? (On a server outside U.S. jusidiction?)
I, for one, would like to play arround with them.
Too bad they got yanked from the website.
Actually, if they keep the materials online, won't it increase interest if they set up a hack_sdmi_II? Or at least it will get them some free research into watermarks.
Think about it:
release the contest materials without EULA
watch a few newsgroups/webites/bbses for all the different cracks that show up
watch the net for discussion of what worked and what didn't
design next watermark accordingly
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
What I'd really like to see is a userspace HURD running on the Linux kernel.
As it stands, if I want to keep HURD out of my hardware, I need to set up Debian Linux inside VMWare, then use that
Debian installation to install HURD inside the VMWare session. A userspace HURD would also require less time to boot than booting through a VMWare session.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Think about what you would do if you were Apple and discovered that your MacOS ran faster when ported to x86. It would seem to me that you would simply slighlty cripple the code. As long as you never resleased the source code, you could make the Motorolla hardware appear faster than the x86 hardware. That way you could sell your x86 version of the OS and make some money. If people liked the OS, thier next hardware purchase would be a Motorolla-Mac in order to run the OS faster. You could actually use the OS to win converts to your hardare, even if the x86 hardare ORIGINALLY ran the OS faster. Of course, this ploy goes out the window with the open-souced Darwin.
The alternative would be to waste the man-hours already invested in porting the OS by scrapping the project.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Don't forget that the celeron IIs are FCPGA (the chip is flipped, so equivalent pins are in different locations on the array), not PPGA, so hopefully ABIT or someone will come out with a FCPGA to PPGA "slocket".
I'd really like to see ABIT come out with a redesigned BP6 for FCPGA chips. I'd hate to have to get a higher priced dual slot-1 board in order to run SMP Celeron IIs with slockets.
On the other hand, for those brave-but-stupid people out there, you can work on your technique for hammering those pins back out the other side of the package to convert an FCPGA to a PPGA chip 8-o.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
I despise Intel's dominance as much as anyone, but claims of AMD's absolute superiority don't hold much water. AMD is currently king of floating point for the x86 architecture, however, overclockability, power consumption, cache speed, operating temps all leave something to be desired.
I'm not sure about the 1GHz machines, but AMD was having real problems with thier caches, at least when the 800 MHz Athlons came out. They ended up setting the cache multipliers at 3/8. If you're doing hard core rendering and simulation, you'll want an Athlon, but you'll also want to be running an SMP machine. Unfortunately, there aren't a lot of SMP Athlon machines out there.
If, on the other hand, you're looking at gaming. I beleive the video card is the current bottleneck in a high performace gaming system. The Athlon/PII decision becomes a mattter of personal preference.
Database manipulation and general OS tasks would seem to be where the PII would shine, given that it's cache multiplier is 1. That whole cache multiplier problem is going to be a real big problem for AMD if they don't get it figured out soon.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
A few comments on a few of the ideas floating arround here. My electric vehicle knowledge is about two years old. However, most of my info somes from my experience on the MIT Solar Electric Vehicle team, so most of it should still be applicable for anything priced for the consumer market.
Right now, IMHO, the best candidates for near-term energy storage in EVs are ultracapictors and flywheels. Both have a clear advantage over batteries in terms of discharge rates. Ultracapicitors currently have energy density issues and flywheels have some efficiency issues. However, flywheels have the advantage of requiring a controller to convert to and from kinetic energy. It would be relatively easy for the controller to be linked to the power management computer via a digital command coax. In an accident, there would be very little risk of electrical disharge, even if the output terminals are shorted.
I eas very surprised at the ammount of noise an MGM wheel-hub motor makes, especially considdering that it's 98% efficient, IIRC. I believe that most air-cooled brushless DC motors would have a similar noise level. There is a clacking noise generated that is load enough to get anoying inside the unshielded body of the Manta GT sloar race car. The stator coils contract slightly when energized becasue the individual windings are attracted to eachother. Most of the motor controller inefficiencis result from its inability to generate perfect square wave outputs. Rise times kill effiency. This means that the input to the coils will be as sharp a feasably possible, whcih means that the contraction of a coil will probably produce an audible "clack" if there is no insulating medium (such as liquid coolant ductwork) between the listener and the coil. When I first heard it, I thought there was a piece of plastic in contact with the rotor because it sounded like a playing card clacking on a bike spoke. Granted, an electric motor will be quieter than a comparable IC engine, especially an unmuffled nitromethane engine with racing cams. Don't be fooled into thinking that electric cars are necessarily silent, though.
About the constant-torque issue: it is true that most brushless DC motors develop nearly constant torque over thier entire RPM range. However, this is sub-optimal. The near constant torque arises from constant clearance between the rotor and the stator coils. The maximum RPM is also determined by the back-EMF, which is affected greatly by the rotor clearance. There is an optimum clearance for a given set of operating paramiters, so many of the more advanced motors have an actuator that moves the stator back and forth in order to continually optimize the rotor clearance for efficiency. So it actually turns out that the optimum torque curve decreases with RPM. Right now, however, manually adding shims to the motor controls rotor clearance more accurately than an actuator that adjusts clearance dynamically. Since most of the time durring solar car races is spent on highways, cruising right at the speed limit, it's most efficient for the MIT Manta GT to have the rotor clearnce set for cruising speed by dissasembling the motor in lab and adding or removing shims. The extra efficiency gained at cruising speed more than makes up for the inability to continuosly optimize the motor.
On a side note, don't assume that exotic processes and materials are better. Take for instance, the University of Michigan's solar car frame is made of titanium. (At least a few years ago it was.) Titanium is light weight, but very difficult to work with. Titanium is notoriusly expensive and comparitively expensive to work with. It is also imposible to design Titanium for an infinite fatigue life. (The maximum vibration allowable amplitude asymptotically aproaches zero as designed fatigue life approaches infinity. For most steels, however, the allowable amplitude asymptotically appraoches a positive value. Trust me, I spent an entire semster at MIT learning about crack growth and fatigue.) I'm told that the University of Michigan's Ti frame weighed only seven pounds less than the MIT ChroMolly steel frame. Which is more reliable? Which cost less? How many pounds are you willing to shave at eh cost of money and reliability?
Karl
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Okay, so if 20K U.S. is too large for your pet project, set up the <Yourname> Endowment for Opensource Development.
My understanding is that you still get the tax break (Laws may very in your country). This is my understanding: You set up a modest fund. The principal slowly grows over time, and they skim off money yearly for donations to non-profit orgs. A small percentage "skimmed" for donations means that the principal will grow faster, meaning that the integral of the money given to open source over a long time is larger, but the short term donations are very small. You set up the rules for deciding who gets the donations, etc.
IMHO, this is the best way to contribute to the future of OpenSource. If you make a bad decission one year, you didn't throw all of your donation down the tube, there's still money for next year. You ensure that your donation gets invested instead of being spent on short-sighted goals that may not pan out.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Perhapse we'll have to just agree to disagree, but there are many of us who find something aesthetically wrong with laws that don't directly pertain to the crimes they're trying to prevent.
From my point of view, there are two camps on this issue. The realists and the idealists. The realists argue for piling on more charges, such as tool posession, in order to ensure that a criminal does some time. The idealists argue that a criminal should be charged only for actions comitted, and burglary tools should be legal to posess.
Philosophical Discourse: On this issue, I happen to belong to the latter camp. I believe in goal-driven management, not method-driven management. (I am the house manager for my fraternity. I tell Jon that the trash must not overflow the trash can, we cannot have flies or rats feasting, etc. I do not tell Jon to use a square knot to close the bags, etc.)
I believe that the government, as an UberManager, should by extension, legislate and mandate based on goals, not methodological details. Power plants should be required to keep SO2 emissions below a certain level, but not required to install foo-type exhaust processors. I beleive this has a certain asthetic appeal. I believe charging criminals for crimes but not tool posestion has this same aesthetic appeal.
In short, I think charging a malicious hacker with possesion of l0pht crack is a poor way to go about the business of prosecution. I also tend to agree with the slippery-slope arguments floating arround this thread. Enumerating on them further would be a waste of time, IMHO.
Sidenote: As far as the crack pipe analogy, be careful about the word *only*. "The *only* use of spare change is economic exchange" is a false statement. I have used dimes as screwdrivers. People make jewelry and collections our of coins. I would imagine there are a few individuals who find crack pipes beautiful, but don't use crack themselves. There may be a legitimate reason to collect crack pipes.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Slashdot Mirror
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
This is how some code is distributed in a GPL form and a BSDL form. The authors just take their source code and slap a different comment section at the top. It may or may not be put under the GPL as the last step before release. In any case, as long as they authored 100% of the code, they can remove one liscence and slap on another. OF course, this doesn't affect previously released code. ("Oops! Just kidding, delete that GPLed code from your HD" doesn't hold water.)
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Their database seems like the greatest potential gain for the community. The hashing of files is pretty simple, given the number of crytographically strong open-source hashes out there. The UI/customization end of tripwire seems like it would be relatively straightforward to design. It seems to me that most of the room for real software engineering is in the database file format.
People have already created driver-level crypto filesystems, but has anyone ever proposed a driver-level tripwire filesystem? Of course, you would need to tell the fs whcih files and directories to keep track of or you would be swamped with change logs.
Has anyone ever proposed a secured journaling filesystem? While we're replacing/overhauling the Linux filesystem, we might as well add secure functionality. (Assuming we don't cause a false sense of security.) Setting a file attribute flag to secure could cause any changes to the file or directory (including mv and cp) to be logged in a compact format. Any changes in the secure-log flag for all files in the fs would also have to be logged. In ultra-paranoid environments, one could even securely log file reads. (It's not that much more work to include this in a new driver.) Use an itterative one-time password scheme to watermark the logs (even a 64 bit hash would be relatively secure, because of the number of hashes that would need to be matched to change logs very far back in time). The easiest way to sign the hash is just to encrypt it with the one-time password. You keep the first one-time password on a locked floppy, along with a copy of the executable for checking the logs and computing the hashes of the files stored in the logs (add a hash to the logifile only when something changes). With the first password, you can compute the second, with the second you can compute the third, etc. This means that you can decrypt all of the hashes of the logfile if you have the floppy.
On the other hand, if the filesystem driver keeps only the current one-time password, then any attacker will be detected if s/he alters the logs for any time earlier than when they broke in. (Since creating the correct hashes requires knowing the password for that time, and passwords for earlier times cannot be computed from passwords for later times.) You can keep snapshots of the logfile if you like, but they are not necessary for intrusion detection. One only needs to first check the integrity of the logfile, then trace through the changes according to the logfile. Any discrepincies between a file and it's last recorded hash indicate file corruption or a security breach. People could "turn back the clock" on the filesystem by changing the files back to a previous state and deleting any logs since, but any subsequent changes to the fs would be logged with the wrong one-time-password and this would be detected.
First pos.. wow that took a while to write and revise! I'm surprised you actually read this far.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Merging Wine into this situation, it would be usefull to use a pass-through driver translate (guest machine) Windows API graphics calls to X graphics calls on the host machine.
Writing "pass through" drivers should be easy as cake for any OS. Then the work becomes writing the libraries to translate the APIs.
Thus, one could create a hybrid system of virtualization (like a pass-through app that replaces the kernel) and API duplication (libary to translate the kerenel and library calls to host OS calls). Thus, you can work from both ends of the spectrum. Use Wine for what it does well (speed) and use plex86 for what it does well (sandbox, compatibility by using the original API handlers). If the Wine implementation is poor at something, then let Windows handle that part inside of plex86. Given this approach, plex86 would eventually allow you to mix and match Wine and M$ (sandboxed) solutions. Of course, this also extends to other OSes.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
I'd be doing the same thing... If I wasn't running a PII 266 w/ 288 Mb of RAM.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
How well locked-down is the QNX configuration on iOpeners? Can you modify the OS from within the OS, or do you have to download the "normal" version onto a computer with a flash writer and overwrite the original installation? Is there such thing as the superuser in QNX? Does the superuser account exist on iOpeners? Anybody cracked the password yet?
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
You're referring to fiber optic gyros. My understanding is that they look at the interference pattern of light beems traveling in opposite directions arround a ring and you can easily figure out how fast it's rotating.
Ring laser gyros are a similar technology. These may be based on dopler shift. I'm not too sure about how these work.
There are also quartz oscilating gyroscopes. I believe Cadilac uses these as yaw rate sensors in thier traction control systems. Baically, you use the piezoelectric effect to drive oscilations in one direction. The coreolis effect will cause oscilations in a second deirection if the device is rotated.
I worked with silicon oscilating gyroscopes last Summer. They are similar to quartz olscilating gyros, except that electical attraction is used in driving the oscilations. There are a lot of really cool details that go into designing these things. Unfortunately, my NDA keeps me from saying much more. Work with this stuff if you get the chance. A lot of really cool engineering goes into them, IMHO.
Pendular integrating gyroscopic accelerometers are another very interesting sensor. The Germans used them in thier V2 rockets in order to kill the engine at a specified velocity (this is where the integrating characteristic of the acceleromiter pays off). AFAIK, all US strategic missles use PIGAs.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Offtopic: Is it just me, or is there an extreme concentration of MIT people on /. ? Oh well, back to 6.170.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
I watched the launch on space.com. I thought I remembered them having thermal issues with APU number 2, so it was shut down before the other two APUs. Anybody else catch this? When was the last time they did a compete design audit on the shuttle? Granted it's a very complex system, but it seems that they have more problems than I would be comfortable with.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
I, for one, would like to play arround with them. Too bad they got yanked from the website.
Actually, if they keep the materials online, won't it increase interest if they set up a hack_sdmi_II? Or at least it will get them some free research into watermarks.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
As it stands, if I want to keep HURD out of my hardware, I need to set up Debian Linux inside VMWare, then use that Debian installation to install HURD inside the VMWare session. A userspace HURD would also require less time to boot than booting through a VMWare session.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Think about what you would do if you were Apple and discovered that your MacOS ran faster when ported to x86. It would seem to me that you would simply slighlty cripple the code. As long as you never resleased the source code, you could make the Motorolla hardware appear faster than the x86 hardware. That way you could sell your x86 version of the OS and make some money. If people liked the OS, thier next hardware purchase would be a Motorolla-Mac in order to run the OS faster. You could actually use the OS to win converts to your hardare, even if the x86 hardare ORIGINALLY ran the OS faster. Of course, this ploy goes out the window with the open-souced Darwin.
The alternative would be to waste the man-hours already invested in porting the OS by scrapping the project.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Don't forget that the celeron IIs are FCPGA (the chip is flipped, so equivalent pins are in different locations on the array), not PPGA, so hopefully ABIT or someone will come out with a FCPGA to PPGA "slocket".
I'd really like to see ABIT come out with a redesigned BP6 for FCPGA chips. I'd hate to have to get a higher priced dual slot-1 board in order to run SMP Celeron IIs with slockets.
On the other hand, for those brave-but-stupid people out there, you can work on your technique for hammering those pins back out the other side of the package to convert an FCPGA to a PPGA chip 8-o.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
I'm not sure about the 1GHz machines, but AMD was having real problems with thier caches, at least when the 800 MHz Athlons came out. They ended up setting the cache multipliers at 3/8. If you're doing hard core rendering and simulation, you'll want an Athlon, but you'll also want to be running an SMP machine. Unfortunately, there aren't a lot of SMP Athlon machines out there.
If, on the other hand, you're looking at gaming. I beleive the video card is the current bottleneck in a high performace gaming system. The Athlon/PII decision becomes a mattter of personal preference.
Database manipulation and general OS tasks would seem to be where the PII would shine, given that it's cache multiplier is 1. That whole cache multiplier problem is going to be a real big problem for AMD if they don't get it figured out soon.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
Right now, IMHO, the best candidates for near-term energy storage in EVs are ultracapictors and flywheels. Both have a clear advantage over batteries in terms of discharge rates. Ultracapicitors currently have energy density issues and flywheels have some efficiency issues. However, flywheels have the advantage of requiring a controller to convert to and from kinetic energy. It would be relatively easy for the controller to be linked to the power management computer via a digital command coax. In an accident, there would be very little risk of electrical disharge, even if the output terminals are shorted.
I eas very surprised at the ammount of noise an MGM wheel-hub motor makes, especially considdering that it's 98% efficient, IIRC. I believe that most air-cooled brushless DC motors would have a similar noise level. There is a clacking noise generated that is load enough to get anoying inside the unshielded body of the Manta GT sloar race car. The stator coils contract slightly when energized becasue the individual windings are attracted to eachother. Most of the motor controller inefficiencis result from its inability to generate perfect square wave outputs. Rise times kill effiency. This means that the input to the coils will be as sharp a feasably possible, whcih means that the contraction of a coil will probably produce an audible "clack" if there is no insulating medium (such as liquid coolant ductwork) between the listener and the coil. When I first heard it, I thought there was a piece of plastic in contact with the rotor because it sounded like a playing card clacking on a bike spoke. Granted, an electric motor will be quieter than a comparable IC engine, especially an unmuffled nitromethane engine with racing cams. Don't be fooled into thinking that electric cars are necessarily silent, though.
About the constant-torque issue: it is true that most brushless DC motors develop nearly constant torque over thier entire RPM range. However, this is sub-optimal. The near constant torque arises from constant clearance between the rotor and the stator coils. The maximum RPM is also determined by the back-EMF, which is affected greatly by the rotor clearance. There is an optimum clearance for a given set of operating paramiters, so many of the more advanced motors have an actuator that moves the stator back and forth in order to continually optimize the rotor clearance for efficiency. So it actually turns out that the optimum torque curve decreases with RPM. Right now, however, manually adding shims to the motor controls rotor clearance more accurately than an actuator that adjusts clearance dynamically. Since most of the time durring solar car races is spent on highways, cruising right at the speed limit, it's most efficient for the MIT Manta GT to have the rotor clearnce set for cruising speed by dissasembling the motor in lab and adding or removing shims. The extra efficiency gained at cruising speed more than makes up for the inability to continuosly optimize the motor.
On a side note, don't assume that exotic processes and materials are better. Take for instance, the University of Michigan's solar car frame is made of titanium. (At least a few years ago it was.) Titanium is light weight, but very difficult to work with. Titanium is notoriusly expensive and comparitively expensive to work with. It is also imposible to design Titanium for an infinite fatigue life. (The maximum vibration allowable amplitude asymptotically aproaches zero as designed fatigue life approaches infinity. For most steels, however, the allowable amplitude asymptotically appraoches a positive value. Trust me, I spent an entire semster at MIT learning about crack growth and fatigue.) I'm told that the University of Michigan's Ti frame weighed only seven pounds less than the MIT ChroMolly steel frame. Which is more reliable? Which cost less? How many pounds are you willing to shave at eh cost of money and reliability?
Karl
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
My understanding is that you still get the tax break (Laws may very in your country).
This is my understanding: You set up a modest fund. The principal slowly grows over time, and they skim off money yearly for donations to non-profit orgs. A small percentage "skimmed" for donations means that the principal will grow faster, meaning that the integral of the money given to open source over a long time is larger, but the short term donations are very small. You set up the rules for deciding who gets the donations, etc.
IMHO, this is the best way to contribute to the future of OpenSource. If you make a bad decission one year, you didn't throw all of your donation down the tube, there's still money for next year. You ensure that your donation gets invested instead of being spent on short-sighted goals that may not pan out.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.
From my point of view, there are two camps on this issue. The realists and the idealists. The realists argue for piling on more charges, such as tool posession, in order to ensure that a criminal does some time. The idealists argue that a criminal should be charged only for actions comitted, and burglary tools should be legal to posess.
Philosophical Discourse:
On this issue, I happen to belong to the latter camp. I believe in goal-driven management, not method-driven management. (I am the house manager for my fraternity. I tell Jon that the trash must not overflow the trash can, we cannot have flies or rats feasting, etc. I do not tell Jon to use a square knot to close the bags, etc.)
I believe that the government, as an UberManager, should by extension, legislate and mandate based on goals, not methodological details. Power plants should be required to keep SO2 emissions below a certain level, but not required to install foo-type exhaust processors. I beleive this has a certain asthetic appeal. I believe charging criminals for crimes but not tool posestion has this same aesthetic appeal.
In short, I think charging a malicious hacker with possesion of l0pht crack is a poor way to go about the business of prosecution. I also tend to agree with the slippery-slope arguments floating arround this thread. Enumerating on them further would be a waste of time, IMHO.
Sidenote:
As far as the crack pipe analogy, be careful about the word *only*. "The *only* use of spare change is economic exchange" is a false statement. I have used dimes as screwdrivers. People make jewelry and collections our of coins. I would imagine there are a few individuals who find crack pipes beautiful, but don't use crack themselves. There may be a legitimate reason to collect crack pipes.
Karl
I'm a slacker? You're the one who waited until now to just sit arround.