Slashdot Mirror
Slashback: HETE, HP, Regression
The computing equivalent of Area 51? A short while back HP closed its calculator division. Many have thought HP's calculator department was unprofitable. This was not the case. Many have thought they had no innovation. This was not the case. Turns out that management had 4% workforce to kill and they were part of the cut.
This article explains more. It turns out they had designed several Linux based PDA's ready to produce that were killed by management. Sounds interesting? Go check it out.
The biggest expense was the 12 gross of Estes D engines ... Satellite Designer writes: "The topic of low cost satellites having been mooted here recently, I though I'd alert readers to another such project. The HETE-2 satellite recently located a cosmic gamma-ray burst precisely enough that (with a lot of help from friends) an afterglow was detected, identifying its source. HETE-2 cost $26 million, only 1/3 of what a 'small' scientific satellite normally costs.A lot of commercial 'off the shelf' technology went into HETE. Nothing from Radio Shack, but there are quite a few parts from Digi-Key onboard. You can't save money by using cheap parts (but you *can* save money by using easily obtainable parts), and you can't achieve reliability by using expensive parts (but you *can* help reliability by using the parts best suited for your application). The radical thing about HETE's parts selection was that it considered parts in the application context (as one would do in a normal engineering process), rather than restricting selection to a QPL assembled to meet irrelevant requirements.
The real trick to keeping costs down is to do the job with as small a team as possible in the minimum time possible. Rather than employing a large team of specialists, HETE's scientific investigators did much of the engineering and technical work. A small, carefully selected engineering team filled in the knowledge gaps."
Quitting isn't easy, and why bother? dmarsh writes: "This new article from C|Net seems to be a total contradiction to last week's "Dump Broadband, Dig Out Your Modem!" thread's article. I guess the important difference being that this one is backed up by an actual survey by the National Cable and Telecommunications Association."
Goes to show, in a large group of people you can probably find at least some who fit nearly any premise. As always, question the source ;)
More information about the very new Mandrake Gaming Edition with The Sims seems to be available here and pre-orders seem to be opened at MandrakeStore. Just wanted to let you know because I find this stuff extremely _cool_ :-)
The Linux interfaces show the traditional SVR5 semaphores to be the slowest performers while the pthread mutexes are the fastest.
well duh. Just look at the section of the man pages -- semop is in section 2 (system calls) and pthreads are in section 3 (library calls). As a general rule of thumb, system calls will be slower than library calls (a context switch is involved).
Comment removed based on user account deletion
Empty <a> blocks aren't terribly useful...
I have to admit, I've considered getting away from cable.
Reason: downloads could hit 400+K/s uploads could hit 200K/s (not bits, bytes).
After a year, down ~= 200+K/s upload capped at 128K/s. Ok, fine and dandy.
Insult to injury came when dowload rate varied (no biggie) but a second cap at 128kbits.
When questioning the provider and calling the corporate office I got "Oh, we meant 128kbits not Kbytes".
Uh, huh.
The sad part is no one noticed the drop off in cable revenues at, or shortly after 2 things:
Killing off the *.divx groups and 'capping people off at the knees' as far as uploads.
By capping off uploads and killing off the divx groups @home completely negated the purpose of broadband
Include the caving into the MPAA w/o so much as a defense of its own customers much less adhering to "innocent until proven guilty" therom.
If DSL could provide a 128Kbyte up/down rate and eliminate the install hassles and provide the service for 20 to 25 bucks a month...I'd jump on that in a heartbeat.
If the had a you want faster, you pay more scheme (which @home does not do...WTF?) I'd use it and I'd *recommend* other cable users do it as well.
I can not tell you how many ppl I've recommended cable to because I lost count.
Now I tell them DSL first, cable second if they don't mind "getting less" for the same amount of money.
"once bitten, twice shy"
Ok, in my case it was a nip first then a bite.
Now I am shying away from recommending cable as a first step. Second step getting away especially if the 'veeceedee' groups start disappearing.
Then a lot of us will have absolutely *NO* reasons for sticking with cable.
If it is not on fire, it is a software problem.
the article was about IPC (inter process communication). win critical sections do not provide inter-process facilities. in fact, they don't necessary even work efficiently on SMP systems either. 'nuff said?
Of course critical sections are fast - that's what they were designed to be. The tradeoff is that they can't be used for IPC, so the comparision in the article is misleading .
---
http://slashdot.org/moderation.shtml
Hmm, hope someone updates, that sounded interesting.
The reason why pthreads 'look pretty good' speed-wise is because the pthread library provides user level threads as opposed to a kernel level threads. User level threads have their own scheduler and are much quicker to swap out--less data to save than during a kernel thread context switch. Meanwhile, pthread semaphores (and condition variables) should also be faster depending on the user-to-kernel thread mapping scheme (windows 2k maps each user thread to a kernel thread, for example; I think linux uses a many-to-many mapping). This'll reflect in how fast threads go through their critical sections because they may have to wait shorter/longer to get access to them.
- - - - - - - -
Don't worry, being eaten by a crocodile is just like going to sleep in a giant blender.
Technically, "pthreads" ("POSIX threads") is just an API which can be provided by any thread library. And yes, technically, you can get a user-level threads package that implements pthreads.
But I think you were referring to Linuxthreads, the pthreads implementation used by GNU libc on Linux. Linuxthreads is kernel-level, not user-level.
Semaphores and mutexes may be implementation mostly in user space (I don't know for sure) but thread creation/destruction/scheduling is definitely based on real kernel threads.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Some of their problems have been related to the fact that their team is very small. So, it is possible to make things too cheap.
HETE's operations team is indeed too small. HETE-2 was ready for launch in January, 2000 (it was integrated with the rocket!), but after the Mars lander failure NASA got cold feet and ordered it shipped back to MIT for additional testing. HETE-2's operations were also funded below the HETE project's minimum estimate of operations costs. Since people without long term support need to find new jobs, this combination meant that several people left for new employment either before launch (having already lined up new jobs before the delay) or shortly afterward. While a reduction in the team's size post launch was intended, what happened was too drastic. This definitely made it harder.
It would have been fine if they had no time constraints, but it seems that spending most of the first year essentially in a kind of engineering mode is a bad thing.
Part of the trouble is that HETE needed to be well calibrated before it could generate useful results. A mission like Chandra could do a lot of interesting stuff (especially pretty pictures) before its calibration was finished. Astrometric calibration takes time, however.
In any case, this extra time has not added much to the overall mission cost.
Is there anyway that the community (esp. NASA) could have helped bring things on line sooner?
A launch in January 2000, when HETE was ready, would have helped. Adequate funding of the operations phase would have helped.
Patience also would have helped, I think. The HETE team, NASA, and the community were all impatient for results. This meant that there was an emphasis on working through the inevitable operational problems rather than taking the time to fix them. A team that is too small cannot do both in parallel. Once some of the more time consuming problems had been fixed, positive feedback set in: operations became less labor intensive which meant more time was available to fix problems.
The verizon pppoe software for windows was reported to chew the cpu prodigously like you were running SETI@home. That's where alot of discontent with verizon originated. I heard about that when doing research , but then I already had made other plans. I set Verizon dsl up with a dhcp provding local isp instead of Verizon or earthlink with a Linux floppy based firewall. It's been fabulously great (for the people I set it up for) ever since the splitter was installed. Literally like dialtone.
Oh yes, and another thing: if it isn't a dsl to ethernet bridge, it was never designed to perform with stability in the first place. Whoever your dsl provider is, they don't necessarily want you to be connected 24/7, so as the the technology "matures" , meaning as they get past the tech-savvy, nitpicky, first-adopters, they think : why should they give away hardware that contributes to high uptime when they can buy the cheapest POS usb devices and microfilters instead , saving themselves money and keeping the customers offline a little more ?
oh but maybe i'm just too cynical about the telco monopolies.
Johnny Quest has two Daddies.