I have changed my capslock key to be control on both windows and unix. So, I never have to leave the home row to enter an escape character.
Having started computing on a similar keyboard to what you must have, I've also been tempted to remap my keyboards to switch control and caps-lock. As blasphemous as it sounds, I think I like it better the way it is on PC keyboards. I have fairly large hands, so to hit ctrl I just have to "mash" down with the edge of my left palm. Since the ctrl key is right on the corner of the keyboard, I can hit it consistently and accurately.
The most useful remapping I've done on my keyboard, though, is switching [ to { and ] to }. This speeds things up quite nicely in C-syntax based languages.
I actually just bought a Handspring Visor (Neo), and haven't had any real problems in Windows 2000. The software installed ok, and it synced. The only real difficulty I had was syncing mail. For some reason I couldn't (and still cannot) get it to play nicely with my imap server, regardless of which mail program I tell it to use.
Of course, this isn't really relevant for me, as it seems to work flawlessly in Linux. Once properly configured, pilot-mailsync does my email without a single complaint, and even malsync allows me to play with AvantGo. Command-line utilities like these might not be the nicest for novices, but they allow me to selectively sync only one thing, saving time and batteries in the process.
Unfortunately, the fact that the USB cradle identifies itself to the kernel only when the HotSync button is pressed means that I have to time the button press and running a sync utility, but that's no huge difficulty. Perhaps this is also the reason windows sometimes has problems if the drivers aren't installed right?
I think the problem isn't that you're losing interest in CS, but that it has taken over your life. If you spend almost all of your time doing a single thing, you *will* get bored and frustrated with it, and eventually lose all motivation. You need to "diversify your portfolio" a bit. There's a bunch of things you can do to do this:
Academics: Take an extra year and do a minor. Chances are you've already got most of the prerequisites for something way off your field, like biology or english. You'll learn something new and interesting, and possibly even pick up a new skillset. Besides, it sounds cool to say that you've mastered two completely unrelated fields.
Time Off: Take a weekend, week, month or year off; whatever you can afford to get away for. In that time *DON'T TOUCH A COMPUTER*. Don't even bother with email. It also helps to get away from where you're doing most of your work. This could be a trip to another continent, or just to the next town over.
Hobbies: Non-geeky hobbies are great for "fixing your head", I've found, especially if they're somewhat physical. Get a bike-- mountain biking is a brilliant quick fix if there are trails near where you live, or since winter is coming, go skiing. Hell, even a quick run (as much as I hate running) will put things into perspective sometimes, especially if done on a cool, crisp fall evening.
Of course there's always the weeklong bender of booze and drugs, but that's just not that healthy...
Now go! Turn of the computer and get away from Slashdot! There's hope for ya yet!
Unfortunately not by default, but this can be set on a per-toolbar basis (right-click and the menu is pretty self-explanatory), or globally (I believe) in the control panel.
ridiculously small buttons [...] icons that are so small
This can also be configured in the control panel, although it again is neither default nor exceptionally easy to accomplish.
While I don't think your examples are necessarily the best ones, I totally agree that there are some serious usability issues present in KDE. Some of these are the result of heavily borrowing from the MS Windows interface (the multi-level hierarchical Start/K menu and the task bar come to mind). Many other issues, such as menu and dialog inconsistencies, are the result of either flawed standards documents or developers occasionally ignoring them.
I'm not sure what the issues are that are affecting usability improvements in KDE. Hopefully they *are* being resolved, and we'll see some improvements in teh next versions.
Other lesser-known product like Qunata, Kate and KXML are starting to show real promise. I would like Kate in particular to really catch fire like Emacs has over the years - its time for an editor that it totally integrated with its visual environment.
I've been using Kate more and more in the last while. While it has its quirks and a few bugs (which I'll pass on to bugs.kde.org!), it seems to have a feature set that's "compatible" with the way I work.
Of course, it is kind of strange knowing a *person* named Kate, and seeing the menu choices "About Kate" and "Configure Kate"...
Re:A great example of open-source at work.
on
Five Years of KDE
·
· Score: 3, Insightful
This is a really unfair comparison.
I couldn't agree more. There are very few (if any) paid KDE developers. Basically all of the work that went into producing KDE was done for free by people on their own time. Considering that Microsoft pays its Windows developers, they don't have to work another job at the same time, and there are quite a few more of them, I'd say it's even *more* remarkable that KDE has come as far as it has in such a short timeframe.
Sigh... If you don't want to see Jon Katz stories, don't! It's very easy. Click here, scroll down to where you can exclude authors from the homepage, check the third box down, hit save at the bottom, and you'll never have to see one of his stories again.
Of course, that makes posting trolls in response to his stories all that much harder...
When you starrt [sic] the Java VM you have to compile bytecode for native operation for performance even close to fast. That's a complicated and time consuming process, and in the end you have to wait far too long on older machines before your applet is running
Not exactly. The two major speed issues with running Java applications are:
the startup time of the JVM before the bytecode starts running (or is even loaded)
the speed of the GUI libraries (AWT & Swing)
The first one is a pain-in-the-ass, especially for small applets or applications that don't do much themselves; why should a seemingly insignificant applet take a long time to start? The second one is the main reason why people consider Java to be "slow". It is (hopefully) being addressed in the next version of Java, although this won't help most browsers that use a version of Java that's several years old.
Those issues aside, Java is actually a relatively quick language. Using such tricks as just-in-time compilation to native code (this is done as the bytecode is running, and uses various code profiling techniques), the speed of a java program can approach that of a natively compiled one.
The only time where it is possible to put logic on a client and get reliable performance is where you have complete control of the client's software and hardware - i.e. a closed computing environment.
I'd say that this is a fairly accurate descripion of the abstraction provided by a virtual machine for a language-- i.e. Java's JVM. While the JVM runs on many different hardware platforms, it provides a closed computing environment with a reasonably fixed set of APIs across all platforms it runs on. Performance (i.e. execution speed) does differ across the different speeds of the underlying host cpu, but this is also the case for natively compiled applications.
As far as the four points you make go, I think they are all valid. Java (as an applet language) does a reasonable job of addressing the first three (security, compatability and portability). The fourth (separation of presentation and logic) is really up to the designer of the system to do in a sane way.
... The only major drawback is that you must use AWT and/or JFC bindings to get anything on the screen.
I'm not sure about Jython or Scheme, but Java applets can communicate back to the browser window and use it to render html that they generate. In many cases, this is a much more appropriate way of displaying things on the screen, and isn't quite as ugly looking as AWT can be.
In this case, the applet *is* the plugin. Simply write your "applet" using the plugin API of the given browser, compile for whichever platform you want, and there ya go!
Of course, a much more "interesting" solution to this would be to write a browser plugin that contains gcc/g++ and all appropriate libraries. Your applet would then just be C or C++ source code, and when downloaded, the plugin would compile and run it for you! In addition, you'd be able to run your applets on any platform that you ported your plugin to. Aside from the obvious security issues with untrusted C/C++ code, and the *size* that this plugin would be, you have to admit, it'd be a very hack-worthy thing to do!
Matching that checksum will only show other people that their download is identical to yours. If you're concerned about someone having uploaded a file to an ftp server that has some form of a trojan embedded, you really need the md5 from the original distributor. Of course you need some way of verifying that the sum you get there is actually *from* there, but that might be just a tad neurotic for a game demo!
I'd say there's nothing to worry about in most of North America and Europe. We've got some reasonable laws requiring the inspection of meat at slaughterhouses, so the risk is minimal. Your biggest risk is probably contracting some form of E. coli due to poor meat handling at restaurants etc.
Oh, *computer* worms. Well, that's a bit different...
I think that it would be *possible* to write a worm targetting Linux machines right now, but it probably could never spread as quickly as the recent MS-specific worms we've seen. Even though many (most?) Linux distributions come with some relatively serious security flaws out-of-the-box, Linux is still a "geek OS". The average Linux user hopefully knows enough to apply most of the critical security updates, and won't be running too many unneeded services. Add to that the fact that while growing, there still aren't *that* many systems out there running Linux, and I'd say that the density of vulnerable Linux boxes out there is so low that a worm would have a difficult time spreading.
As far as the future goes, though, unless the various distributors become more and more security conscious (I believe that they are doing this), we may be at risk. Doing such things as running potentially vulnerable services as their own userid, turning off unneeded ones, and only opening ports with an actual service that needs it open to the outside may seem like common sense to hopefully all of us, but these are things that distributions should automatically do for the newbie users.
a 0.0.1 point increase? well whoopty fucking do, I use KDE and I don't really care, call me next time they do a 0.1 update cuz no one really cares, this isn't the freakin kernel here
Heh. While unintentional, I think that was actually a pretty big compliment for the kde developers. Why do you ask? Well, this 0.0.1 increment is actually a bug fix release. Since you (and I'm sure the sentiment is shared by many others) don't see the need to download this, that goes to show that the previous 2.2 release was actually quite stable and significantly bug free!
Personally, I'd tend to agree with you-- almost. I've found 2.2 to be *very* stable, and use it as my desktop. That said, there still were a few tiny little bugs and quirks that occasionally bothered me, so I'll probably grab 2.2.1 when I've got time.
Don't bother. The likelyhood that you'll see a second hit from an infected box that's already hit you is practically zero. If you *manually* add a rule to your firewall for every host, you'll be so busy you'll go insane within the hour. If you've got a script doing it, you'll have so many rules that the performance of your firewall will take a hit, and your table of rules will become so cluttered that when you do a cleanout you'll probably have to start from scratch again.
Ipchains/iptables can do all kinds of things based on where the packet is from, and where it's going, but it doesn't show you any information on what exactly it contains. Without running a webserver, you *can* use ipchains to log connection attempts to port 80. If you've never run a webserver, you can be pretty sure that almost all connections made will be from one of the various worms (Code Red variants and this new one), but there's no way of telling for sure.
Why not just use ssh port forwarding (tunneling) to connect to the remote mail server? If the boxes dialing in to the isp are some variant of unix, it's as simple as:
ssh -l user@host -L localport:mailserver:25
and then configuring the client software to connect to the localhost at localport for sending mail. Most windows ssh clients will let you do the same thing (somehow).
Of course, this is assuming that the mail server you're wanting to connect to is actually *yours*, or at the least you can get it set up to allow incoming ssh and port forwarding. If it all works, though, as an added bonus all of your communication between the dialup host and your mail server will be encrypted.
Ah, but in each of your three examples, Open Source is not the business model in and of itself, but rather something loosely tied *to* the business model.
If you're selling a service that supports or interacts with Open Source software, your business model is essentially to sell that service for money. The fact that *what* you are supporting has been Open Sourced is essentially a small footnote to that. You may not have to deal with as many licensing issues (or at least different ones) when you actually implement your service, but this should just be a small side bar if you're being intelligent about it.
In contrast, though, I think that closed source software can be and *is* a business model. You develop it, and then you sell the rights allowing people to use it. Simple enough. Of course you can also develop other business models on top of this that are essentially the same as those you'd have for Open Source software.
What about some company or another making some 486 CPUs with the latest.13micron technology, and making a highly integrated motherboard with 8 or so megs of ram on it plus another 4 or so megs of static ram for application storage purposes and calling it one kick ass integrated computer?
Substitute an architecturally more modern CPU for "486" in that, add a touch LCD screen, and you've got a PDA. It's been done, and probably been done better than it would be using a 486.
Why would a dnet client written in asm for this OS be substantially faster than one written in asm for another (non asm) OS? The only speedup would be in calls made to OS functions, and a program that's highly computationally bound isn't going to be making to many of those.
If you want your dnet client to run at its absolute possible fastest, you're best off doing away with the whole OS business in its entirety. A non-multitasking environment such as good ol' DOS would probably be best for that.
Re:Can we move on to the next level please?
on
MenuetOS Debuts
·
· Score: 2
Your post seems to indicate that you believe that there is an OS "war" going on, with separate camps struggeling for world (or at least computer) domination. While I think this is true (to an extent) for commercial systems that compete directly with one another, I think it's pretty silly to generalize it to Linux, other Open Source OSs, and niche systems.
Systems basically appear randomly when someone's pet project becomes stable enough to appear on the/. radar, or when a company tries something new, thinking they've found a new niche market to make some money in. If they are crap (many are), they will just go away after a period of time. If they do what they were designed for well (assuming there was some form of design involved), they fill their niche. A select few grow in strength, and as their popularity and abilities grow, their "population" increases.
The analogy I'm trying to draw is one with evolution (as you may have guessed). Random mutations create new organisms. Most mutations are detrimental, and the organism dies (or never makes it past the embryo stage). Others confer some form of advantage, and presto, you have a platypus. Of course whether the penguin is an animal with just a small niche or the potential to become the dominant species remains to be seen!
My point is, though, that just like in evolution, there is no predestined goal of "domination", or a conscious quest for survival. The best we can do is introduce some new mutations and do a little bit of genetic engineering on our favourite uh... OS, and hope for the best.
Slashdot Mirror
I have changed my capslock key to be control on both windows and unix. So, I never have to leave the home row to enter an escape character.
Having started computing on a similar keyboard to what you must have, I've also been tempted to remap my keyboards to switch control and caps-lock. As blasphemous as it sounds, I think I like it better the way it is on PC keyboards. I have fairly large hands, so to hit ctrl I just have to "mash" down with the edge of my left palm. Since the ctrl key is right on the corner of the keyboard, I can hit it consistently and accurately.
The most useful remapping I've done on my keyboard, though, is switching [ to { and ] to }. This speeds things up quite nicely in C-syntax based languages.
My "headlines parser" did the same thing. You know it's time for coffee when...
I actually just bought a Handspring Visor (Neo), and haven't had any real problems in Windows 2000. The software installed ok, and it synced. The only real difficulty I had was syncing mail. For some reason I couldn't (and still cannot) get it to play nicely with my imap server, regardless of which mail program I tell it to use.
Of course, this isn't really relevant for me, as it seems to work flawlessly in Linux. Once properly configured, pilot-mailsync does my email without a single complaint, and even malsync allows me to play with AvantGo. Command-line utilities like these might not be the nicest for novices, but they allow me to selectively sync only one thing, saving time and batteries in the process.
Unfortunately, the fact that the USB cradle identifies itself to the kernel only when the HotSync button is pressed means that I have to time the button press and running a sync utility, but that's no huge difficulty. Perhaps this is also the reason windows sometimes has problems if the drivers aren't installed right?
I think the problem isn't that you're losing interest in CS, but that it has taken over your life. If you spend almost all of your time doing a single thing, you *will* get bored and frustrated with it, and eventually lose all motivation. You need to "diversify your portfolio" a bit. There's a bunch of things you can do to do this:
Academics: Take an extra year and do a minor. Chances are you've already got most of the prerequisites for something way off your field, like biology or english. You'll learn something new and interesting, and possibly even pick up a new skillset. Besides, it sounds cool to say that you've mastered two completely unrelated fields.
Time Off: Take a weekend, week, month or year off; whatever you can afford to get away for. In that time *DON'T TOUCH A COMPUTER*. Don't even bother with email. It also helps to get away from where you're doing most of your work. This could be a trip to another continent, or just to the next town over.
Hobbies: Non-geeky hobbies are great for "fixing your head", I've found, especially if they're somewhat physical. Get a bike-- mountain biking is a brilliant quick fix if there are trails near where you live, or since winter is coming, go skiing. Hell, even a quick run (as much as I hate running) will put things into perspective sometimes, especially if done on a cool, crisp fall evening.
Of course there's always the weeklong bender of booze and drugs, but that's just not that healthy...
Now go! Turn of the computer and get away from Slashdot! There's hope for ya yet!
They still don't label toolbar buttons.
Unfortunately not by default, but this can be set on a per-toolbar basis (right-click and the menu is pretty self-explanatory), or globally (I believe) in the control panel.
ridiculously small buttons [...] icons that are so small
This can also be configured in the control panel, although it again is neither default nor exceptionally easy to accomplish.
While I don't think your examples are necessarily the best ones, I totally agree that there are some serious usability issues present in KDE. Some of these are the result of heavily borrowing from the MS Windows interface (the multi-level hierarchical Start/K menu and the task bar come to mind). Many other issues, such as menu and dialog inconsistencies, are the result of either flawed standards documents or developers occasionally ignoring them.
I'm not sure what the issues are that are affecting usability improvements in KDE. Hopefully they *are* being resolved, and we'll see some improvements in teh next versions.
Other lesser-known product like Qunata, Kate and KXML are starting to show real promise. I would like Kate in particular to really catch fire like Emacs has over the years - its time for an editor that it totally integrated with its visual environment.
I've been using Kate more and more in the last while. While it has its quirks and a few bugs (which I'll pass on to bugs.kde.org!), it seems to have a feature set that's "compatible" with the way I work.
Of course, it is kind of strange knowing a *person* named Kate, and seeing the menu choices "About Kate" and "Configure Kate"...
This is a really unfair comparison.
I couldn't agree more. There are very few (if any) paid KDE developers. Basically all of the work that went into producing KDE was done for free by people on their own time. Considering that Microsoft pays its Windows developers, they don't have to work another job at the same time, and there are quite a few more of them, I'd say it's even *more* remarkable that KDE has come as far as it has in such a short timeframe.
Sigh... If you don't want to see Jon Katz stories, don't! It's very easy. Click here, scroll down to where you can exclude authors from the homepage, check the third box down, hit save at the bottom, and you'll never have to see one of his stories again.
Of course, that makes posting trolls in response to his stories all that much harder...
Not exactly. The two major speed issues with running Java applications are:
- the startup time of the JVM before the bytecode starts running (or is even loaded)
- the speed of the GUI libraries (AWT & Swing)
The first one is a pain-in-the-ass, especially for small applets or applications that don't do much themselves; why should a seemingly insignificant applet take a long time to start? The second one is the main reason why people consider Java to be "slow". It is (hopefully) being addressed in the next version of Java, although this won't help most browsers that use a version of Java that's several years old.Those issues aside, Java is actually a relatively quick language. Using such tricks as just-in-time compilation to native code (this is done as the bytecode is running, and uses various code profiling techniques), the speed of a java program can approach that of a natively compiled one.
The only time where it is possible to put logic on a client and get reliable performance is where you have complete control of the client's software and hardware - i.e. a closed computing environment.
I'd say that this is a fairly accurate descripion of the abstraction provided by a virtual machine for a language-- i.e. Java's JVM. While the JVM runs on many different hardware platforms, it provides a closed computing environment with a reasonably fixed set of APIs across all platforms it runs on. Performance (i.e. execution speed) does differ across the different speeds of the underlying host cpu, but this is also the case for natively compiled applications.
As far as the four points you make go, I think they are all valid. Java (as an applet language) does a reasonable job of addressing the first three (security, compatability and portability). The fourth (separation of presentation and logic) is really up to the designer of the system to do in a sane way.
... The only major drawback is that you must use AWT and/or JFC bindings to get anything on the screen.
I'm not sure about Jython or Scheme, but Java applets can communicate back to the browser window and use it to render html that they generate. In many cases, this is a much more appropriate way of displaying things on the screen, and isn't quite as ugly looking as AWT can be.
How about a browser plugin for C/C++ apps?
In this case, the applet *is* the plugin. Simply write your "applet" using the plugin API of the given browser, compile for whichever platform you want, and there ya go!
Of course, a much more "interesting" solution to this would be to write a browser plugin that contains gcc/g++ and all appropriate libraries. Your applet would then just be C or C++ source code, and when downloaded, the plugin would compile and run it for you! In addition, you'd be able to run your applets on any platform that you ported your plugin to. Aside from the obvious security issues with untrusted C/C++ code, and the *size* that this plugin would be, you have to admit, it'd be a very hack-worthy thing to do!
Matching that checksum will only show other people that their download is identical to yours. If you're concerned about someone having uploaded a file to an ftp server that has some form of a trojan embedded, you really need the md5 from the original distributor. Of course you need some way of verifying that the sum you get there is actually *from* there, but that might be just a tad neurotic for a game demo!
I'd say there's nothing to worry about in most of North America and Europe. We've got some reasonable laws requiring the inspection of meat at slaughterhouses, so the risk is minimal. Your biggest risk is probably contracting some form of E. coli due to poor meat handling at restaurants etc.
Oh, *computer* worms. Well, that's a bit different...
I think that it would be *possible* to write a worm targetting Linux machines right now, but it probably could never spread as quickly as the recent MS-specific worms we've seen. Even though many (most?) Linux distributions come with some relatively serious security flaws out-of-the-box, Linux is still a "geek OS". The average Linux user hopefully knows enough to apply most of the critical security updates, and won't be running too many unneeded services. Add to that the fact that while growing, there still aren't *that* many systems out there running Linux, and I'd say that the density of vulnerable Linux boxes out there is so low that a worm would have a difficult time spreading.
As far as the future goes, though, unless the various distributors become more and more security conscious (I believe that they are doing this), we may be at risk. Doing such things as running potentially vulnerable services as their own userid, turning off unneeded ones, and only opening ports with an actual service that needs it open to the outside may seem like common sense to hopefully all of us, but these are things that distributions should automatically do for the newbie users.
a 0.0.1 point increase? well whoopty fucking do, I use KDE and I don't really care, call me next time they do a 0.1 update cuz no one really cares, this isn't the freakin kernel here
Heh. While unintentional, I think that was actually a pretty big compliment for the kde developers. Why do you ask? Well, this 0.0.1 increment is actually a bug fix release. Since you (and I'm sure the sentiment is shared by many others) don't see the need to download this, that goes to show that the previous 2.2 release was actually quite stable and significantly bug free!
Personally, I'd tend to agree with you-- almost. I've found 2.2 to be *very* stable, and use it as my desktop. That said, there still were a few tiny little bugs and quirks that occasionally bothered me, so I'll probably grab 2.2.1 when I've got time.
Argh! I'm just firewalling them off as they hit.
Don't bother. The likelyhood that you'll see a second hit from an infected box that's already hit you is practically zero. If you *manually* add a rule to your firewall for every host, you'll be so busy you'll go insane within the hour. If you've got a script doing it, you'll have so many rules that the performance of your firewall will take a hit, and your table of rules will become so cluttered that when you do a cleanout you'll probably have to start from scratch again.
Ipchains/iptables can do all kinds of things based on where the packet is from, and where it's going, but it doesn't show you any information on what exactly it contains. Without running a webserver, you *can* use ipchains to log connection attempts to port 80. If you've never run a webserver, you can be pretty sure that almost all connections made will be from one of the various worms (Code Red variants and this new one), but there's no way of telling for sure.
18/Sep/2001:06:16:18 -0700 here in Vancouver.
Oh wait, that's haptically, not hepatically...
Why not just use ssh port forwarding (tunneling) to connect to the remote mail server? If the boxes dialing in to the isp are some variant of unix, it's as simple as:
ssh -l user@host -L localport:mailserver:25
and then configuring the client software to connect to the localhost at localport for sending mail. Most windows ssh clients will let you do the same thing (somehow).
Of course, this is assuming that the mail server you're wanting to connect to is actually *yours*, or at the least you can get it set up to allow incoming ssh and port forwarding. If it all works, though, as an added bonus all of your communication between the dialup host and your mail server will be encrypted.
Ah, but in each of your three examples, Open Source is not the business model in and of itself, but rather something loosely tied *to* the business model.
If you're selling a service that supports or interacts with Open Source software, your business model is essentially to sell that service for money. The fact that *what* you are supporting has been Open Sourced is essentially a small footnote to that. You may not have to deal with as many licensing issues (or at least different ones) when you actually implement your service, but this should just be a small side bar if you're being intelligent about it.
In contrast, though, I think that closed source software can be and *is* a business model. You develop it, and then you sell the rights allowing people to use it. Simple enough. Of course you can also develop other business models on top of this that are essentially the same as those you'd have for Open Source software.
What about some company or another making some 486 CPUs with the latest .13micron technology, and making a highly integrated motherboard with 8 or so megs of ram on it plus another 4 or so megs of static ram for application storage purposes and calling it one kick ass integrated computer?
Substitute an architecturally more modern CPU for "486" in that, add a touch LCD screen, and you've got a PDA. It's been done, and probably been done better than it would be using a 486.
Why would a dnet client written in asm for this OS be substantially faster than one written in asm for another (non asm) OS? The only speedup would be in calls made to OS functions, and a program that's highly computationally bound isn't going to be making to many of those.
If you want your dnet client to run at its absolute possible fastest, you're best off doing away with the whole OS business in its entirety. A non-multitasking environment such as good ol' DOS would probably be best for that.
Your post seems to indicate that you believe that there is an OS "war" going on, with separate camps struggeling for world (or at least computer) domination. While I think this is true (to an extent) for commercial systems that compete directly with one another, I think it's pretty silly to generalize it to Linux, other Open Source OSs, and niche systems.
/. radar, or when a company tries something new, thinking they've found a new niche market to make some money in. If they are crap (many are), they will just go away after a period of time. If they do what they were designed for well (assuming there was some form of design involved), they fill their niche. A select few grow in strength, and as their popularity and abilities grow, their "population" increases.
Systems basically appear randomly when someone's pet project becomes stable enough to appear on the
The analogy I'm trying to draw is one with evolution (as you may have guessed). Random mutations create new organisms. Most mutations are detrimental, and the organism dies (or never makes it past the embryo stage). Others confer some form of advantage, and presto, you have a platypus. Of course whether the penguin is an animal with just a small niche or the potential to become the dominant species remains to be seen!
My point is, though, that just like in evolution, there is no predestined goal of "domination", or a conscious quest for survival. The best we can do is introduce some new mutations and do a little bit of genetic engineering on our favourite uh... OS, and hope for the best.