It seems you have convinced yourself that the world should be modeled in terms of procedures. This is typical for people who have programmed using procedural languages. The same happens to people who program OO: they see classes everywhere. Then you have people who like functional languages: suddenly everything seems a function.
The sad part is that all these paradigms have problems where they can be applied very well and none of them can be applied to all problems well.
Now back to OO. What is it good for: it's a good way to structure complex systems. If you have a complex system, you can probably make its structure more explicit by using objects, design patterns and so on.
Mind you, it is no silver bullet and you wouldn't be the first one to build a super complex, flexible OO everything system that doesn't perform well and is impossible to maintain.
Symptoms that indicate you might benefit from OO:
- There's a lot of commonalities between the programs you write: this indicates that you can generalize functionality.
- There's a lot of dependencies between your modules: you need to encapsulate and hide stuff
- You have a lot of complex data structures and lots of functionality around those data structures: hmm objects???
If you are serious about adopting OO you should spent some time with books about OO design such as for example Gammma's excellent book about design patterns.
As for your question regarding engineering problems. I have worked with companies involved in building embedded stuff like fire alarms, haemo dialysis machines (medical machines), mobile phones, digital radio systems and embedded server products. All of them use OO based designs to their advantage so it can be done. And in case you are wondering: all of these systems were very large systems (500 KLOC - 5 MLOC). Using OO is a necessity for these companies since it is the only tool they have to keep complexity under control.
It's open source (GPL) so you can build yourself a version without that stuff. In addition there's options to not install the spyware when you install limewire and finally there's a java only installer that doesn't have the spyware at all.
Plenty of options to use an excellent, free product without being nagged and spied upon. Bearshare is nice too, but from where I'm standing, most of the innovative features come from the limewire people. That's why I use limewire.
There have been a few recent major screw ups at the dutch OM (the dutch district attorney). Consequently, they'll be reluctant to take on a high profile case that has a good chance of blowing up in their face. Legally speaking, Kazaa is not doing anything wrong (at least, that would be hard to prove). The fact that the most useful application of their software is trading warez, divx and mp3 is irrelevant since they do not actually engage in the transactions themselves (unlike napster).
Basically what Kazaa said is that they have no way to comply with what the dutch judge told them to do (namely to put an end to the illegal exchange of the above mentioned stuff using Kazaa). It is simply not feasible since the transactions are fully peer to peer. The searches nor the downloads go through a central server.
In any case, Limewire 2.0 is available now and has some new features that should enhance scalability of the gnutella network greatly. Gnutella is open source and has no dependencies on a login server (unlike Kazaa) eliminating the last link to a central server. If Kazaa is going to lose their case it will be because of the logins.
The single player levels are kind of nice although the AI of your opponents is rather low. Getting through the levels isn't really much of a challenge except for a few isolated spots where you overrun by hordes of lame monsters. Without the good graphics it wouldn't be much of a game.
I actually liked som of the levels. There is one where you are supposed to sneak past some guards and snipe them in such a way the other guards won't notice. That was kind of fun. The main problem with rtcw is that after about 10 hours of gameplay you're done. Since the levels are so easy, replaying is not much fun since you know where all the soldiers are and how to find your way to the level exit.
The multiplayer mode is not for me. I never liked teamplay because most of the time your fellow teammembers suck and it takes way to much time become effective as a team. I prefer plain deathmatch: spawn and go on a kamikaze killing spree. The problem with rtcw is that it doesn't offer deathmatch and that the teamplay is particularly nasty because of the player classes. It bored me within two minutes. Basically I spawned, watched others shoot each other and then finally really spawned into the game (i.e. not as a spectator) in an impossible position with almost no weapons. Naturally since I didn't know the level, the guns and my team members I got killed almost instantly. That means more watching others play (for some reason they don't let you respawn immediately). At that point I realized rtcw multiplayer was crap. Of 20 minutes online gameplay, I had not had more than 5 minutes worth of action, not my idea of a good time.
Jini lacked a killer application. P2p already has one (mp3 sharing, instant messaging) so JXTA needs another one to prove it is worth bothering with. Unless it is found it will die slowly and will eventually disappear.
I fear JXTA will go the same way. SUN is a server side company and it has never understood the client side. For example: Java's failure on the client side; the crappy GUI they ship with their OS and the fact that their most succesfull desktop products (forte and staroffice) were acquired rather than created at SUN. When they announced JXTA I was one of the dozens of puzzled folks who were left wondering what the fuss was about when you unzipped the demo.
Crappy GUI and *gasp* a unix shell like interface to the whole thing, apparently the only thing these guys grasp. I know it is only a demo app but it is hardly an inspiring one. Unless they get some real, useful and most importantly unique apps out based on JXTA that actually require JXTA (morpheus et al. demonstrate that mp3 sharing does not require such a poweful tool) it is doomed to fail.
When it comes to p2p, the UI is all that matters. Nobody cares about what is powering it. Long after the napster network collapsed, people were running napster: to play their mp3! Apple understands UIs so they created iPod: instant hit.
The only thing I see on the JXTA site is stuff I already have (and hence does not require JXTA). This tells me that the JXTA developers are as much in the dark as I am when it comes to the killer app JXTA so desparately needs. They have a cool idea but no clue as to what to do with it.
Many technologies die this way. A few years ago mobile agents were a hot thing. It never took off because people just couldn't figure out a useful application for it. There were many cool demos and prototypes and I had lots of fun playing with the aglet stuff from IBM but no useful application of all this technology. Same for 3d userinterfaces. We have the hardware to run 3d stuff, but other than games and CAD, this hardware is not used to replace the desktop metaphore. Then there's VRML: another cool idea that never took off. The message is clear, once the coolness wears off there has to be a reason to keep using a technology.
It would be cool to have my toaster instruct the coffee machine to download britney spears. However I hate britney spears and it would spoil my breakfast having to listen to her when all I wanted was some toast and coffee (which don't require either jini or JXTA). I'm not saying that SUN should abandon JXTA, I'm just telling them that if they continue the way they are doing things now, they might as well abandon it right now.
Just the other day there was a hilarious comic on dilbert about some guys in a swamp whose business model was to sell mud to people who live in mud.
I don't see how this is any different. First of all the services these companies are competing against are 0$. On top of that there are lots of restrictions on what you can do with the music you download and you lose the music once you stop paying.
There's simply no way this can be profitable. It has failure written all over it. Hosting the music costs money, licensing the music costs money, writing and maintaining the software needed for playback and license enforcing costs money. There's no way that cost can ever be recovered.
smb and nfs lack the scalability you need. All that users want is put some search terms in a box, hit enter and click on a link.
Similarly they just want to drag a bunch of files to some folder and forget about it rather than having to share a folder and advertise that you have shared your folder and that it can be found at some very long, hard to remember address. That's too difficult for average users and they won't share or browse shared stuff.
Basically if you create a bridge between your browser and a gnutella client, you could do the same. Just build an http server into the gnutella client and you can search and open documents using your browser. Of course you'd want some additional functionality (like share the cached documents you requested; some naming scheme so that you get the index.html you are looking for) but technically it doesn't get much more difficult than that. It would be a nice project for somebody working on their master thesis.
Of course the thing is that nobody bothered to do so sofar. As pointed out above, it is a really simple combination of what we already have. Yet it takes some creativity (courtesy of IBM) to think of doing it. That's what I find so interesting about this stuff. Everybody is so busy thinking of websites as a central thing that nobody has even considered decentralization (even though it makes perfect sense).
That applies to most languages. Just understanding the syntax is about an hour or so of work for most programmers (shorter if they are experienced, longer if they haven't seen a real language yet).
However, whether you are dealing with the STL, MFC or the Java API, it takes time to get productive with that. The Java API is simply huge and covers an enormous amount of functionality that you don't have to invent yourself. Luckily, there is JavaDoc that helps to browse through APIs. In addition, most APIs are well designed and have been through extensive review processess (unlike the crap Microsoft pours out over you) so if you know your design patterns, you won't have trouble understanding how everything fits together.
If other languages appear to be simpler, maybe that is because they don't include so much functionality and require you to do more work reinventing the wheel.
This seems like a technicality too me. Any cell is 'life' too me. However a human != a cell IMHO. So I have no problem with manipulating embryo cells.
The trouble is defining when an embryo becomes human life. From a scientific point of view this is a non debate since life is not a scientific term. You could differentiate between organic and non organic matter, perhaps even distinguish between things that contain DNA or don't contain DNA. Or even go as far as defining life as a cell. However is a computer simulated cell life (impossible, I know, but hyphotetically?)? What about aritificial intelligence?
Consequently, you have hardline religious people taking the extreme point of view that any embryo of any size is human life and should be protected. Whereas scientists will point out that especially in the early stage embryo's have very little characteristics that you could call human. It has no brain (hence no conscience), no internal organs, no way of sensing the world. It is just a blob of cells with no personality, will or anything else worth protecting.
I tend to position myself on the scientific side and consider stepping on a bug a greater crime than killing an embryo since unlike the embryo the bug has a little brain, perhaps even a personality and is definately interacting with its world in some meaningful way.
I'm against legislation against cloning because I am in favour of separation of state and church. Any legislation would be based on non scientific (most likely religious) arguments and hence interfere with this highly valued principle. Any legislation would interfere with scientific research. The earth is not flat, we can go to the moon and we will be able to clone humans. That's fine with me.
You shouldn't mix up science fiction with reality. There's nothing scary happening here. By definition, cloning does not create something new but merely duplicates something existing. The debate when something becomes 'human life' is a pure relegious debate. From a scientific point of view however, there were never more than just the cells. You have one cluster of cells, you split it and you have two clusters of cells. If it happens under natural circumstances you call the end result a twin. If you help nature a little, some people suddenly think of it as Frankenstein's monster.
Apart from all the technical details, the cloning process is somthing like: take an egg, replace DNA with DNA of choice, grow the embryo, split the embryo, proceed using mother nature's own processes. From a religious point of view this is not even supposed to be possible but the end result is kind of hard to deny (challenging the assumptions that underly some religions). However, most relegions rely on ignorance anyway so I doubt that this development will affect them in anyway.
In any case, when my liver/kidney/heart/whatever fails I would be very pleased if a backup part, constructed from my own cells, would be available rather than having to rely on third party provided parts. Everyday lots of people die because there are no donor organs available. And even if there is a donor organ it is uncertain whether the transplantation will succeed. This technology could be a great contribution to a solution to this problem.
Exactly, cds are expensive and unnecessary. The record industry's businessmodel is not selling music but cds. The better the music the more cds they sell, however good music is not the primary goal (example: Britney Spears' voice is not her greatest asset. She has to use her whole body to get those cds sold.).
The business model for an artist is different: artists want to sell good music and most of them also enjoy playing their music and would like to make money doing that. Until the internet with its cheap music distribution in the form of mp3 arrived there was some harmony between the artists goals and the record companies goals. However that is no longer the case.
Currently we are in a transition period where some people still spend money buying cds. However, this is a shrinking market. In the long term people will no longer be buying and selling units (e.g. a cd) of music.
You could get moralistic about this and call it theft and be very angry. However, the cold reality is that reproducing music has no cost associated with it. Therefore recovering the cost of the production (i.e. the recording) with asking money for the reproduction is not going to work. There are no good technologies that enable you to monopolize the reproduction process and there are serious legal obstacles for preventing other people from copying music as well. So given the technological and legal obstacles it is unlikely that there will ever be an effective way to stop people from copying music.
Is this bad for music in general? I don't think so. Apart from the past 50-100 years there never was a market for cds and that didn't stop people from making good music. If people could do it 100 years ago they will be able to do it in the future as well. Maybe there will be less multi millionaire artists like Micheal Jackson or Madonna but there will still be people making good music for other people.
X11 made sense in the time that client computers were expensive. These days you can have a pretty decent PC for very little money so that largely removes the need for displaying stuff remotely.
In addition there are now alternative ways to remotely operate a computer. You could use a webserver or use some XML based messaging system (e.g. SOAP). A good example where this is applied is netware from novel. It used to depend on windows for the GUI, but the later versions have a web based GUI. No need for remote display at all.
So seen in this light, it is a correct design decision not to build network transparency into the GUI since that introduces complexity and performance problems. For legacy X based apps you can always install an X server that runs on top of the GUI.
I don't think I mentioned either BE-OS or windows. I did mention Mac OS X since I consider the way applications are bundled far superior to the inconsistent mess applications are after deployment on linux.
I read the thing you linked to, he thinks there's a problem (correct) and he points at a cause (incorrect, IMHO). His solution (standardization) has been suggested before has so far not worked at all.
I think the real cause is that UNIX was never designed but merely assembled from parts that happened to be available (like hey we need a tool for listing files: lets use ls) or were created on the fly. If people had taken the time to think about how to manage applications properly they would have designed it differently.
This is only part of the problem and characteristic for the way unix has evolved. The whole problem is that there are no standards, just conventions which most unix programmers are only partly aware of. I imagine the whole reason for putting all binaries in a single directory was that you then only have to add one directory to the path variable. In other words because of genuine lazyness you have around 2000 executables in your/usr/bin directory. Of course adding all 2000 programs to the path is not the right solution either (that would be moving the problem rather than solving it). Obviously the path variable itself is not a very scalable solution and needs to be reconsidered.
To sum it up UNIX programs all have their own sets of parameters, their own semantics for those parameters, their own config files with their own syntax. Generally a program's related files are scattered through out the system. Just making things consistent would hugely improve usability of unix and reduce system administrator training cost. Most of the art of maintaining a unix system goes into memorizing commandline parameters, configuration file locations and syntax and endless man pages. Basically the ideal system administrator is not to bright (after all it is quite simple work), can work very precise, and has memorized every manpage he ever encountered. The not to bright part is essential because otherwise he'll get a good job offer and he'll be gone in no time.
Here's a sample better solution for the problem (inspired by mac os X packages): give each app its very own directory structure with e.g. the directories bin, man, etc for binaries, documentation and configuration. In the root of each package specify a meta information file (preferably xml based) with information about how to integrate the program with the system (e.g. commands that should be in the path, menu items, etc.). Standardize this format and make sure that the OS automatically integrates the program (i.e. adds the menu items, adds the right binaries to a global path, integrates the documentation with the help system). Of course you can elaborate greatly on these concepts but the result would be that you no longer need package managers except perhaps for assisting with configuration.
30 mile per gallon is not as quite as efficient as a modern car (i'm not talking about the petrol devouring monsters you people drive in the US). So if you replace all cars with planes you get a huge increase in fuel consumption (under the arguably wrong assumption that the amount of trafic would stay stable).
Replacing all cars with planes is unlikely to happen and airlines generally operate on distances which would be well beyond the range of a skycar so they would continue to exist. Point to point travel is only possible if you have airstrips at each point (which is not the case).
I strongly doubt that planes can be as fuel efficient as cars (assuming that they have similar weight). Also you need facilities to land and take off which will likely not be in your backyard. So you still need a car to get to and from the airport and that sort of makes short hops unfeasible since you might as well drive to your destination instead of the airport.
I also doubt that trafic on the ground would reduce much since planes are probably going to be toys for the rich. Also the amount of trafic tends to grow if you increase the capacity of the infrastructure.
It is bad enough to have regular airplanes burning thousands of tons of kerosine in our atmosphere every day. The effect of millions of cars burning extra fuel to stay airborne in addition to getting from A to B would be disastrous IMHO.
Then there's the issue of horizon pollution, imagine sitting in your backyard unable to escape the trafic that is passing right over it. In my country (The Netherlands) it is already hard to find a place where you can't see/hear regular trafic.
Then there's the issue of accidents and their consequences. Apart from probably being fatal for the people inside the flying car, heavy objects dropping from the sky may pose a danger themselves as well.
I just browsed the limewire developer website. The next version (1.9) will include cool new download technology and meta search technology (XML based). This stuff just missed the 1.8 release but is expected to be released soon.
In addition, the major gnutella problem (scalability)is going to be addressed in a beta release shortly after that. Historically, Limewire has releases every few weeks so I suspect a 2.0 could be here before the end of this year. With the introduction of supernodes, gnutella will be as scalable as fasttrack (essentially supernodes are the key difference between the fasttrack protocol and the gnutella protocol). Only it will be open (both the protocol and the implementations). This is very good news.
I'm increasingly annoyed with the crappy/buggy morpheus interface (kazaa is exactly the same but includes spyware). I experience random crashes and the UI seems to be assembled by a couple of morons. My little sister could do a better job given a 3 day course in VB for dummies.
I always liked the limewire interface, with the improved search ability it will be a worthy competitor to kazaa/morpheus and with the supernodes in place it will be as scalable as the fasttrack network.
I really like the way this is evolving. Just as the RIAA is starting to sue Fastrack licensees, something else they deemed irrelevant before is given a new chance. It must drive them nuts. Gnutella must have at least a dozen different clients. No one owns the protocol and most clients are open-source. The only way to ban it is to start sueing on the client side. Luckily, freenet is still improving too:-). Internet time is just passing too soon for them I guess. Next thing you know, you're irrelevant and your business model blows up in your face.
I have the source code on my hardrive, licensed under the GPL accessible through CVS (what do you want more?). Pretty interesting to look at too. Well written, pretty well documented. I'm actually considering playing with it if I can find the time.
I don't mind Limewire showing some banners. I don't see how they can make money otherwise at Limewire. The spyware is more of an issue and I will block/remove it if I encounter it. I must warn the people from limewire that knowledgeable software users, open source developers in particular *hate* spyware. As such I think that such a move would be counterproductive since those very same people are also limewire's core users.
Java is often referred to as a platform as well. There are in fact web servers written in Java and the performance is not horrible. With the upcoming jdk, new more efficient IO will be possible so there will be even better performing web servers available.
And then of course there are servlets and servlet engines which are used to run complex, large websites. So it is possible.
You can only access anything on the heap if your programming language allows it (e.g. C or C++) in which case you need to constrain how the language is used. I've seen quite a few companies who work with C/C++ employ strict coding guidelines that accomplish this.
If you have a lot of independent tasks which don't share data. You use threads because that will give you a more scalable system. Of course your system will be riddled with bugs if you start doing all sorts of pointer arithmetic which, in general, is a bad idea (even on non distributed systems). If two threads are accessing the same data they are sharing it. If they shouldn't, its a bug. The only reason processes are useful is that they force you to employ methods other than pointers to access shared data (so if you create a bug by doing funky pointer arithmetic it will only affect one process).
Multi threaded applications are known to scale to several thousands of threads on relatively modest hardware. Context switches typically occur when different threads/processes on the same processor are accessing different data. Context switching for processes is more expensive then for threads on modern operating systems.
You are calling me silly for recommending threads as good alternative for processes in situations that require scalability. Yet, IMHO, this is exactly the reason why apache 2.0 is using threads.
Shared data is inevitable in distributed systems. If you isolate the data for each process using memory protection, that implies that there has to be some means of transferring data from one process to another (e.g. pipes). Typically such mechanisms are cumbersome and make context switches expensive.
My whole point is that with highlevel languages, such as Java, the language encapsulates most of the complexity of dealing with synchronization. Java does not have a process concept other than the (typically single) JVM process that hosts all the threads.
Strong typing, and OO further enhance the stability and consistency. Emulating such mechanisms in a language like C is hard and requires intimate knowledge of parallel programming and discipline of the programmers.
Therefore multithreading wasn't very popular until very recently. Only since the 2.2 and 2.4 linux kernels were introduced, threading has become somewhat feasible in terms of performance. Using the new threading features requires that you think beyond the heap as a central storage facility for data. In Java the heap is something that JVM uses to store and manage objects. At the programming level you only have objects. Objects are referred to by other objects (which may be threads) and may refer to/create objects themselves. Access to the data in the objects is done through access methods and where applicable you make those methods synchronized (i.e. you include the synhronized keyword in the method signature or employ a synchronized code block somewhere) to ensure no other objects interfere.
Each time you employ (or should employ) a synchronization mechanism, you would have had to employ a similar mechanism if you had been using processes. The only problem is that that mechanism would probably be much more expensive to use since you are accessing data across address space boundaries.
With this in mind, the use of processes is limited to situations where there is little or no communication between the processes. Implementing such software using threads should be dead simple since you will only have a few situations where the threads are accessing each others data so there is no real risk for race conditions. Such situations you can deal with using well designed APIs and by preventing dirty pointer arithmetic. A company I have worked with who write large embedded software systems for an OS without memory protection on processes has successfully built a rock solid system this way in C++. By their own account they have actually encountered very few race conditions in their system. My guess is that the apache people have employed similar techniques and code guidelines to avoid the kind of bugs you are talking about.
So if you are encountering race conditions in your code, using processes rather than threads won't solve your problems because you still need to synchronize data. You can do so more cheaply with threads than with processes.
Programming threads is just as hard as programming with processes on a conceptual level. The type of problems you encounter are the same.
However, process handling is potentially more expensive since processes have separate address spaces and require special mechanisms for communication between these address spaces. From the point of view of system resources and scalability you are better of with threads than with processes. Typically the amount of threads an OS can handle is much larger than the amount of processess it can handle. With multi processor systems becoming more prevalent, multithreaded systems are required to be able to use all the processors effectively and distribute the load evenly.
The primary reasone why you would want to use processes anyway is stability. When the mother process holding a bunch of threads dies, all its threads die too. If your application consists of 1 process and 1000 threads, a single thread can bring down the entire application. At the process level, you have the OS shielding each process' addressspace from the other processess so that gives you some level of protection against misbehaving processes. Running apache in multiple processes therefore gives you some protection, if one of the httpd processes dies, the other processes can take over and continue to handle requests.
The use of highlevel languages & APIs (e.g. Java and it's threading facilities) addresses these stability issues and makes it safer (not perfectly safe) to use threads. Java for instance offers memory management facilities that basically prevent such things as buffer overflows or illegal memory access. This largely removes the need for the kind of memory protection an OS offers for processes.
Apache 2.0 is specifically designed to be more scalable than the 1.3.x series. Threading is a key architectural change in this respect. Sadly it is not written in Java which unlike some people on slashdot believe is very capable of competing with lower level languages in this type of server applications. Presumably the apache developers are using a few well developed C APIs to provide some protection against stability issues.
Slashdot Mirror
It seems you have convinced yourself that the world should be modeled in terms of procedures. This is typical for people who have programmed using procedural languages. The same happens to people who program OO: they see classes everywhere. Then you have people who like functional languages: suddenly everything seems a function.
The sad part is that all these paradigms have problems where they can be applied very well and none of them can be applied to all problems well.
Now back to OO. What is it good for: it's a good way to structure complex systems. If you have a complex system, you can probably make its structure more explicit by using objects, design patterns and so on.
Mind you, it is no silver bullet and you wouldn't be the first one to build a super complex, flexible OO everything system that doesn't perform well and is impossible to maintain.
Symptoms that indicate you might benefit from OO:
- There's a lot of commonalities between the programs you write: this indicates that you can generalize functionality.
- There's a lot of dependencies between your modules: you need to encapsulate and hide stuff
- You have a lot of complex data structures and lots of functionality around those data structures: hmm objects???
If you are serious about adopting OO you should spent some time with books about OO design such as for example Gammma's excellent book about design patterns.
As for your question regarding engineering problems. I have worked with companies involved in building embedded stuff like fire alarms, haemo dialysis machines (medical machines), mobile phones, digital radio systems and embedded server products. All of them use OO based designs to their advantage so it can be done. And in case you are wondering: all of these systems were very large systems (500 KLOC - 5 MLOC). Using OO is a necessity for these companies since it is the only tool they have to keep complexity under control.
It's open source (GPL) so you can build yourself a version without that stuff. In addition there's options to not install the spyware when you install limewire and finally there's a java only installer that doesn't have the spyware at all.
Plenty of options to use an excellent, free product without being nagged and spied upon. Bearshare is nice too, but from where I'm standing, most of the innovative features come from the limewire people. That's why I use limewire.
There have been a few recent major screw ups at the dutch OM (the dutch district attorney). Consequently, they'll be reluctant to take on a high profile case that has a good chance of blowing up in their face. Legally speaking, Kazaa is not doing anything wrong (at least, that would be hard to prove). The fact that the most useful application of their software is trading warez, divx and mp3 is irrelevant since they do not actually engage in the transactions themselves (unlike napster).
Basically what Kazaa said is that they have no way to comply with what the dutch judge told them to do (namely to put an end to the illegal exchange of the above mentioned stuff using Kazaa). It is simply not feasible since the transactions are fully peer to peer. The searches nor the downloads go through a central server.
In any case, Limewire 2.0 is available now and has some new features that should enhance scalability of the gnutella network greatly. Gnutella is open source and has no dependencies on a login server (unlike Kazaa) eliminating the last link to a central server. If Kazaa is going to lose their case it will be because of the logins.
The single player levels are kind of nice although the AI of your opponents is rather low. Getting through the levels isn't really much of a challenge except for a few isolated spots where you overrun by hordes of lame monsters. Without the good graphics it wouldn't be much of a game.
I actually liked som of the levels. There is one where you are supposed to sneak past some guards and snipe them in such a way the other guards won't notice. That was kind of fun. The main problem with rtcw is that after about 10 hours of gameplay you're done. Since the levels are so easy, replaying is not much fun since you know where all the soldiers are and how to find your way to the level exit.
The multiplayer mode is not for me. I never liked teamplay because most of the time your fellow teammembers suck and it takes way to much time become effective as a team. I prefer plain deathmatch: spawn and go on a kamikaze killing spree. The problem with rtcw is that it doesn't offer deathmatch and that the teamplay is particularly nasty because of the player classes. It bored me within two minutes. Basically I spawned, watched others shoot each other and then finally really spawned into the game (i.e. not as a spectator) in an impossible position with almost no weapons. Naturally since I didn't know the level, the guns and my team members I got killed almost instantly. That means more watching others play (for some reason they don't let you respawn immediately). At that point I realized rtcw multiplayer was crap. Of 20 minutes online gameplay, I had not had more than 5 minutes worth of action, not my idea of a good time.
Jini lacked a killer application. P2p already has one (mp3 sharing, instant messaging) so JXTA needs another one to prove it is worth bothering with. Unless it is found it will die slowly and will eventually disappear.
I fear JXTA will go the same way. SUN is a server side company and it has never understood the client side. For example: Java's failure on the client side; the crappy GUI they ship with their OS and the fact that their most succesfull desktop products (forte and staroffice) were acquired rather than created at SUN. When they announced JXTA I was one of the dozens of puzzled folks who were left wondering what the fuss was about when you unzipped the demo.
Crappy GUI and *gasp* a unix shell like interface to the whole thing, apparently the only thing these guys grasp. I know it is only a demo app but it is hardly an inspiring one. Unless they get some real, useful and most importantly unique apps out based on JXTA that actually require JXTA (morpheus et al. demonstrate that mp3 sharing does not require such a poweful tool) it is doomed to fail.
When it comes to p2p, the UI is all that matters. Nobody cares about what is powering it. Long after the napster network collapsed, people were running napster: to play their mp3! Apple understands UIs so they created iPod: instant hit.
The only thing I see on the JXTA site is stuff I already have (and hence does not require JXTA). This tells me that the JXTA developers are as much in the dark as I am when it comes to the killer app JXTA so desparately needs. They have a cool idea but no clue as to what to do with it.
Many technologies die this way. A few years ago mobile agents were a hot thing. It never took off because people just couldn't figure out a useful application for it. There were many cool demos and prototypes and I had lots of fun playing with the aglet stuff from IBM but no useful application of all this technology. Same for 3d userinterfaces. We have the hardware to run 3d stuff, but other than games and CAD, this hardware is not used to replace the desktop metaphore. Then there's VRML: another cool idea that never took off. The message is clear, once the coolness wears off there has to be a reason to keep using a technology.
It would be cool to have my toaster instruct the coffee machine to download britney spears. However I hate britney spears and it would spoil my breakfast having to listen to her when all I wanted was some toast and coffee (which don't require either jini or JXTA). I'm not saying that SUN should abandon JXTA, I'm just telling them that if they continue the way they are doing things now, they might as well abandon it right now.
Just the other day there was a hilarious comic on dilbert about some guys in a swamp whose business model was to sell mud to people who live in mud.
I don't see how this is any different. First of all the services these companies are competing against are 0$. On top of that there are lots of restrictions on what you can do with the music you download and you lose the music once you stop paying.
There's simply no way this can be profitable. It has failure written all over it. Hosting the music costs money, licensing the music costs money, writing and maintaining the software needed for playback and license enforcing costs money. There's no way that cost can ever be recovered.
smb and nfs lack the scalability you need. All that users want is put some search terms in a box, hit enter and click on a link.
Similarly they just want to drag a bunch of files to some folder and forget about it rather than having to share a folder and advertise that you have shared your folder and that it can be found at some very long, hard to remember address. That's too difficult for average users and they won't share or browse shared stuff.
Basically if you create a bridge between your browser and a gnutella client, you could do the same. Just build an http server into the gnutella client and you can search and open documents using your browser. Of course you'd want some additional functionality (like share the cached documents you requested; some naming scheme so that you get the index.html you are looking for) but technically it doesn't get much more difficult than that. It would be a nice project for somebody working on their master thesis.
Of course the thing is that nobody bothered to do so sofar. As pointed out above, it is a really simple combination of what we already have. Yet it takes some creativity (courtesy of IBM) to think of doing it. That's what I find so interesting about this stuff. Everybody is so busy thinking of websites as a central thing that nobody has even considered decentralization (even though it makes perfect sense).
That applies to most languages. Just understanding the syntax is about an hour or so of work for most programmers (shorter if they are experienced, longer if they haven't seen a real language yet).
However, whether you are dealing with the STL, MFC or the Java API, it takes time to get productive with that. The Java API is simply huge and covers an enormous amount of functionality that you don't have to invent yourself. Luckily, there is JavaDoc that helps to browse through APIs. In addition, most APIs are well designed and have been through extensive review processess (unlike the crap Microsoft pours out over you) so if you know your design patterns, you won't have trouble understanding how everything fits together.
If other languages appear to be simpler, maybe that is because they don't include so much functionality and require you to do more work reinventing the wheel.
This seems like a technicality too me. Any cell is 'life' too me. However a human != a cell IMHO. So I have no problem with manipulating embryo cells.
The trouble is defining when an embryo becomes human life. From a scientific point of view this is a non debate since life is not a scientific term. You could differentiate between organic and non organic matter, perhaps even distinguish between things that contain DNA or don't contain DNA. Or even go as far as defining life as a cell. However is a computer simulated cell life (impossible, I know, but hyphotetically?)? What about aritificial intelligence?
Consequently, you have hardline religious people taking the extreme point of view that any embryo of any size is human life and should be protected. Whereas scientists will point out that especially in the early stage embryo's have very little characteristics that you could call human. It has no brain (hence no conscience), no internal organs, no way of sensing the world. It is just a blob of cells with no personality, will or anything else worth protecting.
I tend to position myself on the scientific side and consider stepping on a bug a greater crime than killing an embryo since unlike the embryo the bug has a little brain, perhaps even a personality and is definately interacting with its world in some meaningful way.
I'm against legislation against cloning because I am in favour of separation of state and church. Any legislation would be based on non scientific (most likely religious) arguments and hence interfere with this highly valued principle. Any legislation would interfere with scientific research. The earth is not flat, we can go to the moon and we will be able to clone humans. That's fine with me.
You shouldn't mix up science fiction with reality. There's nothing scary happening here. By definition, cloning does not create something new but merely duplicates something existing. The debate when something becomes 'human life' is a pure relegious debate. From a scientific point of view however, there were never more than just the cells. You have one cluster of cells, you split it and you have two clusters of cells. If it happens under natural circumstances you call the end result a twin. If you help nature a little, some people suddenly think of it as Frankenstein's monster.
Apart from all the technical details, the cloning process is somthing like: take an egg, replace DNA with DNA of choice, grow the embryo, split the embryo, proceed using mother nature's own processes. From a religious point of view this is not even supposed to be possible but the end result is kind of hard to deny (challenging the assumptions that underly some religions). However, most relegions rely on ignorance anyway so I doubt that this development will affect them in anyway.
In any case, when my liver/kidney/heart/whatever fails I would be very pleased if a backup part, constructed from my own cells, would be available rather than having to rely on third party provided parts. Everyday lots of people die because there are no donor organs available. And even if there is a donor organ it is uncertain whether the transplantation will succeed. This technology could be a great contribution to a solution to this problem.
Exactly, cds are expensive and unnecessary. The record industry's businessmodel is not selling music but cds. The better the music the more cds they sell, however good music is not the primary goal (example: Britney Spears' voice is not her greatest asset. She has to use her whole body to get those cds sold.).
The business model for an artist is different: artists want to sell good music and most of them also enjoy playing their music and would like to make money doing that. Until the internet with its cheap music distribution in the form of mp3 arrived there was some harmony between the artists goals and the record companies goals. However that is no longer the case.
Currently we are in a transition period where some people still spend money buying cds. However, this is a shrinking market. In the long term people will no longer be buying and selling units (e.g. a cd) of music.
You could get moralistic about this and call it theft and be very angry. However, the cold reality is that reproducing music has no cost associated with it. Therefore recovering the cost of the production (i.e. the recording) with asking money for the reproduction is not going to work. There are no good technologies that enable you to monopolize the reproduction process and there are serious legal obstacles for preventing other people from copying music as well. So given the technological and legal obstacles it is unlikely that there will ever be an effective way to stop people from copying music.
Is this bad for music in general? I don't think so. Apart from the past 50-100 years there never was a market for cds and that didn't stop people from making good music. If people could do it 100 years ago they will be able to do it in the future as well. Maybe there will be less multi millionaire artists like Micheal Jackson or Madonna but there will still be people making good music for other people.
X11 made sense in the time that client computers were expensive. These days you can have a pretty decent PC for very little money so that largely removes the need for displaying stuff remotely.
In addition there are now alternative ways to remotely operate a computer. You could use a webserver or use some XML based messaging system (e.g. SOAP). A good example where this is applied is netware from novel. It used to depend on windows for the GUI, but the later versions have a web based GUI. No need for remote display at all.
So seen in this light, it is a correct design decision not to build network transparency into the GUI since that introduces complexity and performance problems. For legacy X based apps you can always install an X server that runs on top of the GUI.
I don't think I mentioned either BE-OS or windows. I did mention Mac OS X since I consider the way applications are bundled far superior to the inconsistent mess applications are after deployment on linux.
I read the thing you linked to, he thinks there's a problem (correct) and he points at a cause (incorrect, IMHO). His solution (standardization) has been suggested before has so far not worked at all.
I think the real cause is that UNIX was never designed but merely assembled from parts that happened to be available (like hey we need a tool for listing files: lets use ls) or were created on the fly. If people had taken the time to think about how to manage applications properly they would have designed it differently.
This is only part of the problem and characteristic for the way unix has evolved. The whole problem is that there are no standards, just conventions which most unix programmers are only partly aware of. I imagine the whole reason for putting all binaries in a single directory was that you then only have to add one directory to the path variable. In other words because of genuine lazyness you have around 2000 executables in your /usr/bin directory. Of course adding all 2000 programs to the path is not the right solution either (that would be moving the problem rather than solving it). Obviously the path variable itself is not a very scalable solution and needs to be reconsidered.
To sum it up UNIX programs all have their own sets of parameters, their own semantics for those parameters, their own config files with their own syntax. Generally a program's related files are scattered through out the system. Just making things consistent would hugely improve usability of unix and reduce system administrator training cost. Most of the art of maintaining a unix system goes into memorizing commandline parameters, configuration file locations and syntax and endless man pages. Basically the ideal system administrator is not to bright (after all it is quite simple work), can work very precise, and has memorized every manpage he ever encountered. The not to bright part is essential because otherwise he'll get a good job offer and he'll be gone in no time.
Here's a sample better solution for the problem (inspired by mac os X packages): give each app its very own directory structure with e.g. the directories bin, man, etc for binaries, documentation and configuration. In the root of each package specify a meta information file (preferably xml based) with information about how to integrate the program with the system (e.g. commands that should be in the path, menu items, etc.). Standardize this format and make sure that the OS automatically integrates the program (i.e. adds the menu items, adds the right binaries to a global path, integrates the documentation with the help system). Of course you can elaborate greatly on these concepts but the result would be that you no longer need package managers except perhaps for assisting with configuration.
30 mile per gallon is not as quite as efficient as a modern car (i'm not talking about the petrol devouring monsters you people drive in the US). So if you replace all cars with planes you get a huge increase in fuel consumption (under the arguably wrong assumption that the amount of trafic would stay stable).
Replacing all cars with planes is unlikely to happen and airlines generally operate on distances which would be well beyond the range of a skycar so they would continue to exist. Point to point travel is only possible if you have airstrips at each point (which is not the case).
I strongly doubt that planes can be as fuel efficient as cars (assuming that they have similar weight). Also you need facilities to land and take off which will likely not be in your backyard. So you still need a car to get to and from the airport and that sort of makes short hops unfeasible since you might as well drive to your destination instead of the airport.
I also doubt that trafic on the ground would reduce much since planes are probably going to be toys for the rich. Also the amount of trafic tends to grow if you increase the capacity of the infrastructure.
It is bad enough to have regular airplanes burning thousands of tons of kerosine in our atmosphere every day. The effect of millions of cars burning extra fuel to stay airborne in addition to getting from A to B would be disastrous IMHO.
Then there's the issue of horizon pollution, imagine sitting in your backyard unable to escape the trafic that is passing right over it. In my country (The Netherlands) it is already hard to find a place where you can't see/hear regular trafic.
Then there's the issue of accidents and their consequences. Apart from probably being fatal for the people inside the flying car, heavy objects dropping from the sky may pose a danger themselves as well.
I just browsed the limewire developer website. The next version (1.9) will include cool new download technology and meta search technology (XML based). This stuff just missed the 1.8 release but is expected to be released soon.
:-). Internet time is just passing too soon for them I guess. Next thing you know, you're irrelevant and your business model blows up in your face.
In addition, the major gnutella problem (scalability)is going to be addressed in a beta release shortly after that. Historically, Limewire has releases every few weeks so I suspect a 2.0 could be here before the end of this year. With the introduction of supernodes, gnutella will be as scalable as fasttrack (essentially supernodes are the key difference between the fasttrack protocol and the gnutella protocol). Only it will be open (both the protocol and the implementations). This is very good news.
I'm increasingly annoyed with the crappy/buggy morpheus interface (kazaa is exactly the same but includes spyware). I experience random crashes and the UI seems to be assembled by a couple of morons. My little sister could do a better job given a 3 day course in VB for dummies.
I always liked the limewire interface, with the improved search ability it will be a worthy competitor to kazaa/morpheus and with the supernodes in place it will be as scalable as the fasttrack network.
I really like the way this is evolving. Just as the RIAA is starting to sue Fastrack licensees, something else they deemed irrelevant before is given a new chance. It must drive them nuts. Gnutella must have at least a dozen different clients. No one owns the protocol and most clients are open-source. The only way to ban it is to start sueing on the client side. Luckily, freenet is still improving too
I have the source code on my hardrive, licensed under the GPL accessible through CVS (what do you want more?). Pretty interesting to look at too. Well written, pretty well documented. I'm actually considering playing with it if I can find the time.
I don't mind Limewire showing some banners. I don't see how they can make money otherwise at Limewire. The spyware is more of an issue and I will block/remove it if I encounter it. I must warn the people from limewire that knowledgeable software users, open source developers in particular *hate* spyware. As such I think that such a move would be counterproductive since those very same people are also limewire's core users.
Java is often referred to as a platform as well. There are in fact web servers written in Java and the performance is not horrible. With the upcoming jdk, new more efficient IO will be possible so there will be even better performing web servers available.
And then of course there are servlets and servlet engines which are used to run complex, large websites. So it is possible.
You can only access anything on the heap if your programming language allows it (e.g. C or C++) in which case you need to constrain how the language is used. I've seen quite a few companies who work with C/C++ employ strict coding guidelines that accomplish this.
If you have a lot of independent tasks which don't share data. You use threads because that will give you a more scalable system. Of course your system will be riddled with bugs if you start doing all sorts of pointer arithmetic which, in general, is a bad idea (even on non distributed systems). If two threads are accessing the same data they are sharing it. If they shouldn't, its a bug. The only reason processes are useful is that they force you to employ methods other than pointers to access shared data (so if you create a bug by doing funky pointer arithmetic it will only affect one process).
Multi threaded applications are known to scale to several thousands of threads on relatively modest hardware. Context switches typically occur when different threads/processes on the same processor are accessing different data. Context switching for processes is more expensive then for threads on modern operating systems.
You are calling me silly for recommending threads as good alternative for processes in situations that require scalability. Yet, IMHO, this is exactly the reason why apache 2.0 is using threads.
Shared data is inevitable in distributed systems. If you isolate the data for each process using memory protection, that implies that there has to be some means of transferring data from one process to another (e.g. pipes). Typically such mechanisms are cumbersome and make context switches expensive.
My whole point is that with highlevel languages, such as Java, the language encapsulates most of the complexity of dealing with synchronization. Java does not have a process concept other than the (typically single) JVM process that hosts all the threads.
Strong typing, and OO further enhance the stability and consistency. Emulating such mechanisms in a language like C is hard and requires intimate knowledge of parallel programming and discipline of the programmers.
Therefore multithreading wasn't very popular until very recently. Only since the 2.2 and 2.4 linux kernels were introduced, threading has become somewhat feasible in terms of performance. Using the new threading features requires that you think beyond the heap as a central storage facility for data. In Java the heap is something that JVM uses to store and manage objects. At the programming level you only have objects. Objects are referred to by other objects (which may be threads) and may refer to/create objects themselves. Access to the data in the objects is done through access methods and where applicable you make those methods synchronized (i.e. you include the synhronized keyword in the method signature or employ a synchronized code block somewhere) to ensure no other objects interfere.
Each time you employ (or should employ) a synchronization mechanism, you would have had to employ a similar mechanism if you had been using processes. The only problem is that that mechanism would probably be much more expensive to use since you are accessing data across address space boundaries.
With this in mind, the use of processes is limited to situations where there is little or no communication between the processes. Implementing such software using threads should be dead simple since you will only have a few situations where the threads are accessing each others data so there is no real risk for race conditions. Such situations you can deal with using well designed APIs and by preventing dirty pointer arithmetic. A company I have worked with who write large embedded software systems for an OS without memory protection on processes has successfully built a rock solid system this way in C++. By their own account they have actually encountered very few race conditions in their system. My guess is that the apache people have employed similar techniques and code guidelines to avoid the kind of bugs you are talking about.
So if you are encountering race conditions in your code, using processes rather than threads won't solve your problems because you still need to synchronize data. You can do so more cheaply with threads than with processes.
Programming threads is just as hard as programming with processes on a conceptual level. The type of problems you encounter are the same.
However, process handling is potentially more expensive since processes have separate address spaces and require special mechanisms for communication between these address spaces. From the point of view of system resources and scalability you are better of with threads than with processes. Typically the amount of threads an OS can handle is much larger than the amount of processess it can handle. With multi processor systems becoming more prevalent, multithreaded systems are required to be able to use all the processors effectively and distribute the load evenly.
The primary reasone why you would want to use processes anyway is stability. When the mother process holding a bunch of threads dies, all its threads die too. If your application consists of 1 process and 1000 threads, a single thread can bring down the entire application. At the process level, you have the OS shielding each process' addressspace from the other processess so that gives you some level of protection against misbehaving processes. Running apache in multiple processes therefore gives you some protection, if one of the httpd processes dies, the other processes can take over and continue to handle requests.
The use of highlevel languages & APIs (e.g. Java and it's threading facilities) addresses these stability issues and makes it safer (not perfectly safe) to use threads. Java for instance offers memory management facilities that basically prevent such things as buffer overflows or illegal memory access. This largely removes the need for the kind of memory protection an OS offers for processes.
Apache 2.0 is specifically designed to be more scalable than the 1.3.x series. Threading is a key architectural change in this respect. Sadly it is not written in Java which unlike some people on slashdot believe is very capable of competing with lower level languages in this type of server applications. Presumably the apache developers are using a few well developed C APIs to provide some protection against stability issues.