Actually, that is being done to some extent in the oilpatch... Engineering contracting firms will outsource the plant design to India, and just take care of the management side of things. The problem with that is, the petroleum and control systems engineers in India have little concept of what it's like to build and operate a plant in ambient temperatures of -40, and then when they specify materials or methods that don't meet code, it's up to the local folks to fix up the mess. In the end, the customer pays more and/or gets a product that is inferior to something done by people with appropriate experience.
Right. The point you make is that most of the time when you do a subcontracting job, you'll have a decent amount of documentation to work with, as well as an established hardware platform. However, if the project is at a stage where the hardware design is in flux or it's being debugged, and where the software-software interface spec hasn't been nailed down, then going to an outside software developer is a big waste of time and money, regardless of how cheap the labor on the other end is.
Outsourcing only works effectively if you are in that mythical work environment where requirements are fully established, interfaces are completely specified, and test harnesses for all the code are in place before a line gets written.
In the embedded software space, where real-time interaction between various interrupts means that system design and hard core debugging skills are king, outsourcing, and especially overseas, will never be a factor.
Sorry - I misattributed the statement to Darl - it was actually one of his minions, Blake Stowell: "The site will include a calendar of the cases SCO currently has in litigation as well as access to the legal filings made in SCO's cases. There are, however, no plans to allow readers to discuss the documents on the Web site. "If we opened it up to that, it would simply become another one of the message boards that our detractors use to try and overwhelm us," Stowell said."
Nope - according to Darl himself (as quoted in TFA), if they had a forum on that site it would just be overrun by pro-open-source zealots with nothing better to do than to lambaste SCO.
You must live in Saskatchewan. Come out and drive Hwy 1 between Lake Louise and Revelstoke. As a bonus, you'll get to recalibrate your notion of 'narrower' and 'windier' at least as it applies to national traffic corridors, on the little stretch going down into Golden.
If this ever happens to you do not ever attempt to turn the ignition all the way off... In most cases you will lose both your power steering and your power braking. Make sure that you keep it at least on partially as most cars will not lose total power this way.
It would help if you had a clearer understanding of automotive systems before trying to give advice such as this. The ignition can be either "on" or "off", and if you turn it off, the engine will stop running (barring stupid card-reader implementations such as described in TFA). If the engine stops running, you lose the hydraulic assist for the steering, as well as the vacuum assist for the brakes, but the steering assist is mostly required at parking speeds, so you'll still be able to steer the car, it just takes a little more effort. The vacuum canister for the brakes is usually large enough that you can get a couple of pumps of the pedal in before the assist goes away, so you will still have power brakes for an all-out stop even after the engine stops.
What is dangerous is that turning the ignition key "all the way off" engages the steering column lock, which keeps you from using the steering at all, and THAT can be fatal if you're moving at speed. Cars with a steering column automatic shifter typically have an interlock that prevents you from turning the ignition to the 'lock' position unless the shift lever is in the 'park' position.
Most likely, the powers-that-be at his company (of which he probably is one) have the intellectual wherewithal to realize that the more responsibility you give to your employees, the more likely the employees are to reward you in terms of productivity and creativity. Putting up a bunch of "don't do this" roadblocks just stifles motivation.
At our company probably 1/3 of the staff take their laptops between home and work (and business travel) all the time. I VPN into our system from home on a regular basis, which effectively exposes both work and home to each other. We have only had one bad episode in the last couple of years, which occurred when the MSBlaster worm got in through an infected laptop and nailed everyone that wasn't running Windoze Update. Educating the staff about spyware removal, antivirus software, and making sure everyone keeps their OS up to date, is actually a lot easier and more productive than just saying "not allowed".
I didn't say they make no money on residential customers. Just that by the time you factor in the number of cable guys with vans and equipment that a service provider needs to keep the residential customers happy and connected, the net profits realized by the cable company from wholesale customers vs. residential customers is probably close to equal. The reason why wholesale customers get wholesale rates is that they don't require nearly as much of the service provider's support. If the cable companies found themselves supporting less and less of the residential networks, they would lose out on the service revenue, but they would also be able to cut out the disproportionately larger support infrastructure that the residential networks require. Smaller organizations generally work more efficiently.
The residential customers also cost them a lot of money to support, either directly or indirectly, so what is happening here is that de-centralizing the distribution of media and communications will require the cable companies and telcos to streamline their operations. It will put some cable service guys out of a job - until those service guys become your friendly local content provider.
Providing an alternate content path as described (and especially having a roving phone automatically finding a way to connect to the PSTN regarless of where it is) is not "easy" but it's a good example of what someone who understands the infrastructure can do using the available technology today.
According to the initial reports Melville reached 330,000 feet - that's now been changed to 358,000 feet, which, if confirmed, would exceed the 354,000 feet achieved by the X-15. IMHO that still doesn't make the two comparable. The X-15 was built as a hypersonic research vehicle, and its altitude records are more a matter of "let's see how high we can go" than the craft being designed specifically with climbing performance in mind. While the SpaceShipOne will never reach the X-15's speeds, it will likely be able to reach significantly greater altitudes than it did even today, since the engines were still shut down prematurely due to the rolls occurring. Congratulations to all involved, and good luck to the other X-prize contenders.
Not to put a damper on Scaled's achievements in any way, but comparisons to the X-15 are not yet in order. The X-15 with the big engine reached Mach 6.7 IIRC, and (not on the same flights) an altitude of 67 miles - double the speed and 10% more altitude. It would be interesting to compare the boost profiles on the altitude record flights for the X-15 to the SS1. How far do they coast up after the rocket engine is shut down?
Say you have one ton of radioactive waste. You need to heat this up, along with four tons of dirt, to 3000 degrees and let things melt into a big happy ball of goo. So how much energy is spent on mining, pre-processing, and finally disposing of that one ton of material, compared to the electrical (and maybe heat) energy extracted from it?
Even so, I'm not quite sure what they expect any voting machine company to do. Let's say they use Linux and a custom and encrypted database format. All you have to do is have somebody reverse engineer the format, get root access to the Linux box and then run a custom script to update the values.
-If an encrypted database were used, along with a strong password phrase and algorithm, there would be very little for anyone to hook into to reverse engineer the format. -Getting root access on the Linux box is also not a trivial task, especially if you don't have physical access to the machine. -If you don't have root access and you write the database access procedure so that root-level or some special group permission is required, then you're not even going to get to the database in the first place.
As Jefferson said in TFA... the coders/designers for that system look like amateurs. Even within a Windows framework there would have been a LOT better ways to implement the database to decrease its vulnerability to casual access by other applications.
I didn't RTFA (I will when it becomes un-Slashdotted), but the 555 or it's more modern variants such as the CMOS versions still have their uses. Simple one-shot timing and oscillators where the frequency or duty cycle needs to be tweakable are far easier to accomplish with the 555 than with a micro. Consider: with the micro, you have to use a crystal to set the reference frequency. How good is your crystal? Now how good is it at -20 degrees C? At +60 degrees C? The 555, along with a couple of good capacitors and resistors, will hum right along with predictable performance at the temperature extremes, for dirt cheap. Doing the work and parts searching to make a micro perform to the same timing accuracy is not trivial. Micros and 555s both have their uses... just not the same ones.
In general (and unless you force them, by writing the code that way) Windoze apps are not at all shy about holding on to their CPU time to the exclusion of other tasks and threads. As a (Borland) example, if you're doing a bunch of processing in a loop, then you must include the occasional call to Application->ProcessMessages(), or else your button presses etc. won't get any airtime until the loop concludes. Nothing wrong with that - it helps to keep the program state sort of known when you're handling events - but if you don't do it then your thread interaction is severely limited.
If you want to take optimal advantage of a parallel multithreading environment then you have to explicitly tell the compiler about what parts of your code are independent of each other, what events can be processed when, and what actions are dependent on what events. The compiler isn't going to make those decisions (correctly or optimally) for you.
Just another case of following procedures without really understanding why those procedures are in place. It's not like it's rocket science or anything...
Not really an offtopic question (at least as far as it relates to general pragmatism vs. an idealistic "every bit must be polished to a mirror-like hue" development approach). However... all software exists to "do stuff". If it's not there in time, then it's just wasted disk space and it inconveniences the hell out of the other folks that were depending on that software to do their thing. Therefore, on-time delivery is not always just a nice-to-have, and being pragmatic about architecture and feature sets can produce better code in the end.
I'm not familiar with the design of the car, but most likely the steering was just a wheel or tiller (like bicycle handlebars) - it doesn't have to be high-tech to be susceptible to sudden failure. It may be that the solar car was struck by a sudden wind gust, made more severe by the fact that he was following the team minivan (thus being subject to the turbulence that exists behind any big blunt object being moved through the air). If the solar car had the misfortune of being designed as a tricycle with one front wheel and two rear wheels, then it would have the same stability issues that eventually drove three-wheeled ATVs out of the marketplace. It's possible that the steering didn't have sufficient caster to be stable at speed, or under all combinations of skid angle. These are all things that might have been contributing factors to the loss of control, which is the main thing that caused the crash and resulting fatality. The fact that the solar car was struck by a minivan, or that the solar car wasn't designed to survive such a mishap, is kind of secondary. Having a steering and suspension geometry that is stable under all foreseen combinations of driver and road input should be a mandatory requirement for a vehicle being driven on public roads.
At one point in my past I built and roadraced GT cars. The combination of slick race-compound tires (9" wide on a 2000 pound car), and the steering axis offset required to allow their use, meant that the steering effort was OK when the front tires weren't sliding, and the caster would re-center the steering. But under conditions where the car was going sideways beyond a certain limit, the steering would drive itself to lock unless you manually wrestled it back to center. Not for the faint of heart or puny forearm development.
RTFA... the solar car swerved across the road into oncoming traffic, directly in front of the minivan. Sometimes it doesn't matter what you can see and what you can't - by the time you can physically react, it's too late.
The aerodynamic drag induced by trying to spin rotors at high speed would keep you from just continually accelerating the blades, just like you can't automatically go faster on a bike by putting on extra gears or steeper ones.
The setback isn't too serious in terms of money, but you can't easily recover the five weeks required to replace the long-lead items. But, as already surmised, the experience of building the first 48" vehicle will have been invaluable and I'm sure they'll find (or commit to) a bunch of items to make improvements. One thing they already did better compared to earlier vehicles: Mass (or lack of it). The 48" vehicle was apparently slightly under the design weight, at 1000 pounds.
Good luck to John and the rest of the crew at Armadillo.
You could look at it like this: If I want to follow you without you realizing it, I can use a variety of senses. I could possibly use smell. If you're upwind of me, then there is little you can do to prevent me smelling you, while I'm at virtually no risk of being detected. I can use sight: I could use a periscope, so that if you look in my direction, all you'll be able to see is the periscope tip, and then it depends on whether or not you recognize that as a threat. I could use radar if that's within my arsenal, and you wouldn't know, unless you had a radar detector that was sensitive to the frequencies I was using. If I get an idea that you're mostly looking in a different direction, I'm free to poke my head up and observe you directly, and only duck when I see you turning my way. This is very applicable if you have multiple predators with a dedicated communication channel: If you have predators mostly surrounding the prey, then any predator that is not within the field of view of the prey is free to make observations and relay them to the rest of the predators.
Programming all that into a distributed set of computing nodes would be a bunch of work, but it's far from impossible.
Slashdot Mirror
Actually, that is being done to some extent in the oilpatch... Engineering contracting firms will outsource the plant design to India, and just take care of the management side of things. The problem with that is, the petroleum and control systems engineers in India have little concept of what it's like to build and operate a plant in ambient temperatures of -40, and then when they specify materials or methods that don't meet code, it's up to the local folks to fix up the mess. In the end, the customer pays more and/or gets a product that is inferior to something done by people with appropriate experience.
Right. The point you make is that most of the time when you do a subcontracting job, you'll have a decent amount of documentation to work with, as well as an established hardware platform. However, if the project is at a stage where the hardware design is in flux or it's being debugged, and where the software-software interface spec hasn't been nailed down, then going to an outside software developer is a big waste of time and money, regardless of how cheap the labor on the other end is.
In the embedded software space, where real-time interaction between various interrupts means that system design and hard core debugging skills are king, outsourcing, and especially overseas, will never be a factor.
Sorry - I misattributed the statement to Darl - it was actually one of his minions, Blake Stowell:
"The site will include a calendar of the cases SCO currently has in litigation as well as access to the legal filings made in SCO's cases. There are, however, no plans to allow readers to discuss the documents on the Web site. "If we opened it up to that, it would simply become another one of the message boards that our detractors use to try and overwhelm us," Stowell said."
Nope - according to Darl himself (as quoted in TFA), if they had a forum on that site it would just be overrun by pro-open-source zealots with nothing better to do than to lambaste SCO.
You mean this page
You must live in Saskatchewan. Come out and drive Hwy 1 between Lake Louise and Revelstoke. As a bonus, you'll get to recalibrate your notion of 'narrower' and 'windier' at least as it applies to national traffic corridors, on the little stretch going down into Golden.
It would help if you had a clearer understanding of automotive systems before trying to give advice such as this. The ignition can be either "on" or "off", and if you turn it off, the engine will stop running (barring stupid card-reader implementations such as described in TFA). If the engine stops running, you lose the hydraulic assist for the steering, as well as the vacuum assist for the brakes, but the steering assist is mostly required at parking speeds, so you'll still be able to steer the car, it just takes a little more effort. The vacuum canister for the brakes is usually large enough that you can get a couple of pumps of the pedal in before the assist goes away, so you will still have power brakes for an all-out stop even after the engine stops.
What is dangerous is that turning the ignition key "all the way off" engages the steering column lock, which keeps you from using the steering at all, and THAT can be fatal if you're moving at speed. Cars with a steering column automatic shifter typically have an interlock that prevents you from turning the ignition to the 'lock' position unless the shift lever is in the 'park' position.
At our company probably 1/3 of the staff take their laptops between home and work (and business travel) all the time. I VPN into our system from home on a regular basis, which effectively exposes both work and home to each other. We have only had one bad episode in the last couple of years, which occurred when the MSBlaster worm got in through an infected laptop and nailed everyone that wasn't running Windoze Update. Educating the staff about spyware removal, antivirus software, and making sure everyone keeps their OS up to date, is actually a lot easier and more productive than just saying "not allowed".
I didn't say they make no money on residential customers. Just that by the time you factor in the number of cable guys with vans and equipment that a service provider needs to keep the residential customers happy and connected, the net profits realized by the cable company from wholesale customers vs. residential customers is probably close to equal.
The reason why wholesale customers get wholesale rates is that they don't require nearly as much of the service provider's support. If the cable companies found themselves supporting less and less of the residential networks, they would lose out on the service revenue, but they would also be able to cut out the disproportionately larger support infrastructure that the residential networks require. Smaller organizations generally work more efficiently.
The residential customers also cost them a lot of money to support, either directly or indirectly, so what is happening here is that de-centralizing the distribution of media and communications will require the cable companies and telcos to streamline their operations. It will put some cable service guys out of a job - until those service guys become your friendly local content provider. Providing an alternate content path as described (and especially having a roving phone automatically finding a way to connect to the PSTN regarless of where it is) is not "easy" but it's a good example of what someone who understands the infrastructure can do using the available technology today.
According to the initial reports Melville reached 330,000 feet - that's now been changed to 358,000 feet, which, if confirmed, would exceed the 354,000 feet achieved by the X-15. IMHO that still doesn't make the two comparable. The X-15 was built as a hypersonic research vehicle, and its altitude records are more a matter of "let's see how high we can go" than the craft being designed specifically with climbing performance in mind. While the SpaceShipOne will never reach the X-15's speeds, it will likely be able to reach significantly greater altitudes than it did even today, since the engines were still shut down prematurely due to the rolls occurring. Congratulations to all involved, and good luck to the other X-prize contenders.
Not to put a damper on Scaled's achievements in any way, but comparisons to the X-15 are not yet in order. The X-15 with the big engine reached Mach 6.7 IIRC, and (not on the same flights) an altitude of 67 miles - double the speed and 10% more altitude. It would be interesting to compare the boost profiles on the altitude record flights for the X-15 to the SS1. How far do they coast up after the rocket engine is shut down?
Say you have one ton of radioactive waste. You need to heat this up, along with four tons of dirt, to 3000 degrees and let things melt into a big happy ball of goo. So how much energy is spent on mining, pre-processing, and finally disposing of that one ton of material, compared to the electrical (and maybe heat) energy extracted from it?
-If an encrypted database were used, along with a strong password phrase and algorithm, there would be very little for anyone to hook into to reverse engineer the format.
-Getting root access on the Linux box is also not a trivial task, especially if you don't have physical access to the machine.
-If you don't have root access and you write the database access procedure so that root-level or some special group permission is required, then you're not even going to get to the database in the first place.
As Jefferson said in TFA... the coders/designers for that system look like amateurs. Even within a Windows framework there would have been a LOT better ways to implement the database to decrease its vulnerability to casual access by other applications.
I didn't RTFA (I will when it becomes un-Slashdotted), but the 555 or it's more modern variants such as the CMOS versions still have their uses. Simple one-shot timing and oscillators where the frequency or duty cycle needs to be tweakable are far easier to accomplish with the 555 than with a micro. Consider: with the micro, you have to use a crystal to set the reference frequency. How good is your crystal? Now how good is it at -20 degrees C? At +60 degrees C? The 555, along with a couple of good capacitors and resistors, will hum right along with predictable performance at the temperature extremes, for dirt cheap. Doing the work and parts searching to make a micro perform to the same timing accuracy is not trivial. Micros and 555s both have their uses... just not the same ones.
If you want to take optimal advantage of a parallel multithreading environment then you have to explicitly tell the compiler about what parts of your code are independent of each other, what events can be processed when, and what actions are dependent on what events. The compiler isn't going to make those decisions (correctly or optimally) for you.
Everyone knows that Yellow Stuff Makes It Faster. And a big honkin' chrome tip.
Just another case of following procedures without really understanding why those procedures are in place. It's not like it's rocket science or anything...
Not really an offtopic question (at least as far as it relates to general pragmatism vs. an idealistic "every bit must be polished to a mirror-like hue" development approach). However... all software exists to "do stuff". If it's not there in time, then it's just wasted disk space and it inconveniences the hell out of the other folks that were depending on that software to do their thing. Therefore, on-time delivery is not always just a nice-to-have, and being pragmatic about architecture and feature sets can produce better code in the end.
At one point in my past I built and roadraced GT cars. The combination of slick race-compound tires (9" wide on a 2000 pound car), and the steering axis offset required to allow their use, meant that the steering effort was OK when the front tires weren't sliding, and the caster would re-center the steering. But under conditions where the car was going sideways beyond a certain limit, the steering would drive itself to lock unless you manually wrestled it back to center. Not for the faint of heart or puny forearm development.
RTFA... the solar car swerved across the road into oncoming traffic, directly in front of the minivan. Sometimes it doesn't matter what you can see and what you can't - by the time you can physically react, it's too late.
The aerodynamic drag induced by trying to spin rotors at high speed would keep you from just continually accelerating the blades, just like you can't automatically go faster on a bike by putting on extra gears or steeper ones.
Good luck to John and the rest of the crew at Armadillo.
You could look at it like this: If I want to follow you without you realizing it, I can use a variety of senses. I could possibly use smell. If you're upwind of me, then there is little you can do to prevent me smelling you, while I'm at virtually no risk of being detected. I can use sight: I could use a periscope, so that if you look in my direction, all you'll be able to see is the periscope tip, and then it depends on whether or not you recognize that as a threat. I could use radar if that's within my arsenal, and you wouldn't know, unless you had a radar detector that was sensitive to the frequencies I was using. If I get an idea that you're mostly looking in a different direction, I'm free to poke my head up and observe you directly, and only duck when I see you turning my way. This is very applicable if you have multiple predators with a dedicated communication channel: If you have predators mostly surrounding the prey, then any predator that is not within the field of view of the prey is free to make observations and relay them to the rest of the predators. Programming all that into a distributed set of computing nodes would be a bunch of work, but it's far from impossible.