My old man had a mild stroke. The place he worked (a school district actually, not a corporation) deperately wanted him to sign a form to the effect that the stroke was not caused by work-related stress.
I thought it was outright morbid of them to be more interested in preventing a lawsuit than, well, anything. The only action they took was ask him to sign away his rights. I think there might have been a get-well card, but it wasn't signed by the legal department that's for sure.
More generally, you just don't go around signing things because your company asks you to. It's your name on the line and the general rule is that if they ask you to sign something purely it's for their benefit. When there is a disagreement or adversarial situation their benefit is almost always your loss.
It's great having tutorials and references and pdfs and stuff, but I love being able to type "man functionname" or "man commandname" find out exactly how something is intended to be used. And the "SEE ALSO" section at the end is pure gold.
>> CVT's of a given size can only handle so much torque at once. > The same thing is true of any drivetrain, regardless of input.
Indeed. I should have asserted that CVTs of a given size can handle less torque than an automatic transmission of similar size. I don't have any reference to back this up, so I will have to let it go. But I believe the idea that the torque limitations of the transmission are a greater issue in a diesel-electric hybrid than in a gas-electric hybrid is still valid.
I've had many cats over the last twenty years, and not one has had trouble recognizing and tracking objects on tv shows
It isn't only retinal fusion that causes the image to appear stable--a lot of plain old televisions have phosphors that decay slowly after being hit by the electron beam. If the phosphor is still decaying by the time it gets hit by the next iteration of the beam there may be enough of an image for a pet to see.
One experiment is to use a camera and set the exposure to different speeds, then take some pictures of a TV screen. Might even work with a digital camera, though you might get some artifacts from the CCD scan. Anyway, what I've seen with inexpensive film cameras is that the whole image is present (from decay of previous scans) but there is a band of pixels that are bright, having been freshly illuminated during the time the shutter was open.
You are right, they are not mutually exclusive at all. However, there are some minor technical issues that meant that gas-electric hybrids got developed first.
The main reason is that the torque curves for gas and electric motors are complementary. Electric motors produce maximum torque at (or near) 0 RPM. Gas motors produce maximum torque far higher. It depends on the engine, but a typical four banger that gets used in a hybrid may have max torque up around 4000RPM. Diesels produce their highest torque lower, around 1500RPM. So what happens in a hybrid is that you step on the gas and get a rush from the electric motor, then the diesel gives its max torque soon after, then...nothing, they both peter out and you have to shift early and often to compensate.
Another issue is that in a couple of cases, hybrid vehicles were developed with a CVT (continuously variable transmission). Again, the torque presents a problem. CVT's of a given size can only handle so much torque at once. If the electric motor and the diesel are both producing a lot of torque at the same time, you'd have to provide a larger, heavier CVT to accomodate.
Finally, hybrids gained a lot of popularity for environmental reasons. This made them popular in "green" places like California. Unfortunately, CA has strict emissions standards and currently very few diesel passenger car engines meet these standards. A hybrid vehicle that cannot be sold in CA would limit its success drastically. As low-sulfur fuel is phased in, this might change.
None of these are reasons that diesel-electric hybrids could not be brought to market, but together they added up to a "not yet" decision pm the part of automakers.
While conceptually unrelated, I put threads into the same mental category as untyped pointers. They are extremely powerful, but a complete PITA to debug if anything goes wrong, even moreso if you are maintaining someone else's void* or pthread_create filled application.
What I've always done is code extremely defensively: 1. make the various threads data-independent enough to be free-running and only co-ordinate at the start and finish of a thread's activity. If necessary, re-architect everything in sight to make this possible. 2. when interaction is required, get a nice big coarse-grained lock and do everything that needs to be done and get it over with. profile it; there's a good chance it'll be over with quickly enough that it won't erase gains from parallelism or at least you can see what's taking so long and move it outside the lock. 3. do TONS of load testing with lots of big files and random data. thread-related bugs can often hide for years in your code. Unlike divide by zero or null pointer references, a thread bug won't necessarily give any kind of hardware fault or exception. You have to go hunt for the bugs, they won't just pop up and say hi here i am. 4. If you have multiple people of various technical abilities working on the code, you should add a grep/sed script to your makefile to check for accidental introduction of mt-unsafe library calls (strtok, ctime, etc). Flag new monitors and locks for review. Warn about dumb things like using static or global variables. 5. Last trick is to use a layer to allow your program to be compiled for fork/wait, pthread_create/pthread_join, or just plain old co-routine execution (esp if there is a socket you can set to non-blocking). In addition to being able to test your code for correctness in various situations, you also have a baseline to see if the multithreading is an actual improvement.
With the obvious exceptions for embarassingly parallel algorithms, I've found that humdrum client/server or middleware stuff: (a) gets only marginal gains from multithreading (b) you have to work for it--profiling and tuning are still required to get top-notch performance (c) effectient scaling beyond a handful of threads is the exception not the rule. If you have more threads than CPU's, it's a simple fact that some of them are going to be waiting and then your scaling is done.
I've been using Apple's products since the Apple II+ way back in 1980. 25 years of Apple hardware, software, programming, and sharing the goodness of the Apple way with friends and family. I've always had a warm fuzzy feeling for the company, their employees, and their products.
Over the last couple of weeks, though, the feeling started to fade. It's completely gone now.
Apple is just another company.
You'd think after the cancer scare Jobs would have mellowed out.
Seems like the school bears some responsibility for outsourcing the acceptance letters to an easy-to-hack site. The cynic in me tells me that half the reason they are coming down so hard on the students is to divert attention from their own security failure.
You are correct only if the building is heated by electrical resistance.
If it is heated by any other method (including heat pumps), there will be some difference in cost, usually favoring the alternative. Exactly how much difference depends on utility rates and the efficiency of installed equipment.
Judging by
this it's fair to say that electrical resistance heating is 2 to 4 times more expensive than other heating methods.
In a multi-story apartment building, the heat or a/c given to one tenant diffuses to neighboring apartments. It's typical to have three walls, the floor and ceiling connected to other apartments, and only one wall with doors and windows facing the outside world. 5/6 of your surface area is shared, so it makes sense to regulate heat loss/gain in the commons.
His turning off the thermostat doesn't undo the heat or a/c he gets from neighbors; he's benefitting from their thermostat settings. If the place were perfectly insulated, he'd have to give up and turn his on anyway. If everyone turned off their thermostats, within a day the place would be unliveable. Check out a commercial building that turns its HVAC off on weekends. By mid-sunday it's stuffy and either freezing cold or unbearably hot.
We eat out at restaurants instead of cooking meals individually.
I realize there's an efficiency of scale from having 100 people all getting their food cooked on the same stove, but I've seen restaurant equipment and it isn't very efficient. Huge flames, giant vents to move the heat and smoke out of the kitchen, and the sad part is that they leave almost every cooking appliance on the whole time they're open. Soup has to stay hot on a stove, the oven has to stay hot, the grill has to stay hot. On top of that, there is an add-on effect from staffing the restaurant: by delegating food prep, you now have to have more people around. Their housing and transportation uses energy in a fairly insidious overpopulation-inducing feedback loop.
Saved $120/month by turning of the jacuzzi-like thing in our backyard. Man that was a hog. The salesman said it was going to be abouyt $25/mon. Liar.
Blew a big wad of money on a 4-zone 2 stage a/c with SEER of 15.0. This replaced an unzoned 1-stage with an SEER that I was guessing to be about 9 when originally installed but probably down to about 5 because of mechanical problems. Unless you're county building codes are strict about a/c efficiency, you probably have the cheapest, least efficient a/c that was available when your house was built.
Newer houses have lots of "can lights" these days. Mine came with 20+ 75W floods sprinkled throughout the house. I replaced 'em all with 18W compact fluourescents. I didn't see a direct effect on the electric bill 'cause I replaced the bulbs gradually, but I'm guessing at about $15 a month in savings from that.
Another killer was a portable 1500W space heater that my wife liked to leave on for several hours a day. I unplugged it one day when she was gone and hid it from her.
All told, my highest electric bills have been just above $300. Last one was $79 and I'm anticipating summer peaks of maybe $130 this year.
Future plans include a new fridge, better insulated windows, a vapor barrier in the attic, and some quality time with a caulking gun.
You are mistaken. Ballmer does the screaming these days.
Re:Sometimes formal QA is needed, sometimes not.
on
QA != Testing
·
· Score: 1
Similar to that sentiment...I tend to anticipate quality needs by the number of customers. A custom app for a single customer on a single platform isn't going to be exposed to tons of variables. Once it's installed and running, it will likely keep running until the underlying hardware craps out, except for dumb things like memory leaks.
If you have, say, a dozen customers using the software, you'll run into more platforms. The code starts getting a few #ifdefs. Then some thread-safe system call turns out not to be thread safe on some other platform, or a system call has slightly different semantics, or/usr/lib isn't laid out like you thought it was all the time. The installer program becomes spaghetti at a slightly faster rate than the rest of the code.
Ramp up to a thousands of customers, and while management is now happy because they can do revenue projections and spreadsheets and other MBA stuff, now your life is heck. You have to port to almost every version (in the last 10 years) of 9 different posix-ish platforms, plus win98 and NT. You start getting elevated support calls that boil down to spyware stealing cycles from your app. People install your data files on wacky hardware like USB 1.1 RAID over Samba. User's machines are partitioned oddly and/tmp fills up before your installer even has a chance to check for disk space.
If you have millions of customers, you're screwed. No matter what you do, almost any code you write or change will get broken somewhere on someone's machine because of some insane impossible-to-debug three way interaction that never, ever, happens in debug mode. Things like java and c# start to sound like good ideas.
They do this because the craft is designed to be so light that the full fuel load can only be handled on a single flight and the 2nd full load would likely destroy the craft structurally.
We're used to thinking of steel, which can handle repeated flexing and loading near its limits without failure almost indefinitely, and aluminum which can handle 20000+ cycles, but composites have ranges of behavior depending on what they are composed of, and how they are assembled. To get the light weight for the craft, the team has chosen to design for only ONE CYCLE of wing (or more likely wing spar) flex under full fuel load.
If cost were no object they could build two, verify that they are identical, and test one to destruction, but that's not always practical.
Maybe if they didn't load cell phones will all kinds of web-browsing, picture taking, mp3 playing, text messaging, tv playing extra features they'd be so cheap that nobody would care if they were stolen.
The easiest way to do it in C is with qsort and comparitive function that returns a random number between -1 and 1 inclusive.
Little known fact about the C library: qsort is allowed to crash your program if the compare function returns inconsistent result for a given pair of keys.
What you're talking about it micro-optimization. Compilers are pretty good at that, and you should let them do their job.
Programmers should optimize at a higher level: by their choice of algorithms, organizing the program so that memory access is cache-friendly, making sure various objects don't get destroyed and re-created unnecessarily, that sort of thing.
Has anyone looked into decrypting the broadcast-flagged data streams? Judging by past efforts of the home entertainment and media industries to secure their content, there's a good chance that the broadcast flag will be irrelevant in a couple of months.
Slashdot Mirror
Not a great story.
My old man had a mild stroke. The place he worked (a school district actually, not a corporation) deperately wanted him to sign a form to the effect that the stroke was not caused by work-related stress.
I thought it was outright morbid of them to be more interested in preventing a lawsuit than, well, anything. The only action they took was ask him to sign away his rights. I think there might have been a get-well card, but it wasn't signed by the legal department that's for sure.
More generally, you just don't go around signing things because your company asks you to. It's your name on the line and the general rule is that if they ask you to sign something purely it's for their benefit. When there is a disagreement or adversarial situation their benefit is almost always your loss.
DON'T SIGN ANYTHING!
No matter what, don't sign any contract, agreement, notice, any piece of paper they hand you. Just grab your box of stuff and walk out of the door.
It's great having tutorials and references and pdfs and stuff, but I love being able to type "man functionname" or "man commandname" find out exactly how something is intended to be used. And the "SEE ALSO" section at the end is pure gold.
>> My guess is Microsoft needs a new CEO ... Who is the right person for that job?
I think Carly Fiorina is available.
There are no hybrid passenger cars in production that match your description. Only train locomotives operate as you describe.
>> CVT's of a given size can only handle so much torque at once.
> The same thing is true of any drivetrain, regardless of input.
Indeed. I should have asserted that CVTs of a given size can handle less torque than an automatic transmission of similar size. I don't have any reference to back this up, so I will have to let it go. But I believe the idea that the torque limitations of the transmission are a greater issue in a diesel-electric hybrid than in a gas-electric hybrid is still valid.
It isn't only retinal fusion that causes the image to appear stable--a lot of plain old televisions have phosphors that decay slowly after being hit by the electron beam. If the phosphor is still decaying by the time it gets hit by the next iteration of the beam there may be enough of an image for a pet to see.
One experiment is to use a camera and set the exposure to different speeds, then take some pictures of a TV screen. Might even work with a digital camera, though you might get some artifacts from the CCD scan. Anyway, what I've seen with inexpensive film cameras is that the whole image is present (from decay of previous scans) but there is a band of pixels that are bright, having been freshly illuminated during the time the shutter was open.
I have noticed that I'm more sensitive to flicker after a transition from bright sunlight to office lighting.
My usual monitor is set to 75Hz which is fine for me. After I come in from a walk on a sunny day I can see some flicker that I normally wouldn't.
You are right, they are not mutually exclusive at all. However, there are some minor technical issues that meant that gas-electric hybrids got developed first.
The main reason is that the torque curves for gas and electric motors are complementary. Electric motors produce maximum torque at (or near) 0 RPM. Gas motors produce maximum torque far higher. It depends on the engine, but a typical four banger that gets used in a hybrid may have max torque up around 4000RPM. Diesels produce their highest torque lower, around 1500RPM. So what happens in a hybrid is that you step on the gas and get a rush from the electric motor, then the diesel gives its max torque soon after, then...nothing, they both peter out and you have to shift early and often to compensate.
Another issue is that in a couple of cases, hybrid vehicles were developed with a CVT (continuously variable transmission). Again, the torque presents a problem. CVT's of a given size can only handle so much torque at once. If the electric motor and the diesel are both producing a lot of torque at the same time, you'd have to provide a larger, heavier CVT to accomodate.
Finally, hybrids gained a lot of popularity for environmental reasons. This made them popular in "green" places like California. Unfortunately, CA has strict emissions standards and currently very few diesel passenger car engines meet these standards. A hybrid vehicle that cannot be sold in CA would limit its success drastically. As low-sulfur fuel is phased in, this might change.
None of these are reasons that diesel-electric hybrids could not be brought to market, but together they added up to a "not yet" decision pm the part of automakers.
While conceptually unrelated, I put threads into the same mental category as untyped pointers. They are extremely powerful, but a complete PITA to debug if anything goes wrong, even moreso if you are maintaining someone else's void* or pthread_create filled application.
What I've always done is code extremely defensively:
1. make the various threads data-independent enough to be free-running and only co-ordinate at the start and finish of a thread's activity. If necessary, re-architect everything in sight to make this possible.
2. when interaction is required, get a nice big coarse-grained lock and do everything that needs to be done and get it over with. profile it; there's a good chance it'll be over with quickly enough that it won't erase gains from parallelism or at least you can see what's taking so long and move it outside the lock.
3. do TONS of load testing with lots of big files and random data. thread-related bugs can often hide for years in your code. Unlike divide by zero or null pointer references, a thread bug won't necessarily give any kind of hardware fault or exception. You have to go hunt for the bugs, they won't just pop up and say hi here i am.
4. If you have multiple people of various technical abilities working on the code, you should add a grep/sed script to your makefile to check for accidental introduction of mt-unsafe library calls (strtok, ctime, etc). Flag new monitors and locks for review. Warn about dumb things like using static or global variables.
5. Last trick is to use a layer to allow your program to be compiled for fork/wait, pthread_create/pthread_join, or just plain old co-routine execution (esp if there is a socket you can set to non-blocking). In addition to being able to test your code for correctness in various situations, you also have a baseline to see if the multithreading is an actual improvement.
With the obvious exceptions for embarassingly parallel algorithms, I've found that humdrum client/server or middleware stuff:
(a) gets only marginal gains from multithreading
(b) you have to work for it--profiling and tuning are still required to get top-notch performance
(c) effectient scaling beyond a handful of threads is the exception not the rule. If you have more threads than CPU's, it's a simple fact that some of them are going to be waiting and then your scaling is done.
I've been using Apple's products since the Apple II+ way back in 1980. 25 years of Apple hardware, software, programming, and sharing the goodness of the Apple way with friends and family. I've always had a warm fuzzy feeling for the company, their employees, and their products.
Over the last couple of weeks, though, the feeling started to fade. It's completely gone now.
Apple is just another company.
You'd think after the cancer scare Jobs would have mellowed out.
FYI, the Volkwagen New Beetle, the one that looks like this, is water cooled.
Seems like the school bears some responsibility for outsourcing the acceptance letters to an easy-to-hack site. The cynic in me tells me that half the reason they are coming down so hard on the students is to divert attention from their own security failure.
If it is heated by any other method (including heat pumps), there will be some difference in cost, usually favoring the alternative. Exactly how much difference depends on utility rates and the efficiency of installed equipment.
Judging by this it's fair to say that electrical resistance heating is 2 to 4 times more expensive than other heating methods.
Calm down.
In a multi-story apartment building, the heat or a/c given to one tenant diffuses to neighboring apartments. It's typical to have three walls, the floor and ceiling connected to other apartments, and only one wall with doors and windows facing the outside world. 5/6 of your surface area is shared, so it makes sense to regulate heat loss/gain in the commons.
His turning off the thermostat doesn't undo the heat or a/c he gets from neighbors; he's benefitting from their thermostat settings. If the place were perfectly insulated, he'd have to give up and turn his on anyway. If everyone turned off their thermostats, within a day the place would be unliveable. Check out a commercial building that turns its HVAC off on weekends. By mid-sunday it's stuffy and either freezing cold or unbearably hot.
Get the motion sensor replacement switches. Fit right in to most switchboxes. www.smarthome.com has 'em.
Or, ask your roommate to eat more carrots.
We eat out at restaurants instead of cooking meals individually.
I realize there's an efficiency of scale from having 100 people all getting their food cooked on the same stove, but I've seen restaurant equipment and it isn't very efficient. Huge flames, giant vents to move the heat and smoke out of the kitchen, and the sad part is that they leave almost every cooking appliance on the whole time they're open. Soup has to stay hot on a stove, the oven has to stay hot, the grill has to stay hot. On top of that, there is an add-on effect from staffing the restaurant: by delegating food prep, you now have to have more people around. Their housing and transportation uses energy in a fairly insidious overpopulation-inducing feedback loop.
Saved $120/month by turning of the jacuzzi-like thing in our backyard. Man that was a hog. The salesman said it was going to be abouyt $25/mon. Liar.
Blew a big wad of money on a 4-zone 2 stage a/c with SEER of 15.0. This replaced an unzoned 1-stage with an SEER that I was guessing to be about 9 when originally installed but probably down to about 5 because of mechanical problems. Unless you're county building codes are strict about a/c efficiency, you probably have the cheapest, least efficient a/c that was available when your house was built.
Newer houses have lots of "can lights" these days. Mine came with 20+ 75W floods sprinkled throughout the house. I replaced 'em all with 18W compact fluourescents. I didn't see a direct effect on the electric bill 'cause I replaced the bulbs gradually, but I'm guessing at about $15 a month in savings from that.
Another killer was a portable 1500W space heater that my wife liked to leave on for several hours a day. I unplugged it one day when she was gone and hid it from her.
All told, my highest electric bills have been just above $300. Last one was $79 and I'm anticipating summer peaks of maybe $130 this year.
Future plans include a new fridge, better insulated windows, a vapor barrier in the attic, and some quality time with a caulking gun.
You are mistaken.
Ballmer does the screaming these days.
Similar to that sentiment...I tend to anticipate quality needs by the number of customers. A custom app for a single customer on a single platform isn't going to be exposed to tons of variables. Once it's installed and running, it will likely keep running until the underlying hardware craps out, except for dumb things like memory leaks.
/usr/lib isn't laid out like you thought it was all the time. The installer program becomes spaghetti at a slightly faster rate than the rest of the code.
/tmp fills up before your installer even has a chance to check for disk space.
If you have, say, a dozen customers using the software, you'll run into more platforms. The code starts getting a few #ifdefs. Then some thread-safe system call turns out not to be thread safe on some other platform, or a system call has slightly different semantics, or
Ramp up to a thousands of customers, and while management is now happy because they can do revenue projections and spreadsheets and other MBA stuff, now your life is heck. You have to port to almost every version (in the last 10 years) of 9 different posix-ish platforms, plus win98 and NT. You start getting elevated support calls that boil down to spyware stealing cycles from your app. People install your data files on wacky hardware like USB 1.1 RAID over Samba. User's machines are partitioned oddly and
If you have millions of customers, you're screwed. No matter what you do, almost any code you write or change will get broken somewhere on someone's machine because of some insane impossible-to-debug three way interaction that never, ever, happens in debug mode. Things like java and c# start to sound like good ideas.
They do this because the craft is designed to be so light that the full fuel load can only be handled on a single flight and the 2nd full load would likely destroy the craft structurally.
We're used to thinking of steel, which can handle repeated flexing and loading near its limits without failure almost indefinitely, and aluminum which can handle 20000+ cycles, but composites have ranges of behavior depending on what they are composed of, and how they are assembled. To get the light weight for the craft, the team has chosen to design for only ONE CYCLE of wing (or more likely wing spar) flex under full fuel load.
If cost were no object they could build two, verify that they are identical, and test one to destruction, but that's not always practical.
Maybe if they didn't load cell phones will all kinds of web-browsing, picture taking, mp3 playing, text messaging, tv playing extra features they'd be so cheap that nobody would care if they were stolen.
Little known fact about the C library: qsort is allowed to crash your program if the compare function returns inconsistent result for a given pair of keys.
What you're talking about it micro-optimization.
Compilers are pretty good at that, and you should let them do their job.
Programmers should optimize at a higher level: by their choice of algorithms, organizing the program so that memory access is cache-friendly, making sure various objects don't get destroyed and re-created unnecessarily, that sort of thing.
Has anyone looked into decrypting the broadcast-flagged data streams? Judging by past efforts of the home entertainment and media industries to secure their content, there's a good chance that the broadcast flag will be irrelevant in a couple of months.