Yeah, that looks pretty simple. I have not looked at Smalltalk too much but the GOF "Design Patterns" book and people into OO theory obviously like it.
But what if you want to break out of the iteration when a particular element is found?
I find it hard to belive that Java is really faster on linux than it is on just about any other platform. At least Java 2 anyway. Do they have native threads yet? Blackdown changed their status page. Where's the checklist page? If they do use native threads I guess they don't use ptreads. If they did each thread would appear as a separeate LWP. Imagine running a Java proggie that had 300 threads and then looking at top and finding 300 6MB processes(linux threads reports same total memory usage of all threads for each individual thread). Although I have never done any benchmarks my feeling through expirience is that its just a little slower due to particular memory usages and other stuff I have heard. But maybe they sorted some of that stuff out. Great to hear if it's true. I wouldn't develop on anything else even if it where half the speed.
After seeing a few posts about how slow Java is I must inform you that Java is not meant to be fast. It is just very good as a programming language and correctness is paramount to speed. It's object oriented functionality is basically unparalleled in the industry. It is much easier to write programs that take advantage of OO constructs than all other OO languages(if you think Smalltalk or something else is just as good or better I'd like to hear your arguments). Sure C++ and many other languages have these features but in practice is has been proven that most people don't know how to use them properly so brings more programmers closer to the far superior OO world.
This is where the problem lies. I would guesstimate that 9 out of 10 coders using an OO language don't really understand OO principles. They might claim to understand, but in reality their code is modular at best. If you have one well designed high level OO construct, your program it will be more that 2x better(I know you probably don't see why but this is a VERY BIG deal).
If one person with great OO skills writes the high level design the 9 other coders can work happily writing their "pseudOO" code and you can still end up with a good application. If they really screw up their little piece you can very easily replace it because the OO abstractions prevent these mistakes from transcending the system.
A well written Java app can be quite fast too. It's the many VB programmers who jumped on the Java bandwagon and use IDEs, misconfigured application servers, producing what they think is good code that give Java a bad wrap.
Yeah, I was just looking into threading on Linux. The pthreads implementation uses a separate light weight process for each thread and give it a separate pid. As a result ps and top are not sure which process should accout for memory allocation so it just displays the same for each. I think the separate pid thing should go away but I've heard they're are no plans to fix it:~(
As has been already posted and discussed, Java computational performance is a match for C+=[you mean C++ ?] today.
I have not done any J3D and only a little AWT and Swing but I have done a ton of Java(http://jcifs.samba.org) and I frankly don't see how what you say above is possible. Java is slow. Java AWT is slower. I found the article you mention but just don't have time to read the whole thing at this moment. You have a relavent section you can point me to? A string I can search on using find in the browser would be great.
... no longer feasable to cram more transistors in a fixed area (10 nm? 1 nm? 1 A?).
Hate to be a penis but is the '1 A' supposed to mean an Angstrom? A carbon to carbon bond is 1.4 Angstroms. It would be pretty hard to sqeeze a transistor into the space of an atom:P
localhost [127.0.0.1] 6000 (?) open
localhost [127.0.0.1] 3240 (?) open
localhost [127.0.0.1] 2179 (?) open
localhost [127.0.0.1] 515 (printer) open
localhost [127.0.0.1] 514 (shell) open
localhost [127.0.0.1] 513 (login) open
localhost [127.0.0.1] 139 (netbios-ssn) open
localhost [127.0.0.1] 113 (auth) open
localhost [127.0.0.1] 111 (sunrpc) open
localhost [127.0.0.1] 98 (linuxconf) open
localhost [127.0.0.1] 80 (www) open
localhost [127.0.0.1] 79 (finger) open
localhost [127.0.0.1] 23 (telnet) open
localhost [127.0.0.1] 21 (ftp) open
What your saying is absolutely true. I don't know why your making it sound like a counter point. I'm saying we need new a better reusable software component model to stop from writing the crappy software I've been talking about.
I went through the 'everything is an object' phase in 1994. I got over it.
Or maybe you didn't get it. I know a lot of people think they know how to program in OO but there stuff is modular at best. One very simple but good OO construct in a program can reduce the complexity of the application by more than half. That is a very big deal if you really understand it.
What are you talking about? Linux is a piece of crap compared to other commercial UNIX. For instance Solaris has the ability to tie threads to particular CPUs. Linux barely runs on multiple cpus and has no real concurrency facilities(at least not any that I hear people using, but I may be wrong about this last part).
I seriously doubt they are talking about using the bases of DNA to represent the data(ie an 8 bit byte). That would mean physically manipulating it which would be relativly slow as it is a chemical reaction.
Rather I believe the idea is to simply use DNA as wire. Yes, DNA conducts electricity. Electrions can travel down the overlapping pi bonds of the chromatic rings in the core.
What kind of new cooling device are they going to create/use that will keep the DNA from degrading or just plain denaturing?
Well, presumably the final product would be a solid. If the surrounding environment is just right it could be very stable. It's ability to denature would be much different from that of DNA in solution. They wouldn't necessarily use the exact derivatives of nucleotides found in nature either. In fact it's likely they would not. There would be ligands(fragments hanging off) that would stabilize it. Perhaps into a crystalline substance. Crystalline substances that are held together with ionic bonds are very strong. I'm no expert but I did take a biochem class called "DNA Protein Interactions". Pretty sweet class.
Well, lets take a look at your stack example in more detail. In theory, everything works peachy _if_ the stack was implemented without error. If, on the other hand, it is used by several projects before a subtle bug is discovered and corrected, then there could be problems if one or more of the applications are depending on behavior that changed when the bug was fixed.
First off, your application is faulty if it fails to operate as expected when the implementation of the interface works as advertised(ie the pop function is a little slow revieling a concurrency flaw in the app). So then your talking about the case where the interface was not designed properly which is just crappy software and not worth talking about.
This happens a lot -- with each new version of most libraries, applications start to break.
Things break because there not using the properly designed abstractions that you get with good reusable software componentry. So when something fundamental that transends the system changes... kaboom. Thats why you need modular reusable software components with well defined interfaces. Preferrably the language that your writing this in supports some form of dynamic binding. NextStep was written in objective c which has these features and it is a noticibly superior product as a result.
The problem is, for which application do you fix the behavior?
Both. Use preprocessor directives so that the broken apps can stay broken.
'you're relying on behavior thats not guaranteed by the interface'.
Then your just talking about really crappy software that should be deprecated and this not worth talking about. You have sort of half made my arguments for me. I think with a little thought and a little more hands on with something OO and you would sway the other direction. If we don't get above malloc and gets as reusable software componentry UNIX will never go anywhere.
But usually autodetecting a format just looks at the first couple of bytes yes? Most config files don't use #! or magic numbers or anything so you can't reliably discern anything other then wheather or not the file is text or binary.
Some very good points here. When I get moderation I'll remember to come back here and bring this up.
However, I'm not convinced that XML should be used. I would insist that the configuration file abstraction be one layer up, meaning any configuration format is allowed as long as the common parser can parse it into whatever the tree might look like in memory. Then your at the same point you would be if the file where xml. IOW the memory model is the same but persistent storage is cofigurable.
I have looked at XML quite a bit. I haven't written code for it, but think about what a typical config would look like in XML. Try something as trivial as syslog and you'll see how ugly it can get. Not all configs look like they map into XML as well as apache.conf or smb.conf.
I agree with you in part. Doesn't anyone think it's weird that this guys are writing what looks to me like Microsoft Windows? I think we're going to have to be a little more clever than that.
However, I don't agree that code reuse eliminates opportunities and leads to obsolete and brittle code...etc. In fact it is just the opposite.
For example, if you write an implementation of a stack datastructure and say "ok guys, everyone _has_ to use this stack whenever you use a stack" thats ok. If it doesn't quite meet someones requirements, then they can change the standard a little, "hey, this stack needs an is_empty() function for my program to work". These changes don't break anyone elses code and are resonable so it works. But if the coder claims the stack needs something and that something would break other peoples code then the coder doesn't really need a stack. They need a completely different data structure and therefore are free to code it up on their own(However in doing so they should try very hard to isolate the concept and provide the abstraction for others to use in return).
Also this is _more_ flexible than you suggest because you can always move from the reuse model to your monolithic "custom" code, "ok, this whole stack abstraction is now the bottleneck, lets just wire this thing together directy". How is this not good for projects with indefinate development lifetime? Monolithic "custom" code is exactly the kind of code that after a long period of development causes you to throw up your arms and declare a re-write(Like Miguel is doing BTW).
Programming is just too difficult to not reuse code. Human beings are just not collectively smart enough. It's as simple as that.
Well, I'm excited about that. You're excited about it, I'm excited about it. Your name's Shoeboy and mine is KidSock... wheres TeenBoot when you need em?
I am still weary of these "tools" because underneath you know they are just clumsy text file editors. Half the time they wipe out any settings made by hand. There's no telling what would happen if you used them together(actually I know what would happen, you get spaghetti!).
It is an absolute requirement that these glorified property editors allow for intelligent parsing. IOW it must be as careful as possible about existing settings such that one can either edit by hand and/or use the configuration tool. This is completely possible. The only thing it might botch are any comments because they have a context that any tool could not possibly understand(ie is the comment for the line above or below).
Now if they librarified their parsers and made them generic then they might convince application developers to use one. Then life would be a lot easier.
And NO XML! You ever think about what even syslog.conf would look like as XML?
I like your ideas of web based administration(and being compatible with Lynx). However this would presumably be based running executable content via the network. Even if you restrict users to the localhost, exposing this funcitonality to yet another open port on the machine is undesireable.
There's a real world out there. And while blinkenlights and big monitors and code can be fun, a computer is only a tool, a means to an end. Forget that, and you will one day find that you no longer have an end in sight - in fact, that you are quite pointless.
Why is this marked Insightful? To the contrary what is this end you speak of? Maybe we like to write free code because it's fun, good natured, and gives us purpose. Sounds like you could use a little purpose yourself. Ironic that your calling us "pointless".
Also I don't see anyone whining about the success of other products in this thread. I guess you must be new because you would have realized than on Slashdot you have to separate the peas from the carrots.
So how can you argue that OS's like Windows 2000 are highly crashable when YOU HAVEN'T USED THEM?
Because many Slashdotters work in corporate IT departments where to, their dismay must support, MS Windows in one form or another as it is the primary client delivery platform. This is where the real anger stems. I know because I am a Professional NT Machine Rebooter:~)
It[Windows 2000] crashes very infrequently -- about as often as my Linux box (once every 4 weeks), and only when I'm deliberately trying to crash it, like running Unreal
I doubt your Linux box is "crashing". It's the X server thats crashing. If you telnet in you can restart X and if you wait long enough I believe X will automatically restart(although it will not restore your current session, you will have to re-login). This is significantly different from the BSOD.
One of the major reasons why Linux isn't garnering the attention it deserves is because of the zealots who argue without thinking.
Actually, I believe Linux is getting attention it does not deserve and I agree with you on this second part but you have not backed up your arguments too well either.
>> What we have is a bloated, buggy, slow monstrosity that makes open source look bad.
> 'Open source' is a style of development, not a specific entity. Mozilla has nothing to do with open source, and everything to do with the developers and the goals of the project. Think about it like this - Mozilla is written largely in an OO language (C++). Does Mozilla's so-called 'failure' make OOP look bad?
It would if OOP was just beginning to gain acceptance in the commercial world as is open source. Besides, splitting hairs doesn't matter. Management will still stay "no, we will not open-source our project. Look at what happend to Mozilla."
The Linux world needs a coherent vision of component software. Shell pipes aren't good enough. Neither is the duct-tape world of Perl. If the Linux world had such a vision, the open-source community could write to it and make real progress. But it's very hard to retrofit architecture.
Right on the money brother. Librarify everything and then your apps are small programs that use a collection of well defined interfaces. The same interfaces would be used by other applications in the system. The rendering engine should be in a ansi c portable shared library. The drawing routines for the windowing system would be abstracted into a common set of interfaces making gui libraries portable. The browser would use a shared library for accessing http resources, or ftp, nfs, smb, smtp etc. Programs would be small. The interfaces would not only abstract the implementation from the caller but also the developers of the libraries. This is perhaps the most important because people can work on their individual pieces of code without worring about dependancies.
Reduce everything to primitives and freeze it into high quality shared libraries.
However, on a properly configured network most people will be properly isolated from seeing most traffic due to switching. I used to be on a very busy hub. I could see pretty much everything. It was very interesting. After they got more connections installed to get rid of the hub we all went to the switch. Now I only see stuff for me and broadcast stuff.
As a side note, I have to say the Ethereal packet analyser is one of the best peices of open source software I have ever seen. I think there's a lot of crappy open source stuff out there that gets a lot more credit then it deserves but Ethereal is excellent and does not suffer from these problems as far as I can tell. It doesn't get every packet right and occationally it crashes but it's not 1.0 yet. I have been using it for some time to reverse engineer the CIFS protocol(Microsoft Windows native file and print sharing protocol) and it works fantastic. It basically made the project possible. I have spend probably _hundreds_ of hours in front of it.
Slashdot Mirror
Yeah, that looks pretty simple. I have not looked at Smalltalk too much but the GOF "Design Patterns" book and people into OO theory obviously like it.
But what if you want to break out of the iteration when a particular element is found?
meaning, ...if(eachElement.equals(whatImLookingFor)) {
break;
}...
KidSock
I find it hard to belive that Java is really faster on linux than it is on just about any other platform. At least Java 2 anyway. Do they have native threads yet? Blackdown changed their status page. Where's the checklist page? If they do use native threads I guess they don't use ptreads. If they did each thread would appear as a separeate LWP. Imagine running a Java proggie that had 300 threads and then looking at top and finding 300 6MB processes(linux threads reports same total memory usage of all threads for each individual thread). Although I have never done any benchmarks my feeling through expirience is that its just a little slower due to particular memory usages and other stuff I have heard. But maybe they sorted some of that stuff out. Great to hear if it's true. I wouldn't develop on anything else even if it where half the speed.
KidSock
After seeing a few posts about how slow Java is I must inform you that Java is not meant to be fast. It is just very good as a programming language and correctness is paramount to speed. It's object oriented functionality is basically unparalleled in the industry. It is much easier to write programs that take advantage of OO constructs than all other OO languages(if you think Smalltalk or something else is just as good or better I'd like to hear your arguments). Sure C++ and many other languages have these features but in practice is has been proven that most people don't know how to use them properly so brings more programmers closer to the far superior OO world.
This is where the problem lies. I would guesstimate that 9 out of 10 coders using an OO language don't really understand OO principles. They might claim to understand, but in reality their code is modular at best. If you have one well designed high level OO construct, your program it will be more that 2x better(I know you probably don't see why but this is a VERY BIG deal).
If one person with great OO skills writes the high level design the 9 other coders can work happily writing their "pseudOO" code and you can still end up with a good application. If they really screw up their little piece you can very easily replace it because the OO abstractions prevent these mistakes from transcending the system.
A well written Java app can be quite fast too. It's the many VB programmers who jumped on the Java bandwagon and use IDEs, misconfigured application servers, producing what they think is good code that give Java a bad wrap.
KidSock
Yeah, I was just looking into threading on Linux. The pthreads implementation uses a separate light weight process for each thread and give it a separate pid. As a result ps and top are not sure which process should accout for memory allocation so it just displays the same for each. I think the separate pid thing should go away but I've heard they're are no plans to fix it :~(
KidSock
As has been already posted and discussed, Java computational performance is a match for C+=[you mean C++ ?] today.
I have not done any J3D and only a little AWT and Swing but I have done a ton of Java(http://jcifs.samba.org) and I frankly don't see how what you say above is possible. Java is slow. Java AWT is slower. I found the article you mention but just don't have time to read the whole thing at this moment. You have a relavent section you can point me to? A string I can search on using find in the browser would be great.
KidSock
Hate to be a penis but is the '1 A' supposed to mean an Angstrom? A carbon to carbon bond is 1.4 Angstroms. It would be pretty hard to sqeeze a transistor into the space of an atom :P
KidSock
[miallen@prodlinux satserv]$ nc -v -z localhost 1-10000
localhost [127.0.0.1] 6000 (?) open
localhost [127.0.0.1] 3240 (?) open
localhost [127.0.0.1] 2179 (?) open
localhost [127.0.0.1] 515 (printer) open
localhost [127.0.0.1] 514 (shell) open
localhost [127.0.0.1] 513 (login) open
localhost [127.0.0.1] 139 (netbios-ssn) open
localhost [127.0.0.1] 113 (auth) open
localhost [127.0.0.1] 111 (sunrpc) open
localhost [127.0.0.1] 98 (linuxconf) open
localhost [127.0.0.1] 80 (www) open
localhost [127.0.0.1] 79 (finger) open
localhost [127.0.0.1] 23 (telnet) open
localhost [127.0.0.1] 21 (ftp) open
KidSock
What your saying is absolutely true. I don't know why your making it sound like a counter point. I'm saying we need new a better reusable software component model to stop from writing the crappy software I've been talking about.
I went through the 'everything is an object' phase in 1994. I got over it.
Or maybe you didn't get it. I know a lot of people think they know how to program in OO but there stuff is modular at best. One very simple but good OO construct in a program can reduce the complexity of the application by more than half. That is a very big deal if you really understand it.
Kid Sock
What are you talking about? Linux is a piece of crap compared to other commercial UNIX. For instance Solaris has the ability to tie threads to particular CPUs. Linux barely runs on multiple cpus and has no real concurrency facilities(at least not any that I hear people using, but I may be wrong about this last part).
KidSock
I seriously doubt they are talking about using the bases of DNA to represent the data(ie an 8 bit byte). That would mean physically manipulating it which would be relativly slow as it is a chemical reaction.
Rather I believe the idea is to simply use DNA as wire. Yes, DNA conducts electricity. Electrions can travel down the overlapping pi bonds of the chromatic rings in the core.
KidSock
What kind of new cooling device are they going to create/use that will keep the DNA from degrading or just plain denaturing?
Well, presumably the final product would be a solid. If the surrounding environment is just right it could be very stable. It's ability to denature would be much different from that of DNA in solution. They wouldn't necessarily use the exact derivatives of nucleotides found in nature either. In fact it's likely they would not. There would be ligands(fragments hanging off) that would stabilize it. Perhaps into a crystalline substance. Crystalline substances that are held together with ionic bonds are very strong. I'm no expert but I did take a biochem class called "DNA Protein Interactions". Pretty sweet class.
KidSock
Well, lets take a look at your stack example in more detail. In theory, everything works peachy _if_ the stack was implemented without error. If, on the other hand, it is used by several projects before a subtle bug is discovered and corrected, then there could be problems if one or more of the applications are depending on behavior that changed when the bug was fixed.
First off, your application is faulty if it fails to operate as expected when the implementation of the interface works as advertised(ie the pop function is a little slow revieling a concurrency flaw in the app). So then your talking about the case where the interface was not designed properly which is just crappy software and not worth talking about.
This happens a lot -- with each new version of most libraries, applications start to break.
Things break because there not using the properly designed abstractions that you get with good reusable software componentry. So when something fundamental that transends the system changes ... kaboom. Thats why you need modular reusable software components with well defined interfaces. Preferrably the language that your writing this in supports some form of dynamic binding. NextStep was written in objective c which has these features and it is a noticibly superior product as a result.
The problem is, for which application do you fix the behavior?
Both. Use preprocessor directives so that the broken apps can stay broken.
'you're relying on behavior thats not guaranteed by the interface'.
Then your just talking about really crappy software that should be deprecated and this not worth talking about. You have sort of half made my arguments for me. I think with a little thought and a little more hands on with something OO and you would sway the other direction. If we don't get above malloc and gets as reusable software componentry UNIX will never go anywhere.
KidSock
But usually autodetecting a format just looks at the first couple of bytes yes? Most config files don't use #! or magic numbers or anything so you can't reliably discern anything other then wheather or not the file is text or binary.
KidSock
Some very good points here. When I get moderation I'll remember to come back here and bring this up.
However, I'm not convinced that XML should be used. I would insist that the configuration file abstraction be one layer up, meaning any configuration format is allowed as long as the common parser can parse it into whatever the tree might look like in memory. Then your at the same point you would be if the file where xml. IOW the memory model is the same but persistent storage is cofigurable.
I have looked at XML quite a bit. I haven't written code for it, but think about what a typical config would look like in XML. Try something as trivial as syslog and you'll see how ugly it can get. Not all configs look like they map into XML as well as apache.conf or smb.conf.
KidSock
I agree with you in part. Doesn't anyone think it's weird that this guys are writing what looks to me like Microsoft Windows? I think we're going to have to be a little more clever than that.
However, I don't agree that code reuse eliminates opportunities and leads to obsolete and brittle code ...etc. In fact it is just the opposite.
For example, if you write an implementation of a stack datastructure and say "ok guys, everyone _has_ to use this stack whenever you use a stack" thats ok. If it doesn't quite meet someones requirements, then they can change the standard a little, "hey, this stack needs an is_empty() function for my program to work". These changes don't break anyone elses code and are resonable so it works. But if the coder claims the stack needs something and that something would break other peoples code then the coder doesn't really need a stack. They need a completely different data structure and therefore are free to code it up on their own(However in doing so they should try very hard to isolate the concept and provide the abstraction for others to use in return).
Also this is _more_ flexible than you suggest because you can always move from the reuse model to your monolithic "custom" code, "ok, this whole stack abstraction is now the bottleneck, lets just wire this thing together directy". How is this not good for projects with indefinate development lifetime? Monolithic "custom" code is exactly the kind of code that after a long period of development causes you to throw up your arms and declare a re-write(Like Miguel is doing BTW).
Programming is just too difficult to not reuse code. Human beings are just not collectively smart enough. It's as simple as that.
KidSock
I've spent probably 100 hours in front of Ethereal and Ars-Fartsica(smelly name) is right on, it is an argument for GUIs if I have ever seen one.
KidSock
Well, I'm excited about that. You're excited about it, I'm excited about it. Your name's Shoeboy and mine is KidSock ... wheres TeenBoot when you need em?
KidSock
How do you get karma for posting stuff like this?
KidSock
I am still weary of these "tools" because underneath you know they are just clumsy text file editors. Half the time they wipe out any settings made by hand. There's no telling what would happen if you used them together(actually I know what would happen, you get spaghetti!).
It is an absolute requirement that these glorified property editors allow for intelligent parsing. IOW it must be as careful as possible about existing settings such that one can either edit by hand and/or use the configuration tool. This is completely possible. The only thing it might botch are any comments because they have a context that any tool could not possibly understand(ie is the comment for the line above or below).
Now if they librarified their parsers and made them generic then they might convince application developers to use one. Then life would be a lot easier.
And NO XML! You ever think about what even syslog.conf would look like as XML?
KidSock
I like your ideas of web based administration(and being compatible with Lynx). However this would presumably be based running executable content via the network. Even if you restrict users to the localhost, exposing this funcitonality to yet another open port on the machine is undesireable.
KidSock
There's a real world out there. And while blinkenlights and big monitors and code can be fun, a computer is only a tool, a means to an end. Forget that, and you will one day find that you no longer have an end in sight - in fact, that you are quite pointless.
Why is this marked Insightful? To the contrary what is this end you speak of? Maybe we like to write free code because it's fun, good natured, and gives us purpose. Sounds like you could use a little purpose yourself. Ironic that your calling us "pointless".
Also I don't see anyone whining about the success of other products in this thread. I guess you must be new because you would have realized than on Slashdot you have to separate the peas from the carrots.
KidSock
So how can you argue that OS's like Windows 2000 are highly crashable when YOU HAVEN'T USED THEM?
Because many Slashdotters work in corporate IT departments where to, their dismay must support, MS Windows in one form or another as it is the primary client delivery platform. This is where the real anger stems. I know because I am a Professional NT Machine Rebooter :~)
It[Windows 2000] crashes very infrequently -- about as often as my Linux box (once every 4 weeks), and only when I'm deliberately trying to crash it, like running Unreal
I doubt your Linux box is "crashing". It's the X server thats crashing. If you telnet in you can restart X and if you wait long enough I believe X will automatically restart(although it will not restore your current session, you will have to re-login). This is significantly different from the BSOD.
One of the major reasons why Linux isn't garnering the attention it deserves is because of the zealots who argue without thinking.
Actually, I believe Linux is getting attention it does not deserve and I agree with you on this second part but you have not backed up your arguments too well either.
KidSock
>> What we have is a bloated, buggy, slow monstrosity that makes open source look bad.
> 'Open source' is a style of development, not a specific entity. Mozilla has nothing to do with open source, and everything to do with the developers and the goals of the project. Think about it like this - Mozilla is written largely in an OO language (C++). Does Mozilla's so-called 'failure' make OOP look bad?
It would if OOP was just beginning to gain acceptance in the commercial world as is open source. Besides, splitting hairs doesn't matter. Management will still stay "no, we will not open-source our project. Look at what happend to Mozilla."
KidSock
The Linux world needs a coherent vision of component software. Shell pipes aren't good enough. Neither is the duct-tape world of Perl. If the Linux world had such a vision, the open-source community could write to it and make real progress. But it's very hard to retrofit architecture.
Right on the money brother. Librarify everything and then your apps are small programs that use a collection of well defined interfaces. The same interfaces would be used by other applications in the system. The rendering engine should be in a ansi c portable shared library. The drawing routines for the windowing system would be abstracted into a common set of interfaces making gui libraries portable. The browser would use a shared library for accessing http resources, or ftp, nfs, smb, smtp etc. Programs would be small. The interfaces would not only abstract the implementation from the caller but also the developers of the libraries. This is perhaps the most important because people can work on their individual pieces of code without worring about dependancies.
Reduce everything to primitives and freeze it into high quality shared libraries.
KidSock
However, on a properly configured network most people will be properly isolated from seeing most traffic due to switching. I used to be on a very busy hub. I could see pretty much everything. It was very interesting. After they got more connections installed to get rid of the hub we all went to the switch. Now I only see stuff for me and broadcast stuff.
As a side note, I have to say the Ethereal packet analyser is one of the best peices of open source software I have ever seen. I think there's a lot of crappy open source stuff out there that gets a lot more credit then it deserves but Ethereal is excellent and does not suffer from these problems as far as I can tell. It doesn't get every packet right and occationally it crashes but it's not 1.0 yet. I have been using it for some time to reverse engineer the CIFS protocol(Microsoft Windows native file and print sharing protocol) and it works fantastic. It basically made the project possible. I have spend probably _hundreds_ of hours in front of it.
http://www.zing.org
Thanks Richard!
KidSock