Slashdot Mirror
Slashback: Crusher, Satellites, Silence
That fetid odor continues to rise. cconnell writes "In September, Slashdot and Developer.com were kind enough to publish an article I wrote titled Most Software Stinks!. The article generated 748 comments on slashdot, making it one of the most active stories in recent months. Here is a follow up piece I wrote which responds to some of the comments."
Silence, fool! The Panther! writes "Here's an article I wrote that shows step by step how to achieve some measure of silence in my home office. It's different from most in that it approaches damping existing hardware rather than buying new. Some ideas were suggestions of Slashdot readers from a previous article. Lots of photos for the reading-impaired." Hemos may have been going for a rather normal-looking but quiet PC, but The Panther sure isn't.
Step 39: With your dremel strapped to the hamster, gently nudge the billiard ball ... Now that the famous pencil trick isn't an option for would-be AMD overclockers, more complicated means have been found to unlock and reclock. Carlos writes: "I saw that you have a scoopage on the unlocking of the Athlon XP by Tom's Hardware and there is a better and more reversible way by VR-Zone."
200 years is a long time even for a Congressman. Michael H. writes "Woohoo! Congress has given a $30 million shot in the arm to the Pluto-Kuiper Belt mission, previously feared canceled. CNN story here. There's still no guarantee that it won't be canceled later, but at least Congress is listening to the fact that it would take ~200 years for the next window if we missed this one."
Hey, that guy's too old to be a kernel maintainer -- we'll make him an actor. bahamat wrote yesterday: "I'm hanging out in Wil Wheaton's chat room (#rfb on undernet) and he's just announced that he's going to be making a cameo as Wesley Crusher in the new Star Trek X." Apparently, the news hit quite a few readers, too -- and for those who haven't, check out our interview with Wil. Maybe he'll get to be on The Tick, too.
Seriously, it would be cool if he was on The Tick, but even better if he was Sweater Boy or something.
I mean, think about the banter between Wesley Crusher and the Blue Icon of Justice!
-
--- Will in Seattle - What are you doing to fight the War?
...did you do to that webpage? The one about the quiet PC. All the text is there but all the images are scrunched up, overlapping, in the upper left hand corner. I'm interested but not so much that I'm going to download and fix this braindead web design.
324006
This article takes me back to a previous job and one of my co-workers. He was fanatic about removing all 'noise' from his office. His PC being the most evil of all noise makers.
He went to the trouble of locating a 6V power source in the PC and then rewiring the fans from their 12V source to the lower power.
The PC was also wrapped in various forms of egg crate foam to reduce vibration and further dampen noise.
When he started complaining about the flourescent lighting in the building we had to warn him that no re-wiring was allowed!
Wil Wheaton should be on The Tick.. as Wesley Crusher. Then the Tick can finally kill Wesley, and when Wil goes to Star Trek conventions, all the people with "Die Wesley" buttons will be behind the times.
Wesley's dead, dude.
...well-designed software still needs clarifying comments.
Any programmer knows that commenting your code is very helpful. I have written small programs for myself without comments. Now when I go back to them, it is very hairy to know what I was thinking and what it is supposed to do at that time. Comments are also like road signs. They help you understand what the program is are doing, and it is executed. Just ask any hardcore programmer, they will agree. Thanks for the insight.
Will Wheaton as "The Ensign-uator".
While most characters have only a few great lines that have double meanings, everything he says will be a stream of double and tripple ententres (sp?).
JET Program: see Japan, meet intere
His humor is postmodern - his funny is based on the fact that Deliverance and Trek star Wil Wheaton is making the jokes. That doesn't make it bad humor - just self-referential.
Goat sex free since 2001
Allow me to point you to Wil's previous comment on the interview.
Summary: he was joking.
When this story was first posted, an alert Slashdotter pointed out that the 200-year figure was not generally agreed upon, because using Venus as the gravity slingshot (actually, it's more of a trebuchet , isn't it?) would allow launching a mission in any year. Plus, there's no real compelling evidence that the atmosphere will freeze out during the Plutonian winter.
Don't get me wrong—I do want to see a mission to Pluto in my lifetime, but I just want to get the facts straight. Anyone with supporting data either way?
I take it that you haven't installed XP yet.
-----
Free P2P Backup, Windows & Linux
Because "software engineering" (I hate that name, its programming gadammit) is not primarily implementation. Building a bridge requires very litte groundbreaking design: you take a typically take a known bridge concept, and specialize it for the terrain. The tough part is getting it implemented on time and in budget, with tons of logistic hurdles, and avoiding material disaster.
Programming on the other hand is a continuous design process. Implementation is a non-problem, its an ongoing architecture process. (Imagine trying to design a 20 mile long building with 7-10 architects, each with their own unique style)
On top of that, its all non-visual. An architect can look at rendered pictures of what he is designing to get an intuitive feel for its correctness, whereas a programmer must form his image without the benefit of evolved human spacial perception.
Requirements analysis for a bridge is so simple a child can grok it: "something i can walk over the river on". For your typical programming job requirements are much more nebulous: the customer doesnt really know what they want half the time (but theyll know it when they see it).
The whole analogy between Contruction Engineering and The Art of Programming is flawed, otherwise a completed contruction project would be a 40 foot high stack of blueprints that are suppossed to solve a problem that nobody fully understands.
If making a complex program is anything like putting up a large building, then we shouldn't be suprised if most programs are seriously flawed. We've only been doing software engineering for a few decades (somewhere between 1 and 12, depending on how you define the concept). Builders and architects have been honing their skill set for for several thousand years. And they still screw up occasionaly. You can argue that such failures are tragic, but are necessary for engineering to advance.
Now that the famous pencil trick isn't an option for would-be AMD overclockers
What exactly is this famous pencil trick?
(don't bother modding up for a stupid question, just bear with my ignorance and maybe someone can clue me in?)
Mr. Connell makes the excellent point that some engineering problems -- anything from difficult bridge designs to going to the moon -- are every bit as complicated as the software we produce.
... well, everything. None of the early stuff is quite good enough yet. Don't fool yourself into thinking Linux is the end of the road in operating systems, for example. Software is immature. We're forging ahead on every front at once, before the basic pieces are in place, and this will necessarily strain the industry. Once the infrastructure settles down, once we don't need as many projects going on, natural consolidation will lead to more people on each team and better quality.
I agree.
However, it's important to consider one thing -- how many bridges are built every year? How many have as many challenges as the Clark Bridge? Not many, certainly. How much software is written in a year?
If I had, say, three years and millions of dollars to design every piece of software I write, with lots of subordinates double-checking everything I do, well then my code would be perfect as well. The fact is, however, that we write an awful lot more software every year than we build engineering feats, and that has a lot to do with the quality issue. If every program were written over a period of years by a dedicated team of engineers backed by serious budgets, there wouldn't be nearly as much crappy software. However, there's a lot more software hacked together by one guy working out of his garage -- and I daresay if we built bridges that way, a lot of them would fall down.
"So," says the critic, "we just need to design software as seriously as we design bridges."
Not really, I respond. For one thing, our need for software is *really high* right now. We need tons of it -- web browsers, and word processors, and operating systems, and filesystems, and
When civil engineering was immature, a lot of bridges fell down, too, before everything was worked out. I doubt too many people stood around saying "You idiots! Every wagon we design works! Why not bridges?!?" At that time, building bridges was so difficult that it was amazing it ever worked. If it fell down, you just built it stronger and hoped for the best. We've come a long way since then.
I think we're at a similar point in software engineering. Sure, some of our stuff really sucks, but it's such a new field that it's really amazing that we get anything done at all. I frankly think it's unreasonable to expect the field to have matured overnight.
Maybe I'm just not as picky as some people, maybe the cynicism of old age is setting in. But I really don't feel that there's any need for a "Grab the torches and pitchforks! We improve software quality *now*!" movement. Things are getting better, and they will continue to as the market matures. Maybe we should just let it.
ZFS: because love is never having to say fsck
The construction analogy is not perfect (no analogy is) and you can argue that it's seriously flawed. But I see one point of similarity that's hard to avoid: reducing all of software creation to "programming" is as simplistic as reducing all construction to masonry, carpentry, and welding.
Star Trek X? Does that have David Duchonovy as the captain who interrogates every alien race they encounter on the suspicion they abducted his sister?
It's well worth it. I think the current interest in quiet PCs is encouraging. Computers are plenty fast for most of us, so the next big push is going to be making them easier to live with. FireWire/USB, screwless cases, and "quiet" PCs are going to be increasingly popular in the future. I think that Apple's quiet and handy little Cube was a hint of things to come. Too bad they overcharged...
Interestingly enough, the automobile industry followed a lot of the same trends. Horsepower and size were initially everything. There were always the economy models, but the real push was for bigger and faster cars. Now that even a Honda Civic has enough horsepower to get the job done, people are buying for different reasons. Style, comfort, and ease of use are BIG selling points for cars now, while horsepower is just another "nice feature" and the power enthusiast is relegated to a niche market.
You can already see the trend at work. The Athlon is a kick-ass processor, but needing a monster heatsink and fans doesn't make them easy to live with. Ditto for the P4. The Crusoe is making inroads right now just for its' low heat output and the fact that it's "good enough". The main selling point for Seagate's Barracuda ATA IV is its' silence, despite the swarm of larger or faster drives (I bought one). Bulky/noisy/hot overclocker machines will always be there, but I'd look for mainstream PCs to get a LOT more friendly in the next couple years.
This
I worked as a Civil engineer for 7 years before switching over to IT fulltime 5 years ago. I am afraid that all these analogies are wrong. A *LOT* of engineering projects run over budget and *MOST* of them run over time. The only real difference is that most clients don't come to you halfway through building the bridge and tell you to use a suspension system instead of plain old columns. (If they do, the engineer politely tells them to go away as they should have come up with those ideas during the design phase)Therein lies the biggest problem facing software engineering. The client always, repeat always wants to add or change features as you go along. This is OK if it comes during the design phase and not the build phase which is unfortunately when most clients first really realise what they want.
I think that most of us know that he does indeed post on Slashdot. In fact, he said as much in his interview with Slashdot.
A little research goes a long way, Anton.
WTF is Star Trek X?
Never heard of it. But I do admit, in Australia we're not exactly "in the loop" as far as new shit in America is concerned.
A link or some other descriptive item would be nice.
Thanks.
So when I say I dont believe that, I am being honest. All the following rant is based upon what I have experienced "in the trenches", so to speak. Mayhaps there is an more idealized place in the world where i am wrong (but I doubt it).
I've never met a "Software Engineer" who was an "Integrator" who did anything usefull without writing code. Those ones who did not know how to were absolutely useless. Those that did know how but did not implement were continuously running into the impermeable wall of "Reality Check" when they had to be informed that their snooty design couldnt work.
Any decent implementor on the other hand, had to be a designer/integrator almost by definition, becasuse there were never any rigourous enough requirements to be a tunnel visioned "implementor". Getting requirements that fine grained is apparently equivalent to writing the code.
If you are a high-level code "Architect" who thinks that implementing involves solving the same old simple subproblems, then you havent been reusing code very well. Check your abstraction level and start over.
You will find the truth: Software design *is* software implementation. There are no "Software Engineers", there are only Programmers.
If you draw a pentagon on the surface of the chip with a pencil, then your processor becomes invincible, and runs at 666 GHz. This is also known as the "pentagram of protection" trick.
Depending on how successful Spiner is in his negotiations, maybe the the movie will open with Data's severed head on a table.
They tried that.
It didn't work.
:-P
I don't know much about the actual building of bridges but the Bridge Builder game gave me a much deeper appreciation of the physics behind bridges. Plus, it was a fun way to fritter away a few hours on a rainy afternoon. Check it out.
..It's true, they don't make kindling the way they used to. If you don't believe me, try overclocking a K62 to 1.6Ghz - That's MUCH better kindling than an Athlon XP..
air and light and time and space
that they named a Star Trek character after a Quake demo!
You think somebody who tries to architect a software project without understanding the coding issues is stupid? I can't argue with that. Doesn't mean that the same skill are involved in architecting and coding.
By the same token, construction engineers who don't know how to lay a brick or weld a joint probably don't put up very good buildings. But that doesn't mean every mason or welder knows how to put up a skyscraper.
That only works for the first 1,000 cycles.
I coulda sworn his real name was Wil Wheaton, and cameos were appearances as yourself.
Upgrade Data to OS-X!
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
I admit it, your knowledge of Star Trek, The Next Generation far exceeds my own. I only vaguely remembered the episode at all, and that he had smashed up the glass thing. By the way, there are many vague laws even in our country. Let's say there's a street where the speed limit isn't posted, so you go the speed you assume the street should be, right? Well, then you get pulled over by a cop who tells you that you should have been going slower. "But it wasn't posted!" And then the cop says, "Ignorance from the law is no excuse." Even if you're from another state and had no idea that this street had a weird speed limit. Yeah, that's right. "Ignorance from the law is not an excuse" is a bureaucrat's excuse for being a jack ass.
As far as there being girls and "some games," I think I'll need to watch that episode again. If they're cute, then Crusher really was an idiot.
Oh yeah, I thought I might add this: The word "idiot" is not the language of a 2nd grader. It's the language of someone from Indiana, where it's pronounced the correct way: "idjit."
bright light: a light that is full of light or illumination.
See my point?
> If you are a high-level code "Architect" who thinks that implementing involves solving the
> same old simple subproblems, then you havent been reusing code very well. Check your
> abstraction level and start over.
I do think implementing involves solving the same old simple subproblems over and over again.
Why do you think we have patterns? Software tends to follow a set of rules, where the problems are often similar to ones you have tackled before, albeit with a slightly different set of initial tools and/or conditions. e.g. Resource pooling, factories, data warehouses... I could go on....
Perhaps you could explain what you mean by 'you haven't been reusing code very well'.
Surely not for Strom Thurmond.
This sig made only from recycled ASCII
DISPLAY display;
Rememeber, it's the code that actually does the work. Comments should explain what's not obvious in the code, but should NEVER substitute for well laid out, well written, and easily readable code. And comments shouldn't try to educate the programmer. For instance, back in the CGA card age, I wrote a function for drawing lines, with the following prototype:
void bresenham_line(int x1, int y1, intx2, int y2)
I put no comments in the function code itself. If a programmer has never heard of Bresenham's algorithm, he has no place in maintaining graphics code. The same is valid for a large number of well known algorithms, which are so basic and have been implemented so many times that all programmers should know them.
It may be hard for the beginners, but you are a beginner only once. That's why I prefer to write C programs in Unix, instead of Java, or VB programs in M$-Windows. Once you learn how to use industrial grade tools, you won't be satisfied with hobbyist tools anymore.
But, unfortunately, this is not always possible. Programmers are often seen as people who can do any maintenance in any sort of software. And that's where an over-abundance of comments may help. It's not that those comments are really necessary for a competent programmer to understand the code, they are actually doing a totally different job: they are trying to educate a financial programming expert in the basic concepts of digital signal processing (for example).
In the end, I believe that's one of the main reasons why so many programs stink. They were done by people who knew how to program, but didn't have but the vaguest idea about what they were programming for.
You mean, unles they were Open Source programs?
This isn't bull - its.. well, possible.
Some scientists in the UK have tested rooms with high incidences of 'spooky occurences' for noise, magnetics and such. They find that InfraSound, low frequency sound, is very often present.
They also found that this can resonate in your eyes. This makes you see grey patches - i.e. ghosts.
Most fans wont create infra sound - but your CASE might!
Isn't Star Trek X supposed to be like, hundreds of years before the Wesley Crusher character? Oh well, just throw in another time-machine worm-hole.
It's 10 PM. Do you know if you're un-American?
:)
hawk
If you're going to tantalize us with the claim that you own a totally silent PC, you are morally required to describe your system!
Because "software engineering" (I hate that name, its programming gadammit)
write complete operational code for a modern satalite(controlls, attitude adjustment, taking pictures, sending data, etc..), and keep it under 640K. Then you'll understand the difference between a software engineer and a programmer.
is not primarily implementation. Building a bridge requires very litte groundbreaking design:
you take a typically take a known bridge concept, and specialize it for the terrain.
If this is not a goal you try to achieve, then yes, you are just a programmer.
The tough part is getting it implemented on time and in budget, with tons of logistic hurdles, and avoiding material disaster.
Programming on the other hand is a continuous design process.
you need to look up the word design, think about implementing it, then get out of the business.
Implementation is a non-problem, its an ongoing architecture process. (Imagine trying to design a 20 mile long building with 7-10 architects, each with their own unique style)
this is why design standards are used by software engineers, but not programmers like you
On top of that, its all non-visual. An architect can look at rendered pictures of what he is designing to get an intuitive feel for its correctness,
my grandfather was an architect, and if he was alive right now he would kick your ass for that comment.
whereas a programmer must form his image without the benefit of evolved human spacial perception.
this goes back to design standards and practices.
Requirements analysis for a bridge is so simple a child can grok it: "something i can walk over the river on".
thats a pretty lame example, and I'm sure it would piss off the engineers that build bridges.
Its like saying the requirements analys for a program is so simple because anyone who sees the results can grasp all the detail that go on.
For your typical programming job requirements are much more nebulous: the customer doesnt really know what they want half the time (but theyll know it when they see it).
you froget the four steps:Design, design, design, code.
The whole analogy between Contruction Engineering and The Art of Programming is flawed, otherwise a completed contruction project would be a 40 foot high stack of blueprints that are suppossed to
solve a problem that nobody fully understands.
If that statement was true, satellites would fall from the sky every day, man would not have gotten to the moon and back again, computer networks would not exist, etc,etc,etc...
You sir have no concept of the field in which you are employeed.
Please scoot back to your PERL and VB programming, and leave the Engineering problems and analogies to engineers.
The Kruger Dunning explains most post on
Still, 24 decibels is pretty low. I've heard 40 quoted as an acceptable background noise for a sound studio, though most sources say 10. Assuming Seagate measured intensity right next to the drive, little or no sound must escape from the case.
I looked at marketing blurbs for various recent drives. All the products that are supposed to be "quiet" list seeking noise somewhere below 40 decibels. (Of course, all use bels instead of decibels, and none given sound frequency or the distance at which the sound intensity was measured.) I'm no acoustic engineer, but I rather suspect that any of these drives could be made "silent" with the right enclosure.
The fan is certainly going to be a much bigger noise source. It's a pity nobody tries to make fanless systems unless Steve Jobs is looking over their shoulder!
I'm a little bemused to hear a 450 Mhz G4 system described as "starting to show its age". What kind of app is it too slow to run? And are you sure the processor is the bottleneck? I'm not a Mac enthusiast, but the number-crunching superiority of the G4 architecture is pretty blatant. Perhaps an video card upgrade is in order.