I haven't seen a stable version of Netscape/Mozilla since 3.x; Communicator crashes on me three or four times a day. I'll be happy to have access to something that doesn't make me feel like I'm using a Windows application.
That said, I use Communicator because it's reasonably fast and supports SSL. It seems to be the best browser, even with all its faults, available to Linux users. That doesn't keep me from cursing when it crashes:-)
Higher resolution would definately increase saleability.
For example, I'm a very amature photographer. In this respect, I'd say I'm similar to about 30 percent of the camera owners on the planet, the rest are either professional or advanced amatures, or don't use their cameras for more than memorabilia photographs.
What I do do is take a lot of really bad pictures; every once in a great while, though, one will turn out really well -- something I'd consider marketable, it is so good. When this happens, I want to be able to blow it up to a 14" or so print and maybe frame and hang it.
The problem is that the digital camera I have is great for snapshots, but if I happen to ever take that one special picture with it, I won't be able to blow it up.
I don't think that the niche I'm in is that small. I'm sure there are a very many people out there who are like me. A decent resolution digital camera, one that will let me have a photo printed at a larger size with no noticeable pixelization would be a godsend.
I really want one of the 3.3 megapixels; the CoolPix looks good. I have an older 900, and my only real complaint is that it takes forever to cycle, and even longer to turn on. What with the battery drain, this is a terrible combination of "features". It should have a standby mode that it goes into rather than turning off after the timeout period.
In any case, I'm not buying a newer camera until I can find one that has decent resolution and a fast cycle period. Has anybody bought a 2Mp or greater camera with a reasonably small amount of cycle time between photos?
Esperanto has a couple of valid claims that make it a better choice as an international language. The first is that, all things being equal, it is easier to learn than any other language. This claim assumes the obvious point that "any other" doesn't include languages which are extremely similar to, or derivatives of, your native language. The second claim is that Esperanto is relatively "neutral", in that it isn't the native language of any nation; therefore, if everybody spoke it as a second language for international communication, nobody would be at the psychological disadvantage of speaking to someone in their native language.
Case in point: Americans have this perception of Arnold Schwarzenegger, Jean-Claude Van Damme, Claudia Schiffer, and Nina Hagen as being dumb; this perception may or may not be accurate, but much of the perception is due to the fact that these people speak imperfect english, or speak it with an accent. The native speaker always has a psychological edge.
Esperanto has 16 grammatical rules, and no exceptions. It is highly regular, avoids noun genders, and all verbs are conjugated exactly the same way. It is very easy for Westerners to learn, and easier than any Western language for Easterners. There are, at last count, over 2 million Esperanto speakers, although this estimate is admittedly optimistic, as most "Esperanto speakers" have limited experience actually speaking the language. This means that about one in every 3000 people has some working knowledge of Esperanto.
Esperanto needs much wider acceptance before it can became a linga franca; English, at the moment, enjoys that status. However, as most Slashdotters would agree, just because something is the de-facto standard, doesn't mean either that it is the best choice, or that it should remain the standard, eg. Windo[(ws)(ze)].
Esperanto can be learned so rapidly, that if you have any interest at all, I recommend that you check it out. You can get a working knowledge good enough read the usenet groups or participate in the IRC rooms within a couple of weeks of regular study (an hour). There is even a free 10-lesson email course with tutors which provides all of the foundation you need to start communicating. The Esperanto community is, in a lot of ways, much like the Open Source community, and I'm constantly suprised that I don't see more cross-polination between the two groups. You will notice, however, that KDE comes with fairly extensive Esperanto language support.
Even TravelLang has an English/Esperanto translator, and some of their translation software uses Esperanto as the medium language, much as XML can be used as a many-to-many point of translation.
No kidding. Here's a really good example: while I was living in Munich, I heard a joke told by Austrians about Bavarians. The joke relied on the fact that Bavarians tell a lot of jokes about Austrians, which in turn relied on the knowledge that there is a perception in Bavaria that Austrians are stupid, which in turn is based on the sound of the Austrian accent. I heard quite a few of those kinds of jokes while I was there. Still, all in all, I didn't find the day-to-day communication relying so much on contextual culture knowledge that it was really a problem.
This is the sort of technology which we both dread and anticipate. Self-driven cars, (more) intelligent houses, home security, smarter traffic signals... all of the spin-off products from something like this would be great to have around.
On the other hand, this could also be the basis for technology that tracks where you go and what you do. Under the auspices of controlling crime, criminals could be "flagged" and watched, traffic policing could be automated, etc. Where it gets scary is in who determines what suspicios behavior is, or who qualifies as needing to be watched, or the fact that you are removing the human element from the decision making process of evaluating a crime.
In the end, both the citizens and the govornment want this kind of pervasive, intelligent, monitoring technology to be ubiquitous. The difference is that citizens want to be able to turn it off.
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 0
Mmmm. You are right; you can change cyphers, but not public key algorithms.
Of course, this will all be moot in September, when the RSA patent expires...
Re:Value added for SRP?
on
SSH v. SRP
·
· Score: 1
Mmmm. You are right; you can change cyphers, but not public key algorithms. <p> Of course, this will all be moot in September, when the RSA patent expires...
There are certain advantages to not requiring a public/private key pair to be lugged around, but also certain disadvantages.
Most importantly, you imply that public/private key authentication is the only way to use SSH, and this is not true. SSH (OpenSSH) allows users to authenticate from arbitrary hosts securely through the normal PAM authentication, so I still don't see the advantage of SRP. Still, if you allow this sort of authentication, SSH becomes less secure, for reasons which I outline below.
The downside of using a passphrase as the authentication mechanism is that it is inherantly weaker than using public/private keys. If a private key is stored encrypted, the system is more secure by nature of requiring both physical access to the private key, and access to the passphrase by which it is encrypted. If you are using a passphrase authentication mechanism and I somehow get your passphrase, you are screwed; I have access to all systems where you use that passphrase. However, if you somehow get my passphrase, and I'm using public/private keys, you *still* have to somehow get ahold of my private key to authenticate yourself as me. Similarly, just grabbing my encrypted private key isn't enough, because you can't decrypt and use the key without my passphrase.
OpenSSH does solve the SSH1 protocol security issues. Check their website.
SRP hasn't been around nearly as long as SSH, and hasn't been as severely scrutinized for weaknesses, so it doesn't mean much to say that no weaknesses have yet been found. Only time will tell.
As far as I can see, SRP provides no functionality that isn't already present in SSH. In the interest of full disclosure, I'll state that I don't have anything to do with any SSH project, although I do use OpenSSH. When I speak of SSH below, I'm speaking of OpenSSH in particular.
From a purely technical point of view, SSH, when using public key cryptography, is as secure as SRP. In the following list, I don't claim that SRP doesn't do any of these things; I'm merely clarifying what SSH does do.
SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.
SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.
Authentication is done either with public/private keys or with a server side authentication mechanism, such as PAM. In the second case, any passwords or other information is transmitted encrypted, and so is secure. In the first case, the password is never transmitted and there is no chance of the user's password on the server being compromised through SSH. The user's password is never used to encrypt a session.
OpenSSH, OpenSSL, and LSH are all open source, non-commercial projects.
SSH allows securing of arbitrary ports, and provides extensive port forwarding capabilities. Therefore, any service on a server running SSHD can be secured, as long as the client program can alter the port of the service it is requesting. As an example, to secure an IMAP connection, one would issue: ssh -L 1442:servername:143 servername and then connect with their email client to localhost:1442.
Although most users of OpenSSH are unaware of the fact, OpenSSL, which is required for OpenSSH, provides a powerful tool for dealing with X.509 certificates. With OpenSSL, you can encrypt, generate hashes, generate certificates, generate certificate requests, and perform a large number of other security-related actions. OpenSSL documentation is extremely sparce, and due to the complexity of X.509, using OpenSSL tools can be difficult; this is probably the primary reason why most people are oblivious to OpenSSL capabilities.
OpenSSL is the basis for a number of port wrapping tools, such as sslwrap. With these tools, you can provide secure sockets to services such as HTTP, IMAP, telnet, and POP. Many clients, such as Netscape, understand secure sockets, and several ports are defined as "well known ports" for these secure services. (EG: IMAP's secure port is 993, and Netscape Communicator knows and can take advantage of this).
Using public keys with SSH simplifies accessing services, so that 'ssh' and 'scp' are as easy to use as 'rsh' and 'rcp'. This is slightly less secure on a shared client, because the private key is held in the client memory during a login session, and is subject to core dump attacks. If the client machine is not shared, this is not an issue.
OpenSS[HL] doesn't require using RSA algorithms; in fact, you can choose from any number of non-commercial algorithms.
The SRP site claims that there are several "advantages" to using SRP, but never says what these advantages are in relation to. In particular, the SRP site does not claim that SRP is more secure than SSH. SRP is certainly more secure that vanilla telnet, but I see no advantage to using SRP over SSH. The obvious advantage to using SSH over SRP is that SSH is ubiquitous, and well tested.
Please, if anyone knows any way in which SRP is superior to SSH, I'd like to know.
This kind of feedback is what will really make the difference. The actual product at this stage may not be terribly innovative, but from all accounts, the people at the company are very responsive.
Regarding complaints that the robot isn't smart enough... this is a software issue, and since Probotics are making the API available, I don't see any reason why you couldn't write a driver that updates the map as it encounters obsticals.. Remember, the Cye does provide feedback to the base when it encounters an obstical; it just doesn't have a ranged sensor. The Cye can be as intelligent as you want it to be.
I'm enthusaistic about this. This is basically a real-life robot-wars situation, where you can program your own behavior. If there were a USB port on the Cye mobile unit that could communicate with the base via the radio, then the Cye would have limitless possibility for expansion; robot-arm attachments, light and audio sensers... I can't believe Probotics doesn't have these improvements planned.
The artical seems to be dated, and relies a lot on this concept that one has to change physical keyboards to use Dvorak, which isn't true. KDE makes it trivial to change keyboard layouts on the fly. I haven't seen a modern OS that won't let you change keyboard layouts easily, and most come with Dvorak. Therefore, there isn't much reason for people to not learn Dvorak, when they're first learning to type. I attribute the lack of Dvorak dominance to ignorance and laziness.
I think I type faster in Dvorak, if for no other reason than I make fewer typos. I know it is more comfortable than QWERTY. Since I haven't kept up practicing QWERTY, I have to hunt'n'peck when I use a QWERTY layout.
What the heck were you testing? On the standard two-handed DVORAK keyboard layout (there are one-handed layouts as well), of your test sentance, the right hand types:
The growthrate doesn't suprise me, because I don't understand the need for fetchmail in the first place. Everybody I know uses IMAP to access their email; if I downloaded my mail onto a non-server, I'd be crippled. I'm suprised that there are so many people using fetchmail, since it implies that:
These people access their email from exactly one computer, or
These people are content with only having access to their email from one computer.
Now, I know most Linux hackers are C programmers or scripters, but Java is far from being dead, as is far from having failed. There are 1.7 million Java programmers, according to the Boston Globe artical, and 399,000 Linux hosts on the net, according to the April RIPE host count. You can double the Linux count and halve the Java count and still ask whether, if Java is dead, what is Linux?
Java wasn't intended to kill Windows; it still needs an OS to run on top of. As a result, it provides as much advantage to Windows as it does to any other OS. The hope was that Java would provide a mechanism for software houses to produce software that would run on any platform, and thereby give other OSes a chance to fight on a level playing field. It isn't up to Java to defeat MS; it is up to other OSes. Whether the Java language itself is better than any other language is a mostly matter of taste and is an issue of debate for computer theorists; however, many of the features of Java, which are lacking in C or C++, and many of the features that are lacking in Java which are present in C and C++, make developing Java applications easier.
Maybe Java isn't as popular among Linux users because we have the slowest virtual machines of any platform. At our development we use several Java applications in our development suite, and on the Windows NT machines these applications are scarcely slower than native apps. Most importantly, I can use the same apps on my Linux development machine; if it weren't for Java, I'd have to run Windows to be consistent with the other non-Linux developers, so I, for one, am grateful to Java for allowing me to use the OS of my own choice.
It is a mistake to claim that Java has failed or is dead, and a disservice to fail to recognize what opportunities the Java platform has provided anybody who wants freedom to choose their OS.
Now, I know most Linux hackers are C programmers or scripters, but Java is far from being dead, as is far from having failed. There are 1.7 million Java programmers, according to the Boston Globe artical, and 399,000 Linux hosts on the net, according to the April RIPE host count. You can double the Linux count and halve the Java count and still ask whether, if Java is dead, what is Linux? Java wasn't intended to kill Windows; it still needs an OS to run on top of. As a result, it provides as much advantage to Windows as it does to any other OS. The hope was that Java would provide a mechanism for software houses to produce software that would run on any platform, and thereby give other OSes a chance to fight on a level playing field. It isn't up to Java to defeat MS; it is up to other OSes. Whether the Java language itself is better than any other language is a mostly matter of taste and is an issue of debate for computer theorists; however, many of the features of Java, which are lacking in C or C++, and many of the features that are lacking in Java which are present in C and C++, make developing Java applications easier. Maybe Java isn't as popular among Linux users because we have the slowest virtual machines of any platform. At our development we use several Java applications in our development suite, and on the Windows NT machines these applications are scarcely slower than native apps. Most importantly, I can use the same apps on my Linux development machine; if it weren't for Java, I'd have to run Windows to be consistent with the other non-Linux developers, so I, for one, am grateful to Java for allowing me to use the OS of my own choice. It is a mistake to claim that Java has failed or is dead, and a disservice to fail to recognize what opportunities the Java platform has provided anybody who wants freedom to choose their OS.
It is annoying that the most programmer friendly APIs seem to produce the least friendly user friendly interfaces. MUI on the Amiga was, by far, the best GUI API I've ever seen.
I like the design of Swing (for Java). Fresco uses a novel design, but it is slow. GTK is slower than QT, so I prefer QT as a user, but GTK (IMHO) is more attractive.
Overall, I think we can count ourselves lucky that we have such a variety to choose from. The programmers for some OSes don't have the option to choose style over speed, or a nicer API.
I think that MOSIX is a kernel patch. One downloads the 2.2 kernel, downloads the MOSIX changes, and recompiles the kernel. By definition, this is a sourcecode kernel patch. MOSIX isn't a module, but that's different. Also, I do believe that MOSIX works with process threads, and doesn't require any special programming; that is, it will work with all applications, MOSIX-aware, or not.
Yeah, ESR's choice of phraseology was unfortunate. All applications on a Windoze box run, effectively, as root, which makes Windoze systems less secure than Linux. On the other hand, Linux also suffers from root-itis. MVS has a much better system (and I heard someone mention EROS) by which root doesn't exist, and root's functions are distributed among several admin users. What this means is that to compromise an MVS system and erase your tracks, you have to compromise several accounts. On Linux, you only have to compromise 1 account (root). On Windoze, you only have to compromise any one of (potentially) numerous accounts.
Even if this were more than simply a celebration, it wouldn't be suprising. The US of A is the only non-third world country that *still* doesn't use metric, just going to show that you don't have to be French to be obstinate.
At the risk of being redundant, if you'd be so kind as to post your experiences, benchmarks, problems, solutions, and general ORBish information to the linuxorb mailing list, I'll try to format it into a reasonable information sheet for the LinuxOrb web page. You'll have to subscribe to the list before you can post.
Would you email me with more details regarding the problem you had and your solution so that I can add it to the linuxorb web page?
If you'd like to post the information to the linuxorb mailing list, we'd really appreciate it. You'll have to subscribe first, for anti-spam purposes. The relevant email addresses are:
Slashdot Mirror
That said, I use Communicator because it's reasonably fast and supports SSL. It seems to be the best browser, even with all its faults, available to Linux users. That doesn't keep me from cursing when it crashes :-)
For example, I'm a very amature photographer. In this respect, I'd say I'm similar to about 30 percent of the camera owners on the planet, the rest are either professional or advanced amatures, or don't use their cameras for more than memorabilia photographs.
What I do do is take a lot of really bad pictures; every once in a great while, though, one will turn out really well -- something I'd consider marketable, it is so good. When this happens, I want to be able to blow it up to a 14" or so print and maybe frame and hang it.
The problem is that the digital camera I have is great for snapshots, but if I happen to ever take that one special picture with it, I won't be able to blow it up.
I don't think that the niche I'm in is that small. I'm sure there are a very many people out there who are like me. A decent resolution digital camera, one that will let me have a photo printed at a larger size with no noticeable pixelization would be a godsend.
In any case, I'm not buying a newer camera until I can find one that has decent resolution and a fast cycle period. Has anybody bought a 2Mp or greater camera with a reasonably small amount of cycle time between photos?
Case in point: Americans have this perception of Arnold Schwarzenegger, Jean-Claude Van Damme, Claudia Schiffer, and Nina Hagen as being dumb; this perception may or may not be accurate, but much of the perception is due to the fact that these people speak imperfect english, or speak it with an accent. The native speaker always has a psychological edge.
Esperanto has 16 grammatical rules, and no exceptions. It is highly regular, avoids noun genders, and all verbs are conjugated exactly the same way. It is very easy for Westerners to learn, and easier than any Western language for Easterners. There are, at last count, over 2 million Esperanto speakers, although this estimate is admittedly optimistic, as most "Esperanto speakers" have limited experience actually speaking the language. This means that about one in every 3000 people has some working knowledge of Esperanto.
Esperanto needs much wider acceptance before it can became a linga franca; English, at the moment, enjoys that status. However, as most Slashdotters would agree, just because something is the de-facto standard, doesn't mean either that it is the best choice, or that it should remain the standard, eg. Windo[(ws)(ze)].
Esperanto can be learned so rapidly, that if you have any interest at all, I recommend that you check it out. You can get a working knowledge good enough read the usenet groups or participate in the IRC rooms within a couple of weeks of regular study (an hour). There is even a free 10-lesson email course with tutors which provides all of the foundation you need to start communicating. The Esperanto community is, in a lot of ways, much like the Open Source community, and I'm constantly suprised that I don't see more cross-polination between the two groups. You will notice, however, that KDE comes with fairly extensive Esperanto language support.
Even TravelLang has an English/Esperanto translator, and some of their translation software uses Esperanto as the medium language, much as XML can be used as a many-to-many point of translation.
More information can be found at:
No kidding. Here's a really good example: while I was living in Munich, I heard a joke told by Austrians about Bavarians. The joke relied on the fact that Bavarians tell a lot of jokes about Austrians, which in turn relied on the knowledge that there is a perception in Bavaria that Austrians are stupid, which in turn is based on the sound of the Austrian accent. I heard quite a few of those kinds of jokes while I was there. Still, all in all, I didn't find the day-to-day communication relying so much on contextual culture knowledge that it was really a problem.
On the other hand, this could also be the basis for technology that tracks where you go and what you do. Under the auspices of controlling crime, criminals could be "flagged" and watched, traffic policing could be automated, etc. Where it gets scary is in who determines what suspicios behavior is, or who qualifies as needing to be watched, or the fact that you are removing the human element from the decision making process of evaluating a crime.
In the end, both the citizens and the govornment want this kind of pervasive, intelligent, monitoring technology to be ubiquitous. The difference is that citizens want to be able to turn it off.
Of course, this will all be moot in September, when the RSA patent expires...
Mmmm. You are right; you can change cyphers, but not public key algorithms.
<p>
Of course, this will all be moot in September, when the RSA patent expires...
Most importantly, you imply that public/private key authentication is the only way to use SSH, and this is not true. SSH (OpenSSH) allows users to authenticate from arbitrary hosts securely through the normal PAM authentication, so I still don't see the advantage of SRP. Still, if you allow this sort of authentication, SSH becomes less secure, for reasons which I outline below.
The downside of using a passphrase as the authentication mechanism is that it is inherantly weaker than using public/private keys. If a private key is stored encrypted, the system is more secure by nature of requiring both physical access to the private key, and access to the passphrase by which it is encrypted. If you are using a passphrase authentication mechanism and I somehow get your passphrase, you are screwed; I have access to all systems where you use that passphrase. However, if you somehow get my passphrase, and I'm using public/private keys, you *still* have to somehow get ahold of my private key to authenticate yourself as me. Similarly, just grabbing my encrypted private key isn't enough, because you can't decrypt and use the key without my passphrase.
OpenSSH does solve the SSH1 protocol security issues. Check their website.
SRP hasn't been around nearly as long as SSH, and hasn't been as severely scrutinized for weaknesses, so it doesn't mean much to say that no weaknesses have yet been found. Only time will tell.
From a purely technical point of view, SSH, when using public key cryptography, is as secure as SRP. In the following list, I don't claim that SRP doesn't do any of these things; I'm merely clarifying what SSH does do.
- SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.
- SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.
- Authentication is done either with public/private keys or with a server side authentication mechanism, such as PAM. In the second case, any passwords or other information is transmitted encrypted, and so is secure. In the first case, the password is never transmitted and there is no chance of the user's password on the server being compromised through SSH. The user's password is never used to encrypt a session.
- OpenSSH, OpenSSL, and LSH are all open source, non-commercial projects.
- SSH allows securing of arbitrary ports, and provides extensive port forwarding capabilities. Therefore, any service on a server running SSHD can be secured, as long as the client program can alter the port of the service it is requesting. As an example, to secure an IMAP connection, one would issue: ssh -L 1442:servername:143 servername and then connect with their email client to localhost:1442.
- Although most users of OpenSSH are unaware of the fact, OpenSSL, which is required for OpenSSH, provides a powerful tool for dealing with X.509 certificates. With OpenSSL, you can encrypt, generate hashes, generate certificates, generate certificate requests, and perform a large number of other security-related actions. OpenSSL documentation is extremely sparce, and due to the complexity of X.509, using OpenSSL tools can be difficult; this is probably the primary reason why most people are oblivious to OpenSSL capabilities.
- OpenSSL is the basis for a number of port wrapping tools, such as sslwrap. With these tools, you can provide secure sockets to services such as HTTP, IMAP, telnet, and POP. Many clients, such as Netscape, understand secure sockets, and several ports are defined as "well known ports" for these secure services. (EG: IMAP's secure port is 993, and Netscape Communicator knows and can take advantage of this).
- Using public keys with SSH simplifies accessing services, so that 'ssh' and 'scp' are as easy to use as 'rsh' and 'rcp'. This is slightly less secure on a shared client, because the private key is held in the client memory during a login session, and is subject to core dump attacks. If the client machine is not shared, this is not an issue.
- OpenSS[HL] doesn't require using RSA algorithms; in fact, you can choose from any number of non-commercial algorithms.
The SRP site claims that there are several "advantages" to using SRP, but never says what these advantages are in relation to. In particular, the SRP site does not claim that SRP is more secure than SSH. SRP is certainly more secure that vanilla telnet, but I see no advantage to using SRP over SSH. The obvious advantage to using SSH over SRP is that SSH is ubiquitous, and well tested.Please, if anyone knows any way in which SRP is superior to SSH, I'd like to know.
I have to add that Qt 2 matches GTK for look-n-feel, so I don't really see any reason to use GTK.
Regarding complaints that the robot isn't smart enough... this is a software issue, and since Probotics are making the API available, I don't see any reason why you couldn't write a driver that updates the map as it encounters obsticals.. Remember, the Cye does provide feedback to the base when it encounters an obstical; it just doesn't have a ranged sensor. The Cye can be as intelligent as you want it to be.
I'm enthusaistic about this. This is basically a real-life robot-wars situation, where you can program your own behavior. If there were a USB port on the Cye mobile unit that could communicate with the base via the radio, then the Cye would have limitless possibility for expansion; robot-arm attachments, light and audio sensers... I can't believe Probotics doesn't have these improvements planned.
--- SER
I think I type faster in Dvorak, if for no other reason than I make fewer typos. I know it is more comfortable than QWERTY. Since I haven't kept up practicing QWERTY, I have to hunt'n'peck when I use a QWERTY layout.
What the heck were you testing? On the standard two-handed DVORAK keyboard layout (there are one-handed layouts as well), of your test sentance, the right hand types:
thssnwltnddntlt
and the left hand types:
iiaeayouaioiei
15 to 14 characters is not a 75% ratio!
- These people access their email from exactly one computer, or
- These people are content with only having access to their email from one computer.
Am I missing something?Now, I know most Linux hackers are C programmers or scripters, but Java is far from being dead, as is far from having failed. There are 1.7 million Java programmers, according to the Boston Globe artical, and 399,000 Linux hosts on the net, according to the April RIPE host count. You can double the Linux count and halve the Java count and still ask whether, if Java is dead, what is Linux?
Java wasn't intended to kill Windows; it still needs an OS to run on top of. As a result, it provides as much advantage to Windows as it does to any other OS. The hope was that Java would provide a mechanism for software houses to produce software that would run on any platform, and thereby give other OSes a chance to fight on a level playing field. It isn't up to Java to defeat MS; it is up to other OSes. Whether the Java language itself is better than any other language is a mostly matter of taste and is an issue of debate for computer theorists; however, many of the features of Java, which are lacking in C or C++, and many of the features that are lacking in Java which are present in C and C++, make developing Java applications easier.
Maybe Java isn't as popular among Linux users because we have the slowest virtual machines of any platform. At our development we use several Java applications in our development suite, and on the Windows NT machines these applications are scarcely slower than native apps. Most importantly, I can use the same apps on my Linux development machine; if it weren't for Java, I'd have to run Windows to be consistent with the other non-Linux developers, so I, for one, am grateful to Java for allowing me to use the OS of my own choice.
It is a mistake to claim that Java has failed or is dead, and a disservice to fail to recognize what opportunities the Java platform has provided anybody who wants freedom to choose their OS.
Now, I know most Linux hackers are C programmers or scripters, but Java is far from being dead, as is far from having failed. There are 1.7 million Java programmers, according to the Boston Globe artical, and 399,000 Linux hosts on the net, according to the April RIPE host count. You can double the Linux count and halve the Java count and still ask whether, if Java is dead, what is Linux? Java wasn't intended to kill Windows; it still needs an OS to run on top of. As a result, it provides as much advantage to Windows as it does to any other OS. The hope was that Java would provide a mechanism for software houses to produce software that would run on any platform, and thereby give other OSes a chance to fight on a level playing field. It isn't up to Java to defeat MS; it is up to other OSes. Whether the Java language itself is better than any other language is a mostly matter of taste and is an issue of debate for computer theorists; however, many of the features of Java, which are lacking in C or C++, and many of the features that are lacking in Java which are present in C and C++, make developing Java applications easier. Maybe Java isn't as popular among Linux users because we have the slowest virtual machines of any platform. At our development we use several Java applications in our development suite, and on the Windows NT machines these applications are scarcely slower than native apps. Most importantly, I can use the same apps on my Linux development machine; if it weren't for Java, I'd have to run Windows to be consistent with the other non-Linux developers, so I, for one, am grateful to Java for allowing me to use the OS of my own choice. It is a mistake to claim that Java has failed or is dead, and a disservice to fail to recognize what opportunities the Java platform has provided anybody who wants freedom to choose their OS.
It is annoying that the most programmer friendly APIs seem to produce the least friendly user friendly interfaces. MUI on the Amiga was, by far, the best GUI API I've ever seen.
I like the design of Swing (for Java). Fresco uses a novel design, but it is slow. GTK is slower than QT, so I prefer QT as a user, but GTK (IMHO) is more attractive.
Overall, I think we can count ourselves lucky that we have such a variety to choose from. The programmers for some OSes don't have the option to choose style over speed, or a nicer API.
I think that MOSIX is a kernel patch. One downloads the 2.2 kernel, downloads the MOSIX changes, and recompiles the kernel. By definition, this is a sourcecode kernel patch. MOSIX isn't a module, but that's different. Also, I do believe that MOSIX works with process threads, and doesn't require any special programming; that is, it will work with all applications, MOSIX-aware, or not.
Yeah, ESR's choice of phraseology was unfortunate. All applications on a Windoze box run, effectively, as root, which makes Windoze systems less secure than Linux. On the other hand, Linux also suffers from root-itis. MVS has a much better system (and I heard someone mention EROS) by which root doesn't exist, and root's functions are distributed among several admin users. What this means is that to compromise an MVS system and erase your tracks, you have to compromise several accounts. On Linux, you only have to compromise 1 account (root). On Windoze, you only have to compromise any one of (potentially) numerous accounts.
Even if this were more than simply a celebration, it wouldn't be suprising. The US of A is the only non-third world country that *still* doesn't use metric, just going to show that you don't have to be French to be obstinate.
Thanks!
You do have to jump through a few hoops to get it set up properly first, though. You can find out more info at the LinuxOrb web site.
Would you email me with more details regarding the problem you had and your solution so that I can add it to the linuxorb web page?
If you'd like to post the information to the linuxorb mailing list, we'd really appreciate it. You'll have to subscribe first, for anti-spam purposes. The relevant email addresses are:
linuxorb-subscribe@tatoosh.com
linuxorb-unsubscribe@tatoosh.com
Thanks!