Another thing that comes to mind is what Apple's VP of hardware engineering Jon Rubenstein said in an interview. He said that engineers get too creative when they do work, and end up engineering things that do not need engineering - the rote work, as he put it. You have to get engineers to be creative in the non-rote work.
That advice may apply well to hardware, but I think it's a Bad Idea for software. My attitude is generally that if I'm doing rote work, I've screwed up. I should make the computer do it; it will do it more more quickly, without possibility of error or boredom. So if I have redundant code, I attempt to restructure it so that work is done by the computer. Ideally at compile-time (so it's faster for the user) but at run-time if necessary. (Quality over performance.)
You refer to the cable guys as iif they are the epitome of computer science. They aren't computer scientists. They almost certainly aren't even programmers. Perhaps to the completely ignorant, all computer-related jobs are the same, but they aren't. Most jobs as a technician are crap.
Agreed.
Slightly above that would be the post of admin. Keeping something up to date. Installing new software. Above that, some network and system admins have interesting jobs designing new systems, implementing creative solutions to problems, and so forth. Programmers have a similar opportunity, to do creative coding, but often it's just another solution to another problem. Not something that sounds like a lotta fun. And above that would be computer science. Research. Whole different ball game.
Here's where you lose me. I don't agree that computer science is "above" programming. In fact, I'd say that programming is the union of computer science and software engineering. Superior programming requires contributions from both fields.
Software engineering is nothing to sneer at. It envelopes version control, coding style, rigorous specifications, code review, bug tracking, API documentation, user manuals, user interface design and testing, unit/regression/acceptance testing, etc. There's some real artistry involved. It's easy for us programmers to neglect these, saying that they aren't hard but we don't have the interest or resources. But in reality, when I really try to do even the most seemingly mundane of these tasks, I find there's a lot more skill involved than I previously realized.
The experience has also made me skeptical of the idea of farming software engineering tasks off wholesale to specialized people. For example, writing good API documentation requires the involvement of the people who designed the interface. Likewise good user manuals require the people who designed the UI and administered the user tests. Pure technical writers can maybe even write the bulk of the prose, but if they can't do what they document, they don't have a prayer of noting subtleties without help.
Summary: I think actually designing, implementing, and even proving correctness/efficiency of algorithms is a much smaller part of the whole than we like to admit. The other things not only valuable and difficult, but also should be done by the same people.
I take it you don't know much about Raskin. He has real reasons to criticize "another Windows" as he puts it, reasons that go far beyond "we've used this same model for some time."
That may be true, but my point stands. The article mentioned that he thinks they're implementing "another Windows" but doesn't answer two immediate questions: (1) why he thinks that is true and (2) why he thinks that is bad. It's poor journalism.
If you'd care to do what Salon did not, please feel free to post (or link to) a summary of his reasons. I have read a little of his work but not much. (And surely others have seen none at all.) I'm sure people would love to discuss them...
"There's this wonderful outpouring of creativity in the open-source world," Lanier said. "So what do they make -- another version of Unix?"
Jef Raskin jumped in. "And what do they put on top of it? Another Windows!"
"What are they thinking?" Lanier continued. "Why is the idealism just about how the code is shared -- what about idealism about the code itself?"
This is similar to many articles before disparaging the WIMP (Windows, Icons, Mouse, Pointer) model. A bunch of "visionaries" who see that we've used this same model for some time and therefore are convinced it is horribly limiting, and that we are using it solely because the people who actually make systems have less imagination than people who write these kinds of articles. [*] They never have any but the most vague suggestions of a better model. They certainly never take the time to explore its limitations longer to ensure it really is workable (much less actually an improvement).
In fact, this article is so vacuous that I'm not sure what they think stinks about software, much less why. And certainly not how to fix it.
[*] In fairness, this article mentions people who have done some impressive work in the past (and is thus atypical of the genre). But still, I do not see any suggestions for a fundamentally better model or even any concrete problems with the existing one.
At least one kernel developer is blind, and I never found this out until we met in person.
How do blind peeople program? What tools do they use to read code? When I navigate through code, I skim a lot. I use a folding text editor and expand folds as I'm more interested in the details of a function. I get a feel for the structure by looking at the indentation, the lengths of functions, etc. I guess I could see conceptually that a tool could exist to help a blind person do the same thing by sound, but I'm having trouble imagining the specifics. Especially with languages like Python (where whitespace is significant), a straight-up reading of the text would not be sufficient for programming. You'd need help seeing the indentation of existing code and placing it properly for new code. I guess it could be as simple as saying "12 spaces" at the beginning of each line, but I'd think they'd have something better than that. I'm curious what it is.
More generally, I'm curious what better tools we could have for coding quickly. I was intrigued a while ago by a (I think) Microsoft Research project where they tried to create an IDE that showed things more visually and with richer symbols, as you'd see in the pseudocode in a lot of textbooks. One of the project leaders was asked about blind people, and he said that his tool was not intended for them at all (or even for color-blind people, I believe). He drew an analogy to fighter pilots, where good vision is just a prerequisite. He said that blind people were free to design their own development software tailored for sound. I wonder if he's right if we'll end up with some really specialized programming tools, tailored to both our senses and the programming languages we use.
There must be a point where software makers can no longer say "DISCLAIMER: IF WE BREAK YOUR MACHINE, IT'S NOT OUR FAULT."
No, I think software makers must be able to continue making these disclaimers, for two reasons:
If they couldn't, no one would ever release free (as in beer) software anymore. Would you want to assume that level of liability for no gain?
Even in commercial software, it would slow down everything tremendously. Testing everything to the level that they test life-supporting systems is just not reasonable.
Instead, here's a radical idea: understand that software with such disclaimers was never intended to be used in situations where its failure could kill someone. So don't.
There is software out there that does not have blanket safety disclaimers. I believe QNX Neutrino does not, for example. I know they're using it in safety-critical systems at nuclear power plants.
You know... it's a really sad state of affairs when you have the lowest form of profession on the planet, and they know it well enough to actually be able to publicly say it with a straight face.
No, I think it is a mark of true professionalism to do a good job representing a client who apparently views your profession as the lowest one on the planet. There's nothing in that quote to suggest Thomas Clark agrees with this practice, and in fact I bet he hates it. But he did argue that it's legal. And it seems he did a good job, because he won.
Alan Hicks wrote: I can legally buy my own general purpose antibiotics and knock out most anything.
Idarubicin replied: Most common ailments from which people suffer (most coughs and colds, the flu) are viral infections. Antibiotics don't have any effect on them whatsoever. [...] through the regular use of antibiotics, you encourage the evolution of bacterial strains resistant to common broad-spectrum antibiotics. That doesn't just screw you, by the way...it affects the rest of us too.
Idarubicin is very much right. As someone who is quite allergic to at least one antibiotic, I hate people who abuse antibiotics by (1) taking them when they are unnecessary and (2) failing to finish their courses of antibiotics. (You do not stop taking the pills when you feel better! You take them all!) By failing to use antibiotics properly, you encourage resistant strains. Thus, we have to switch to different antibiotics, and that idea scares me. There aren't that many good ones to choose from, and who knows if any of the other ones are also dangerous to me. I'd rather just stick with the one I've repeatedly taken without problems, but people like Alan Hicks might make that impossible.
They're already limiting antibiotic use for ear infections, which are bacterial infections. They likely will have to start limiting them more for other types of infections as well. Though the article doesn't say so, I believe this is largely because antibiotics are abused by people like you, Alan Hicks.
How to take antibiotics properly: Go to the doctor when you think you need them. Tell him your symptoms. If he thinks you need antibiotics, question it anyway. Make sure his diagnosis makes sense, and make sure it is for a bacterial infection. When he gives you a course of antibiotics, take every one at the proper time. If you only feel better near the very end of the course, ask about extending the course to completely knock out the infection.
The second she got in, she started telling everyone how she was a lawyer, and making demands, refusing to sign forms, etc. Frankly, how she was able to be a bitch with two anuerisms is beyond me. [...] The doctors, not being idiots, or as nice as you perhaps, refused to take care of her, and I can see why.
Ugh! Isn't it common for people to have abnormal behavior immediately following an aneurism? Granted, that apparently was not the case for her (she did not just make threats right then; she sued the other hospital later) but how did they know that? Granted, I don't have the diagnosis/treatment knowledge they do, but I wouldn't want to take the risk that the extra time to send her to a different hospital wouldn't actually cause the harm she was claiming. Not only would her lawsuit claim then be legitimate, I'd have to live with that on my conscience.
Good Samaritan laws (which is amusing if you know the history of the Samaritans... which is why their being a good one was noteworthy)
As an AC mentioned, I don't think they were a horrible people, but there was a lot of mutual animosity between them and the Jews. There had been a recent incident involving defacing a temple, and so Jews were actually praying that Samaritans would not get eternal life. You can read the parable itself at Luke 10:30 and a good analysis here. It mentions why the priest and Levite were reluctant to help, and why the Samaritan would be as well. Yet of course the despised Samaritan does what the others would not.
I'm an atheist, but I like this parable. And it seems that most people neither understand the historical details nor understand that they can be the good Samaritan in their daily lives.
I routinely see over 10% of windows users show up with spyware on my anti-spyware page, and that's just what can be detected with a simple javascript utility over the web, so the actual total must be even higher than that.
Interesting, but I strongly doubt that those people are a representative sample of the total Windows-using population.
> >
What the hell kind of html is that?!? Firefox hates it.
> Looks pretty normal, it's just missing all the CSS information, which makes it quite deformed.
Indeed. It has an XHTML preamble, matching XHTML/CSS, and a fair amount of dynamic stuff (polls, email notifications, interface to the sex offender registry, etc.). This is a reasonably extensive site, and it's obvious that some quality work went into each page. (Not a Dreamweaver job.)
I don't know how much the bandwidth actually cost, or if he's actually demanding $300,000 (the two articles are conflicting, as people mentioned above), but there was skilled labor involved.
Until now, Intel-compatible processors have not been able to distinguish between sections of memory that contain data and those that contain program instructions. This has allowed hackers to insert malicious program instructions in sections of memory that are supposed to contain data only, and use buffer overflow to overwrite the "pointer" data that tells the processor which instruction to execute next. Hackers use this to force the computer to start executing their own code (see graphic).
The new AMD chips prevent this. They separate memory into instruction-only and data-only sections. If hackers attempt to execute code from the data section of memory, they will fail. Windows will then detect the attempt and close the application.
I've seen patches to Linux that provide a non-executable stack. There's also the mprotect(2) system call to change memory protection from user programs. And I believe OpenBSD has had a non-executable stack in the mainline for at least a couple releases.
So what they're advertising here seems to have already existed. If not, how are the things above possible?
> > Thirdly, Java GC is not really "conservative". An object is eligable for collection when (and only when) the reference count is zero.
> Minor nitpick, that is not completly correct.
An object can still have references to it, and still be elegible for gc'ing. That is what Weak- and SoftReferences are used for.
You're right, but that's not the whole truth. Back in the day when Java did not have weak or soft references, objects could still be eligible for collection while being referenced. To understand this, imagine a program's memory as a directed graph; allocated memory blocks are vertices, and non-null pointers are edges. Then say certain things are "grounded" (I'm making up a term here; I don't know the proper one) - stacks of live threads and statically allocated memory. A vertex is eligible for collection if and only if there are no (strong) paths to it from a grounded vertex. (Strong path = one not using weak or soft references.)
So when does this actually happen? Well, you can represent a tree in memory, and you might have a reference back to the parent node. (Assume you're not using these new reference types, for backwards compatibility or whatever reason.) Then your graph has a cycle. If you remove all outside references to the tree, there still are non-zero reference counts there. Yet the garbage collector can learn that it is not reachable and dispose of it.
If it weren't for this problem, we wouldn't need garbage collectors. We'd just use reference counting and be done with it. Maybe it'd be advantageous to keep a data structure of stuff that could be freed rather than immediately doing so in some situations (for responsiveness when there's no need to free memory any time soon) but that's as far as anyone would ever take it.
Is there any nifty way to speed up the compile->execute cycle? The way I see me coding is:
[...]
c)reboot test machine and wait 1-3 minutes for it to come up
[...]
step C could be frustrating, is there a quicker way to go about it?
You could making your changes to a User-mode Linux kernel to avoid the reboot. Or running it inside a virtual machine. That way you only have the kernel's boot time, not the main system BIOS, ATA-100 BIOS, SCSI BIOS, etc.
Also, what is the likely() and unlikely() functions you speak of. Google shows a lot of unrelated info.
They're macros that tell the compiler if the expression contained within is likely to be true or false. There's an article about them here. If you've ever seen any code that mentions __builtin_expect, it's the same thing with better names:
Try experiments. Make a change, set a hypothesis about what it will do, and run it. Then see why you were wrong, if you were. Then try it again. Even just getting in the habit of running the build system will help, and setting up experiments like this will help your debugging.
An addendum: your experiments don't have to be anything spectacular. Here are a few:
Try adding a few printk statements throughout the code, decide when you expect they will print and what they will say, and confirm it.
Try tuning a sysctl or hardcoded value. See how it affects performance. Do microbenchmarks or benchmark real systems. Make pretty graphs. (Graphs are fun!)
Add a likely() or unlikely() option to help the compiler's branch prediction. Again, test the performance. Or take one away - it's possible someone was wrong about the performance
And in user-level code, there are even more things you can do:
compile with -ftest-coverage to see what code is run and design unit tests to that uses every line. This will help your understand, could find existing bugs or dead code, and will help you be confident in your changes if you later make any.
compile with -ftest-coverage -fprofile-arcs to see what code branches are very likely or unlikely to be taken, then use likely() and unlikely() to change the branch prediction. Benchmark the results.
Another project I've considered is adding likely() and unlikely() equivalents to boost. A lot of people use this code, so increasing its performance a little would be pretty beneficial.
I wish I could wrap my head around even the smallest part of the kernel. There is so much code in there and aside from main(), it is hard to find a good place to start studying.
Very recently, I've been writing some low-level code. There was a long while I'd thought this was out of my league. Then I realized several things:
I was not happy with several characteristics of the low-level code other people had written and I was depending on.
I had done some more low-level stuff long ago - like a couple simple but legitimately useful assembly programs in DOS, and even a patch that added a sort of capability system to the OpenBSD kernel. (I never polished up the patch enough to send it in to them or anything, but the point is that it essentially worked, and I wasn't afraid to take it on.)
When I'd done those things back in the day, I wasn't anywhere near as good a coder as I am now.
The only reason I'd been unable to do these things more recently is an attitude that I'm not good enough, not a reality. (It's an attitude a lot of people in low-level code promote, I think. They so much don't want to waste their time with people who really are bad that they probably don't mind scaring off a few people who are in fact good but don't realize it. Also, I think there's ego involved - it's an exclusive club, why not let it stay that way.)
So I think the moral of the story is to just be fearless/persistent. If you're not confident, there are plenty of ways you can improve without even involving anyone else:
Read the code. It sounds obvious, but there's a lot of code I'd stayed away from even looking at because of intimidation.
Try experiments. Make a change, set a hypothesis about what it will do, and run it. Then see why you were wrong, if you were. Then try it again. Even just getting in the habit of running the build system will help, and setting up experiments like this will help your debugging.
Find something lacking and try to fix it.
And then, if you're still not comfortable talking on the linux-kernel list, I think you have at least another couple choices:
If you're lucky, you're friendly with someone more skilled and can use him/her to screen questions.
There's a couple lists like kernel-janitors and kernel-newbies to dip your feet in the water.
Sometimes in the process of writing an eloquent question through email you'll figure out the answer yourself. (Did you see the teddy bear anecdote in the debugging link above?)
As for myself, I'm taking my own advice to make sigsafe - an alternate set of system call wrappers (libc level) that eliminate a couple race conditions involving signals, without a performance penalty. It's going well - the code works, and I have a race condition checker and microbenchmark to prove it. I just released my first version. Now I'm working on the documentation; it still needs a lot of work. (I could use plenty of help with this project! If you want to try low-level programming, it's a great way. It requires writing assembly for each combination of operating system and architecture. I've only written it for two systems. There are plenty left, and public systems to do it on if you don't have access to exotic machines of your own. Plus, you can hopefully gain some low-level understanding by proof-reading and helping me write the documentation.)
Once I have that polished, I've got a couple projects I might try in the Linux kernel (and/or other kernels):
implementing a couple of system calls - the nonblocking_read(2) and nonblocking_write(2) that djb mentions.
implementing SO_RCVTIMEO and SO_SNDTIMEO under Linux. Assuming no one has yet; I haven't checked, so the manpage could just be out of date. Which brings m
Did you get a 503 unavailable? I've seen that error on and off a few times in the last week.
Twice it gave me a main page, but all the links were redirects back to the home page.
I think the slashcode is weakening.....
The redirects back to the front page are what happens when the MySQL database backend goes down. I'm surprised you've never noticed it before; it seems to happen regularly.
I always find it funny because whenever a MySQL vs. PostgreSQL argument starts, a MySQL person always says "Slashdot uses MySQL, so it must be reliable." Ummm, no. If they really wanted to say slashdot proves MySQL was more reliable, they should lie and say it uses PostgreSQL.
LennyDotCom said: When I spent my summers as a kid in italy on the farm when ever it looked like hail I would hear a booming sound like cannons. My mother told me it was the cannons that they fired into the clouds to stop the hail from knocking the grapes off the vines.
Pisco linked to an article (part 1 / part 2) that said:
His skepticism was well founded. Widespread damaging hailstorms raked regions of Austria, France, and Italy between
1902 and 1904. Vine growers protected by cannons were pounded mercilessly. By 1905, in a sudden turnaround, many disgusted vineyard owners had gotten rid of their hail cannons.
These absurd-looking devices fell into the dustbin of history, but not so for the tantalizing concept of weather modification. Cloud seeding and hail modification have preoccupied meteorologists in the years since then, but again, with largely unproven effects.
What's your secret to longevity? Are you a vampire?
Complex numbers and multidimensional arrays may be implementable in C++, but the possibility of getting everyone using the same package like boost::multi_array to do it seems somewhat unlikely. These are things that should be standardized in a language for scientific computing.
True to a certain extent, but I find more and more boost code showing up everywhere (in general; not just the math package). It's written by a lot of the same people involved in the C++ standard, and a fair amount of it is on the standards track. boost code gets a lot of review and publicity.
I think there are only a few serious C++ packages for this sort of work. few != 1, and "few" can grow, but I guess I don't see that as a big problem.
This is the standard homogeneous vs. heterogeneous argument, and I'm not sure it's one you can conclusively settle.
I also note that the boost::multi_array syntax for specifying subarrays is both longer and less standard than Fortran's Matlab style notation.
Certainly; C++ has always been an ugly language.
"The solution may be to move high-level optimizations out of compilers and into libraries. The Blitz++ library demonstrates how this may be done in C++." This sounds like a lot like admitting defeat and giving up on producing a C++ compiler that is any good for optimizing code for scientific computing. In contrast decent Fortran compilers produce very good executables with fairly straightforward coding of algorithms and relatively little extra effort.
I guess I just don't care if the effort was put into the library or the compiler, as long as I didn't have to do it. Why should it matter?
Modern Fortran compilers will compile all the old libraries.
True. But C++ is better for interacting with the rest of the modern world. There just aren't that many people using Fortran anymore, and C++ continues to grow.
C++ does not offer a lot of features that are needed for number crunching and are lacking in Fortran. People don't have any incentive to switch.
I kind of assume it's desirable to switch, because of the advantages in interacting with the rest of the world. I'm afraid I can't come up with a lot of specific advantages; I know much more about C++ than about scientific computing. But in general, I think templates are a killer feature for high-performance computing. They let you do so much with so little code.
The reason that Fortran is still popular in the scientific community is that it's pretty well optimised for the kind of tasks that you're likely to be doing. For example, Fortran has complex numbers as a basic data type. It's also simpler than C based languages for working with multidimensional arrays - no need to futz about with arrays of pointers or whatever, just declare a (resizable, if desired) multidimensional array. In general, the builtin functions are designed to work well on parallel architectures, so writing good parallel code isn't (quite) so much hard work.
The advantages you've listed just aren't that important against C++:
Compex numbers aren't built-in, but who cares? C++ classes let you do anything you can do with a primitive type, both as far as optimizations are concerned and syntactically (through operator overloading)
Likewise, multidimensional arrays can have all the syntactic sugar you want, through magical things like boost::multi_array.
I don't know as much about the parallel stuff, but obviously a lot of thought has gone into doing that kind of thing in C++. Intel also has a compiler that will auto-parallelize C++ (and Fortran), though I've never played with it.
It's very commonly said that Fortran is faster than any other language. I don't think that's actually true. This article, written back in July '97, talks about a lot of other techniques possible in C++ to close the performance gap and even outperform Fortran. And in the seven years since, C++ compilers have improved greatly, and these techniques have been widely adopted. There are a lot more papers here.
If you enable HT, you are cutting your L3 cache in half per "processor." So your 2.5Ghz Xeon with 512k cache turns into two 2.5ghz chips with 256k each.
Interesting. That's not the reason for disabling HyperThreading that I've heard. I often hear people say it should be disabled unless you have a scheduler that supports HyperThreading well. There are lots of opportunities to go wrong when scheduling tasks on HT-enabled CPUs.
For example, if you have one real processor and are running a high-priority task and a low-priority task, the low-priority task will get 50% of the processor time with a non-HT aware scheduler, since it says "well, I've got this processor free, so I might as well use it" when that's not really true. This problem is discussed more here.
Similarly, if you've got several high-performance tasks and several real processors, you want to spread them out across as many real processors as possible to maximize parallelism.
There are a few reasons why this project never took off:
First, they widely advertised it and then took forever to get the site going. I think most people had forgotten about it or given up on it by that point. And then they never publicized it again. (Specifically, it was initially slashdotted on 6 Feb 2002. On 13 Oct 2002, a message on the Sardonix mailing list mentioned that it had been mostly live for a couple weeks, and that the point system still wasn't online. No wider announcement.)
Second, all the packages listed there for review were fairly well-respected blocks of code written by skilled coders. Consequently, most of the reviews were of the form "yup, this code essentially looks good". They were also extremely large projects, so people said "I didn't do a full review; I just tried this automated tool". It doesn't really mesh up with what he said in the article:
Cowen believes Sardonix was a casualty of security community culture, which he says rewards researchers who find clever or splashy holes in a program, but not for making software more secure. "The Bugtraq model is: find a bug, win a prize -- a modest amount of fame," says Cowen. "Our model is: review a whole body of code, eventually finding no bugs, and receive a deeper level of appreciation from people who use the code.
"It seems the Sardonix lesson is people don't want to play this game, they want to play the Bugtraq game."
There was no "making software more secure [...] eventually finding no bugs"; I don't think anyone ever really found a significant bug through this project.
If they had targeted lots of small projects on freshmeat (like web stuff - PHP, mod_perl, JSP/servlet, etc.), it would have been much more interesting. Those projects have all kinds of security bugs. They could have taught the people in question some good security practices and actually accomplished what they set out to do. Maybe they would have eventually branched out into certifying these infrastructure projects, but it wasn't a good initial goal.
Lastly, who knows they did with that DARPA funding. Plenty of open source projects with no funding do much more impressive works than that website, and in much less time, too.
Yes, but, these are the same analysts who predicted the GameCube's price drop, the PS2 price drop, and the XBox price drop. They've done well before, and they will probably be spot on about this one too. Now, as for the Xbox 2 in 2005, I think they'd have to have some serious balls to try and do that, but I wouldn't put it past them.
That's all true, but how close do analysts need to be for their guess to be considered correct? The price of a console will drop several times before they stop selling it. We don't need analysts to tell us that. So all these people are predicting is when and by how much. How close did they come on those earlier predictions?
Slashdot Mirror
That advice may apply well to hardware, but I think it's a Bad Idea for software. My attitude is generally that if I'm doing rote work, I've screwed up. I should make the computer do it; it will do it more more quickly, without possibility of error or boredom. So if I have redundant code, I attempt to restructure it so that work is done by the computer. Ideally at compile-time (so it's faster for the user) but at run-time if necessary. (Quality over performance.)
Agreed.
Slightly above that would be the post of admin. Keeping something up to date. Installing new software. Above that, some network and system admins have interesting jobs designing new systems, implementing creative solutions to problems, and so forth. Programmers have a similar opportunity, to do creative coding, but often it's just another solution to another problem. Not something that sounds like a lotta fun. And above that would be computer science. Research. Whole different ball game.
Here's where you lose me. I don't agree that computer science is "above" programming. In fact, I'd say that programming is the union of computer science and software engineering. Superior programming requires contributions from both fields.
Software engineering is nothing to sneer at. It envelopes version control, coding style, rigorous specifications, code review, bug tracking, API documentation, user manuals, user interface design and testing, unit/regression/acceptance testing, etc. There's some real artistry involved. It's easy for us programmers to neglect these, saying that they aren't hard but we don't have the interest or resources. But in reality, when I really try to do even the most seemingly mundane of these tasks, I find there's a lot more skill involved than I previously realized.
The experience has also made me skeptical of the idea of farming software engineering tasks off wholesale to specialized people. For example, writing good API documentation requires the involvement of the people who designed the interface. Likewise good user manuals require the people who designed the UI and administered the user tests. Pure technical writers can maybe even write the bulk of the prose, but if they can't do what they document, they don't have a prayer of noting subtleties without help.
Summary: I think actually designing, implementing, and even proving correctness/efficiency of algorithms is a much smaller part of the whole than we like to admit. The other things not only valuable and difficult, but also should be done by the same people.
That may be true, but my point stands. The article mentioned that he thinks they're implementing "another Windows" but doesn't answer two immediate questions: (1) why he thinks that is true and (2) why he thinks that is bad. It's poor journalism.
If you'd care to do what Salon did not, please feel free to post (or link to) a summary of his reasons. I have read a little of his work but not much. (And surely others have seen none at all.) I'm sure people would love to discuss them...
The article is crap. A typical snippet:
This is similar to many articles before disparaging the WIMP (Windows, Icons, Mouse, Pointer) model. A bunch of "visionaries" who see that we've used this same model for some time and therefore are convinced it is horribly limiting, and that we are using it solely because the people who actually make systems have less imagination than people who write these kinds of articles. [*] They never have any but the most vague suggestions of a better model. They certainly never take the time to explore its limitations longer to ensure it really is workable (much less actually an improvement).
In fact, this article is so vacuous that I'm not sure what they think stinks about software, much less why. And certainly not how to fix it.
[*] In fairness, this article mentions people who have done some impressive work in the past (and is thus atypical of the genre). But still, I do not see any suggestions for a fundamentally better model or even any concrete problems with the existing one.
How do blind peeople program? What tools do they use to read code? When I navigate through code, I skim a lot. I use a folding text editor and expand folds as I'm more interested in the details of a function. I get a feel for the structure by looking at the indentation, the lengths of functions, etc. I guess I could see conceptually that a tool could exist to help a blind person do the same thing by sound, but I'm having trouble imagining the specifics. Especially with languages like Python (where whitespace is significant), a straight-up reading of the text would not be sufficient for programming. You'd need help seeing the indentation of existing code and placing it properly for new code. I guess it could be as simple as saying "12 spaces" at the beginning of each line, but I'd think they'd have something better than that. I'm curious what it is.
More generally, I'm curious what better tools we could have for coding quickly. I was intrigued a while ago by a (I think) Microsoft Research project where they tried to create an IDE that showed things more visually and with richer symbols, as you'd see in the pseudocode in a lot of textbooks. One of the project leaders was asked about blind people, and he said that his tool was not intended for them at all (or even for color-blind people, I believe). He drew an analogy to fighter pilots, where good vision is just a prerequisite. He said that blind people were free to design their own development software tailored for sound. I wonder if he's right if we'll end up with some really specialized programming tools, tailored to both our senses and the programming languages we use.
No, I think software makers must be able to continue making these disclaimers, for two reasons:
Instead, here's a radical idea: understand that software with such disclaimers was never intended to be used in situations where its failure could kill someone. So don't.
There is software out there that does not have blanket safety disclaimers. I believe QNX Neutrino does not, for example. I know they're using it in safety-critical systems at nuclear power plants.
No, I think it is a mark of true professionalism to do a good job representing a client who apparently views your profession as the lowest one on the planet. There's nothing in that quote to suggest Thomas Clark agrees with this practice, and in fact I bet he hates it. But he did argue that it's legal. And it seems he did a good job, because he won.
Alan Hicks wrote: I can legally buy my own general purpose antibiotics and knock out most anything.
Idarubicin replied: Most common ailments from which people suffer (most coughs and colds, the flu) are viral infections. Antibiotics don't have any effect on them whatsoever. [...] through the regular use of antibiotics, you encourage the evolution of bacterial strains resistant to common broad-spectrum antibiotics. That doesn't just screw you, by the way...it affects the rest of us too.
Idarubicin is very much right. As someone who is quite allergic to at least one antibiotic, I hate people who abuse antibiotics by (1) taking them when they are unnecessary and (2) failing to finish their courses of antibiotics. (You do not stop taking the pills when you feel better! You take them all!) By failing to use antibiotics properly, you encourage resistant strains. Thus, we have to switch to different antibiotics, and that idea scares me. There aren't that many good ones to choose from, and who knows if any of the other ones are also dangerous to me. I'd rather just stick with the one I've repeatedly taken without problems, but people like Alan Hicks might make that impossible.
They're already limiting antibiotic use for ear infections, which are bacterial infections. They likely will have to start limiting them more for other types of infections as well. Though the article doesn't say so, I believe this is largely because antibiotics are abused by people like you, Alan Hicks.
How to take antibiotics properly: Go to the doctor when you think you need them. Tell him your symptoms. If he thinks you need antibiotics, question it anyway. Make sure his diagnosis makes sense, and make sure it is for a bacterial infection. When he gives you a course of antibiotics, take every one at the proper time. If you only feel better near the very end of the course, ask about extending the course to completely knock out the infection.
Ugh! Isn't it common for people to have abnormal behavior immediately following an aneurism? Granted, that apparently was not the case for her (she did not just make threats right then; she sued the other hospital later) but how did they know that? Granted, I don't have the diagnosis/treatment knowledge they do, but I wouldn't want to take the risk that the extra time to send her to a different hospital wouldn't actually cause the harm she was claiming. Not only would her lawsuit claim then be legitimate, I'd have to live with that on my conscience.
As an AC mentioned, I don't think they were a horrible people, but there was a lot of mutual animosity between them and the Jews. There had been a recent incident involving defacing a temple, and so Jews were actually praying that Samaritans would not get eternal life. You can read the parable itself at Luke 10:30 and a good analysis here. It mentions why the priest and Levite were reluctant to help, and why the Samaritan would be as well. Yet of course the despised Samaritan does what the others would not.
I'm an atheist, but I like this parable. And it seems that most people neither understand the historical details nor understand that they can be the good Samaritan in their daily lives.
Interesting, but I strongly doubt that those people are a representative sample of the total Windows-using population.
> Looks pretty normal, it's just missing all the CSS information, which makes it quite deformed.
Indeed. It has an XHTML preamble, matching XHTML/CSS, and a fair amount of dynamic stuff (polls, email notifications, interface to the sex offender registry, etc.). This is a reasonably extensive site, and it's obvious that some quality work went into each page. (Not a Dreamweaver job.)
I don't know how much the bandwidth actually cost, or if he's actually demanding $300,000 (the two articles are conflicting, as people mentioned above), but there was skilled labor involved.
Sure, but at least some of these patches work on x86. From the Openwall kernel patch FAQ:
I've seen patches to Linux that provide a non-executable stack. There's also the mprotect(2) system call to change memory protection from user programs. And I believe OpenBSD has had a non-executable stack in the mainline for at least a couple releases.
So what they're advertising here seems to have already existed. If not, how are the things above possible?
> > Thirdly, Java GC is not really "conservative". An object is eligable for collection when (and only when) the reference count is zero.
> Minor nitpick, that is not completly correct. An object can still have references to it, and still be elegible for gc'ing. That is what Weak- and SoftReferences are used for.
You're right, but that's not the whole truth. Back in the day when Java did not have weak or soft references, objects could still be eligible for collection while being referenced. To understand this, imagine a program's memory as a directed graph; allocated memory blocks are vertices, and non-null pointers are edges. Then say certain things are "grounded" (I'm making up a term here; I don't know the proper one) - stacks of live threads and statically allocated memory. A vertex is eligible for collection if and only if there are no (strong) paths to it from a grounded vertex. (Strong path = one not using weak or soft references.)
So when does this actually happen? Well, you can represent a tree in memory, and you might have a reference back to the parent node. (Assume you're not using these new reference types, for backwards compatibility or whatever reason.) Then your graph has a cycle. If you remove all outside references to the tree, there still are non-zero reference counts there. Yet the garbage collector can learn that it is not reachable and dispose of it.
If it weren't for this problem, we wouldn't need garbage collectors. We'd just use reference counting and be done with it. Maybe it'd be advantageous to keep a data structure of stuff that could be freed rather than immediately doing so in some situations (for responsiveness when there's no need to free memory any time soon) but that's as far as anyone would ever take it.
[...]
c)reboot test machine and wait 1-3 minutes for it to come up
[...]
step C could be frustrating, is there a quicker way to go about it?
You could making your changes to a User-mode Linux kernel to avoid the reboot. Or running it inside a virtual machine. That way you only have the kernel's boot time, not the main system BIOS, ATA-100 BIOS, SCSI BIOS, etc.
Also, what is the likely() and unlikely() functions you speak of. Google shows a lot of unrelated info.
They're macros that tell the compiler if the expression contained within is likely to be true or false. There's an article about them here. If you've ever seen any code that mentions __builtin_expect, it's the same thing with better names:
An addendum: your experiments don't have to be anything spectacular. Here are a few:
- Try adding a few printk statements throughout the code, decide when you expect they will print and what they will say, and confirm it.
- Try tuning a sysctl or hardcoded value. See how it affects performance. Do microbenchmarks or benchmark real systems. Make pretty graphs. (Graphs are fun!)
- Add a likely() or unlikely() option to help the compiler's branch prediction. Again, test the performance. Or take one away - it's possible someone was wrong about the performance
And in user-level code, there are even more things you can do:Another project I've considered is adding likely() and unlikely() equivalents to boost. A lot of people use this code, so increasing its performance a little would be pretty beneficial.
Very recently, I've been writing some low-level code. There was a long while I'd thought this was out of my league. Then I realized several things:
So I think the moral of the story is to just be fearless/persistent. If you're not confident, there are plenty of ways you can improve without even involving anyone else:
And then, if you're still not comfortable talking on the linux-kernel list, I think you have at least another couple choices:
As for myself, I'm taking my own advice to make sigsafe - an alternate set of system call wrappers (libc level) that eliminate a couple race conditions involving signals, without a performance penalty. It's going well - the code works, and I have a race condition checker and microbenchmark to prove it. I just released my first version. Now I'm working on the documentation; it still needs a lot of work. (I could use plenty of help with this project! If you want to try low-level programming, it's a great way. It requires writing assembly for each combination of operating system and architecture. I've only written it for two systems. There are plenty left, and public systems to do it on if you don't have access to exotic machines of your own. Plus, you can hopefully gain some low-level understanding by proof-reading and helping me write the documentation.)
Once I have that polished, I've got a couple projects I might try in the Linux kernel (and/or other kernels):
The redirects back to the front page are what happens when the MySQL database backend goes down. I'm surprised you've never noticed it before; it seems to happen regularly.
I always find it funny because whenever a MySQL vs. PostgreSQL argument starts, a MySQL person always says "Slashdot uses MySQL, so it must be reliable." Ummm, no. If they really wanted to say slashdot proves MySQL was more reliable, they should lie and say it uses PostgreSQL.
Pisco linked to an article (part 1 / part 2) that said:
What's your secret to longevity? Are you a vampire?
True to a certain extent, but I find more and more boost code showing up everywhere (in general; not just the math package). It's written by a lot of the same people involved in the C++ standard, and a fair amount of it is on the standards track. boost code gets a lot of review and publicity.
I think there are only a few serious C++ packages for this sort of work. few != 1, and "few" can grow, but I guess I don't see that as a big problem.
This is the standard homogeneous vs. heterogeneous argument, and I'm not sure it's one you can conclusively settle.
I also note that the boost::multi_array syntax for specifying subarrays is both longer and less standard than Fortran's Matlab style notation.
Certainly; C++ has always been an ugly language.
"The solution may be to move high-level optimizations out of compilers and into libraries. The Blitz++ library demonstrates how this may be done in C++." This sounds like a lot like admitting defeat and giving up on producing a C++ compiler that is any good for optimizing code for scientific computing. In contrast decent Fortran compilers produce very good executables with fairly straightforward coding of algorithms and relatively little extra effort.
I guess I just don't care if the effort was put into the library or the compiler, as long as I didn't have to do it. Why should it matter?
Modern Fortran compilers will compile all the old libraries.
True. But C++ is better for interacting with the rest of the modern world. There just aren't that many people using Fortran anymore, and C++ continues to grow.
C++ does not offer a lot of features that are needed for number crunching and are lacking in Fortran. People don't have any incentive to switch.
I kind of assume it's desirable to switch, because of the advantages in interacting with the rest of the world. I'm afraid I can't come up with a lot of specific advantages; I know much more about C++ than about scientific computing. But in general, I think templates are a killer feature for high-performance computing. They let you do so much with so little code.
The advantages you've listed just aren't that important against C++:
It's very commonly said that Fortran is faster than any other language. I don't think that's actually true. This article, written back in July '97, talks about a lot of other techniques possible in C++ to close the performance gap and even outperform Fortran. And in the seven years since, C++ compilers have improved greatly, and these techniques have been widely adopted. There are a lot more papers here.
Interesting. That's not the reason for disabling HyperThreading that I've heard. I often hear people say it should be disabled unless you have a scheduler that supports HyperThreading well. There are lots of opportunities to go wrong when scheduling tasks on HT-enabled CPUs.
For example, if you have one real processor and are running a high-priority task and a low-priority task, the low-priority task will get 50% of the processor time with a non-HT aware scheduler, since it says "well, I've got this processor free, so I might as well use it" when that's not really true. This problem is discussed more here.
Similarly, if you've got several high-performance tasks and several real processors, you want to spread them out across as many real processors as possible to maximize parallelism.
First, they widely advertised it and then took forever to get the site going. I think most people had forgotten about it or given up on it by that point. And then they never publicized it again. (Specifically, it was initially slashdotted on 6 Feb 2002. On 13 Oct 2002, a message on the Sardonix mailing list mentioned that it had been mostly live for a couple weeks, and that the point system still wasn't online. No wider announcement.)
Second, all the packages listed there for review were fairly well-respected blocks of code written by skilled coders. Consequently, most of the reviews were of the form "yup, this code essentially looks good". They were also extremely large projects, so people said "I didn't do a full review; I just tried this automated tool". It doesn't really mesh up with what he said in the article:
There was no "making software more secure [...] eventually finding no bugs"; I don't think anyone ever really found a significant bug through this project.
If they had targeted lots of small projects on freshmeat (like web stuff - PHP, mod_perl, JSP/servlet, etc.), it would have been much more interesting. Those projects have all kinds of security bugs. They could have taught the people in question some good security practices and actually accomplished what they set out to do. Maybe they would have eventually branched out into certifying these infrastructure projects, but it wasn't a good initial goal.
Lastly, who knows they did with that DARPA funding. Plenty of open source projects with no funding do much more impressive works than that website, and in much less time, too.
That's all true, but how close do analysts need to be for their guess to be considered correct? The price of a console will drop several times before they stop selling it. We don't need analysts to tell us that. So all these people are predicting is when and by how much. How close did they come on those earlier predictions?