The articles looked like a lot of fluff to me, meandering far without ever reaching a point, but it did make me think a little about our collective responsibility as software developers and that's always a good thing.
I agree with the idea that developers are responsible to their users, in much the same way that doctors, lawyers and other certified professionals are. IMHO, shipping a piece of software that crashes users' systems or corrupts their data or allows someone on the Internet to steal their data, when you knew it would do those things but shipped it anyway due to schedule pressure etc. is an act of malpractice. If a product (and here I'm talking mostly about an OS-level product) is shipped without proof that "due diligence" was exercised in finding and fixing bugs, the vendor should simply not be allowed to sell it any more.
Nobody expects perfection. If you have a reasonable procedure for finding and fixing bugs, you needn't worry about this, even if a serious bug does in fact slip through. If you give away your code for free, you also needn't worry. But if you hope to make money by selling software that you know (or should know, according to reasonable standards within the profession) is not adequately tested and debugged, then, well, screw you.
>Executable file format has nothing to do with the architecture of the microprocessor the executable is designed to run on, but with the operating system.
Well, saying that executable format has nothing to do with processor architecture(s) seems a little strong. The two do relate in quite a few ways.
>Personally, "fat" executable formats don't appeal to me
Me neither. One alternative would be to distribute code "compiled" for some sort of VM and then either interpret it or compile it (user choice) as is done for Java. This is a special case of the more general approach tried by ANDF (Architecture Neutral Distribution Format, for you younger folks) and similar efforts peaking around ten years ago. Some used virtual machines, some encoded parse trees so you could do more global kinds of optimization while compiling ("installing") the result, etc.
There are some really big-time hairy issues involved in all this, but I've never been convinced that the non-adoption of ANDF was really due to technical failings so much as end-user ignorance of the benefits. I would love to see some of these ideas brought back.
>Sorry if I had it wrong but I was under the impression that Linux was multitasking but that once a process was in the kernel it was not pre-empted til its timeslice was complete or it blocked on IO. That is pre-emptive multitasking.
It is sufficient that tasks be preemptible _while in user space_ to be considered preemptive multitasking. In point of fact, very few OSes allow kernel preemption - mostly true realtime OSes, which BTW means more than having "realtime" process priorities a la NT or many UNIXen.
Linux doesn't have kernel preemption. NT doesn't either. Oddly, AIX does, but that makes sense when you consider that AIX had to make the kernel pageable anyway because of bloat and paging is a kind of preemption so why not go all the way?
>...one thing that hasn't been pointed out yet: journaling file systems don't (immediately) overwrite a file when it is changed. > >To elaborate, imagine a long tape that represents your hard drive...
It hasn't been pointed out because it's not true. What you're talking about is a _log structured_ file system. That's a whole different thing. A _journaling_ file system looks after the metadata using a (duh) journal that records changes to directories, attributes, allocation maps etc. so they can be either rolled forward or rolled back upon reboot. However, a JFS (not necessarily IBM's JFS, though they were pioneers in this area) has pretty much the same ways of handling the actual file data as any other FS, including deferred writes etc.
Any FS including a JFS or LSFS may support features for increased synchrony providing greater data integrity, such as fsync() or O_SYNC, but that's really a separate matter.
>If you add automatic failure-detection to MOSIX, you have HA+speed. You'd only need to make sure state was mirrored across the cluster.
Yeah, all you need to add high availability is make sure state is mirrored across the cluster and add failure detection. All you need to write a kernel is run a few lines of code through a compiler. All you need to build a car is weld a few bits of metal together.
>>Even on that front, Linus's contributions were >nill. > >I wouldn't say that; he did preside over a novel development model, harnessing the work of hundreds of programmers across the world and coordinating these efforts into a kernel in quite a short time.
OK, so give him a management degree. Or philosophy. But not CS. I agree with those who say he has done nothing to advance the "state of the art". Linux could have been written ten years before Linus, by any of a hundred programmers who'd had exposure to Minix or XINU etc. Some would argue that the functional equivalent of Linux _was_ written ten years before Linus, by the authors of a coupla dozen UNIX flavors from BSD onward.
What Linus did is a great _practical_ achievement, but at the theoretical level which is justification for a doctorate it just doesn't count.
I love to bash Microsoft. You know why? One reason is that they rely on FUD about their competitors' products to sell their own. In other words, it's the FUD I hate. So I enjoy it just as much when anti-MS FUD gets shredded as when pro-MS FUD does. It's amazing all the lame excuses I'm seeing now that people's cherished false claims have been disproven.
I particularly love the bit about how a farm of small boxes is better than a single big box for availability reasons. This is only true if the boxes in question are in some sort of HA arrangement, and the fact of the matter is that HA on Linux lags _way_ behind HA on AIX, Solaris, HP-UX or Digital UNIX. The "no big boxes" schtick is just more FUD.
As for the "Linus is so smart, no he's not" thread and microkernels: Linux has proven many times that he needs to grow up as an OS designer. Sure, existing microkernels suck because they use inefficient IPC interfaces between modules, and Linux avoids all that overhead, but there's a little excluded-middle thing going on here. One doesn't have to be entirely monolithic and non-modular like Linux to avoid the faults of IPC-based microkernels. I've worked with a bunch of UNIX kernels plus NT, and Linux is _the biggest_ pain in the ass as far as implementing a self-contained module. Damn good thing I can change the core code, because that's the only way to do many important things even though it doesn't have to be that way. Modularity is _still_ a good thing, and something Linux sorely lacks (though it has improved a lot and I expect will continue to improve).
>"Why not? How are graphics fundamentally different than, say, network cards?" > > Because they're a *lot* more complicated.
More complex than a NIC driver? Yeah. But more complex than, say, a distributed filesystem? No, not really. As you say:
>Video cards these ARE computers in their own right.
Yep, they're complicated, but that's because an awful lot of complexity is _in the card_. Is the _interface_ to a graphics card's functionality more complex than other kernel entities? Again, no, not really.
A lot of people have serious misunderstandings about what should or should not go into the kernel. Generally, I think things should be kept out of the kernel unless there's a good reason for putting them in, but such good reasons are not uncommon. At the same time, I think that allowing user-level access to hardware resources is a bad idea, but if it's done in a very tightly controlled way it can be great. For example, at Dolphin I worked on a shared-memory card. If it had worked properly, processes on separate nodes could share memory as easily and transparently (and almost as quickly) as processes on the same node. That would have been way cool. Of course, an important part of the hardware and software design was how to allow applications access to the mapped data areas without allowing them to access control stuff, and as of the time I left the card didn't really work very well anyway. So we have examples of how all these "rules" can and should be broken in specific cases.
Two of the best reasons for putting stuff in the kernel have to do with address spaces and synchronization. The address-space problems are readily resolvable in more advanced research-type operating systems, at least mostly, but in some ways the fundamental and unchangeable UNIX model of processes and address spaces etc. makes this extremely difficult and a new driver is still safer/easier than a severely-hacked virtual memory system even if it's harder/riskier than a user-space program. The synchronization issues are probably more important wrt putting graphics in the kernel or not. If all you're mapping into user space is frame buffers, fine; the worst that can happen is that somebody draws over somebody else's part of the screen. But as soon as you provide user-level access to any other graphics facilities at all, you start opening up a big synchronization Can O' Worms. In some ways, you end up more vulnerable than if you put the gritty bits in the kernel where proper synchronization (which may be complex and non-obvious or even impossible to do without a high level of data sharing which brings you into the address-space side of things) can be rigidly enforced.
I don't know enough about the itty-bitty details of graphics-device interfaces to take a particular stand on whether they should go into the kernel or user space or a little of both (the last seems most likely). I just think that most of the arguments I've seen on the issue are totally "off" wrt why we should or should not implement things in-kernel. There seems to be a lot more ideology and stubbornness involved than actual risk assessment or performance modeling.
I'll believe it when they build one
on
Terabit Routers
·
· Score: 3
Saying something is "scalable to X terabits" doesn't mean much unless you specify what an "X-terabit router" really has to do. A big $#@! pile of PCs is "scalable to X terabits" if they're all handling totally independent traffic flows and never have to talk to one another, for example. Probably the most useful measure is "cross-sectional bandwidth" (i.e. the amount of bandwidth you'd have to remove to partition the nodes into two or more isolated subsets) as used for measuring intramachine interconnects, but - alas - Avici doesn't give us that information.
There's also this little issue of balance. Nothing scales perfectly, and often you don't know where the bottleneck will be until you build one. Sure, if you add up all the links maybe you get up to X terabits, but maybe node-internal contention for some resource limits you to X/100. Of course, this never stopped marketing types from acting as though their machine/link/router would be the first in the history of computing to scale perfectly.
>Free Software Foundation texts which compare the GPL to other licenses are always written from the FSF's point of view, and their hardline politics comes through in their articles. This article suffers from the same problem, just from the opposite angle.
On what do you base that? If someone comes in without previous bias, examine two alternatives objectively (or at least as objectively as we mere humans are capable of doing), finds one alternative markedly inferior, and then writes up their findings, are we to criticize them for their _after the fact_ "bias"? That's ridiculous. It's the affirmative action of licensing debates - demanding equal outcomes rather than equal opportunity for different viewpoints. Thank God we don't code that way.
There have traditionally been two streams of cluster development. One stream, represented by Beowulf, is high performance. Such clusters are actually _less_ reliable than single machines, since a failure of a single component can cause failure of an application running across the entire cluster. The other stream, represented by products such as Digital's TruClusters or Clam/IBM's HACMP/6000 (on which I used to work), is high availability. High availability in general is about reducing _total downtime_ for applications. There may be an interruption, but it should be short (long enough for takeover to occur, which is less time than a full reboot). This contrasts with actual fault tolerance, in which the occurrence of the failure is completely hidden to users or perhaps even to the application itself. Both HA and FT systems tend to become _more_ reliable as components are added, but they also tend to perform worse than the same hardware in a non-HA setup due to synchronization costs etc.
Web service is one of the easiest things to make highly available. There's very little server-side state, reads predominate over writes by a couple of orders of magnitude, etc. In fact, the TurboLinux white paper even states that they don't support any form of data consistency, so your traffic had better be _all_ reads. Yuk. They also talk about the "active router" providing "fault tolerance", indicating that they don't know the difference between fault tolerance and high availability.
Some of the monitoring code is useful in other contexts, but they got that from somewhere else. As near as I can tell, PHT's own technical contribution is near zero.
First off, to all those engaged in the "I get more bandwidth than you" pissing contest: try beating 560Mb/s sustained application-to-application bandwidth between two P2/450GX systems (running NT, BTW, but not NT's TCP/IP). So you think you can beat that, eh? Try beating 2us application-to-application latency for zero-length messages. Can't do it, even with buzzwords like VIA and I2O, can you? OK, next topic.
Regarding TCP/IP on the card: as another poster pointed out, this is not a new thing but a very old thing. I once worked on putting DECnet on old 3Com "smart" cards...ick. There are all sorts of problems with doing this sort of thing on the card. First is upgradability of the network stack. You immediately become dependent on the manufacturer for upgrades - don't expect open-source firmware any time soon, even if you had the tools to compile and load it. FPGAs aren't really a good choice here because they increase the component and design costs too much. You'd be much better off using a commodity embedded microcontroller with "firmware" stored in flash memory, although this may still increase the cost unacceptably and for _real_ speed you just plain have to chuck all this stuff out the window and go ASIC. As it turns out, most systems in most uses have more CPU power to burn than any other type of resource. Some guys at HP several years ago took this observation and ran with it; they designed a card that was even more stripped down than the typical Ethernet card, doing even more of the work in software, and they actually got excellent results.
Lastly, the conversation about NT's networking code reminds me of an exchange I had with an engineer at MS a couple of years ago. He was saying that they had to sacrifice a little on TCP/IP features and error checking (e.g. not crashing if sent a source-routed frame, or something like that) to get speed. My response was that (a) not checking unusual conditions in incoming network packets is just unacceptable, and (b) NT's TCP/IP performance is piss poor, indicating that they have bigger issues to worry about than shaving a few instructions by not checking packet headers. In the time since then I have found no reason to change either observation.
OK, I have nothing against Dylan-the-idea. Seems to be a fine language and I wouldn't mind seeing it get broader exposure. I'm not so sure about Dylan-the-reality, though, and I also detest advocates' excesses even in support of something I generally like. That said...
>>Can your language be extended and embedded with ease? >It is much more extensible than Python because of a powerful macro system. It is probably not easily embedded.
Powerful macro system? Sorry, that's no substitute at all for extension and embedding. I interpret your answer here as a "no".
>Is the language implementation and libraries for it written in the language itself?
Dylan: yes Python: no
And this is a good thing for Dylan? Most of the libraries for both languages are implemented within the language. The difference is that Python gives you an option to implement a library using native code if you feel the need - e.g. for performance - and Dylan doesn't. As for implementing Dylan in Dylan or Python in Python...well, that's just an academic exercise of little interest or value to anyone actually trying to write an application.
>Does code written in the language peform on par with C and C++ code?
Dylan: yes Python: no
You're using a pretty loose definition of "on par with" there. In any case, this question misses the point of Python. Guido very specifically made Python easy to extend because he doesn't buy the "one language fits all" dogma. The idea is not necessarily to write everything in Python, although you usually can and not notice any performance problem; the idea is to write the vast bulk of your application in Python to take advantage of its high-level features, and optimize very small parts by converting them to native-language extensions if necessary. This keeps the language definition and implementation simple and clean, while still allowing an application (not a microbenchmark) to perform every bit as well as it needs to. I personally think it's a good design choice, though the debate is still ongoing.
BTW, some of the best rationales for languages that allow easy integration with other languages instead of trying to do absolutely everything themselves have been offered by John Ousterhout, even though Python has fulfilled that dream better than his own Tcl.
>Dylan also has a lot of powerful language features which Python lacks. Python is cool though.
Python has a lot of powerful language features which Dylan lacks. Dylan is cool, though.;-)
Yeah, we expected that. I sort of think that if Python used braces instead of indentation to identify blocks, it would have twice or more the acceptance it has now. Then again, is that a goal? There are plenty of people using and extending and supporting it now, and it's not clear that there's anything to be gained by attracting the "no rules" types away from perl. I hope they're happy with perl; we're happier with Python.
Here's another clue: not everyone who likes Python likes the enforced indentation. It was certainly a big turnoff for me at first, even though like any responsible programmer I indent anyway (Python is actually very forgiving of different indentation styles, as long as you're consistent and even sometimes when you're not). Some people who use Python like this feature, most have learned to live with it, and a few outright hate it but use the language anyway. Why? Because that _one_ wart is outweighed by all of the many things Python did right (or at least nearly right). Real objects, plus metaprogramming. Understandable scope rules. Good control structures, including robust exception handling. Extension/embedding. And if all these still aren't enough for you, the source is about as clearly written as the source for a language implementation can be. Maybe perl or Tcl don't have this one wart, but they have all sorts of other cancers to make up for that.
It's nice to see Python getting (a small fraction of) the recognition it deserves compared to other scripting languages, and Guido getting credit for one of the best-written pieces of free software out there.
It's also nice to see systems folks like DB getting recognition. We do most of the heavy lifting, and most of the world only sees the people who create widgets and eye candy.
>How many OSS programmers even use software engineering techniques it all? How many have read and used Booch/Rumbaugh/Jacobsen? How many do UML/Cue cards?
I agree with most of what you say, and absolutely agree that there's a difference between OSS and professional development. I've mentioned many times how OSS folks have the luxury of stinting on undesirable tasks like documentation and testing, and often do so, while professional programmers must live up to a more rigorous standard.
However, the precise examples you mention make me shiver. Standard notation and methods are very important and useful things for engineers, but I would contend that Booch/UML/etc. have not yet been accepted even by the existing professional software engineering community as a standard at the same level as standards in other engineering disciplines. IMHO they don't even deserve such status; all the buzzwords you mention have to do with one particular OOP/OOD perspective or interpretation. They're an instance, if you will, of general OOP/OOD, and OOP/OOD is itself an instance of more basic modularity, encapsulation and information hiding principles. There are plenty of perfectly viable alternatives, and plenty of well-educated well-trained fully professional software engineers who prefer those alternatives. Acting as though everyone who doesn't use UML is something less than a peer to those who do is IMHO painting with too broad a brush.
The first, point, similar to that brought up by a previous poster, is that the ladder of programming difficulty/competency has many rungs, and those on lower rungs don't always realize how many rungs are still above them. It's possible to make very rapid progress learning to program, and the most visible results tend to occur at the earliest stages. So someone just learning sees that in a very short time they've learned to produce something that _looks_ 90% similar to what the pros do, and they think they've learned 90% of what there is to know about programming. They think that a license can't be worth much if they fulfilled 90% of the requirements in a few weeks, and they also have trouble accepting that there are still meaningful distinctions to be made between programmers with more experience than themselves.
The second point is that many posters here seem to be arguing from an unstated belief that it's not possible to evaluate programmer skill in any meaningful way whatsoever. Yes, I know some are presenting arguments in different directions, but the most common seems to be "tests are meaningless". I could be polite in my response to that, but this is slashdot so why bother?;-) Basically I think this view is most commonly held by those who think they're super-studly programmers because they can hack a little JavaScript or whatever but don't do very well when real programming knowledge is required because they don't even understand what the important problems/issues in real programming are. The problem can't be with them, of course, because they're elite, so it must be that the evaluation methods are flawed. I think the real pros are more likely to accept the possibility that software engineers' levels of competence can be evaluated pretty effectively, and concentrate on different arguments against licensing or certification.
Personally, I don't much like the idea of government regulation and such, and a single written test or series of tests doesn't seem useful to evaluate someone's skills across the whole spectrum of what software engineering encompasses. However, I kind of like the idea of a "guild hall" system in which a local group of "master craftsmen" who are actually familiar with an individual's work (not just coding, but also specification, testing, scheduling, etc.) can confer journeyman status or higher, and in which the _customer_ can decide what their requirements are for involvement or engineers at some level requiring such proof of competence.
The first theme is that replacing one kind of bias with another doesn't solve anything. For years I've been involved in opposing attempts to replace anti-female sexism with anti-male sexism. The account of a "magnet school" where the geeks got preferential treatment over the "locals" seems like the same sort of thing. It just doesn't work.
Secondly, about "shock" behavior. This is oriented more toward the goths than the nerds. Shock has its value in drawing attention to some other quality you have, which might not be seen because of the blind spots everyone tends to have. At one point in my life I had to deal with people who didn't see anything about me but that I was a lot younger than them and I didn't have a degree like them. They thought they knew what that meant, no matter how good my work was. By deliberately getting in a few faces, I forced them to ask "what does that mean" and look at my work for an answer and actually see my work. HOWEVER...shock behavior _by itself_ is not very worthwhile. All package, no contents, like saying "hey, look at this!" and then there's nothing to see. If what you're drawing attention to is your lack of other qualities/skills/whatever, then maybe some of that energy you put into piercings and tattoos and eyeliner should go into developing the content rather than the package.
Lastly, about diversity. I was reading this thing about Ally McBeal's romance with a black character, and how not making an issue of his blackness was a bad thing, and I wanted to puke. Diversity itself is nothing to celebrate; it's the _fruits_ of diversity that matter, the different things that we can _all_ enjoy because we allow different groups to be different and create them. I guess this is actually very similar to my last point. Difference for a purpose is one thing, difference because you can't help it is another, and difference just to get a rise out of people is yet another. I don't see any reason to celebrate or even particularly tolerate the last of these.
...but my eyes could do without the unreadable black-and-blue-on-dark-grey color scheme. Wired is the worst thing that ever happened to graphic design, almost like a "what not to do" object lesson but some people don't seem to get the joke.
>You're not going to find anything faster than dedicated network-attached storage like a Network Appliance filer for NFS or CIFS.
The #1 reason for this is that a dedicated filer isn't even _allowed_ to do other work. The #2 reason is that the dedicated filer is configured to a CPU/memory/bus/disk balance appropriate for file service.
When you peek under the covers, though, neither the hardware nor the software is really anything special or unique. A reasonably intelligent person who knows something about performance measurement and tuning would generally have little trouble duplicating the functionality and performance of a Netapp (or any of their competitors) using commidity parts and software...for about 1/3 the price.
>This is a bit of a troll because you're talking about private schools though aren't you? I was asking for a comparison of like with like - public schools in the US and state schools in the UK.
Sorry again. Yes, I went to private schools, but my brother went to a public one; as near as I can tell, his school was both more stratified and more cliquish than mine. Fistfights were rare at my school, and nobody expected their friends to join in, but at his school "gang warfare" seemed fairly common.
We're straying pretty far from the topic, though, and plenty of others have provided accounts closer to home of cliquishness in UK schools.
>does anyone notice how no one in america is responsible for their actions anymore? >... >GET IT THROUGH YOUR HEADS. IT'S BAD PARENTING, NOT THE MEDIA THAT IS TURNING YOUR KIDS INTO KILLERS.
Moron. You're just as actively engaged in finger-pointing - and not at the perps themselves - as anyone else here. The parents didn't kill 13+ people any more than the media did.
Slashdot Mirror
The articles looked like a lot of fluff to me, meandering far without ever reaching a point, but it did make me think a little about our collective responsibility as software developers and that's always a good thing.
I agree with the idea that developers are responsible to their users, in much the same way that doctors, lawyers and other certified professionals are. IMHO, shipping a piece of software that crashes users' systems or corrupts their data or allows someone on the Internet to steal their data, when you knew it would do those things but shipped it anyway due to schedule pressure etc. is an act of malpractice. If a product (and here I'm talking mostly about an OS-level product) is shipped without proof that "due diligence" was exercised in finding and fixing bugs, the vendor should simply not be allowed to sell it any more.
Nobody expects perfection. If you have a reasonable procedure for finding and fixing bugs, you needn't worry about this, even if a serious bug does in fact slip through. If you give away your code for free, you also needn't worry. But if you hope to make money by selling software that you know (or should know, according to reasonable standards within the profession) is not adequately tested and debugged, then, well, screw you.
>Executable file format has nothing to do with the architecture of the microprocessor the executable is designed to run on, but with the operating system.
Well, saying that executable format has nothing to do with processor architecture(s) seems a little strong. The two do relate in quite a few ways.
>Personally, "fat" executable formats don't appeal to me
Me neither. One alternative would be to distribute code "compiled" for some sort of VM and then either interpret it or compile it (user choice) as is done for Java. This is a special case of the more general approach tried by ANDF (Architecture Neutral Distribution Format, for you younger folks) and similar efforts peaking around ten years ago. Some used virtual machines, some encoded parse trees so you could do more global kinds of optimization while compiling ("installing") the result, etc.
There are some really big-time hairy issues involved in all this, but I've never been convinced that the non-adoption of ANDF was really due to technical failings so much as end-user ignorance of the benefits. I would love to see some of these ideas brought back.
>Sorry if I had it wrong but I was under the impression that Linux was multitasking but that once a process was in the kernel it was not pre-empted til its timeslice was complete or it blocked on IO. That is pre-emptive multitasking.
It is sufficient that tasks be preemptible _while in user space_ to be considered preemptive multitasking. In point of fact, very few OSes allow kernel preemption - mostly true realtime OSes, which BTW means more than having "realtime" process priorities a la NT or many UNIXen.
Linux doesn't have kernel preemption. NT doesn't either. Oddly, AIX does, but that makes sense when you consider that AIX had to make the kernel pageable anyway because of bloat and paging is a kind of preemption so why not go all the way?
>only the Mac OS clings to cooperative multitasking these days
Actually, Win9x still relies on it quite a bit, though MS will swear up and down that it ain't so. NT, OTOH, is truly preemptive.
>...one thing that hasn't been pointed out yet: journaling file systems don't (immediately) overwrite a file when it is changed.
>
>To elaborate, imagine a long tape that represents your hard drive...
It hasn't been pointed out because it's not true. What you're talking about is a _log structured_ file system. That's a whole different thing. A _journaling_ file system looks after the metadata using a (duh) journal that records changes to directories, attributes, allocation maps etc. so they can be either rolled forward or rolled back upon reboot. However, a JFS (not necessarily IBM's JFS, though they were pioneers in this area) has pretty much the same ways of handling the actual file data as any other FS, including deferred writes etc.
Any FS including a JFS or LSFS may support features for increased synchrony providing greater data integrity, such as fsync() or O_SYNC, but that's really a separate matter.
>If you add automatic failure-detection to MOSIX, you have HA+speed. You'd only need to make sure state was mirrored across the cluster.
Yeah, all you need to add high availability is make sure state is mirrored across the cluster and add failure detection. All you need to write a kernel is run a few lines of code through a compiler. All you need to build a car is weld a few bits of metal together.
>>No high availability clustering (Beowolf is cool but completely unrelated to this)
>
>MOSIX was just GPL'ed. This is a good foundation.
MOSIX is also cool, but also totally unrelated to HA.
>>Even on that front, Linus's contributions were >nill.
>
>I wouldn't say that; he did preside over a novel development model, harnessing the work of hundreds of programmers across the world and coordinating these efforts into a kernel in quite a short time.
OK, so give him a management degree. Or philosophy. But not CS. I agree with those who say he has done nothing to advance the "state of the art". Linux could have been written ten years before Linus, by any of a hundred programmers who'd had exposure to Minix or XINU etc. Some would argue that the functional equivalent of Linux _was_ written ten years before Linus, by the authors of a coupla dozen UNIX flavors from BSD onward.
What Linus did is a great _practical_ achievement, but at the theoretical level which is justification for a doctorate it just doesn't count.
I love to bash Microsoft. You know why? One reason is that they rely on FUD about their competitors' products to sell their own. In other words, it's the FUD I hate. So I enjoy it just as much when anti-MS FUD gets shredded as when pro-MS FUD does. It's amazing all the lame excuses I'm seeing now that people's cherished false claims have been disproven.
I particularly love the bit about how a farm of small boxes is better than a single big box for availability reasons. This is only true if the boxes in question are in some sort of HA arrangement, and the fact of the matter is that HA on Linux lags _way_ behind HA on AIX, Solaris, HP-UX or Digital UNIX. The "no big boxes" schtick is just more FUD.
As for the "Linus is so smart, no he's not" thread and microkernels: Linux has proven many times that he needs to grow up as an OS designer. Sure, existing microkernels suck because they use inefficient IPC interfaces between modules, and Linux avoids all that overhead, but there's a little excluded-middle thing going on here. One doesn't have to be entirely monolithic and non-modular like Linux to avoid the faults of IPC-based microkernels. I've worked with a bunch of UNIX kernels plus NT, and Linux is _the biggest_ pain in the ass as far as implementing a self-contained module. Damn good thing I can change the core code, because that's the only way to do many important things even though it doesn't have to be that way. Modularity is _still_ a good thing, and something Linux sorely lacks (though it has improved a lot and I expect will continue to improve).
>"Why not? How are graphics fundamentally different than, say, network cards?"
>
> Because they're a *lot* more complicated.
More complex than a NIC driver? Yeah. But more complex than, say, a distributed filesystem? No, not really. As you say:
>Video cards these ARE computers in their own right.
Yep, they're complicated, but that's because an awful lot of complexity is _in the card_. Is the _interface_ to a graphics card's functionality more complex than other kernel entities? Again, no, not really.
A lot of people have serious misunderstandings about what should or should not go into the kernel. Generally, I think things should be kept out of the kernel unless there's a good reason for putting them in, but such good reasons are not uncommon. At the same time, I think that allowing user-level access to hardware resources is a bad idea, but if it's done in a very tightly controlled way it can be great. For example, at Dolphin I worked on a shared-memory card. If it had worked properly, processes on separate nodes could share memory as easily and transparently (and almost as quickly) as processes on the same node. That would have been way cool. Of course, an important part of the hardware and software design was how to allow applications access to the mapped data areas without allowing them to access control stuff, and as of the time I left the card didn't really work very well anyway. So we have examples of how all these "rules" can and should be broken in specific cases.
Two of the best reasons for putting stuff in the kernel have to do with address spaces and synchronization. The address-space problems are readily resolvable in more advanced research-type operating systems, at least mostly, but in some ways the fundamental and unchangeable UNIX model of processes and address spaces etc. makes this extremely difficult and a new driver is still safer/easier than a severely-hacked virtual memory system even if it's harder/riskier than a user-space program. The synchronization issues are probably more important wrt putting graphics in the kernel or not. If all you're mapping into user space is frame buffers, fine; the worst that can happen is that somebody draws over somebody else's part of the screen. But as soon as you provide user-level access to any other graphics facilities at all, you start opening up a big synchronization Can O' Worms. In some ways, you end up more vulnerable than if you put the gritty bits in the kernel where proper synchronization (which may be complex and non-obvious or even impossible to do without a high level of data sharing which brings you into the address-space side of things) can be rigidly enforced.
I don't know enough about the itty-bitty details of graphics-device interfaces to take a particular stand on whether they should go into the kernel or user space or a little of both (the last seems most likely). I just think that most of the arguments I've seen on the issue are totally "off" wrt why we should or should not implement things in-kernel. There seems to be a lot more ideology and stubbornness involved than actual risk assessment or performance modeling.
Saying something is "scalable to X terabits" doesn't mean much unless you specify what an "X-terabit router" really has to do. A big $#@! pile of PCs is "scalable to X terabits" if they're all handling totally independent traffic flows and never have to talk to one another, for example. Probably the most useful measure is "cross-sectional bandwidth" (i.e. the amount of bandwidth you'd have to remove to partition the nodes into two or more isolated subsets) as used for measuring intramachine interconnects, but - alas - Avici doesn't give us that information.
There's also this little issue of balance. Nothing scales perfectly, and often you don't know where the bottleneck will be until you build one. Sure, if you add up all the links maybe you get up to X terabits, but maybe node-internal contention for some resource limits you to X/100. Of course, this never stopped marketing types from acting as though their machine/link/router would be the first in the history of computing to scale perfectly.
>Free Software Foundation texts which compare the GPL to other licenses are always written from the FSF's point of view, and their hardline politics comes through in their articles. This article suffers from the same problem, just from the opposite angle.
On what do you base that? If someone comes in without previous bias, examine two alternatives objectively (or at least as objectively as we mere humans are capable of doing), finds one alternative markedly inferior, and then writes up their findings, are we to criticize them for their _after the fact_ "bias"? That's ridiculous. It's the affirmative action of licensing debates - demanding equal outcomes rather than equal opportunity for different viewpoints. Thank God we don't code that way.
There have traditionally been two streams of cluster development. One stream, represented by Beowulf, is high performance. Such clusters are actually _less_ reliable than single machines, since a failure of a single component can cause failure of an application running across the entire cluster. The other stream, represented by products such as Digital's TruClusters or Clam/IBM's HACMP/6000 (on which I used to work), is high availability. High availability in general is about reducing _total downtime_ for applications. There may be an interruption, but it should be short (long enough for takeover to occur, which is less time than a full reboot). This contrasts with actual fault tolerance, in which the occurrence of the failure is completely hidden to users or perhaps even to the application itself. Both HA and FT systems tend to become _more_ reliable as components are added, but they also tend to perform worse than the same hardware in a non-HA setup due to synchronization costs etc.
Web service is one of the easiest things to make highly available. There's very little server-side state, reads predominate over writes by a couple of orders of magnitude, etc. In fact, the TurboLinux white paper even states that they don't support any form of data consistency, so your traffic had better be _all_ reads. Yuk. They also talk about the "active router" providing "fault tolerance", indicating that they don't know the difference between fault tolerance and high availability.
Some of the monitoring code is useful in other contexts, but they got that from somewhere else. As near as I can tell, PHT's own technical contribution is near zero.
First off, to all those engaged in the "I get more bandwidth than you" pissing contest: try beating 560Mb/s sustained application-to-application bandwidth between two P2/450GX systems (running NT, BTW, but not NT's TCP/IP). So you think you can beat that, eh? Try beating 2us application-to-application latency for zero-length messages. Can't do it, even with buzzwords like VIA and I2O, can you? OK, next topic.
Regarding TCP/IP on the card: as another poster pointed out, this is not a new thing but a very old thing. I once worked on putting DECnet on old 3Com "smart" cards...ick. There are all sorts of problems with doing this sort of thing on the card. First is upgradability of the network stack. You immediately become dependent on the manufacturer for upgrades - don't expect open-source firmware any time soon, even if you had the tools to compile and load it. FPGAs aren't really a good choice here because they increase the component and design costs too much. You'd be much better off using a commodity embedded microcontroller with "firmware" stored in flash memory, although this may still increase the cost unacceptably and for _real_ speed you just plain have to chuck all this stuff out the window and go ASIC. As it turns out, most systems in most uses have more CPU power to burn than any other type of resource. Some guys at HP several years ago took this observation and ran with it; they designed a card that was even more stripped down than the typical Ethernet card, doing even more of the work in software, and they actually got excellent results.
Lastly, the conversation about NT's networking code reminds me of an exchange I had with an engineer at MS a couple of years ago. He was saying that they had to sacrifice a little on TCP/IP features and error checking (e.g. not crashing if sent a source-routed frame, or something like that) to get speed. My response was that (a) not checking unusual conditions in incoming network packets is just unacceptable, and (b) NT's TCP/IP performance is piss poor, indicating that they have bigger issues to worry about than shaving a few instructions by not checking packet headers. In the time since then I have found no reason to change either observation.
OK, I have nothing against Dylan-the-idea. Seems to be a fine language and I wouldn't mind seeing it get broader exposure. I'm not so sure about Dylan-the-reality, though, and I also detest advocates' excesses even in support of something I generally like. That said...
;-)
>>Can your language be extended and embedded with ease?
>It is much more extensible than Python because of a powerful macro system. It is probably not easily embedded.
Powerful macro system? Sorry, that's no substitute at all for extension and embedding. I interpret your answer here as a "no".
>Is the language implementation and libraries for it written in the language itself?
Dylan: yes
Python: no
And this is a good thing for Dylan? Most of the libraries for both languages are implemented within the language. The difference is that Python gives you an option to implement a library using native code if you feel the need - e.g. for performance - and Dylan doesn't. As for implementing Dylan in Dylan or Python in Python...well, that's just an academic exercise of little interest or value to anyone actually trying to write an application.
>Does code written in the language peform on par with C and C++ code?
Dylan: yes
Python: no
You're using a pretty loose definition of "on par with" there. In any case, this question misses the point of Python. Guido very specifically made Python easy to extend because he doesn't buy the "one language fits all" dogma. The idea is not necessarily to write everything in Python, although you usually can and not notice any performance problem; the idea is to write the vast bulk of your application in Python to take advantage of its high-level features, and optimize very small parts by converting them to native-language extensions if necessary. This keeps the language definition and implementation simple and clean, while still allowing an application (not a microbenchmark) to perform every bit as well as it needs to. I personally think it's a good design choice, though the debate is still ongoing.
BTW, some of the best rationales for languages that allow easy integration with other languages instead of trying to do absolutely everything themselves have been offered by John Ousterhout, even though Python has fulfilled that dream better than his own Tcl.
>Dylan also has a lot of powerful language features which Python lacks. Python is cool though.
Python has a lot of powerful language features which Dylan lacks. Dylan is cool, though.
Yeah, we expected that. I sort of think that if Python used braces instead of indentation to identify blocks, it would have twice or more the acceptance it has now. Then again, is that a goal? There are plenty of people using and extending and supporting it now, and it's not clear that there's anything to be gained by attracting the "no rules" types away from perl. I hope they're happy with perl; we're happier with Python.
Here's another clue: not everyone who likes Python likes the enforced indentation. It was certainly a big turnoff for me at first, even though like any responsible programmer I indent anyway (Python is actually very forgiving of different indentation styles, as long as you're consistent and even sometimes when you're not). Some people who use Python like this feature, most have learned to live with it, and a few outright hate it but use the language anyway. Why? Because that _one_ wart is outweighed by all of the many things Python did right (or at least nearly right). Real objects, plus metaprogramming. Understandable scope rules. Good control structures, including robust exception handling. Extension/embedding. And if all these still aren't enough for you, the source is about as clearly written as the source for a language implementation can be. Maybe perl or Tcl don't have this one wart, but they have all sorts of other cancers to make up for that.
It's nice to see Python getting (a small fraction of) the recognition it deserves compared to other scripting languages, and Guido getting credit for one of the best-written pieces of free software out there.
It's also nice to see systems folks like DB getting recognition. We do most of the heavy lifting, and most of the world only sees the people who create widgets and eye candy.
>How many OSS programmers even use software engineering techniques it all? How many have read and used Booch/Rumbaugh/Jacobsen? How many do UML/Cue cards?
I agree with most of what you say, and absolutely agree that there's a difference between OSS and professional development. I've mentioned many times how OSS folks have the luxury of stinting on undesirable tasks like documentation and testing, and often do so, while professional programmers must live up to a more rigorous standard.
However, the precise examples you mention make me shiver. Standard notation and methods are very important and useful things for engineers, but I would contend that Booch/UML/etc. have not yet been accepted even by the existing professional software engineering community as a standard at the same level as standards in other engineering disciplines. IMHO they don't even deserve such status; all the buzzwords you mention have to do with one particular OOP/OOD perspective or interpretation. They're an instance, if you will, of general OOP/OOD, and OOP/OOD is itself an instance of more basic modularity, encapsulation and information hiding principles. There are plenty of perfectly viable alternatives, and plenty of well-educated well-trained fully professional software engineers who prefer those alternatives. Acting as though everyone who doesn't use UML is something less than a peer to those who do is IMHO painting with too broad a brush.
The first, point, similar to that brought up by a previous poster, is that the ladder of programming difficulty/competency has many rungs, and those on lower rungs don't always realize how many rungs are still above them. It's possible to make very rapid progress learning to program, and the most visible results tend to occur at the earliest stages. So someone just learning sees that in a very short time they've learned to produce something that _looks_ 90% similar to what the pros do, and they think they've learned 90% of what there is to know about programming. They think that a license can't be worth much if they fulfilled 90% of the requirements in a few weeks, and they also have trouble accepting that there are still meaningful distinctions to be made between programmers with more experience than themselves.
;-) Basically I think this view is most commonly held by those who think they're super-studly programmers because they can hack a little JavaScript or whatever but don't do very well when real programming knowledge is required because they don't even understand what the important problems/issues in real programming are. The problem can't be with them, of course, because they're elite, so it must be that the evaluation methods are flawed. I think the real pros are more likely to accept the possibility that software engineers' levels of competence can be evaluated pretty effectively, and concentrate on different arguments against licensing or certification.
The second point is that many posters here seem to be arguing from an unstated belief that it's not possible to evaluate programmer skill in any meaningful way whatsoever. Yes, I know some are presenting arguments in different directions, but the most common seems to be "tests are meaningless". I could be polite in my response to that, but this is slashdot so why bother?
Personally, I don't much like the idea of government regulation and such, and a single written test or series of tests doesn't seem useful to evaluate someone's skills across the whole spectrum of what software engineering encompasses. However, I kind of like the idea of a "guild hall" system in which a local group of "master craftsmen" who are actually familiar with an individual's work (not just coding, but also specification, testing, scheduling, etc.) can confer journeyman status or higher, and in which the _customer_ can decide what their requirements are for involvement or engineers at some level requiring such proof of competence.
The first theme is that replacing one kind of bias with another doesn't solve anything. For years I've been involved in opposing attempts to replace anti-female sexism with anti-male sexism. The account of a "magnet school" where the geeks got preferential treatment over the "locals" seems like the same sort of thing. It just doesn't work.
Secondly, about "shock" behavior. This is oriented more toward the goths than the nerds. Shock has its value in drawing attention to some other quality you have, which might not be seen because of the blind spots everyone tends to have. At one point in my life I had to deal with people who didn't see anything about me but that I was a lot younger than them and I didn't have a degree like them. They thought they knew what that meant, no matter how good my work was. By deliberately getting in a few faces, I forced them to ask "what does that mean" and look at my work for an answer and actually see my work. HOWEVER...shock behavior _by itself_ is not very worthwhile. All package, no contents, like saying "hey, look at this!" and then there's nothing to see. If what you're drawing attention to is your lack of other qualities/skills/whatever, then maybe some of that energy you put into piercings and tattoos and eyeliner should go into developing the content rather than the package.
Lastly, about diversity. I was reading this thing about Ally McBeal's romance with a black character, and how not making an issue of his blackness was a bad thing, and I wanted to puke. Diversity itself is nothing to celebrate; it's the _fruits_ of diversity that matter, the different things that we can _all_ enjoy because we allow different groups to be different and create them. I guess this is actually very similar to my last point. Difference for a purpose is one thing, difference because you can't help it is another, and difference just to get a rise out of people is yet another. I don't see any reason to celebrate or even particularly tolerate the last of these.
...but my eyes could do without the unreadable black-and-blue-on-dark-grey color scheme. Wired is the worst thing that ever happened to graphic design, almost like a "what not to do" object lesson but some people don't seem to get the joke.
>You're not going to find anything faster than dedicated network-attached storage like a Network Appliance filer for NFS or CIFS.
The #1 reason for this is that a dedicated filer isn't even _allowed_ to do other work. The #2 reason is that the dedicated filer is configured to a CPU/memory/bus/disk balance appropriate for file service.
When you peek under the covers, though, neither the hardware nor the software is really anything special or unique. A reasonably intelligent person who knows something about performance measurement and tuning would generally have little trouble duplicating the functionality and performance of a Netapp (or any of their competitors) using commidity parts and software...for about 1/3 the price.
>This is a bit of a troll because you're talking about private schools though aren't you? I was asking for a comparison of like with like - public schools in the US and state schools in the UK.
Sorry again. Yes, I went to private schools, but my brother went to a public one; as near as I can tell, his school was both more stratified and more cliquish than mine. Fistfights were rare at my school, and nobody expected their friends to join in, but at his school "gang warfare" seemed fairly common.
We're straying pretty far from the topic, though, and plenty of others have provided accounts closer to home of cliquishness in UK schools.
>does anyone notice how no one in america is responsible for their actions anymore?
>...
>GET IT THROUGH YOUR HEADS. IT'S BAD PARENTING, NOT THE MEDIA THAT IS TURNING YOUR KIDS INTO KILLERS.
Moron. You're just as actively engaged in finger-pointing - and not at the perps themselves - as anyone else here. The parents didn't kill 13+ people any more than the media did.