ANOTHER serial graphics bus? Is not the upgrade path to IEEE 1394B (800 Mbps Fire Wire) and beyond sufficent?
According to the article, AGP8X will use a 32-bit bus at 533MHz. That's 17Gb/s. So the answer to your question is an emphatic NO, the "upgrade" path to IEEE-1394b is absolutely not sufficient. The two technologies are so far apart, intended for such entirely different purposes, that it's ridiculous even to think about either ever replacing the other.
I don't know about MIPS Unix, but the IBM RT (AIX) used a MIPS cpu
Are you sure about that? Maybe it was a later flavor of RT? The original RT used one of the very earliest RISC processors, called ROMP, and IIRC may even have come out before MIPS existed. I used one briefly, and MIPS it most certainly was not.
The VMS guy was/is Dave Cutler. There is no official connection between VMS and NT, but there are definite "stylistic" similarities...which is only to be expected when the same people work on two projects in succession. Conspiracy theorists also like to tout the idea that NT on Alpha was a concession made to keep DEC from suing their asses.
Rick Rashid of Mach notiriety is also at MS now, but I don't know his role. This is the guy who made his reputation talking about microkernels even though Mach had all of a microkernel's weaknesses and none of its strengths during his tenure, and didn't become a true microkernel until after he left. If anyone could fit an at the world's foremost purveyor of vaporware it's him.
I guess the reason everyone is so excited about USB getting faster is that its kinda like open source software in the light that anyone can use it and develop for it without having to pay any royalties to anyone.
Oh, bullshit. Intel makes more on USB than Apple makes on Firewire. They just bury the cost in chipsets and motherboards so the newbies don't notice.
64-bit 66 Mhz PCI can go 528 megabytes per second.
Looked at another way, PCI does whatever the chipset lets it do. About 3 years ago, the very best Intel chipset could push less than 600Mb/s through a 32-bit 33MHz PCI bus - about 60% of nominal bandwidth. PCI chipsets have gotten a lot better, but the bus itself is still not the bottleneck. I wonder how much of that 528MB/s you mention is actually realizable.
That's pretty simple. Not too many computers are shipped with firewire pre-installed.
And why is that, do you think? Could it be because our "good friends" at Intel, who make the most common chipsets, are more interested in pushing their own separate standard than in adding 1394 support? You better believe that having USB displace 1394 is worth more than $1/port (the original 1394 license fee, now a quarter of that) to Intel.
Who wants to put more money in Intel's pockets? IMO AMD and VIA missed a huge opportunity by not putting 1394 support into their chipsets just to stick it to Intel and their "standards".
Let me guess - you write hardware drivers for a living;)
Why, yes I do, if by "hardware driver" you mean "anything that runs in kernel space". Specifically, I write filesystems nowadays, though I've also written network and physical-device drivers. In the past I've worked on the kernel itself, on middleware, and - a long time ago - on applications. I even wrote a tiny bit of embedded code once. Of all of these types of programming, writing drivers seems to leave one at the mercy of others' design or interface decisions the most. The tools also tend to be the worst. It can be very difficult and frustrating.
So why do I, and others, put up with it? Why don't we do something else? Well, I admit that there's a certain satisfaction in seeking out and overcoming the greatest challenges available, proving oneself, etc. It's a motivation similar to the one that drives some percentage of soldiers to become SEALs or Rangers or Airborne. Mostly, though, I think people do this stuff because they realize it's necessary or it's The Right Way to do something they consider interesting - in my case, distributed and cluster filesystems.
Nobody likes to hear bitching from people who don't understand what they do. What programmer, of any stripe, would not resent a PHB badgering them about adding some stupid feature that conflicts with a product's original design? Well, to a kernel guy (and it is unfortunately the most male-dominated programming specialty) an app programmer is almost indistinguishable from a non-programmer. Practically every kernel programmer started out doing apps at some point, and understands what's involved, but 99% of app writers have absolutely no idea what's involved in writing kernels or drivers. Therefore, any app writer who resents having non-programmers critique their own work should likewise refrain from critiquing kernel folks' work.
Unfortunately, I have yet to see an organization that hasn't been afflicted by the office royalty syndrome...
The latest status symbol is big flat-panel displays. With one VP at my company I noticed that not only he had one, but everyone located near him - receptionist, admins, etc. - had one, while engineers in the same section had half their desks taken up with CRTs. What BS.
There are two main reasons SMP isn't more pervasive:
Many systems are I/O bound anyway, and wouldn't benefit from more processors.
Synchronization overhead often overwhelms the parallelism benefit.
The first of these is pretty self-explanatory. I'll try to expand a little on the second.
Multiprocessor (MP)hardware is a lot more complex than uniprocessor (UP) hardware, with extra latency in the memory subsystem to deal with potential cache issues - even if no sharing is occurring at that particular moment. Code running on multiple processors needs to do locking, and the locking itself can be pretty costly (especially since it uses bus-saturating interlocked memory instructions). This is why running an MP kernel on a single processor is even slower than a UP kernel. Lastly, not all code parallelizes well; much of it contains major sequential dependencies. In the end, all of the extra work that's done to make MP behave correctly may end up costing more than it's worth even for small numbers of processes.
As the number of processors increases, all of these effects increase exponentially. The memory system starts to get pretty hideously expensive, cache warming and memory locality issues become more complex as efforts are made to reduce the strain on the memory system, and all the while it becomes harder and harder to keep all of the CPUs busy enough to make the whole thing worthwhile...and this is even for a mere couple of dozen processors.
When you're looking at something like Blue Gene, look not at the amount of CPU power involved but at the incredible memory/communications bandwidth - multiple communicating processors on a single chip, multiple chips on a board, boards arranged into modules, etc. The key to Blue Gene is that they have this phenomenal bandwidth coupled with a specialized application which is almost uniquely able to take advantage of how the memory/communications system is structured.
SMP causes a lot of badly-written drivers to fail, although they might work reasonably well under a single CPU.
I wouldn't be so quick to blame everything on "badly written" drivers if I were you. Applications are fairly simple, locking-wise. They have one entry point and full control over when new threads enter or exit. Apps that benefit at all from SMP usually do so trivially; anything that's a pain in the ass to handle in parallel just gets a huge mutex slapped around it, and apps rarely need to hold two locks at once. For drivers, it's very different. Drivers have multiple entry points, any of which can generally be invoked at any time even when something else is already going on. Single-threading requests is generally not an option for performance reasons. Drivers tend to develop deeper locking hierarchies and more complex locking behaviors than almost any app, so it's no surprise that locking errors - race conditions, deadlocks, etc. - are so common. Yes, a driver that has such errors in it is still broken, but it may still be "better written" than the trivial SMP code app writers can get away with.
It may not be the driver's fault, anyway. The OS itself may have SMP problems that get triggered by specific perfectly-legal driver behavior. For example:
OS takes lock X.
OS calls driver.
Driver calls OS function.
OS tries to take lock X again and self-deadlocks.
I've seen this kind of crap happen on a dozen OSes, in cases where the driver had every right to call that OS function under those conditions but the OS screwed up. I've seen cases where the OS-provided synchronization facilities had subtle bugs (usually SMP-specific bugs) that caused starvation or missed wakeups under some conditions. Drivers are hard to write under the best of conditions, and when they have to be written while avoiding all of the OS bugs it's sometimes amazing that they ever work at all.
While it's probably true that Linux 2.4 is significantly better than NT at several tasks, there are definitely situations where NT beats Linux 2.2.
The above seems to imply an expectation that 2.4 will be faster than 2.2. That's unlikely. The VFS layer has been essentially rewritten for 2.4, and a lot of filesystem code has had to change with it. This is some of the most performance-critical code in the kernel. The really sad part is that, to date, no serious performance measurement activity has been undertaken by the VFS developers, so we don't really know the performance implications yet. Anecdotal evidence from linux-fsdevel (e.g. this message) suggests that reads may be 10-20% slower in 2.4 than in 2.2, while multi-stream writes may be "much faster". I have tried to get more information from the people making such claims - such as descriptions of configurations, tests used, a more concrete definition of "much faster", etc. - but have so far received no reply. I think they're embarrassed, and from what I've seen (see my essay on 2.4 Linux VFS for more) they should be.
IIRC, the i860 and i960 have done ok. Since they were RISC chips from Intel that weren't x86 compatible no one as far as I know used them as a main CPU.
Not quite. Stardent, Oki, and Stratus all had equipment using the i860 as a CPU. They were actually pretty good, except for one thing that eventually killed them: they had a really weird (two-issue, IIRC) instruction pipeline that was hard to code for, and compilers generally weren't up to the task. If you could write code for them they performed rather well, but most people couldn't and hence got only mediocre performance out of them.
As for the i960, it was actually pretty nice - much more elegant architecturally than any other Intel offering IMO. The i960CA was actually developed specifically for BiiN to use in large-scale multiprocessing, but of course that died and everyone forgot about it. C'est la vie... et c'est la mort.;-)
Using the i860 as a CPU always seemed a little odd to me, but the i960 - especially the C or J series - might have made a very good main processor.
I even went to your little web site. It was... well, I can't say anything nice, so I won't say anything at all
So where's yours? I'd love to see it. Please don't disappoint your adoring audience by saying you don't have one, and don't try to take credit for a site you had nothing to do with either.
I don't pretend to be great at web fluff; there are other things I'm much more interested in being good at. Writing (I won't even dignify it by calling "hacking") HTML is about as far from my specialty or interests as can be, so I usually leave it to people who can't cut it in the kernel world. You guys need something to do, after all. The site only exists because some people had specifically asked for some of the scripts and I figured that if those people found the scripts useful then other people might too. Then I added a couple of other things just because I was bored. I think I was waiting for a build of something or other, or perhaps a big download. Total investment? $0 and a couple of hours.
So it's not a work of art. I admit that, but you know what? It's still better than about half the garbage other people put on their personal web pages. Nobody needs another picture of the dog, or another ego-counter or animated GIF or fancy background/border/divider. In fact, if I may rant a little, I happen to know from a previous life (my mother's) in typesetting and graphic design that an overabundance of visual cues actually detracts not only from a page's aesthetic value but also from its utility as a way for readers to view information. Intelligent use of minimal formatting to represent semantically meaningful things like quotation, emphasis, or conceptual structure (e.g. lists) is a skill that's seriously underrated but much more valuable than diddling around with eye candy.
Now that you've read that, go clean up your page to get rid of the <blink> tags, and then tell us where it is. I'm looking forward to it.
None of these products were done in an environment where publishing web sites is considered a major part of the work.
Hmmn... That's a bit dodgy. You see, when companies make products -- products they intend to sell -- they advertise those products, usually making altogether too much noise.
You really do have a lot to learn about industry, don't you? I already mentioned that several of those products existed before there was a web and yet you seem to expect a web presence anyway. Ridiculous. If you'd made even the slightest effort to check, you would have seen that most of the products I named that were developed in the "web era" do in fact have web pages. HACMP/6000 was even used as one of Greg Pfister's case studies in In Search of Clusters. What more could you want as evidence of the projects' reality?
Usually programmers are not asked to create the web site, but they do provide white papers and the like.
Here's another lesson about the real world. Some companies generate lots of white papers. Some companies generate lots of product. Very rarely do the two intersect. The product I'm working on right now was discussed at Usenix, which is much more "open" than any white paper.
So far, you've said, "Torvalds doesn't like debuggers even though other people do. He should set a better example."
Yes, I made those two statements...separately. Their juxtaposition, eliding a great deal of explanation of the connection between the two and thus taking them out of context, is yours. Again we have no evidence of anything about you but your dishonesty.
I'll let you in on a little secret: my remark about "street-cred" was meant to draw you into a techinical discussion of the issues you raised
Bull. Nobody who reads this exchange would believe that. You obviously meant to start a pissing contest, and you lost badly. Now that you're all wet, yellow and smelly from pissing on yourself, you're trying to change your tune. You're so transparent it's amusing.
All you've done since then is brag about your experience, and unconvincingly at that.
You who were the one who insisted on talking about background, not me. If I had not answered your questions about my background I'm sure you would have accused me of hiding from it, and now that I have answered you accuse me of bragging. Next time you try to set up a double bind like that, try to be a little bit less obvious about it. It might even work on someone besides your classmates.
I have contributed to the development of shipping products, both open and closed source. I don't care to name names,
Translation: your claim is pure, unadulterated, total bullshit. Guess what? Absolutely everyone on slashdot would be able to make that translation. You haven't worked on squat or you'd be shouting it from the rooftops, telling everyone how you'd made the greatest contribution to computing since von Neumann. You do know von Neumann, right?
most "commercial"...products fail to meet the quality goals of commercial products. The projects you mentioned are probably excellent examples.
Said without the slightest shred of knowledge. You couldn't even find information about them, despite the fact that such information is readily available, and yet you feel comfortable judging their quality.
Now, are you ready to stop flaming and start thinking?...I'll be here.
...because you have nothing better to do with your time than troll on slashdot. Well, I do. I've wasted enough time with you already. I've given two examples of Linus's weird attitudes that explain why I say what I do about him. I've described my background in great detail when asked (and not before). In general I've backed up everything that I say. You haven't provided anything worth reading - no information about Torvalds, no information except for an outright lie about your own (lack of) background. The closest you've come to discussing anything honestly is a red herring about whether debuggers are in fact a good thing to have. You say they cause too much perturbation to the system, but I've implemented the kernel stubs for a couple and I've used them to debug thousands upon thousands of lines of kernel code so I know that claim is utterly false. You're just trying to get a rise out of someone any way you can, and by now it's abundantly obvious to me - and, I'm sure, to anyone else dumb enough to read this - that you don't even have Clue One about programming.
Go fish somewhere else. There's no longer any need for me to respond, because you've already made my point for me and there's no way I can reveal your total loserhood any more than you've done yourself. My work here is done and, unlike you, I have other work to attend to. Have fun with your insult-laden content-free reply. I'll enjoy watching that hole you've dug for yourself get even bigger with every word you write, without any help from me.
Nope. No mention of why my comment about debuggers and kernel development is wrong and no example of arrogance on the part of anyone but yourself.
Try looking beyond my replies to you specifically. I replied to several other people, and everything you claim is missing is in those replies to others. In my replies directly to you I had even alluded to the fact that your concerns were addressed elsewhere, and provided a pointer.
perhaps a link to a few of these project web sites
None of these products were done in an environment where publishing web sites is considered a major part of the work. Several were done before the web. For your benefit, though:
UMAX was Encore's version of UNIX. TOPIX was Sequoia's. Both were among the very earliest SMP UNIXes, but the companies were somewhat before there time and were moribund before SMP became a viable financial proposition. As far as I know both companies still exist, but if not a quick check of old news archives should be sufficient to verify that these products were real and were used by quite a lot of people.
HACMP/6000 is sold to this day by IBM; check their web-site. REACT was also an IBM product associated with the 7135 disk array, and AFAIK is still on the market but quite likely under a different name.
ATF was a product of CLARiiON, now a division of EMC where I currently work (but in a different division).
Medley was a distributed filesystem from Mango (www.mango.com). They seem to have abandoned that market, but information on the product should still be easy enough to find. It was getting pretty good reviews a couple of years ago.
MPFS is an upcoming EMC product that was discussed at the most recent USENIX. Check the conference papers.
Happy now? Those products are all quite real, as you would already have known if you'd bothered to look.
Without getting into a pissing contest about coding experience
That's pretty funny, considering that you were the one who brought "street cred" into it. All of a sudden, when you're the one who has to back up what you say, it's not so important, eh? Hypocrite.
I will say that I have done systems programming in C and a few flavors of assmebly, and application programming in C++ and Java
OK, so what shipping products have you been involved in? I'll settle for completed open-source projects, even though those all too often fail to meet the same quality goals as commercial products. Or is all of your vaunted experience in class projects? Are you the same jtgold who's a student at MIT?
BTW, application programming barely counts for anything in my book, and certainly in the context of this discussion. If you haven't been involved in a kernel-level project that ended up in the hands of - what was the phrase? oh yeah - "several thousand users", IMO you should shut the hell up and try to learn from the people who actually have lived through that experience.
You might be able to save some face by offering an appology before you make a fool of yourself again with another rabid missive.
It's a shame that forums like slashdot encourage people who've learned to flame before they learn to code - or, too often - learn to think. Come back when you've done something to give you "street cred".;-)
What sanctimoneous tripe! First of all, the burden is on you to demonstrate that statement. The only example you've offered so far, debuggers, is clearly debatable on the grounds I mentioned -- and I notice you didn't bother to address.
You're a lying little turd. How can you say "I notice..." when you obviously didn't bother to check? In point of fact I did address your earlier objection, and also provided a second more detailed example of Torvalds's arrogance. You, by contrast, have added nothing to this conversation. Linus doesn't need cretins like you defending him.
I'm not going to `assume without basis' that you know the first thing about what you are talking about
You won't assume that I do...but you'll gladly assume that I don't. Why is one assumption preferable to the other? What distinguishes them at all...except that one represents a view you came into this conversation already favoring?
until you show me some code that you designed that has thousands of satisfied users
UMAX 4.3, UMAX V, TOPIX, HACMP/6000, REACT, ATF, Medley, MPFS. No, I didn't design or code all of those things myself, except for REACT and ATF, but those two alone account for "thousands of satisfied users". Thousands more have benefited by my work on the others. None are on Linux, of course, and I doubt you've heard of any of them in your tiny little corner of a vast computing world, but that's plenty of "street cred" (what a stupid term!) for most folks. What do you have to offer, little boy? A little bit of Javascript, perhaps? Why should anyone take your word for anything? You haven't established your own credentials, you haven't introduced any new facts or quotes or insight. All you've done is prove my point about too many Linux zealots being asinine little punks with a hundred times more attitude than ability. Go read the advocacy how-to before you presume to defend anyone from the evil outsiders.
You should try reading kernel-traffic (http://kt.linuxcare.com) sometime.
It saddens me to see how quick people are to assume without basis that which it is convenient for them to assume - e.g. that I do not read k-t, that I am not a kernel programmer, etc. I have already addressed this particular canard in #605.
Torvalds is extremely sharp, and some of his ideas about software development are quite good.
You are absolutely correct. Linus is indeed extremely sharp, and his views are often as correct as they are idiosyncratic. However, some of his other ideas are stupid, and by refusing even to acknowledge other views he sets a bad example for people who look up to him. Whether he likes it or not, he is in a position to influence the quality of work produced by a whole generation of programmers. I believe he should take that responsibility more seriously, and make more of a conscious effort to set a good example.
I would take issue with your use of the phrase "lack of discipline". It's not clear whether by "discipline" you mean "being totally focussed on a project" or whetehr you mean "following all orders from superiors, and disregarding consequences of said orders".
As convenient as it may be for you to assume the latter, the answer is "neither". When I refer to discipline, I refer to a capacity for doing things one does not enjoy or even finds unpleasant because they are the "right" things to do. In this context I'm talking about writing clear, modular, extensible and maintainable code, testing that code, and documenting what you did for anyone who may have to work on it later. I'm talking about fixing bugs that you happened to find in other people's code (or at least reporting them to the people who can fix them), and fighting the urge to solve your own problems by rewriting other people's code that is already working just fine. I'm talking about trying to implement things cleanly even if it takes more time than hacking it up. Everyone knows these are Good Things, even the people who don't do them. The discipline to which I refer is no more than not making excuses.
As someone who has spent over a decade in various OS groups, and who now develops filesystems for a living, I am quite well aware of this.
Read the linux-kernel notes at linuxcare.com.
I do, regularly.
His eccentricities are well-considered
Wrong. I've already mentioned his absurd attitude toward debuggers. To take a more recent example, consider his recent comments about real-time. Real-time is not about performance, it's about predictability. "Ten times as fast as necessary, 99% of the time" is great for general-purpose computing, and even for a lot of stuff - e.g. financial or point-of-sale systems - that people persistently mislabel as real-time, but for true real-time - e.g. flight or nuclear power plant control - it just doesn't cut it. Linus obviously doesn't know this, which is OK; it takes most people a while to grok it. What's galling is that Linus is too damn arrogant to listen to the people who do know what real-time is about.
If Linus had just said "real-time is not a goal for Linux, use another platform" that would be fine. Couldn't argue with that. However, he chose instead to treat the real-time folks' concerns as invalid, based on his own misunderstanding of what they're about. That's exactly the kind of parochial attitude I'm talking about. Engineering is about making solutions fit problems, not trying to make problems fit the solution you've developed.
when programming a kernel, you don't use 'best practices'
Maybe you don't, maybe the Linux community in general doesn't, but I do and I expect the people I hire to do so as well. Sure, the tools we kernel hackers have to work with - debuggers, profilers, etc. - are often inferior to those available in user-land, but it is still our responsibility to do the best we can. There is still no excuse for writing code that's hackier than necessary to work around OS insanity (oh, the war stories I could tell!) or for not using the tools that are available.
The debugger is the first refuge of the incompetent (with apologies to Sam Johnson).
Some people do indeed use debuggers as a crutch. I work with a guy whose whole programming methodology seems to be centered on sitting in the debugger, and who is totally incapable of fixing a bug that occurs anywhere but in his own highly tweaked debugging environment - such as from the field. It's a major Bad Idea to rely on debuggers this much.
However, just because something's used as a crutch by some people doesn't mean we should do away with it. Even crutches have legitimate uses.;-) Debuggers are very useful things to have around, and it's ridiculous to look down one's nose at people who use them responsibly, as Linus has on more than one occasion.
Firstbrook's objection is mostly crap, but not entirely. One of the problems with the Linux community is that it does tend to undervalue aspects of software engineering besides straight-out coding. People who concentrate on writing good code rather than more code, or who test the hell out of their code, or who do a good job of documenting what they've done, get a lot less recognition than the people who crank and crank and crank, even if what the people in the latter group crank is mostly garbage. This "bad culture" is directly related to the bad example set by Linus himself, who has some attitudes that most serious software engineers would regard as eccentric at best (e.g. his well-publicized disdain for debuggers). The net result is a huge number of people who think they're hot stuff because they've learned a few nifty tricks, but who lack any deep background or self-discipline because they've never been rewarded for those things.
Which brings us back to Firstbrook. Many people have suggested that the problem is not with Linux but with the lack of things like change logs, but my point is that they're not unrelated. People who have become steeped in Linux knowledge have also been steeped in Linux tradition, and that's a tradition that devalues some of the things that matter in a mission-critical environment. That puts employers and customers in a bad spot if they rely on Linux systems, with the most technically savvy people often being professionally "immature" and often too arrogant to admit that the customer's modus operandi may be valid even if it's not "the Linux way". Employers and customers get tired of that BS real fast, and may well find themselves longing for the days when the people who knew the most about their OS weren't obnoxious little punks.
What has made Linux a very good OS is the amount of youthful enthusiasm that has gone into its development, but in a way that's also what prevents Linux from being a great OS. The Linux community is inseparable from Linux itself, and the skewed reward system in the Linux community has revealed the dark side of youthful enthusiasm - hubris, lack of discipline, and a large dose of "Not Invented Here" syndrome.
Saying that CORBA's interface versioning solves this problem is like saying that a hammer solves the problem of nails. It's a tool, valuable to the extent that people know how to use it properly by making sure that the interface definition accurately and completely describes the behavior of a component and that the "actual interface" doesn't change without corresponding change to the "official interface" - something that doesn't just happen on its own. Arguably, what you really need to solve this problem (and, even more arguably, what some languages or programming models give you) is a way to ensure that all behavioral dependencies are captured in the interface definition and that nobody can even begin to depend on something that could change.
it's easier to explain sex to a virgin than to explain the law to a non-attorney
Unfortunately true, but not of necessity. I understand the need for legal language to be precise etc. but there's no reason for it to be so fuqn obtuse, verbose and counterintuitive. Read Legal Language for an eye-opening account of how it got that way, or Guilty: The Collapse of the American Justice System for some insights from a judge on where it has left us.
If lawyers are going to persist in using unnecessarily opaque language, then IMO they shouldn't bitch about having to explain their usage to non-lawyers.
As for your interpretation of contract law as it applies to NDAs, your expressed opinions coincide with the briefings I've received on the matter. But of course IANAL.;-)
Re:Katz writes about things without having 2 clues
on
Selfish Society
·
· Score: 1
Read Salamander's post closely..."Vote for me and I will use the force of the government to take money from those nasty selfish [fill in the blank] to give to you."
What is this? A competition to outdo each other for sheer stupidity? I said absolutely nothing of the sort. Just because I don't think programmers have a god-given right to a lifestyle ten times better than other people who work just as hard does not by any stretch of the imagination mean that I believe in any socialist "levelling" BS. OK, not by any reasonable stretch of the imagination.;-) Cretins like you often have a talent for imagining things well beyond the ken of saner folk. It's amazing that you can even manage to type, with that few brain cells.
I am keenly aware of how fortunate I am to be in a field where the reward:work ratio is so high, but that doesn't mean I have any intention whatsoever of giving away the rewards I have in fact earned.
Re:Katz writes about things without having 2 clues
on
Selfish Society
·
· Score: 2
Overwhelmingly white??? Has this guy ever been in a computer science program
Yes.
or seen programmers?
Yes. I've been programming professionally for over a decade now, which I'd guess is a decade longer than someone posting from Central Michigan U.:-P
In my group there are nine full-time people, all white, plus one co-op who is Asian. In the associated QA group there are two white, one Asian and one Indian. Of the whole set, there is only one woman, plus our doc writer is a woman. Sadly, this is all pretty much par for the course in real-life software engineering. The whole industry tends to be white and male, even more so in development than in other areas (such as QA, IS, doc or management), and most of all in kernel development. I've worked with hundreds of developers, one of them black and none of them Hispanic. It's sad. But don't take my word for it. Don't accept any "anecdotal evidence" (an oxymoron, BTW) including your own. There are scientific surveys out there showing the same patterns.
Sure, there are exceptions. One group I work with is full of people from India and Pakistan. Another is full of Chinese. These cliques - for want of a better term - are a well-known phenomenon in hiring; people hire others who are like themselves, minorities perhaps even more so than plain-vanilla whites because they (the minorities) feel embattled. And well they should, because by far the largest clique is the white guys. These little spots of diversity are still just spots, against a vast white background.
Drinking and screwing? I don't know what to say. I wish?
OK, perhaps that's not quite accurate. Often the drinking is quite real, but the screwing is more a matter of imagination and reality. Combine that with a smattering of drugs and an obsession about music and you have your average college student. Replace some of the above with random abuse of the college's computer systems to play games, to download mp3s or porn or open-source software (all equally unrelated to coursework), or to further personal profit-making enterprises, and you have the average geek in college. What's noticeably lacking in any of this is adequate focus on actual coursework. For most people, college is no more than a very nice break before you start having to work for a living. Ask anyone who works in the real world, even in a cushy job like programming, whether they envy the "working conditions" in college. The workload and deadlines in college may seem pretty demanding to you, but they're nothing compared with the real world, and nobody in a real job gets as much vacation time.
Slashdot Mirror
According to the article, AGP8X will use a 32-bit bus at 533MHz. That's 17Gb/s. So the answer to your question is an emphatic NO, the "upgrade" path to IEEE-1394b is absolutely not sufficient. The two technologies are so far apart, intended for such entirely different purposes, that it's ridiculous even to think about either ever replacing the other.
Are you sure about that? Maybe it was a later flavor of RT? The original RT used one of the very earliest RISC processors, called ROMP, and IIRC may even have come out before MIPS existed. I used one briefly, and MIPS it most certainly was not.
The VMS guy was/is Dave Cutler. There is no official connection between VMS and NT, but there are definite "stylistic" similarities...which is only to be expected when the same people work on two projects in succession. Conspiracy theorists also like to tout the idea that NT on Alpha was a concession made to keep DEC from suing their asses.
Rick Rashid of Mach notiriety is also at MS now, but I don't know his role. This is the guy who made his reputation talking about microkernels even though Mach had all of a microkernel's weaknesses and none of its strengths during his tenure, and didn't become a true microkernel until after he left. If anyone could fit an at the world's foremost purveyor of vaporware it's him.
Oh, bullshit. Intel makes more on USB than Apple makes on Firewire. They just bury the cost in chipsets and motherboards so the newbies don't notice.
Looked at another way, PCI does whatever the chipset lets it do. About 3 years ago, the very best Intel chipset could push less than 600Mb/s through a 32-bit 33MHz PCI bus - about 60% of nominal bandwidth. PCI chipsets have gotten a lot better, but the bus itself is still not the bottleneck. I wonder how much of that 528MB/s you mention is actually realizable.
And why is that, do you think? Could it be because our "good friends" at Intel, who make the most common chipsets, are more interested in pushing their own separate standard than in adding 1394 support? You better believe that having USB displace 1394 is worth more than $1/port (the original 1394 license fee, now a quarter of that) to Intel.
Who wants to put more money in Intel's pockets? IMO AMD and VIA missed a huge opportunity by not putting 1394 support into their chipsets just to stick it to Intel and their "standards".
Why, yes I do, if by "hardware driver" you mean "anything that runs in kernel space". Specifically, I write filesystems nowadays, though I've also written network and physical-device drivers. In the past I've worked on the kernel itself, on middleware, and - a long time ago - on applications. I even wrote a tiny bit of embedded code once. Of all of these types of programming, writing drivers seems to leave one at the mercy of others' design or interface decisions the most. The tools also tend to be the worst. It can be very difficult and frustrating.
So why do I, and others, put up with it? Why don't we do something else? Well, I admit that there's a certain satisfaction in seeking out and overcoming the greatest challenges available, proving oneself, etc. It's a motivation similar to the one that drives some percentage of soldiers to become SEALs or Rangers or Airborne. Mostly, though, I think people do this stuff because they realize it's necessary or it's The Right Way to do something they consider interesting - in my case, distributed and cluster filesystems.
Nobody likes to hear bitching from people who don't understand what they do. What programmer, of any stripe, would not resent a PHB badgering them about adding some stupid feature that conflicts with a product's original design? Well, to a kernel guy (and it is unfortunately the most male-dominated programming specialty) an app programmer is almost indistinguishable from a non-programmer. Practically every kernel programmer started out doing apps at some point, and understands what's involved, but 99% of app writers have absolutely no idea what's involved in writing kernels or drivers. Therefore, any app writer who resents having non-programmers critique their own work should likewise refrain from critiquing kernel folks' work.
The latest status symbol is big flat-panel displays. With one VP at my company I noticed that not only he had one, but everyone located near him - receptionist, admins, etc. - had one, while engineers in the same section had half their desks taken up with CRTs. What BS.
There are two main reasons SMP isn't more pervasive:
The first of these is pretty self-explanatory. I'll try to expand a little on the second.
Multiprocessor (MP)hardware is a lot more complex than uniprocessor (UP) hardware, with extra latency in the memory subsystem to deal with potential cache issues - even if no sharing is occurring at that particular moment. Code running on multiple processors needs to do locking, and the locking itself can be pretty costly (especially since it uses bus-saturating interlocked memory instructions). This is why running an MP kernel on a single processor is even slower than a UP kernel. Lastly, not all code parallelizes well; much of it contains major sequential dependencies. In the end, all of the extra work that's done to make MP behave correctly may end up costing more than it's worth even for small numbers of processes.
As the number of processors increases, all of these effects increase exponentially. The memory system starts to get pretty hideously expensive, cache warming and memory locality issues become more complex as efforts are made to reduce the strain on the memory system, and all the while it becomes harder and harder to keep all of the CPUs busy enough to make the whole thing worthwhile...and this is even for a mere couple of dozen processors.
When you're looking at something like Blue Gene, look not at the amount of CPU power involved but at the incredible memory/communications bandwidth - multiple communicating processors on a single chip, multiple chips on a board, boards arranged into modules, etc. The key to Blue Gene is that they have this phenomenal bandwidth coupled with a specialized application which is almost uniquely able to take advantage of how the memory/communications system is structured.
I wouldn't be so quick to blame everything on "badly written" drivers if I were you. Applications are fairly simple, locking-wise. They have one entry point and full control over when new threads enter or exit. Apps that benefit at all from SMP usually do so trivially; anything that's a pain in the ass to handle in parallel just gets a huge mutex slapped around it, and apps rarely need to hold two locks at once. For drivers, it's very different. Drivers have multiple entry points, any of which can generally be invoked at any time even when something else is already going on. Single-threading requests is generally not an option for performance reasons. Drivers tend to develop deeper locking hierarchies and more complex locking behaviors than almost any app, so it's no surprise that locking errors - race conditions, deadlocks, etc. - are so common. Yes, a driver that has such errors in it is still broken, but it may still be "better written" than the trivial SMP code app writers can get away with.
It may not be the driver's fault, anyway. The OS itself may have SMP problems that get triggered by specific perfectly-legal driver behavior. For example:
I've seen this kind of crap happen on a dozen OSes, in cases where the driver had every right to call that OS function under those conditions but the OS screwed up. I've seen cases where the OS-provided synchronization facilities had subtle bugs (usually SMP-specific bugs) that caused starvation or missed wakeups under some conditions. Drivers are hard to write under the best of conditions, and when they have to be written while avoiding all of the OS bugs it's sometimes amazing that they ever work at all.
The above seems to imply an expectation that 2.4 will be faster than 2.2. That's unlikely. The VFS layer has been essentially rewritten for 2.4, and a lot of filesystem code has had to change with it. This is some of the most performance-critical code in the kernel. The really sad part is that, to date, no serious performance measurement activity has been undertaken by the VFS developers, so we don't really know the performance implications yet. Anecdotal evidence from linux-fsdevel (e.g. this message) suggests that reads may be 10-20% slower in 2.4 than in 2.2, while multi-stream writes may be "much faster". I have tried to get more information from the people making such claims - such as descriptions of configurations, tests used, a more concrete definition of "much faster", etc. - but have so far received no reply. I think they're embarrassed, and from what I've seen (see my essay on 2.4 Linux VFS for more) they should be.
Not quite. Stardent, Oki, and Stratus all had equipment using the i860 as a CPU. They were actually pretty good, except for one thing that eventually killed them: they had a really weird (two-issue, IIRC) instruction pipeline that was hard to code for, and compilers generally weren't up to the task. If you could write code for them they performed rather well, but most people couldn't and hence got only mediocre performance out of them.
As for the i960, it was actually pretty nice - much more elegant architecturally than any other Intel offering IMO. The i960CA was actually developed specifically for BiiN to use in large-scale multiprocessing, but of course that died and everyone forgot about it. C'est la vie... et c'est la mort. ;-)
Using the i860 as a CPU always seemed a little odd to me, but the i960 - especially the C or J series - might have made a very good main processor.
So where's yours? I'd love to see it. Please don't disappoint your adoring audience by saying you don't have one, and don't try to take credit for a site you had nothing to do with either.
I don't pretend to be great at web fluff; there are other things I'm much more interested in being good at. Writing (I won't even dignify it by calling "hacking") HTML is about as far from my specialty or interests as can be, so I usually leave it to people who can't cut it in the kernel world. You guys need something to do, after all. The site only exists because some people had specifically asked for some of the scripts and I figured that if those people found the scripts useful then other people might too. Then I added a couple of other things just because I was bored. I think I was waiting for a build of something or other, or perhaps a big download. Total investment? $0 and a couple of hours.
So it's not a work of art. I admit that, but you know what? It's still better than about half the garbage other people put on their personal web pages. Nobody needs another picture of the dog, or another ego-counter or animated GIF or fancy background/border/divider. In fact, if I may rant a little, I happen to know from a previous life (my mother's) in typesetting and graphic design that an overabundance of visual cues actually detracts not only from a page's aesthetic value but also from its utility as a way for readers to view information. Intelligent use of minimal formatting to represent semantically meaningful things like quotation, emphasis, or conceptual structure (e.g. lists) is a skill that's seriously underrated but much more valuable than diddling around with eye candy.
Now that you've read that, go clean up your page to get rid of the <blink> tags, and then tell us where it is. I'm looking forward to it.
You really do have a lot to learn about industry, don't you? I already mentioned that several of those products existed before there was a web and yet you seem to expect a web presence anyway. Ridiculous. If you'd made even the slightest effort to check, you would have seen that most of the products I named that were developed in the "web era" do in fact have web pages. HACMP/6000 was even used as one of Greg Pfister's case studies in In Search of Clusters. What more could you want as evidence of the projects' reality?
Here's another lesson about the real world. Some companies generate lots of white papers. Some companies generate lots of product. Very rarely do the two intersect. The product I'm working on right now was discussed at Usenix, which is much more "open" than any white paper.
Yes, I made those two statements...separately. Their juxtaposition, eliding a great deal of explanation of the connection between the two and thus taking them out of context, is yours. Again we have no evidence of anything about you but your dishonesty.
Bull. Nobody who reads this exchange would believe that. You obviously meant to start a pissing contest, and you lost badly. Now that you're all wet, yellow and smelly from pissing on yourself, you're trying to change your tune. You're so transparent it's amusing.
You who were the one who insisted on talking about background, not me. If I had not answered your questions about my background I'm sure you would have accused me of hiding from it, and now that I have answered you accuse me of bragging. Next time you try to set up a double bind like that, try to be a little bit less obvious about it. It might even work on someone besides your classmates.
Translation: your claim is pure, unadulterated, total bullshit. Guess what? Absolutely everyone on slashdot would be able to make that translation. You haven't worked on squat or you'd be shouting it from the rooftops, telling everyone how you'd made the greatest contribution to computing since von Neumann. You do know von Neumann, right?
Said without the slightest shred of knowledge. You couldn't even find information about them, despite the fact that such information is readily available, and yet you feel comfortable judging their quality.
...because you have nothing better to do with your time than troll on slashdot. Well, I do. I've wasted enough time with you already. I've given two examples of Linus's weird attitudes that explain why I say what I do about him. I've described my background in great detail when asked (and not before). In general I've backed up everything that I say. You haven't provided anything worth reading - no information about Torvalds, no information except for an outright lie about your own (lack of) background. The closest you've come to discussing anything honestly is a red herring about whether debuggers are in fact a good thing to have. You say they cause too much perturbation to the system, but I've implemented the kernel stubs for a couple and I've used them to debug thousands upon thousands of lines of kernel code so I know that claim is utterly false. You're just trying to get a rise out of someone any way you can, and by now it's abundantly obvious to me - and, I'm sure, to anyone else dumb enough to read this - that you don't even have Clue One about programming.
Go fish somewhere else. There's no longer any need for me to respond, because you've already made my point for me and there's no way I can reveal your total loserhood any more than you've done yourself. My work here is done and, unlike you, I have other work to attend to. Have fun with your insult-laden content-free reply. I'll enjoy watching that hole you've dug for yourself get even bigger with every word you write, without any help from me.
Try looking beyond my replies to you specifically. I replied to several other people, and everything you claim is missing is in those replies to others. In my replies directly to you I had even alluded to the fact that your concerns were addressed elsewhere, and provided a pointer.
None of these products were done in an environment where publishing web sites is considered a major part of the work. Several were done before the web. For your benefit, though:
Happy now? Those products are all quite real, as you would already have known if you'd bothered to look.
That's pretty funny, considering that you were the one who brought "street cred" into it. All of a sudden, when you're the one who has to back up what you say, it's not so important, eh? Hypocrite.
OK, so what shipping products have you been involved in? I'll settle for completed open-source projects, even though those all too often fail to meet the same quality goals as commercial products. Or is all of your vaunted experience in class projects? Are you the same jtgold who's a student at MIT?
BTW, application programming barely counts for anything in my book, and certainly in the context of this discussion. If you haven't been involved in a kernel-level project that ended up in the hands of - what was the phrase? oh yeah - "several thousand users", IMO you should shut the hell up and try to learn from the people who actually have lived through that experience.
It's a shame that forums like slashdot encourage people who've learned to flame before they learn to code - or, too often - learn to think. Come back when you've done something to give you "street cred". ;-)
You're a lying little turd. How can you say "I notice ..." when you obviously didn't bother to check? In point of fact I did address your earlier objection, and also provided a second more detailed example of Torvalds's arrogance. You, by contrast, have added nothing to this conversation. Linus doesn't need cretins like you defending him.
You won't assume that I do...but you'll gladly assume that I don't. Why is one assumption preferable to the other? What distinguishes them at all...except that one represents a view you came into this conversation already favoring?
UMAX 4.3, UMAX V, TOPIX, HACMP/6000, REACT, ATF, Medley, MPFS. No, I didn't design or code all of those things myself, except for REACT and ATF, but those two alone account for "thousands of satisfied users". Thousands more have benefited by my work on the others. None are on Linux, of course, and I doubt you've heard of any of them in your tiny little corner of a vast computing world, but that's plenty of "street cred" (what a stupid term!) for most folks. What do you have to offer, little boy? A little bit of Javascript, perhaps? Why should anyone take your word for anything? You haven't established your own credentials, you haven't introduced any new facts or quotes or insight. All you've done is prove my point about too many Linux zealots being asinine little punks with a hundred times more attitude than ability. Go read the advocacy how-to before you presume to defend anyone from the evil outsiders.
It saddens me to see how quick people are to assume without basis that which it is convenient for them to assume - e.g. that I do not read k-t, that I am not a kernel programmer, etc. I have already addressed this particular canard in #605.
You are absolutely correct. Linus is indeed extremely sharp, and his views are often as correct as they are idiosyncratic. However, some of his other ideas are stupid, and by refusing even to acknowledge other views he sets a bad example for people who look up to him. Whether he likes it or not, he is in a position to influence the quality of work produced by a whole generation of programmers. I believe he should take that responsibility more seriously, and make more of a conscious effort to set a good example.
As convenient as it may be for you to assume the latter, the answer is "neither". When I refer to discipline, I refer to a capacity for doing things one does not enjoy or even finds unpleasant because they are the "right" things to do. In this context I'm talking about writing clear, modular, extensible and maintainable code, testing that code, and documenting what you did for anyone who may have to work on it later. I'm talking about fixing bugs that you happened to find in other people's code (or at least reporting them to the people who can fix them), and fighting the urge to solve your own problems by rewriting other people's code that is already working just fine. I'm talking about trying to implement things cleanly even if it takes more time than hacking it up. Everyone knows these are Good Things, even the people who don't do them. The discipline to which I refer is no more than not making excuses.
As someone who has spent over a decade in various OS groups, and who now develops filesystems for a living, I am quite well aware of this.
I do, regularly.
Wrong. I've already mentioned his absurd attitude toward debuggers. To take a more recent example, consider his recent comments about real-time. Real-time is not about performance, it's about predictability. "Ten times as fast as necessary, 99% of the time" is great for general-purpose computing, and even for a lot of stuff - e.g. financial or point-of-sale systems - that people persistently mislabel as real-time, but for true real-time - e.g. flight or nuclear power plant control - it just doesn't cut it. Linus obviously doesn't know this, which is OK; it takes most people a while to grok it. What's galling is that Linus is too damn arrogant to listen to the people who do know what real-time is about.
If Linus had just said "real-time is not a goal for Linux, use another platform" that would be fine. Couldn't argue with that. However, he chose instead to treat the real-time folks' concerns as invalid, based on his own misunderstanding of what they're about. That's exactly the kind of parochial attitude I'm talking about. Engineering is about making solutions fit problems, not trying to make problems fit the solution you've developed.
Maybe you don't, maybe the Linux community in general doesn't, but I do and I expect the people I hire to do so as well. Sure, the tools we kernel hackers have to work with - debuggers, profilers, etc. - are often inferior to those available in user-land, but it is still our responsibility to do the best we can. There is still no excuse for writing code that's hackier than necessary to work around OS insanity (oh, the war stories I could tell!) or for not using the tools that are available.
Some people do indeed use debuggers as a crutch. I work with a guy whose whole programming methodology seems to be centered on sitting in the debugger, and who is totally incapable of fixing a bug that occurs anywhere but in his own highly tweaked debugging environment - such as from the field. It's a major Bad Idea to rely on debuggers this much.
However, just because something's used as a crutch by some people doesn't mean we should do away with it. Even crutches have legitimate uses. ;-) Debuggers are very useful things to have around, and it's ridiculous to look down one's nose at people who use them responsibly, as Linus has on more than one occasion.
Firstbrook's objection is mostly crap, but not entirely. One of the problems with the Linux community is that it does tend to undervalue aspects of software engineering besides straight-out coding. People who concentrate on writing good code rather than more code, or who test the hell out of their code, or who do a good job of documenting what they've done, get a lot less recognition than the people who crank and crank and crank, even if what the people in the latter group crank is mostly garbage. This "bad culture" is directly related to the bad example set by Linus himself, who has some attitudes that most serious software engineers would regard as eccentric at best (e.g. his well-publicized disdain for debuggers). The net result is a huge number of people who think they're hot stuff because they've learned a few nifty tricks, but who lack any deep background or self-discipline because they've never been rewarded for those things.
Which brings us back to Firstbrook. Many people have suggested that the problem is not with Linux but with the lack of things like change logs, but my point is that they're not unrelated. People who have become steeped in Linux knowledge have also been steeped in Linux tradition, and that's a tradition that devalues some of the things that matter in a mission-critical environment. That puts employers and customers in a bad spot if they rely on Linux systems, with the most technically savvy people often being professionally "immature" and often too arrogant to admit that the customer's modus operandi may be valid even if it's not "the Linux way". Employers and customers get tired of that BS real fast, and may well find themselves longing for the days when the people who knew the most about their OS weren't obnoxious little punks.
What has made Linux a very good OS is the amount of youthful enthusiasm that has gone into its development, but in a way that's also what prevents Linux from being a great OS. The Linux community is inseparable from Linux itself, and the skewed reward system in the Linux community has revealed the dark side of youthful enthusiasm - hubris, lack of discipline, and a large dose of "Not Invented Here" syndrome.
Saying that CORBA's interface versioning solves this problem is like saying that a hammer solves the problem of nails. It's a tool, valuable to the extent that people know how to use it properly by making sure that the interface definition accurately and completely describes the behavior of a component and that the "actual interface" doesn't change without corresponding change to the "official interface" - something that doesn't just happen on its own. Arguably, what you really need to solve this problem (and, even more arguably, what some languages or programming models give you) is a way to ensure that all behavioral dependencies are captured in the interface definition and that nobody can even begin to depend on something that could change.
it's easier to explain sex to a virgin than to explain the law to a non-attorney
Unfortunately true, but not of necessity. I understand the need for legal language to be precise etc. but there's no reason for it to be so fuqn obtuse, verbose and counterintuitive. Read Legal Language for an eye-opening account of how it got that way, or Guilty: The Collapse of the American Justice System for some insights from a judge on where it has left us.
If lawyers are going to persist in using unnecessarily opaque language, then IMO they shouldn't bitch about having to explain their usage to non-lawyers.
As for your interpretation of contract law as it applies to NDAs, your expressed opinions coincide with the briefings I've received on the matter. But of course IANAL. ;-)
Read Salamander's post closely..."Vote for me and I will use the force of the government to take money from those nasty selfish [fill in the blank] to give to you."
What is this? A competition to outdo each other for sheer stupidity? I said absolutely nothing of the sort. Just because I don't think programmers have a god-given right to a lifestyle ten times better than other people who work just as hard does not by any stretch of the imagination mean that I believe in any socialist "levelling" BS. OK, not by any reasonable stretch of the imagination. ;-) Cretins like you often have a talent for imagining things well beyond the ken of saner folk. It's amazing that you can even manage to type, with that few brain cells.
I am keenly aware of how fortunate I am to be in a field where the reward:work ratio is so high, but that doesn't mean I have any intention whatsoever of giving away the rewards I have in fact earned.
Overwhelmingly white??? Has this guy ever been in a computer science program
Yes.
or seen programmers?
Yes. I've been programming professionally for over a decade now, which I'd guess is a decade longer than someone posting from Central Michigan U. :-P
In my group there are nine full-time people, all white, plus one co-op who is Asian. In the associated QA group there are two white, one Asian and one Indian. Of the whole set, there is only one woman, plus our doc writer is a woman. Sadly, this is all pretty much par for the course in real-life software engineering. The whole industry tends to be white and male, even more so in development than in other areas (such as QA, IS, doc or management), and most of all in kernel development. I've worked with hundreds of developers, one of them black and none of them Hispanic. It's sad. But don't take my word for it. Don't accept any "anecdotal evidence" (an oxymoron, BTW) including your own. There are scientific surveys out there showing the same patterns.
Sure, there are exceptions. One group I work with is full of people from India and Pakistan. Another is full of Chinese. These cliques - for want of a better term - are a well-known phenomenon in hiring; people hire others who are like themselves, minorities perhaps even more so than plain-vanilla whites because they (the minorities) feel embattled. And well they should, because by far the largest clique is the white guys. These little spots of diversity are still just spots, against a vast white background.
Drinking and screwing? I don't know what to say. I wish?
OK, perhaps that's not quite accurate. Often the drinking is quite real, but the screwing is more a matter of imagination and reality. Combine that with a smattering of drugs and an obsession about music and you have your average college student. Replace some of the above with random abuse of the college's computer systems to play games, to download mp3s or porn or open-source software (all equally unrelated to coursework), or to further personal profit-making enterprises, and you have the average geek in college. What's noticeably lacking in any of this is adequate focus on actual coursework. For most people, college is no more than a very nice break before you start having to work for a living. Ask anyone who works in the real world, even in a cushy job like programming, whether they envy the "working conditions" in college. The workload and deadlines in college may seem pretty demanding to you, but they're nothing compared with the real world, and nobody in a real job gets as much vacation time.