The swing voters always hold more power than the multi-issue block voters. There are 40-45% of the people who will vote for canidate A- and nothing canidate B can do or say to change that. Likewise, 40-45% are going to vote for B no matter what A does. The election will be decided by the 10-20% swing voters, whom both A and B are wooing like crazy.
Being a multi-issue voter pretty quickly consigns you to the 80-90% block that gets ignored. You're too hard to woo.
Organization is also important. This is something Geeks are terrible at- we have too much of an anarchist/libertarian streak. Consider: if someone were to organize a "GeekPAC", how successfull would it be? Would you join? Would you contribute money? Would you vote the way the PAC wanted you to vote? Or would you go your own way, and make your own decisions?
If you're a Democrat, what would it take to get you to vote for Bush? If you're a Republican, what would it take to get you to vote for Gore? If you are anarchist/libertarian/socialist/other, what would it take to get you to vote for either?
Although, there is another way to get your beliefs enacted in the political system: control the information to shape the views of the 90%. See Noam Chomsky. The internet/web is not yet a replacement for the classic print/film/radio/TV media, but it's getting there.
You trust all three less once you learn how they're made.
Seriously, my opinion is that there isn't a problem. Frankly, the debates open source has are exceptionally polite and professional. This is how programmers talk to each other- cope with it. They do it in the corporate world as well.
There are three differences. First of all, it's done behind closed doors, so you never hear of the personality conflicts, shouting matches, and even physical assaults, that occur. All you see is the corporate flack painting a Leninist picture of unity of purpose as the entire company strides in lockstep towards a glorious future of increasing shareholder equity. Pay no attention to the men behind the curtain.
Second, in open source, your career isn't threatened by the decisions made. And, by armchair phsycoanalyst extension, neither is your identity. A better example of this than the Bruce Perens/Eric Raymond/Richard Stallman bruhaha is the Gnome/KDE conflict.
In a corporate environment, only one of Gnome or KDE would be developed. The other team would be told "Sorry- you can't work on that anymore, and we're going to throw all of your work into the bit bucket, where it'll never see the light of day again. Better luck next project." Development on Gnome does not preclude development on KDE, or vice versa, giving advocates on both sides room to back off and not take it so personally.
Of course, there is still a lot of strutting and bragging that goes on- "My project is better than yours!" (Especially from those who are at most marginally associated with the projects- AC, this means *YOU*. You rarely see this sort of strutting from the project leads). This is normal, and goes on in the corporate world as well. Heck, it's natural human behavior- listen to new parents talking about their kids.
The third difference are that the debates are public.
The first question I had was "what isn't user friendly about Linux's interface?" I mean, you have your classic WIMP interface- anyone capable of using Windows will come up to speed on how to use Linux reasonably quickly.
Unless you'd like to claim that Windows isn't ready for the desktop...
And then it occurred to me that I have a slightly different definition of "using" than everyone else. I mean doing things like word processing, or browsing the web, etc. Actually getting work done.
I do not mean installing the OS, or getting drivers to work, or installing software, etc. Those I call "administration". The implicit assumption is that the user is also the administrator- and that the box must not only be easy to use, but also easy to administrate. Professional admins need not apply.
In a home environment, there is some legitimacy to this thought (although I'd debate it- how often to YOU have to go over to various relatives or friends houses to fix their computers?). In the corporate world there is NONE WHATSOEVER.
Consider for a moment how many positions are available for Windows administrators (certified or not). With a network of even as few as 100 desktops, you need a professional, trained admin. Very rapidly you need a team of them.
Or should grandma be able to administrate a network of 2000 desktops, half a dozen file/print servers, and a million dollar database server?
Once you accept that even small corporations have professional admins in residence, then it isn't a problem if Linux _requires_ professional admins. In the market it's likely to penetrate, the admins are already there. The budget is already there. And Linux is ready for at least that desktop (the home market will be a longer time in comming).
Actually, it hasn't changed that much since the 70's. Primarily because there isn't much better that you can do- IIRC, parsing has theoretical computational limits (O(n)), and LALR(1) parsing is pushing those limits hard. It's the same reason sorting and searching are mostly dead subjects- there's not a whole lot better we can do, even theoretically.
Aho, et. al. is the Dragon Book. That's one of the seminal references for compiler design. It doesn't get any better.
The only other book I'd recommend is "Compiler Design in C" by Andrew I. Holub- which is actually more about the syntax analysis than the full compiler construction (it contains a simplified Lex & Yacc set of tools- for the same reason Tannebaum wrote Minix). Unfortunately, it's out of print. And you can't have my copy.
Re:Garbage Collection is for Incompetent Programme
on
The New Garbage Man
·
· Score: 4
GC for procedural code is optional. A good idea, IMHO- but still optional. If worse comes to worse, you can always "bubble up" responsibility for deallocating the memory to the block in which encompasses the entire lifetime of the memory. For example, if you had: void * mem_p; void foo(void) { mem_p = malloc(somesize); /* use mem_p */ } void bar(void) { /* does mem_p need to be allocated? */ /* use mem_p */ /* does mem_p need to be freed? */ } void bang(void) { foo(); bar(); } We can refactor this to: void foo (void * mem_p) { ... } void bar (void * mem_p) { ... /* we don't need to free mem_p here */ } void bang (void) { void * mem_p = malloc(somesize); foo(mem_p); bar(mem_p); }
We can do this because the life time of the body of bang() completely encompasses the life time of mem_p- which neither foo() nor bar() does.
Unfortunately, OO programming makes GC signifigantly less optional. And exceptions make GC no longer an option. Consider the following C++ code: { someclass * ptr1 = new someclass(); someclass * ptr2 = new someclass(); ... }
Can you spot the bug? If the program runs out of memory trying to allocate the second class, new throws an exception. But since the exception isn't immediatly caught, the stack is simply poped, and the memory pointed to by ptr1 is leaked.
The solution, as any C++ programmer will tell you, is to use smart classes and smart pointers, which implement GC. I.e., if the language doesn't have GC, you have to add it.
There are other reasons to use GC- by using GC you can more effectively divorce the implementation of a class from it's interface. In a GC system you don't have to export information about the memory management aspects of the implementation. This is especially important if you have two different classes implementing the same interface, but with different memory management requirements.
Which is faster, GC or manual allocation, often depends upon both the program in question, and the GC algorithm implemented. There is some data indicating that copying garbage collection is the fastest in complex situations- what you lose copying the data you win back in better cache and virtual memory utilization.
"True" Microkernel OSs have a problem that's generally swept under the rug of theory: task switches cost performance. Dozens, if not hundreds, of clock cycles per switch, and that's not counting the costs of TLB and cache thrashing. The only way to offset this is by doing fewer task switches- i.e. by "monolithizing" the kernel into larger and larger chunks. An example of this happening is when NT4 brought the graphics primitives into the kernel for performance reasons. In extremis you get the AmigaOS- which was a "true" microkernel design and got good performance, but at the cost of having no memory protection at all. Task switches became little more expensive than procedure calls.
"True" monolithic kernels also have problems- mainly lack of configurability, the need to recompile the entire kernel to add or remove a driver or reconfigure anything, etc. To overcome these limitations, the kernels need to undergo "microkernalization"- an example of this happening is Linux getting loadable modules.
So the best operating systems- those who strike the best balance between configurability and performance- are the "mixed breed" OSs, either monolithic kernels with microkernel-like features, or microkernels with monolithic-like features. At this point, the difference between "microkernels" and "monolithic kernels" is the difference between Coke and Pepsi.
First off, there are profound performance differences that can be acheived simply by optimizing for the Pentium Pro and not the Pentium, see The Twofish Implementations. This is mainly just instruction ordering issues- possible to do in a JIT. There's more to optimization anymore than simple cycle counting.
Second, memory management is a different beast under object oriented programming than under procedural programming. The holy grail of object oriented programming (as it were) is black box reuse- allowing a class maintainer to modify how a class works without those using the class needing to change their code. Not having garbage collection in an OO language either disallows true black-box reuse (which is a maintainability issue), forces the object to implement it's _own_ garbage collection (such as the C++ STL template basic_string does- and this is generally the worst sort of garbage collection, such as basic_string's reference counting), or forces the program to leak memory like a seive. If those are the options, then garbage collection is not too high a price to pay.
Especially when you consider that GC isn't that high of a cost. _Every_ memory management scheme that isn't static in nature that I've seen is O(n). Either on the allocation or on the free. Sooner or later you have to search for a hole. GC doesn't remove this penalty, but instead it allows you to _defer_ it until a better time. Since most programs spend most of their time waiting for input, there are lots of places where garbage collection can be free because the program isn't doing anything else.
Last, but not least, I'd like to point you at the The GC FAQ, a good resource for all things GC related. Highly recommended reading- after it, it was "intuitively obvious" that the world was flat, that the sun went around the earth, and that time didn't slow down as you went faster.
The Morris Worm is actually a good example- yes, a Unix virus _can_ be written, but it takes more know-how than a DOS or WordMacro virus takes. Morris himself was the son of the head of computer security for the NSA, he knew pretty much all the holes unix had back then.
The technical hurdle, as low as it might be, is important. By the time you are sufficiently knowledgable to be dangerous, you're usually intelligent enough to know _why_ this behavior is frowned upon. And have channeled your behaviors into more socially acceptable (and might I add, more rewarding) behaviors. Most decent sysadmins could be hackers and virus writters of legendary proportions. Generally, they aren't.
The open source nature of Linux even helps here- as now there are other ways for a bright teenager to gain fame and technical esteem than writting virii. Instead, they can write kernel patches, or work on Gnome or Abiword, or write their own programs- in other words they can do something _productive_ rather than _destuctive_ programs. I'm kind of interested to see what a couple million chinese programmers can create. I doubt it'll be virii:-).
I find it humorous that in one post Katz rails against individuality and obnoxiousness, and the next against corporatism. One of the biggest things corporatism sells is a warm&fuzzy image- Barney and the Smurfs as corporate spokespeople. The advantage of conformanity and homogenity is that people won't get offended.
Corporatism isn't anything new- does "Whats good for GM is good for the US" sound familiar to anyone? People should read Noam Chomsky more often. Corporatism (as it's known now) took over the national media sometime late in the 19th century (that's the 1800's for those still having problems with their date routines). What is difference is that we're becoming _aware_ of the problem.
On the other hand, Intel is going to try to switch architectures here in a year or three, from the old x86 to the new IA64. This is a vulnerable time for Intel- if you're moving onto a new architecture, why not move onto the best one available? This is the best time in the last couple of decades to launch a new CPU.
I'll agree that the odds are still against them. Too many people buy on the basis of MHz rating and "Intel Inside". But they have a shot...
Do not implicitly assume the problem is only with the testosterone laden male- he's simple the most visible (and least well liked) symbol. _Everything_ offends somebody. If you can't handle being offended, is the problem in the offender? Or is the problem in the offended- who either has been so sheltered that they've never encountered serious offense before, or who are attempting a passive-aggressive strategy for not _allowing_ dissenting viewpoints to be heard.
As a member of the white, male, oppressive class, what the heck do I know about harrassment, including sexual harrasment? Have I ever experienced it? Yeah, I have. I called it high school. Did I let it drive me into a snivelling ball, unable or unwilling to deal with others of my race who offend me? Heck no. I coped. So can you.
And yes, there are discussions I absent myself from. I rarely read slashdot comments with less than a threshold of 4. Not because I simply can't deal with them, but because I have better things to do with my time. Not everyone can participate in all discussions- and that's OK too.
Pardon me for not being PC. Pardon me for not being warm&fuzzy. Pardon me if I've offended you. Pardon me if I don't give a flying fuck if I've offended you. If you can't stand the heat, stay out of the kitchen.
There is another aspect to this people should consider as a possible motive: it's effect on Windows 2000.
An earlier/. article linked to a study claiming that some large plurality (60+%) of large IS departments were not planning on switching to W2K until 2001 or later, while an excessively large minority (10+%) were not planning to switch at all. Wether these numbers are accurate or not it has to be plain that customer demand for W2K will be soft- especially compared to the roll-out of Windows 95. By putting The Man himself on the project, they may be hoping for a "Steve Jobs effect" for W2K. Especially for the faithfull who still look upon Bill Gates as a technical visionary.
In addition, IIRC the W2K project has already driven two managers into early retirement, and Brad Silverberg (of W95 fame) didn't want to touch it with a 10' cattle prod. One has to wonder if W2K hasn't acquired the stench of being a career killer for those put in charge of it within the halls of Microsoft. Once again, putting The Man in charge could be a (internal) PR boost for W2K.
It's not just pornography. It's a question of accountability. By installing commercial blocking software, the _library_ and the _community_ are no longer deciding what is and is not allowed- the corporation writting the blocking software is.
And it's not just Pornography that's getting blocked. Most site lists tend to have disturbing political bias- blocking sites like the National Organization of Women or gay rights sites. But since such lists are generally not available publically, who knows what is in them.
I'm not an employee of either company. But I was a DR-DOS user when this stuff went down. Some comments, if I may: 1) MS used this very error message as a springboard for a serious FUD campaign. Microsoft convinced people that Windows-on-DRDOS was even more unstable than Windows-on-MSDOS. 2) The peice of code responsible for this was encrypted. Now, pray tell, why go to extreme lengths to hide the code if it was legitimate?
But that wasn't the only leg the lawsuit stood on. There was also the minor issue of per-processor licensing and other predatory pricing schemes designed to keep DR-DOS out of the OEM market.
So drown your sorrows in free coke and stock options. You get _no_ sympathy from me.
The article makes it sound like Caldera/DR-DOS said "Hey, we lost- let's sue!" Some things on Caldera's side:
1) Per-processor licensing. Caldera can prove that Microsoft used pressure that no one else could have brought to bear (i.e. monopoly-based pressure) on to the OEMs to prevent DR-DOS from being preinstalled. Microsoft's relationship with (and coercion of) the OEMs is discussed in depth in Judge Jackson's FOF. Caldera can use all of that and more.
2) The christmas beta. If Microsoft hadn't encrypted that code to make it harder to find and determine how it worked, they might have been able to claim it was just a Beta bug. But the _premeditated_ attempt to hide what they were doing says that they knew they were wrong.
Microsoft's defense is "Yeah, we committed a crime- but it can't be undone and it was aeons ago in computer years, so who cares?" Bleh.
That guy working 16-hour days and subsisting on pizza and twinkies is not necessarily more productive (especially in the long run) than the guy whose leaving at 5:30. Stressing out your employees to the point where they're leaving the field and not just your company is dumb. "Gee, he's irreplacable- let's work him till he quits."
The assumption you're making is that solutions you buy don't also have a cost in time. This has not been my experience.
Another thing to consider: cost of duplication is small. Once the thing is working, it's fairly easy to run off a couple of million copies of the software. If you're expecting to sell a couple of million boxes, even a $10/box license suddenly pays for a lot of up-front engineering.
I recall reading a "where is he now?" article on you a couple of years ago, which described a blue-sky project you were working on to seriously compress digital music- to the point where you could stores thousands of hours of music in a couple of gig of hard disk space. At the time I was skeptical (OK, I'm not always the most clued person on the planet), but every Anonymous Coward now knows about MP-3.
What (if any) was your relation to the MP-3 standard and software? Do you have any general comments on MP-3?
But the real problems were with the wetware. The reason this thirty-year-old code is still being used is a "if it ain't broke, don't fix it" mentality. Enough noise needed to be made for the money (and programmer time) to be spent fixing the problem.
Unfortunately, the level of noise needed to make the CEOs and CIOs put the bug on their priority lists were enough to trigger the doomsayers and (even worse) those who figured they could make money on the problem. Technical necessity brought the problem to light, greed blew it out of proportion. Consider for the moment the fact that there is now a stock index for companies based around Y2K.
In a strange sort of way, I do kind of wish some planes fell from the sky, and some people died. Already a Y2K-backlash is begining. Obviously, since the bug was fixed in time, it was all a hoax from the begining. The next time there is a fundamental problem in our technological infrastructure, the response is more likely to be "Y2K was a hoax- this new problem is as well. In addition to not panicing about it, I'm also not going to fix it." Cold as it may sound, some deaths this time around might have saved more lives next time around. Unless, of course, you beleive that there are no more fundamental bugs in our technological infrastructure...
One final comment on Y2K: Don't assume people "suddenly got smart" ten years ago. I've heard a number of people complain about the dumb programmers of yesteryear saving "a measly two bytes". After all, memory is cheap today- obviously, it was cheap back then as well. Go ask someone who was around back then about "a buck a bit"- yes, Virginia, there was a time when memory was $8 a byte, and this was considered _cheap_. Hint: it was about the time a lot of this code was being written. So the "measly two bytes" they saved paid for a decent dinner out.
One would think that, should the IP designer actually get hauled into court they'd be able to at least say "we built the chip and it worked", if not actually be able to prove that the client changed the design.
But there are problems that encryption, or any technology, can solve- if I can get it in plaintext at anypoint, I can break the encryption and change things to my hearts content (or copy things, as the record and movie companies are learning the hardway). Even hardware doesn't help- poke around on http://www.counterpane.com/ for some possibilities for breaking hardware-based encryption. Leaving the debug symbols in the code (or the unprotected keys, as happened with DVD recently) just makes the reverse engineer's job easier.
A suggestion for quake players: have reputation servers. This is not a perfect solution (can the reputation servers be hacked?), but it does give you a _social_ mechanism to discourage cheating. And it's the best you can do.
Gee, we've managed to reinvent code reviews (a weird form, granted, but this is still just code reviews).
"If the feature costs $50,000 to implement today, and $55,000 to implement later when it's needed, implement it later." Well, DUH! It's not the features you expect, it's the features you don't expect which kill you. And this is what seperates a good design from a poor design- a good design can cope with unexpected requirements and features much better.
1) What are the chances that the Supreme Court will decline to hear the appeal? And what justifications are they likely use should they decline the appeal? I remember hearing that the Supreme Court prefers to only hear cases with constitutional implications- could the Supreme Court refuse the appeal based simply on that (and a full schedule)?
2) What implications would this have on the Caldera/DR-DOS lawsuit against Microsoft?
My father grew up on a farm. By age six he was contributing to the economic wealth of his family (doing chores- feeding chickens, etc.). By age 14 he was contributing a signfigiant amount. And this was on an American farm- in the very poor countries children contribute a much greater amount to the economic wealth of the family. It made _economic_ sense for my grand parents to have a lot of kids (which explains why I have eight aunts and uncles). My Dad then went off to college, got a PhD in Math, and started programming computers. His children weren't capable of working in the same office as he until their early twenties, by which time they had moved away and started their own families, or at least stopped contributing to their parent's economic wealth. While he was an economic asset, we were an economic burden- it made sense for him to have fewer children (which explains why I only have 2 siblings). Now, I'm not stating that this is the _only_ factor in deciding how large of a family to have. But statistically, by switching children over from an economic advantage to an economic disadvantage, will drop the average number of children in the family. Indeed, the population census clearly shows a trend of smaller urban (i.e. industrial) families as opposed to rural (i.e. agricultural) families dating back to at least 1840. Religious or social forces do not overcome the fundamental economic forces. Speaking as a catholic, catholicism is pro-large-family religion (everybody: "Every sperm is sacred..."). And yet, Ireland and Italy are also seeing the same population growth slowing that the Protestant countries are (I've lost my bookmark to the CIA's world book). George Bush wasn't kidding when he annouynced a "new world order" (that bit about the taxes was a joke). The late eighties and early nineties saw a fundamental shift in American foriegn policy. Since the 16th century, colonies were the route to economic power (and colonies were the heart of the cause of both World Wars- the colonial haves, England, France, and America (America having claimed the Spanish and Portugese colonies) teaming up against the colonial have-nots, especially they newly-united Germany and newly industrialized Japan). But the economic shocks of the 1980s showed us that our most important trading partners were not our colonies (which had, by that point, expanded from just central/south America to include much of Asia), but rather the other rich industrialized nations- mainly Japan and Europe. In this new economic order, poor colonies are worth squat- illiterate peasants can make much of anything we want to buy, and don't make enough money to buy anything we want to sell. Thus a switch occurred from discouraging colonial independence and economic development to encouraging it (a trend the colonial powers have been bucking, with some success, for over 200 years- we didn't cause it, we just stopped impeding it). With rising economic conditions comes the economic disincentive to large familes, and thereby decreases the population growth (even pushing it negative). Two comments- one, technology is a much bigger influence on military power than numbers. If there is one thing the Gulf War showed, that was it. There is some disagreement by how much Hussein's army outnumbered the allies- I've seen numbers as low as 2x and as high as 5x- but simple numbers didn't help much. The second thing is that modren warfare is incredibly destructive- even conventional warfare. The European theater of WWII was entirely conventional- and it took Europe decades to recover (England still had rationing into the fifties). The "sudden emergence" of Europe and Japan as economic powerhouses in the seventies wasn't- it was a re-emergence after having to rebuild their economies after WWII. Nuclear weapons just make the situation worse. This is one of the main reasons we didn't go to war with the Soviet Union in 1962-63 timeframe- both sides looked at the results of WWII, added a large amount for nuclear weapons, and declared it to expensive. That didn't stop the colonial sniping that went on for another three decades, but it did stop the massive tank thrusts into central germany. Second, by itself, the population implosion doesn't solve the Malthusian dilemna. Yes, you have fewer people being born, put the demand for raw materials and energy per capitia is increasing to make up the difference. There is a solution to this, which I'll post if anyone cares.
First of all, FP doesn't add all that many instructions to an architecture. The alpha has about 6 FP instructions- load fp, store fp, add, subtract, multiply, divide. The PPC (ingoring SIMD) takes this up to about a dozen or so- two of which have as their sole purpose in life making sin() etc. fast to implement (three instructions, vr.s a dozen or so on the Alpha).
Second, there are two _different_ optimization problems chip designers face, generally at different times. The least common optimization is the "clean slate design"- where the chip designers don't have to support anything, and can draw the boundaries wherever they make sense to be drawn. In essence this what what the RISC designers of the eigthies did. The other optimization problem the chip designers are handed an architecture and a set of existing programs and told "make them go faster".
Super-scalar Out of Order execution, branch predicition, more functional units, and speculative code execution are all optimizations you can apply to an existing architecture *without changing the (apparent) semantics of that architecture*- i.e. without breaking legacy code. New instructions allow "new" or recompiled code to gain a performance boost without dropping support for old code (SIMD and DSP-like instructions just happen to be all the rage these days). So of course they're applied to both legacy RISC and legacy CISC applications!
Of course these "patches" are not as effective as fundamentally rearchitecting the CPU. Of course they increase the complexity of the CPU in much greater proportion than they increase performance. This doesn't imply some "ideological impurity", however- this is the fundamental problem of supporting legacy code. This articles thesis boils down to "there are only legacy CPUs out there!". Which, for the moment is true.
But let's consider for a moment what a rearchitected CPU for today would look like. What we'd like to do is to continue the trend RISC started- of shoving the complexity off the CPU and onto the compiler. It would be sort of accurate to claim that RISC's central idea was to shove the complexity of the translation to microcode onto the compiler.
Today's CPU complexity comes primarily from the patches applied to make the legacy code run faster- especially superscalar execution, branch prediction, and speculative execution- all of which require the CPU to deduce information out of sets of instructions. It'd be nice to have the compiler _tell_ the CPU the data ahead of time, so the CPU wouldn't have to spend precious clock time and transistor budget deducing. This, of course, implies a method for explicitly communicating this information in the instruction stream (the only channel of information between the compiler and the CPU)- older instruction sets (of all stripes) forced the CPU to deduce this information because there was no channel in the instruction stream for communicating it.
If this is begining to sound like the Itanium, you're right. Wether this is the right way to go, only time will tell (and, on advice on time's lawyers, time has no statement to make at this point).
Slashdot Mirror
And we're not organized.
The swing voters always hold more power than the multi-issue block voters. There are 40-45% of the people who will vote for canidate A- and nothing canidate B can do or say to change that. Likewise, 40-45% are going to vote for B no matter what A does. The election will be decided by the 10-20% swing voters, whom both A and B are wooing like crazy.
Being a multi-issue voter pretty quickly consigns you to the 80-90% block that gets ignored. You're too hard to woo.
Organization is also important. This is something Geeks are terrible at- we have too much of an anarchist/libertarian streak. Consider: if someone were to organize a "GeekPAC", how successfull would it be? Would you join? Would you contribute money? Would you vote the way the PAC wanted you to vote? Or would you go your own way, and make your own decisions?
If you're a Democrat, what would it take to get you to vote for Bush? If you're a Republican, what would it take to get you to vote for Gore? If you are anarchist/libertarian/socialist/other, what would it take to get you to vote for either?
Although, there is another way to get your beliefs enacted in the political system: control the information to shape the views of the 90%. See Noam Chomsky. The internet/web is not yet a replacement for the classic print/film/radio/TV media, but it's getting there.
You trust all three less once you learn how they're made.
Seriously, my opinion is that there isn't a problem. Frankly, the debates open source has are exceptionally polite and professional. This is how programmers talk to each other- cope with it. They do it in the corporate world as well.
There are three differences. First of all, it's done behind closed doors, so you never hear of the personality conflicts, shouting matches, and even physical assaults, that occur. All you see is the corporate flack painting a Leninist picture of unity of purpose as the entire company strides in lockstep towards a glorious future of increasing shareholder equity. Pay no attention to the men behind the curtain.
Second, in open source, your career isn't threatened by the decisions made. And, by armchair phsycoanalyst extension, neither is your identity. A better example of this than the Bruce Perens/Eric Raymond/Richard Stallman bruhaha is the Gnome/KDE conflict.
In a corporate environment, only one of Gnome or KDE would be developed. The other team would be told "Sorry- you can't work on that anymore, and we're going to throw all of your work into the bit bucket, where it'll never see the light of day again. Better luck next project." Development on Gnome does not preclude development on KDE, or vice versa, giving advocates on both sides room to back off and not take it so personally.
Of course, there is still a lot of strutting and bragging that goes on- "My project is better than yours!" (Especially from those who are at most marginally associated with the projects- AC, this means *YOU*. You rarely see this sort of strutting from the project leads). This is normal, and goes on in the corporate world as well. Heck, it's natural human behavior- listen to new parents talking about their kids.
The third difference are that the debates are public.
Brian
The first question I had was "what isn't user friendly about Linux's interface?" I mean, you have your classic WIMP interface- anyone capable of using Windows will come up to speed on how to use Linux reasonably quickly.
Unless you'd like to claim that Windows isn't ready for the desktop...
And then it occurred to me that I have a slightly different definition of "using" than everyone else. I mean doing things like word processing, or browsing the web, etc. Actually getting work done.
I do not mean installing the OS, or getting drivers to work, or installing software, etc. Those I call "administration". The implicit assumption is that the user is also the administrator- and that the box must not only be easy to use, but also easy to administrate. Professional admins need not apply.
In a home environment, there is some legitimacy to this thought (although I'd debate it- how often to YOU have to go over to various relatives or friends houses to fix their computers?). In the corporate world there is NONE WHATSOEVER.
Consider for a moment how many positions are available for Windows administrators (certified or not). With a network of even as few as 100 desktops, you need a professional, trained admin. Very rapidly you need a team of them.
Or should grandma be able to administrate a network of 2000 desktops, half a dozen file/print servers, and a million dollar database server?
Once you accept that even small corporations have professional admins in residence, then it isn't a problem if Linux _requires_ professional admins. In the market it's likely to penetrate, the admins are already there. The budget is already there. And Linux is ready for at least that desktop (the home market will be a longer time in comming).
Actually, it hasn't changed that much since the 70's. Primarily because there isn't much better that you can do- IIRC, parsing has theoretical computational limits (O(n)), and LALR(1) parsing is pushing those limits hard. It's the same reason sorting and searching are mostly dead subjects- there's not a whole lot better we can do, even theoretically.
Aho, et. al. is the Dragon Book. That's one of the seminal references for compiler design. It doesn't get any better.
The only other book I'd recommend is "Compiler Design in C" by Andrew I. Holub- which is actually more about the syntax analysis than the full compiler construction (it contains a simplified Lex & Yacc set of tools- for the same reason Tannebaum wrote Minix). Unfortunately, it's out of print. And you can't have my copy.
GC for procedural code is optional. A good idea, IMHO- but still optional. If worse comes to worse, you can always "bubble up" responsibility for deallocating the memory to the block in which encompasses the entire lifetime of the memory. For example, if you had:
/* use mem_p */
/* does mem_p need to be allocated? */
/* use mem_p */
/* does mem_p need to be freed? */
...
...
/* we don't need to free mem_p here */
...
void * mem_p;
void foo(void) {
mem_p = malloc(somesize);
}
void bar(void) {
}
void bang(void) {
foo();
bar();
}
We can refactor this to:
void foo (void * mem_p) {
}
void bar (void * mem_p) {
}
void bang (void) {
void * mem_p = malloc(somesize);
foo(mem_p);
bar(mem_p);
}
We can do this because the life time of the body of bang() completely encompasses the life time of mem_p- which neither foo() nor bar() does.
Unfortunately, OO programming makes GC signifigantly less optional. And exceptions make GC no longer an option. Consider the following C++ code:
{
someclass * ptr1 = new someclass();
someclass * ptr2 = new someclass();
}
Can you spot the bug? If the program runs out of memory trying to allocate the second class, new throws an exception. But since the exception isn't immediatly caught, the stack is simply poped, and the memory pointed to by ptr1 is leaked.
The solution, as any C++ programmer will tell you, is to use smart classes and smart pointers, which implement GC. I.e., if the language doesn't have GC, you have to add it.
There are other reasons to use GC- by using GC you can more effectively divorce the implementation of a class from it's interface. In a GC system you don't have to export information about the memory management aspects of the implementation. This is especially important if you have two different classes implementing the same interface, but with different memory management requirements.
Which is faster, GC or manual allocation, often depends upon both the program in question, and the GC algorithm implemented. There is some data indicating that copying garbage collection is the fastest in complex situations- what you lose copying the data you win back in better cache and virtual memory utilization.
Just out of curiosity: how many people looked at the page source of that script before running it? (I did).
"True" Microkernel OSs have a problem that's generally swept under the rug of theory: task switches cost performance. Dozens, if not hundreds, of clock cycles per switch, and that's not counting the costs of TLB and cache thrashing. The only way to offset this is by doing fewer task switches- i.e. by "monolithizing" the kernel into larger and larger chunks. An example of this happening is when NT4 brought the graphics primitives into the kernel for performance reasons. In extremis you get the AmigaOS- which was a "true" microkernel design and got good performance, but at the cost of having no memory protection at all. Task switches became little more expensive than procedure calls.
"True" monolithic kernels also have problems- mainly lack of configurability, the need to recompile the entire kernel to add or remove a driver or reconfigure anything, etc. To overcome these limitations, the kernels need to undergo "microkernalization"- an example of this happening is Linux getting loadable modules.
So the best operating systems- those who strike the best balance between configurability and performance- are the "mixed breed" OSs, either monolithic kernels with microkernel-like features, or microkernels with monolithic-like features. At this point, the difference between "microkernels" and "monolithic kernels" is the difference between Coke and Pepsi.
Brian
First off, there are profound performance differences that can be acheived simply by optimizing for the Pentium Pro and not the Pentium, see The Twofish Implementations. This is mainly just instruction ordering issues- possible to do in a JIT. There's more to optimization anymore than simple cycle counting.
Second, memory management is a different beast under object oriented programming than under procedural programming. The holy grail of object oriented programming (as it were) is black box reuse- allowing a class maintainer to modify how a class works without those using the class needing to change their code. Not having garbage collection in an OO language either disallows true black-box reuse (which is a maintainability issue), forces the object to implement it's _own_ garbage collection (such as the C++ STL template basic_string does- and this is generally the worst sort of garbage collection, such as basic_string's reference counting), or forces the program to leak memory like a seive. If those are the options, then garbage collection is not too high a price to pay.
Especially when you consider that GC isn't that high of a cost. _Every_ memory management scheme that isn't static in nature that I've seen is O(n). Either on the allocation or on the free. Sooner or later you have to search for a hole. GC doesn't remove this penalty, but instead it allows you to _defer_ it until a better time. Since most programs spend most of their time waiting for input, there are lots of places where garbage collection can be free because the program isn't doing anything else.
Last, but not least, I'd like to point you at the The GC FAQ, a good resource for all things GC related. Highly recommended reading- after it, it was "intuitively obvious" that the world was flat, that the sun went around the earth, and that time didn't slow down as you went faster.
The Morris Worm is actually a good example- yes, a Unix virus _can_ be written, but it takes more know-how than a DOS or WordMacro virus takes. Morris himself was the son of the head of computer security for the NSA, he knew pretty much all the holes unix had back then.
:-).
The technical hurdle, as low as it might be, is important. By the time you are sufficiently knowledgable to be dangerous, you're usually intelligent enough to know _why_ this behavior is frowned upon. And have channeled your behaviors into more socially acceptable (and might I add, more rewarding) behaviors. Most decent sysadmins could be hackers and virus writters of legendary proportions. Generally, they aren't.
The open source nature of Linux even helps here- as now there are other ways for a bright teenager to gain fame and technical esteem than writting virii. Instead, they can write kernel patches, or work on Gnome or Abiword, or write their own programs- in other words they can do something _productive_ rather than _destuctive_ programs. I'm kind of interested to see what a couple million chinese programmers can create. I doubt it'll be virii
I find it humorous that in one post Katz rails against individuality and obnoxiousness, and the next against corporatism. One of the biggest things corporatism sells is a warm&fuzzy image- Barney and the Smurfs as corporate spokespeople. The advantage of conformanity and homogenity is that people won't get offended.
Corporatism isn't anything new- does "Whats good for GM is good for the US" sound familiar to anyone? People should read Noam Chomsky more often. Corporatism (as it's known now) took over the national media sometime late in the 19th century (that's the 1800's for those still having problems with their date routines). What is difference is that we're becoming _aware_ of the problem.
On the other hand, Intel is going to try to switch architectures here in a year or three, from the old x86 to the new IA64. This is a vulnerable time for Intel- if you're moving onto a new architecture, why not move onto the best one available? This is the best time in the last couple of decades to launch a new CPU.
I'll agree that the odds are still against them. Too many people buy on the basis of MHz rating and "Intel Inside". But they have a shot...
Do not implicitly assume the problem is only with the testosterone laden male- he's simple the most visible (and least well liked) symbol. _Everything_ offends somebody. If you can't handle being offended, is the problem in the offender? Or is the problem in the offended- who either has been so sheltered that they've never encountered serious offense before, or who are attempting a passive-aggressive strategy for not _allowing_ dissenting viewpoints to be heard.
As a member of the white, male, oppressive class, what the heck do I know about harrassment, including sexual harrasment? Have I ever experienced it? Yeah, I have. I called it high school. Did I let it drive me into a snivelling ball, unable or unwilling to deal with others of my race who offend me? Heck no. I coped. So can you.
And yes, there are discussions I absent myself from. I rarely read slashdot comments with less than a threshold of 4. Not because I simply can't deal with them, but because I have better things to do with my time. Not everyone can participate in all discussions- and that's OK too.
Pardon me for not being PC. Pardon me for not being warm&fuzzy. Pardon me if I've offended you. Pardon me if I don't give a flying fuck if I've offended you. If you can't stand the heat, stay out of the kitchen.
There is another aspect to this people should consider as a possible motive: it's effect on Windows 2000.
/. article linked to a study claiming that some large plurality (60+%) of large IS departments were not planning on switching to W2K until 2001 or later, while an excessively large minority (10+%) were not planning to switch at all. Wether these numbers are accurate or not it has to be plain that customer demand for W2K will be soft- especially compared to the roll-out of Windows 95. By putting The Man himself on the project, they may be hoping for a "Steve Jobs effect" for W2K. Especially for the faithfull who still look upon Bill Gates as a technical visionary.
An earlier
In addition, IIRC the W2K project has already driven two managers into early retirement, and Brad Silverberg (of W95 fame) didn't want to touch it with a 10' cattle prod. One has to wonder if W2K hasn't acquired the stench of being a career killer for those put in charge of it within the halls of Microsoft. Once again, putting The Man in charge could be a (internal) PR boost for W2K.
It's not just pornography. It's a question of accountability. By installing commercial blocking software, the _library_ and the _community_ are no longer deciding what is and is not allowed- the corporation writting the blocking software is.
And it's not just Pornography that's getting blocked. Most site lists tend to have disturbing political bias- blocking sites like the National Organization of Women or gay rights sites. But since such lists are generally not available publically, who knows what is in them.
I'm not an employee of either company. But I was a DR-DOS user when this stuff went down. Some comments, if I may:
1) MS used this very error message as a springboard for a serious FUD campaign. Microsoft convinced people that Windows-on-DRDOS was even more unstable than Windows-on-MSDOS.
2) The peice of code responsible for this was encrypted. Now, pray tell, why go to extreme lengths to hide the code if it was legitimate?
But that wasn't the only leg the lawsuit stood on. There was also the minor issue of per-processor licensing and other predatory pricing schemes designed to keep DR-DOS out of the OEM market.
So drown your sorrows in free coke and stock options. You get _no_ sympathy from me.
The article makes it sound like Caldera/DR-DOS said "Hey, we lost- let's sue!" Some things on Caldera's side:
1) Per-processor licensing. Caldera can prove that Microsoft used pressure that no one else could have brought to bear (i.e. monopoly-based pressure) on to the OEMs to prevent DR-DOS from being preinstalled. Microsoft's relationship with (and coercion of) the OEMs is discussed in depth in Judge Jackson's FOF. Caldera can use all of that and more.
2) The christmas beta. If Microsoft hadn't encrypted that code to make it harder to find and determine how it worked, they might have been able to claim it was just a Beta bug. But the _premeditated_ attempt to hide what they were doing says that they knew they were wrong.
Microsoft's defense is "Yeah, we committed a crime- but it can't be undone and it was aeons ago in computer years, so who cares?" Bleh.
Brian
That guy working 16-hour days and subsisting on pizza and twinkies is not necessarily more productive (especially in the long run) than the guy whose leaving at 5:30. Stressing out your employees to the point where they're leaving the field and not just your company is dumb. "Gee, he's irreplacable- let's work him till he quits."
The assumption you're making is that solutions you buy don't also have a cost in time. This has not been my experience.
Another thing to consider: cost of duplication is small. Once the thing is working, it's fairly easy to run off a couple of million copies of the software. If you're expecting to sell a couple of million boxes, even a $10/box license suddenly pays for a lot of up-front engineering.
I recall reading a "where is he now?" article on you a couple of years ago, which described a blue-sky project you were working on to seriously compress digital music- to the point where you could stores thousands of hours of music in a couple of gig of hard disk space. At the time I was skeptical (OK, I'm not always the most clued person on the planet), but every Anonymous Coward now knows about MP-3.
What (if any) was your relation to the MP-3 standard and software? Do you have any general comments on MP-3?
But the real problems were with the wetware. The reason this thirty-year-old code is still being used is a "if it ain't broke, don't fix it" mentality. Enough noise needed to be made for the money (and programmer time) to be spent fixing the problem.
Unfortunately, the level of noise needed to make the CEOs and CIOs put the bug on their priority lists were enough to trigger the doomsayers and (even worse) those who figured they could make money on the problem. Technical necessity brought the problem to light, greed blew it out of proportion. Consider for the moment the fact that there is now a stock index for companies based around Y2K.
In a strange sort of way, I do kind of wish some planes fell from the sky, and some people died. Already a Y2K-backlash is begining. Obviously, since the bug was fixed in time, it was all a hoax from the begining. The next time there is a fundamental problem in our technological infrastructure, the response is more likely to be "Y2K was a hoax- this new problem is as well. In addition to not panicing about it, I'm also not going to fix it." Cold as it may sound, some deaths this time around might have saved more lives next time around. Unless, of course, you beleive that there are no more fundamental bugs in our technological infrastructure...
One final comment on Y2K: Don't assume people "suddenly got smart" ten years ago. I've heard a number of people complain about the dumb programmers of yesteryear saving "a measly two bytes". After all, memory is cheap today- obviously, it was cheap back then as well. Go ask someone who was around back then about "a buck a bit"- yes, Virginia, there was a time when memory was $8 a byte, and this was considered _cheap_. Hint: it was about the time a lot of this code was being written. So the "measly two bytes" they saved paid for a decent dinner out.
One would think that, should the IP designer actually get hauled into court they'd be able to at least say "we built the chip and it worked", if not actually be able to prove that the client changed the design.
But there are problems that encryption, or any technology, can solve- if I can get it in plaintext at anypoint, I can break the encryption and change things to my hearts content (or copy things, as the record and movie companies are learning the hardway). Even hardware doesn't help- poke around on http://www.counterpane.com/ for some possibilities for breaking hardware-based encryption. Leaving the debug symbols in the code (or the unprotected keys, as happened with DVD recently) just makes the reverse engineer's job easier.
A suggestion for quake players: have reputation servers. This is not a perfect solution (can the reputation servers be hacked?), but it does give you a _social_ mechanism to discourage cheating. And it's the best you can do.
Gee, we've managed to reinvent code reviews (a weird form, granted, but this is still just code reviews).
"If the feature costs $50,000 to implement today, and $55,000 to implement later when it's needed, implement it later." Well, DUH! It's not the features you expect, it's the features you don't expect which kill you. And this is what seperates a good design from a poor design- a good design can cope with unexpected requirements and features much better.
Brian
1) What are the chances that the Supreme Court will decline to hear the appeal? And what justifications are they likely use should they decline the appeal? I remember hearing that the Supreme Court prefers to only hear cases with constitutional implications- could the Supreme Court refuse the appeal based simply on that (and a full schedule)?
2) What implications would this have on the Caldera/DR-DOS lawsuit against Microsoft?
My father grew up on a farm. By age six he was contributing to the economic wealth of his family (doing chores- feeding chickens, etc.). By age 14 he was contributing a signfigiant amount. And this was on an American farm- in the very poor countries children contribute a much greater amount to the economic wealth of the family. It made _economic_ sense for my grand parents to have a lot of kids (which explains why I have eight aunts and uncles). My Dad then went off to college, got a PhD in Math, and started programming computers. His children weren't capable of working in the same office as he until their early twenties, by which time they had moved away and started their own families, or at least stopped contributing to their parent's economic wealth. While he was an economic asset, we were an economic burden- it made sense for him to have fewer children (which explains why I only have 2 siblings). Now, I'm not stating that this is the _only_ factor in deciding how large of a family to have. But statistically, by switching children over from an economic advantage to an economic disadvantage, will drop the average number of children in the family. Indeed, the population census clearly shows a trend of smaller urban (i.e. industrial) families as opposed to rural (i.e. agricultural) families dating back to at least 1840. Religious or social forces do not overcome the fundamental economic forces. Speaking as a catholic, catholicism is pro-large-family religion (everybody: "Every sperm is sacred..."). And yet, Ireland and Italy are also seeing the same population growth slowing that the Protestant countries are (I've lost my bookmark to the CIA's world book). George Bush wasn't kidding when he annouynced a "new world order" (that bit about the taxes was a joke). The late eighties and early nineties saw a fundamental shift in American foriegn policy. Since the 16th century, colonies were the route to economic power (and colonies were the heart of the cause of both World Wars- the colonial haves, England, France, and America (America having claimed the Spanish and Portugese colonies) teaming up against the colonial have-nots, especially they newly-united Germany and newly industrialized Japan). But the economic shocks of the 1980s showed us that our most important trading partners were not our colonies (which had, by that point, expanded from just central/south America to include much of Asia), but rather the other rich industrialized nations- mainly Japan and Europe. In this new economic order, poor colonies are worth squat- illiterate peasants can make much of anything we want to buy, and don't make enough money to buy anything we want to sell. Thus a switch occurred from discouraging colonial independence and economic development to encouraging it (a trend the colonial powers have been bucking, with some success, for over 200 years- we didn't cause it, we just stopped impeding it). With rising economic conditions comes the economic disincentive to large familes, and thereby decreases the population growth (even pushing it negative). Two comments- one, technology is a much bigger influence on military power than numbers. If there is one thing the Gulf War showed, that was it. There is some disagreement by how much Hussein's army outnumbered the allies- I've seen numbers as low as 2x and as high as 5x- but simple numbers didn't help much. The second thing is that modren warfare is incredibly destructive- even conventional warfare. The European theater of WWII was entirely conventional- and it took Europe decades to recover (England still had rationing into the fifties). The "sudden emergence" of Europe and Japan as economic powerhouses in the seventies wasn't- it was a re-emergence after having to rebuild their economies after WWII. Nuclear weapons just make the situation worse. This is one of the main reasons we didn't go to war with the Soviet Union in 1962-63 timeframe- both sides looked at the results of WWII, added a large amount for nuclear weapons, and declared it to expensive. That didn't stop the colonial sniping that went on for another three decades, but it did stop the massive tank thrusts into central germany. Second, by itself, the population implosion doesn't solve the Malthusian dilemna. Yes, you have fewer people being born, put the demand for raw materials and energy per capitia is increasing to make up the difference. There is a solution to this, which I'll post if anyone cares.
First of all, FP doesn't add all that many instructions to an architecture. The alpha has about 6 FP instructions- load fp, store fp, add, subtract, multiply, divide. The PPC (ingoring SIMD) takes this up to about a dozen or so- two of which have as their sole purpose in life making sin() etc. fast to implement (three instructions, vr.s a dozen or so on the Alpha).
Second, there are two _different_ optimization problems chip designers face, generally at different times. The least common optimization is the "clean slate design"- where the chip designers don't have to support anything, and can draw the boundaries wherever they make sense to be drawn. In essence this what what the RISC designers of the eigthies did. The other optimization problem the chip designers are handed an architecture and a set of existing programs and told "make them go faster".
Super-scalar Out of Order execution, branch predicition, more functional units, and speculative code execution are all optimizations you can apply to an existing architecture *without changing the (apparent) semantics of that architecture*- i.e. without breaking legacy code. New instructions allow "new" or recompiled code to gain a performance boost without dropping support for old code (SIMD and DSP-like instructions just happen to be all the rage these days). So of course they're applied to both legacy RISC and legacy CISC applications!
Of course these "patches" are not as effective as fundamentally rearchitecting the CPU. Of course they increase the complexity of the CPU in much greater proportion than they increase performance. This doesn't imply some "ideological impurity", however- this is the fundamental problem of supporting legacy code. This articles thesis boils down to "there are only legacy CPUs out there!". Which, for the moment is true.
But let's consider for a moment what a rearchitected CPU for today would look like. What we'd like to do is to continue the trend RISC started- of shoving the complexity off the CPU and onto the compiler. It would be sort of accurate to claim that RISC's central idea was to shove the complexity of the translation to microcode onto the compiler.
Today's CPU complexity comes primarily from the patches applied to make the legacy code run faster- especially superscalar execution, branch prediction, and speculative execution- all of which require the CPU to deduce information out of sets of instructions. It'd be nice to have the compiler _tell_ the CPU the data ahead of time, so the CPU wouldn't have to spend precious clock time and transistor budget deducing. This, of course, implies a method for explicitly communicating this information in the instruction stream (the only channel of information between the compiler and the CPU)- older instruction sets (of all stripes) forced the CPU to deduce this information because there was no channel in the instruction stream for communicating it.
If this is begining to sound like the Itanium, you're right. Wether this is the right way to go, only time will tell (and, on advice on time's lawyers, time has no statement to make at this point).