You have your regular OO program. Only you don't do the usual thing of littering with duplicate functionality for e.g. synchronization, persistance, security. This kind of code is what makes your program complex and generally requires rigid design rules in order not to blow up in your face. What AOP does instead is separate this kind functionality from your OO program into what is called an aspect.
Aspects consist of code and a pattern defining where this code is to be inserted in the OO program. This process is referred to as weaving.
Take for example logging. All large projects need this. Imagine you could just write down: for all public set methods in package X Y and Z: prior to execution write the name of the method that is called to the log. In aspectJ you'd define this functionality in a few lines of code whereas in your average OO language you would need to edit each and every public set method. In addition if you'd add a new public set method somewhere you would need to add the functionality manually. You might forget, introduce bugs (well, maybe not in logging).
Now logging is just the most simple example of an aspect. There are many more and the people at aspectj.org do a much job of explaining it than I can. So, go have a look with an open mind. Download the compiler, try the examples and use your imagination.
Hmm, you are fast with your judgement. Too fast and obviously you missed the point and didn't do your homework.
AOP is not about Java but rather a total new way of modeling & programming (obviously the general idea was lost on you), it was just implemented on top of Java as a proof of concept. The people who implemented AspectJ (one of the handfull of aspect oriented languages), made sure that it works well, integrates nicely with the language.
Indeed, AspectJ evolved from just a prototype language a few years ago to a production ready compiler and toolset. The very reason it was created was to allow for industrial validation of the ideas that are behind it. The inventor of AOP (Gregor Kiczalez), figured that in order to do so you needed more than just a prototype language.
BTW. the journal side of things is taken care of by the ACM. They recently had a special issue of Communications of the ACM on AOP. Also nearly any conference on OO systems (e.g. Ecoop, OOPSLA, ICSE) in the past few years had papers on AOP issues (validation, language and compiler issues etc.).
If you want to learn about AOP, look at the tutorial and language spec on aspectj.org. Also be sure to look at the examples they provide.
If you go to the limewire site, click on the "network size" menu option and than the "historical", you will get a nice graph of the gnutella network size. You will notice two significant increases in network size over the past few months.
The first one occured when limewire released their 2.0 client with super peer functionality. Essentially this eliminated most of the scalability issues. The second little bump occured when morpheus released their gnutella client yesterday.
Right now the graph indicates over 200K nodes in the network. I'm connected to it using the limewire client. I consider this to be one of the best gnutella GUIs but luckily there's plenty of alternatives for those who don't like it.
Two notable features are missing however (also in the new morpheus client): Browsing someone else's files (like napster used to be able to do, morpheus consistently crashed if I tried to use this feature) and displaying/searching meta information (like album or song name).
The first feature would require a change to the protocol. Limewire tried to implement it using download slots but generally there are not enough available for this to work. The second feature requires some standard way of handling queries (right now it is unspecified what a gnutella client should do with a query).
Morpheus is apparently going to switch to gnutella in their next version of their client. Due to the unexpected exclusion of their existing client of the fasttrack network the release will probably be in a couple of days.
The Gnutella protocol and the fasttrack protocol are actually very similar since limewire added superpeers. In a couple of days (when morpheus releases their gnutella stuff), gnutella will be put to the test. Theoretically it should scale at least as well as fasttrack.
Gnutella has a few advantages over fasttrack: - Gnutella is an open, simple to implement protocol. Fasttrack is a propietary implementation of a propietary protocol. Non authorized implementations are being banned from the network. - there are implementations of Gnutella in various languages for various platforms. The best are free (both in terms of speech and beer). - shutting down one gnutella client doesn't affect other clients. So if bearshare is shut down you just switch to limewire or something else and connect to the same gnutella network. - unlike fasttrack, gnutella has no dependencies on a central server. It only needs the ip of one other client in the network to connect itself. Typically clients contact a webserver to get a list of such clients, however this is optional. - It's theoretically just as scalable and potentially even more scalable (due to future innovations in clients). - Most of the clients are stable and will survive more than a few searches (morpheus consistently crashes on me)
However there are disadvantages: - Gnutella doesn't specify how to handle queries. Consequently some clients are better at this than others and you may get crappy search results. Limewire has metasearch abilities in the works which could potentially be just as good as morpheus (or better). However, until all (or most clients) on the network support this, this will be relatively useless. - The gnutella network is smaller (typically around 50000 hosts at the moment) than fasttrack at the moment.
If you want to give gnutella a try and don't want the spyware, I recommend that you don't download the windows installer but the installer for "other" platforms instead. This will get you nice Java only version without all the crap (except for ads). Also be sure to run it using the latest jdk (1.4.0) as it is somewhat faster than previous versions.
Last year when mac os X was released there was a lot of discussion on the Javalobby about whether or not mac os X was suitable for Java development. One of the concerns raised by among others me was that Apple had been rather slow in updating their JVM in the past. Having java 1.3.1 on Mac OS X is certainly useful but considering it has been out for months on Solaris, Windows and linux it's a bit late. In addition, jdk 1.4.0 was recently released for those platforms as well so when is it going to be available on the mac? This year? Next year?
Apple and Sun (I believe they are cooperating)need to speed up the development if they want to lure Java developers to their OS. It's a fine OS no doubt, but being able to run an up to date JVM is pretty essential if you are developing Java. Basically anything you start developing today will most likely be deployed on a jdk 1.4.x environment.
Windows is a commercial product. It is designed to run well on cheap, affordable computers it runs much better if you throw in an extra little cash. It's specifically not designed to run on obsolete hardware. This also means that no compromises regarding usability and configurability were made to improve performance on old hardware.
IMHO that is a good tradeoff. Running X on a PC with a decent amount of memory and processing power (basically 64MB+, 200Mhz+) is not going to put any significant load on the machine. Similarly, the average windows machine can easily handle both the GUI and server processes. If you are experiencing performance problems with your server processes because of the GUI overhead any responsible sysadmin would upgrade the hardware because getting that close to the performance limit of your hardware is bound to cause you trouble anyway (a minor increase in server load would be enough).
Don't get me wrong, I love linux and have used it on old hardware and found it served my needs perfectly. However, you really need to know your stuff to get it up and running. When it comes to configuring things windows is easy when it can be and just as hard as unix when it needs to be. Basically, for simple server stuff you can get IIS up and running relatively easy. The default setup for apache on the other hand is pretty useable out of the box but as soon as you need to tweak it even slightly you are on your own. For professionals it doesn't matter, they have the time and need to get familiar with whatever they configure. Basically this type of sysadmin is knowledgeable and expensive. You are unlikely to find one in small organizations. Instead you will find loads of inexperienced script kiddies who terrorize their users with major fuckups. If I sound frustrated its because our local sysadmin (linux) just screwed up our mailserver (suse box and some ancient solaris machine) and I'm expecting some important mails. It's not the first time and I'm afraid there's more downtime ahead.
For the casual admin who just needs to get an unfamiliar service up and running with no fuss the windows way of doing things is simply easier. The overhead of a GUI is irrelevant in any business case you can come up with (business cases also include licensing, sysadmin salaries, hw cost, training cost, etc.).
Yes, the compatibility test suite is a really good one being allowed to say you passed it (by carying the compatibility logo) is quite different from spreading the rumor that software package is generally believed to be compatible.
Effectively SUN is using their monopoly position (regarding the compatibility tests) to selectively grant licenses to market partners. IMHO the market should be open and anybody (including MS) should be allowed to attempt to pass the requirements (not necessarily for free).
Tomcat is not a J2EE implementation so there's no direct implication. In addition, it is promoted (by Sun) as a reference implementation for servlets.
If apache decides to abandon their Jakarta projects that doesn't mean these projects die. It just means that they will continue under a different flag (and there are enough interested parties to make this happen).
IMHO it would be bad for the apache foundation since most of its showcase projects (excluding the webserver) are the Jakarta projects. No doubt a significant part of their funding is related to these projects.
I nuked several debian setups this way. I've had apt-get segfaulting on me, removing stuff that I didn't want removed, installing stuff that didn't work. Of course all of this was on testing (so it really deserves that name). Potato is quite stable but completely useless due to the complete lack of packages created in this century (minus some security fixes).
I'm sure most of this could be fixed by a more experienced debian user. But the whole point is that it shouldn't need to be fixed in the first place.
A few months back we wanted to setup a small webserver for our research homepage and some dynamic stuff. Due to various reasons, our local system administrators were uncooperative to say the least so we decided to run our own box. Being extremely short on cash we settled for an old compaq PC donated to us by a company.
I had a debian potato cd around, popped it in and managed to boot from it (luckily the bios supported bootable cds, I hate floppies). I installed the base install and ran into the first problem: what type of network card is in the box. Other distros would auto discover it but debian requires you to select the right kernel module. After extensive trial and error (including removing the cover to look at the very dusty interior) I figured it out. I then brought up the network (our university has plenty of bandwidth), updated the apt sources file and installed the stuff I needed openssh (so we could then unplug the workstation monitor we borrowed), various tools (less,pico,mutt, wget,ncftp,..),apache and the jdk1.3.1 (from SUN's site). Now I hear you think: WTF is he installing Java for on a slow machine like that!!!! But it actually works well. I also installed tomcat 3.2 for servlets and managed to run a few small servlets. In terms of load it probably can't handle very much (at this time the machine was using all its memory) but for testing purposes its fine.
After that I had some fun tweaking the box. I installed X so that I could use a GUI (remote of course), KDE, Gnome. I updated the kernel. To be honest, debian is not for this kind of tweaking. It didn't take me long to fuck it up enough that I couldn't fix it anymore and didn't want to invest more time to find out how to fix it properly.
The machine served our webpages for about half a year. Then we had a hardware failure (disk died) and we never replaced it. Impressively, debian managed to keep running until I foolishly (after a week) decided to reboot to find out what was going on. We never replaced it and our website now lives on the department webserver (a rediculously old sun machine so forgive me for not posting a link here:-)
Debian is nice for small servers, it is easy to install&maintain if you know what you want and if you don't need any "testing" packages (like kernels or kde). However, it is seriously obsolete now. The woody distro is definately better in terms of features but getting it up and running is challenging (i tried a recent image using vmware last week), worst of it is that it still doesn't auto detect any hardware and comes with a 2.2 kernel by default (why is beyond me).
There is no quality advantage when displaying it. Conventional film has evolved too and is very competitive with digital projectors these days. However when you shoot digital, edit digital and distribute digital, you can avoid several conversions between digital and analog. Editing on most films is digital anyway so that's at least two conversions in the analog situation.
The real reason to convert to digital would be that production and distribution of the films would be cheaper since each copy of film costs some money and needs to be shipped to cinemas worldwide and degrades over time. However the money saved on distribution of digital copies is pretty much eliminated by the cost of digital equipment.
The only way to bring the price down is mass production and standardization. That however requires that some cinemas install the early, more expensive machines (this also applies to the newer analog systems). The public doesn't really care and therefore nothing happens.
For the same reason we still have analog tvs, analog radio, analog vcrs, etc. People don't care about the quality and the equipment is too expensive to make them care.
Things have been pretty much the same for the past 20 years so it is time for a small revolution. What will happen in the next couple of years is that the OS (i.e. the kernel + hardware drivers) will become increasingly less relevant. Once.Net, Mono or whatever VM variant really takes off, programs will be OS independent. Of course they will still be API dependent. But likely those API implementations will be portable as well.
That's one trend. The other is that mass produced cheap, networked and mobile computers will be omnipresent. They will all be running some OS (not really relevant which one) and a vm that will make them general purpose. In addition, the network bandwidth will be such that you have easy access to huge amounts of server side storage.
All you need for omnipresent access to all your music is a fat harddrive and a 196 kbps network connection to it. Video requires a bit more but at 1mbps the quality is very acceptable. Mobile networks being capable of this are already planned will very likely be deployed worldwide and widely used in 10 years.
The networks are going to happen, the hardware is happening and the software and most of the concepts needed is already available today. All we need to do is put it together, perfect it a little (remove bugs, improve security, think a little more about privacy).
The latest versions of limewire are much better since they use so-called super peers which makes gnutella very similar to the fasttrack protocol used in morpheus and kazaa. It seems that the gnutella protcol is evolving in the right direction. Especially the early versions were rather stupid and naive.
Right now gnutella's main problem is that nobody knows this, the network can easily handle the amount of users that use it, only it is competing with the much larger fasttrack network which simply has more to offer.
I'm a framemaker user too and I am also looking for alternatives, mostly because I would like a better GUI without losing the features that motivated me to use framemaker.
Even though I'm in a win32 environment, ms word is out of the question for me. I've simply lost too much time recovering images, fixing severe layout issues and working around the many very annoying bugs this word processor has (anyone who has ever tried to keep a figure caption under a figure knows what I'm talking about, it is possible but requires several non trivial measures). I became a framemaker user after word automatically rearranged my master thesis, throwing away all images in the process. That was the last one in a long range of time consuming incidents.
Framemaker doesn't have such inconsistencies. It sure has some strange quirks and severe useability issues but it manages to get the job done reliably. I've worked with it a lot and have learned to work around most of these issues.
I believe star office 6.0 could replace it. Right now it is probably too buggy but it hasn't been released yet. What's important is that it has an open file format (just like framemaker) so it is possible to create conversion tools, it has a reasonably friendly GUI, it is feature rich (including a db for literature references!!)and it's open source (meaning that the more annoying bugs get eliminated by annoyed users).
It's not the ms word killer many believe it to be since that would require much more features and polishing (like it or not, the ms word UI is a pleasure. If only it would work consistently). I'm hoping someone will write coverter for framemaker documents that will preserve a documents structure and crossreferences. Once you have that, the layout can be fixed in a relatively short amount of time so I don't care as much about correct conversion of that.
When I program there's several kinds of resources I use for my information:
- API documentation. Here a deadtree version is useless to me since I prefer a searchable, online version instead. Integration with the IDE makes life even better (highlight with mouse and jump to documentation). Books with API documentation are usually pretty much obsolete by the time they get in print (recent example: core java II just got released and discusses the 1.3 api. The most current version is 1.3.1 and 1.4 is to be released in a few weeks).
- Code examples/tutorials. Cut & paste is really useful here + you basically can't have enough of this kind of information (way more than would fit in a book) -> no use for dead trees here either.
- Background information, in depth discussions of harder issues. Here dead trees can be useful but I generally prefer short articles or or even newsgroup discussions (i love google).
>Doesn't matter if it's 1.0. It'll just be another release.
That is a common mistake. However, lots of people are waiting for 1.0:
- End users who just want something stable. A 1.0 version label is a good indication that at least developers trust it to be stable and usable. And yes I know it has been usable pretty much since the 0.7x versions.
- 3rd party component developers/ plugin developers. They need stable APIs -> 1.0 will be a stable API.
- Gecko based browser developers who have been faced with a moving target for the past few years.
- The mozilla people. They've been criticized a lot for feature creep and not delivering a product. A 1.0 release will end that and allow them to focus on new features rather than producing a 1.0.
So you bought an expensive motherboard and replaced the cpu a few months after you bought it. But you just said cpu power is irrelevant for game performance so why bother?
The reason almost nobody puts a geforce 3 in a pentium II 233 is that its an upgrade that costs way too much for the performance gain. If you have that kind of money you are likely to have money for a more modern pc as well. I actually ran the early demos of unreal tournament on my PII 233 with a riva 128 (software rendering only). Even though it was painfully slow it was playable. On my current PC it runs smoothly at a modest resolution of 800x600. The game does not become more entertaining if you put in more expensive hardware which is why I'm still sticking with the voodoo 3.
Whether you own a geforce 2 or 3 is pretty much irrelevant for most games I know. My voodoo 3 is pretty crappy by todays standards but it still plays wolfenstein, quake 1,2,3, unreal (tournament) and many more games just fine. The driver issues are annoying but can be resolved with a little technical knowhow.
The nice thing about voodoo cards is that most game developers test against it (even though 3dfx no longer exists). My previous pc had an nvidia riva128 which was a fantastic card that was unfortunately poorly supported by most games (unreal 1 for instance ran much better on the inferior voodoo 1). These days I'd definately want a low end nvidia card since they are market leader.
A geforce 3 was overkill a year ago and it still is for most games today. Of course somebody who just wants the best doesn't care about the price of a video card and will buy a geforce ti 500 anyway. However I would recommend against buying one to be prepared for future games because when those games arrive the required hardware will be much cheaper and your ti 500 will be old news anyway.
Dropping a high end card in an old box is nuts since most games that actually require such a card also require high end cpus. Of course, if you insist on running quake 3@1600x1200@200fps you can't have enough hardware but most people would be more than happy running it at 1024x768 with around 40-50fps. Last years budget cards provide that kind of performance for most games on the market today.
I've never considered upgrading a PC a good alternative since invariably I end up replacing most components in the box to get what I want and buying a new box gives me much better performance at just a slightly higher price. The PC I currently have (PIII500, 512 MB and said voodoo 3 card) runs everything I need to run with an acceptable performance level. I have considered upgrading it a few times but its just not worth my money to get a few more fps.
NVidia and ATI would very much like us to buy their video cards in order to be able to run next years games. If you read this review well you cannot come to another conclusion that anybody who bought a gforce 3 card last year has been wasting money since until next year there won't be any games taking advantage of it. By then, the hardware required to run these games will be much cheaper and the same money wasted on a geforce 3 last year will buy you much more performance when you will actually be able to use it.
My two year old pc has a voodoo 3 3000 which at the time was a relatively cheap card. It runs wolfenstein 3d just fine (ok barely but it's playable) so I consider it to be a good investment. If in a year or so Unreal II is released I'll upgrade my pc to be able to run it and invest some money in a good enough video card (I'll settle for full featured unreal 2@1024x768@35fps) and I'll be able to run any game to be released until 2004/2005.
I don't see how you could develop without doing internal reuse these days. However, the distinction between internal and external is fading anyway.
The days that you could start from scratch for a each new product are gone. Many companies are currently finding out the hard way that the cost of that is too much. Take Nokia for example. They produce around 30 or so different mobile phones each year. Each of these phones contains a few million lines of code in software. Obviously, Nokia does not start from scratch for each new phone. Rather they taylor and extend their previous generation software and use it in the next generation phone. The better the design of the old software the easier it is to add new features. Getting new features out a few months before the competitor is critical in the mobile phone industry (one of the reasons Ericsson is having so much trouble).
The type of blackboard reuse you are talking about is very hard to achieve. Basically COTS is a myth except for some generic GUI components and low level stuff like XML parsing. The problem is that creating a reusable component requires knowledge in advance of the requirements it needs to meet. Something every software developer knows is that unexpected requirements will pop up. Hence you will find yourself editing your carefully designed components after some time. Especially when you use your old components in a new product you will find that the requirements are different and that your components do not match 100% in the new situation.
This is why you need a good design: to limit the impact of these inevitable changes.
No sane software architect is going to unleash a fresh college graduate on his multi million dollars worth of software. Expect to do relatively uninteresting work like e.g. testing for a while if you are hired by a company doing embedded systems development.
Only when you prove your skills internally will they let you do some more interesting work. Also keep in mind that for the more cool kinds of jobs in companies doing embedded development there is quite a bit of competition internally. Nobody wants to do testing forever and the more experienced people usually end up getting the more interesting jobs simply because they are better at it and know the system better (it typically takes years to master even modestly sized systems).
Time to market these days means being able to reuse and adapt the previous product's software as quickly as possible. A good design is essential for that and companies that don't do good design are outcompeted by companies who manage to produce better quality software in a shorter timeframe.
The reality of today is that software systems are very large (think millions of lines of code) that represent an investment of many manyears. A quick fix on such code can have a desastrous impact on the time to market of future products. I know of companies that effectively did not bring out new products for two years because they were busy redesigning their software in order to be able to meet future requirements(Netscape is a good example in the public domain).
One of the reasons Java is currently so successful and has seen a quicker time to market than.Net (which has yet to come to market) is good design. Sun spent a great deal of time thinking about security and flexibility as early as 1995. This investment has allowed Java to mature well before MS managed to get anything significant to market. SUN is actively working with industry partners in its much criticized JCP process. MS on the other hand is dictating standards. MS gets its standards out quicker but the ones that get through the JCP process are of such a quality that they are causing MS some very big headaches in for example the mobile applications domain.
I am from the academic world and (pretty rare for an acadamic) I frequently visit software developing companies to gather information for my research. The more successful of these companies invariably have very clever software designers in charge of the software development. Also these companies are very much aware that the quality of their software is their competitive edge.
Slashdot Mirror
Sure,
You have your regular OO program. Only you don't do the usual thing of littering with duplicate functionality for e.g. synchronization, persistance, security. This kind of code is what makes your program complex and generally requires rigid design rules in order not to blow up in your face. What AOP does instead is separate this kind functionality from your OO program into what is called an aspect.
Aspects consist of code and a pattern defining where this code is to be inserted in the OO program. This process is referred to as weaving.
Take for example logging. All large projects need this. Imagine you could just write down: for all public set methods in package X Y and Z: prior to execution write the name of the method that is called to the log. In aspectJ you'd define this functionality in a few lines of code whereas in your average OO language you would need to edit each and every public set method. In addition if you'd add a new public set method somewhere you would need to add the functionality manually. You might forget, introduce bugs (well, maybe not in logging).
Now logging is just the most simple example of an aspect. There are many more and the people at aspectj.org do a much job of explaining it than I can. So, go have a look with an open mind. Download the compiler, try the examples and use your imagination.
Hmm, you are fast with your judgement. Too fast and obviously you missed the point and didn't do your homework.
AOP is not about Java but rather a total new way of modeling & programming (obviously the general idea was lost on you), it was just implemented on top of Java as a proof of concept. The people who implemented AspectJ (one of the handfull of aspect oriented languages), made sure that it works well, integrates nicely with the language.
Indeed, AspectJ evolved from just a prototype language a few years ago to a production ready compiler and toolset. The very reason it was created was to allow for industrial validation of the ideas that are behind it. The inventor of AOP (Gregor Kiczalez), figured that in order to do so you needed more than just a prototype language.
BTW. the journal side of things is taken care of by the ACM. They recently had a special issue of Communications of the ACM on AOP. Also nearly any conference on OO systems (e.g. Ecoop, OOPSLA, ICSE) in the past few years had papers on AOP issues (validation, language and compiler issues etc.).
If you want to learn about AOP, look at the tutorial and language spec on aspectj.org. Also be sure to look at the examples they provide.
It's doing fine so far.
If you go to the limewire site, click on the "network size" menu option and than the "historical", you will get a nice graph of the gnutella network size. You will notice two significant increases in network size over the past few months.
The first one occured when limewire released their 2.0 client with super peer functionality. Essentially this eliminated most of the scalability issues. The second little bump occured when morpheus released their gnutella client yesterday.
Right now the graph indicates over 200K nodes in the network. I'm connected to it using the limewire client. I consider this to be one of the best gnutella GUIs but luckily there's plenty of alternatives for those who don't like it.
Two notable features are missing however (also in the new morpheus client): Browsing someone else's files (like napster used to be able to do, morpheus consistently crashed if I tried to use this feature) and displaying/searching meta information (like album or song name).
The first feature would require a change to the protocol. Limewire tried to implement it using download slots but generally there are not enough available for this to work. The second feature requires some standard way of handling queries (right now it is unspecified what a gnutella client should do with a query).
Silly me, I was of course referring to the limewire client in the last paragraph of my previous post.
IMHO still the best client but feel free to disagree.
Morpheus is apparently going to switch to gnutella in their next version of their client. Due to the unexpected exclusion of their existing client of the fasttrack network the release will probably be in a couple of days.
The Gnutella protocol and the fasttrack protocol are actually very similar since limewire added superpeers. In a couple of days (when morpheus releases their gnutella stuff), gnutella will be put to the test. Theoretically it should scale at least as well as fasttrack.
Gnutella has a few advantages over fasttrack:
- Gnutella is an open, simple to implement protocol. Fasttrack is a propietary implementation of a propietary protocol. Non authorized implementations are being banned from the network.
- there are implementations of Gnutella in various languages for various platforms. The best are free (both in terms of speech and beer).
- shutting down one gnutella client doesn't affect other clients. So if bearshare is shut down you just switch to limewire or something else and connect to the same gnutella network.
- unlike fasttrack, gnutella has no dependencies on a central server. It only needs the ip of one other client in the network to connect itself. Typically clients contact a webserver to get a list of such clients, however this is optional.
- It's theoretically just as scalable and potentially even more scalable (due to future innovations in clients).
- Most of the clients are stable and will survive more than a few searches (morpheus consistently crashes on me)
However there are disadvantages:
- Gnutella doesn't specify how to handle queries. Consequently some clients are better at this than others and you may get crappy search results. Limewire has metasearch abilities in the works which could potentially be just as good as morpheus (or better). However, until all (or most clients) on the network support this, this will be relatively useless.
- The gnutella network is smaller (typically around 50000 hosts at the moment) than fasttrack at the moment.
If you want to give gnutella a try and don't want the spyware, I recommend that you don't download the windows installer but the installer for "other" platforms instead. This will get you nice Java only version without all the crap (except for ads). Also be sure to run it using the latest jdk (1.4.0) as it is somewhat faster than previous versions.
Good, I was misinformed. So what's the fuss about here on slasdot?
Last year when mac os X was released there was a lot of discussion on the Javalobby about whether or not mac os X was suitable for Java development. One of the concerns raised by among others me was that Apple had been rather slow in updating their JVM in the past. Having java 1.3.1 on Mac OS X is certainly useful but considering it has been out for months on Solaris, Windows and linux it's a bit late. In addition, jdk 1.4.0 was recently released for those platforms as well so when is it going to be available on the mac? This year? Next year?
Apple and Sun (I believe they are cooperating)need to speed up the development if they want to lure Java developers to their OS. It's a fine OS no doubt, but being able to run an up to date JVM is pretty essential if you are developing Java. Basically anything you start developing today will most likely be deployed on a jdk 1.4.x environment.
Windows is a commercial product. It is designed to run well on cheap, affordable computers it runs much better if you throw in an extra little cash. It's specifically not designed to run on obsolete hardware. This also means that no compromises regarding usability and configurability were made to improve performance on old hardware.
IMHO that is a good tradeoff. Running X on a PC with a decent amount of memory and processing power (basically 64MB+, 200Mhz+) is not going to put any significant load on the machine. Similarly, the average windows machine can easily handle both the GUI and server processes. If you are experiencing performance problems with your server processes because of the GUI overhead any responsible sysadmin would upgrade the hardware because getting that close to the performance limit of your hardware is bound to cause you trouble anyway (a minor increase in server load would be enough).
Don't get me wrong, I love linux and have used it on old hardware and found it served my needs perfectly. However, you really need to know your stuff to get it up and running. When it comes to configuring things windows is easy when it can be and just as hard as unix when it needs to be. Basically, for simple server stuff you can get IIS up and running relatively easy. The default setup for apache on the other hand is pretty useable out of the box but as soon as you need to tweak it even slightly you are on your own. For professionals it doesn't matter, they have the time and need to get familiar with whatever they configure. Basically this type of sysadmin is knowledgeable and expensive. You are unlikely to find one in small organizations. Instead you will find loads of inexperienced script kiddies who terrorize their users with major fuckups. If I sound frustrated its because our local sysadmin (linux) just screwed up our mailserver (suse box and some ancient solaris machine) and I'm expecting some important mails. It's not the first time and I'm afraid there's more downtime ahead.
For the casual admin who just needs to get an unfamiliar service up and running with no fuss the windows way of doing things is simply easier. The overhead of a GUI is irrelevant in any business case you can come up with (business cases also include licensing, sysadmin salaries, hw cost, training cost, etc.).
Yes, the compatibility test suite is a really good one being allowed to say you passed it (by carying the compatibility logo) is quite different from spreading the rumor that software package is generally believed to be compatible.
Effectively SUN is using their monopoly position (regarding the compatibility tests) to selectively grant licenses to market partners. IMHO the market should be open and anybody (including MS) should be allowed to attempt to pass the requirements (not necessarily for free).
Tomcat is not a J2EE implementation so there's no direct implication. In addition, it is promoted (by Sun) as a reference implementation for servlets.
If apache decides to abandon their Jakarta projects that doesn't mean these projects die. It just means that they will continue under a different flag (and there are enough interested parties to make this happen).
IMHO it would be bad for the apache foundation since most of its showcase projects (excluding the webserver) are the Jakarta projects. No doubt a significant part of their funding is related to these projects.
I nuked several debian setups this way. I've had apt-get segfaulting on me, removing stuff that I didn't want removed, installing stuff that didn't work. Of course all of this was on testing (so it really deserves that name). Potato is quite stable but completely useless due to the complete lack of packages created in this century (minus some security fixes).
I'm sure most of this could be fixed by a more experienced debian user. But the whole point is that it shouldn't need to be fixed in the first place.
A few months back we wanted to setup a small webserver for our research homepage and some dynamic stuff. Due to various reasons, our local system administrators were uncooperative to say the least so we decided to run our own box. Being extremely short on cash we settled for an old compaq PC donated to us by a company.
,apache and the jdk1.3.1 (from SUN's site). Now I hear you think: WTF is he installing Java for on a slow machine like that!!!! But it actually works well. I also installed tomcat 3.2 for servlets and managed to run a few small servlets. In terms of load it probably can't handle very much (at this time the machine was using all its memory) but for testing purposes its fine.
:-)
I had a debian potato cd around, popped it in and managed to boot from it (luckily the bios supported bootable cds, I hate floppies). I installed the base install and ran into the first problem: what type of network card is in the box. Other distros would auto discover it but debian requires you to select the right kernel module. After extensive trial and error (including removing the cover to look at the very dusty interior) I figured it out. I then brought up the network (our university has plenty of bandwidth), updated the apt sources file and installed the stuff I needed openssh (so we could then unplug the workstation monitor we borrowed), various tools (less,pico,mutt, wget,ncftp,..)
After that I had some fun tweaking the box. I installed X so that I could use a GUI (remote of course), KDE, Gnome. I updated the kernel. To be honest, debian is not for this kind of tweaking. It didn't take me long to fuck it up enough that I couldn't fix it anymore and didn't want to invest more time to find out how to fix it properly.
The machine served our webpages for about half a year. Then we had a hardware failure (disk died) and we never replaced it. Impressively, debian managed to keep running until I foolishly (after a week) decided to reboot to find out what was going on. We never replaced it and our website now lives on the department webserver (a rediculously old sun machine so forgive me for not posting a link here
Debian is nice for small servers, it is easy to install&maintain if you know what you want and if you don't need any "testing" packages (like kernels or kde). However, it is seriously obsolete now. The woody distro is definately better in terms of features but getting it up and running is challenging (i tried a recent image using vmware last week), worst of it is that it still doesn't auto detect any hardware and comes with a 2.2 kernel by default (why is beyond me).
There is no quality advantage when displaying it. Conventional film has evolved too and is very competitive with digital projectors these days. However when you shoot digital, edit digital and distribute digital, you can avoid several conversions between digital and analog. Editing on most films is digital anyway so that's at least two conversions in the analog situation.
The real reason to convert to digital would be that production and distribution of the films would be cheaper since each copy of film costs some money and needs to be shipped to cinemas worldwide and degrades over time. However the money saved on distribution of digital copies is pretty much eliminated by the cost of digital equipment.
The only way to bring the price down is mass production and standardization. That however requires that some cinemas install the early, more expensive machines (this also applies to the newer analog systems). The public doesn't really care and therefore nothing happens.
For the same reason we still have analog tvs, analog radio, analog vcrs, etc. People don't care about the quality and the equipment is too expensive to make them care.
Things have been pretty much the same for the past 20 years so it is time for a small revolution. What will happen in the next couple of years is that the OS (i.e. the kernel + hardware drivers) will become increasingly less relevant. Once .Net, Mono or whatever VM variant really takes off, programs will be OS independent. Of course they will still be API dependent. But likely those API implementations will be portable as well.
That's one trend. The other is that mass produced cheap, networked and mobile computers will be omnipresent. They will all be running some OS (not really relevant which one) and a vm that will make them general purpose. In addition, the network bandwidth will be such that you have easy access to huge amounts of server side storage.
All you need for omnipresent access to all your music is a fat harddrive and a 196 kbps network connection to it. Video requires a bit more but at 1mbps the quality is very acceptable. Mobile networks being capable of this are already planned will very likely be deployed worldwide and widely used in 10 years.
The networks are going to happen, the hardware is happening and the software and most of the concepts needed is already available today. All we need to do is put it together, perfect it a little (remove bugs, improve security, think a little more about privacy).
The latest versions of limewire are much better since they use so-called super peers which makes gnutella very similar to the fasttrack protocol used in morpheus and kazaa. It seems that the gnutella protcol is evolving in the right direction. Especially the early versions were rather stupid and naive.
Right now gnutella's main problem is that nobody knows this, the network can easily handle the amount of users that use it, only it is competing with the much larger fasttrack network which simply has more to offer.
I'm a framemaker user too and I am also looking for alternatives, mostly because I would like a better GUI without losing the features that motivated me to use framemaker.
Even though I'm in a win32 environment, ms word is out of the question for me. I've simply lost too much time recovering images, fixing severe layout issues and working around the many very annoying bugs this word processor has (anyone who has ever tried to keep a figure caption under a figure knows what I'm talking about, it is possible but requires several non trivial measures). I became a framemaker user after word automatically rearranged my master thesis, throwing away all images in the process. That was the last one in a long range of time consuming incidents.
Framemaker doesn't have such inconsistencies. It sure has some strange quirks and severe useability issues but it manages to get the job done reliably. I've worked with it a lot and have learned to work around most of these issues.
I believe star office 6.0 could replace it. Right now it is probably too buggy but it hasn't been released yet. What's important is that it has an open file format (just like framemaker) so it is possible to create conversion tools, it has a reasonably friendly GUI, it is feature rich (including a db for literature references!!)and it's open source (meaning that the more annoying bugs get eliminated by annoyed users).
It's not the ms word killer many believe it to be since that would require much more features and polishing (like it or not, the ms word UI is a pleasure. If only it would work consistently). I'm hoping someone will write coverter for framemaker documents that will preserve a documents structure and crossreferences. Once you have that, the layout can be fixed in a relatively short amount of time so I don't care as much about correct conversion of that.
When I program there's several kinds of resources I use for my information:
- API documentation. Here a deadtree version is useless to me since I prefer a searchable, online version instead. Integration with the IDE makes life even better (highlight with mouse and jump to documentation). Books with API documentation are usually pretty much obsolete by the time they get in print (recent example: core java II just got released and discusses the 1.3 api. The most current version is 1.3.1 and 1.4 is to be released in a few weeks).
- Code examples/tutorials. Cut & paste is really useful here + you basically can't have enough of this kind of information (way more than would fit in a book) -> no use for dead trees here either.
- Background information, in depth discussions of harder issues. Here dead trees can be useful but I generally prefer short articles or or even newsgroup discussions (i love google).
>Doesn't matter if it's 1.0. It'll just be another release.
That is a common mistake. However, lots of people are waiting for 1.0:
- End users who just want something stable. A 1.0 version label is a good indication that at least developers trust it to be stable and usable. And yes I know it has been usable pretty much since the 0.7x versions.
- 3rd party component developers/ plugin developers. They need stable APIs -> 1.0 will be a stable API.
- Gecko based browser developers who have been faced with a moving target for the past few years.
- The mozilla people. They've been criticized a lot for feature creep and not delivering a product. A 1.0 release will end that and allow them to focus on new features rather than producing a 1.0.
That in short is why a 1.0 is so important.
So you bought an expensive motherboard and replaced the cpu a few months after you bought it. But you just said cpu power is irrelevant for game performance so why bother?
The reason almost nobody puts a geforce 3 in a pentium II 233 is that its an upgrade that costs way too much for the performance gain. If you have that kind of money you are likely to have money for a more modern pc as well. I actually ran the early demos of unreal tournament on my PII 233 with a riva 128 (software rendering only). Even though it was painfully slow it was playable. On my current PC it runs smoothly at a modest resolution of 800x600. The game does not become more entertaining if you put in more expensive hardware which is why I'm still sticking with the voodoo 3.
Yeah that's right :-). But it runs wolf 3d fine too!!
Whether you own a geforce 2 or 3 is pretty much irrelevant for most games I know. My voodoo 3 is pretty crappy by todays standards but it still plays wolfenstein, quake 1,2,3, unreal (tournament) and many more games just fine. The driver issues are annoying but can be resolved with a little technical knowhow.
The nice thing about voodoo cards is that most game developers test against it (even though 3dfx no longer exists). My previous pc had an nvidia riva128 which was a fantastic card that was unfortunately poorly supported by most games (unreal 1 for instance ran much better on the inferior voodoo 1). These days I'd definately want a low end nvidia card since they are market leader.
A geforce 3 was overkill a year ago and it still is for most games today. Of course somebody who just wants the best doesn't care about the price of a video card and will buy a geforce ti 500 anyway. However I would recommend against buying one to be prepared for future games because when those games arrive the required hardware will be much cheaper and your ti 500 will be old news anyway.
Dropping a high end card in an old box is nuts since most games that actually require such a card also require high end cpus. Of course, if you insist on running quake 3@1600x1200@200fps you can't have enough hardware but most people would be more than happy running it at 1024x768 with around 40-50fps. Last years budget cards provide that kind of performance for most games on the market today.
I've never considered upgrading a PC a good alternative since invariably I end up replacing most components in the box to get what I want and buying a new box gives me much better performance at just a slightly higher price. The PC I currently have (PIII500, 512 MB and said voodoo 3 card) runs everything I need to run with an acceptable performance level. I have considered upgrading it a few times but its just not worth my money to get a few more fps.
NVidia and ATI would very much like us to buy their video cards in order to be able to run next years games. If you read this review well you cannot come to another conclusion that anybody who bought a gforce 3 card last year has been wasting money since until next year there won't be any games taking advantage of it. By then, the hardware required to run these games will be much cheaper and the same money wasted on a geforce 3 last year will buy you much more performance when you will actually be able to use it.
My two year old pc has a voodoo 3 3000 which at the time was a relatively cheap card. It runs wolfenstein 3d just fine (ok barely but it's playable) so I consider it to be a good investment. If in a year or so Unreal II is released I'll upgrade my pc to be able to run it and invest some money in a good enough video card (I'll settle for full featured unreal 2@1024x768@35fps) and I'll be able to run any game to be released until 2004/2005.
I don't see how you could develop without doing internal reuse these days. However, the distinction between internal and external is fading anyway.
The days that you could start from scratch for a each new product are gone. Many companies are currently finding out the hard way that the cost of that is too much. Take Nokia for example. They produce around 30 or so different mobile phones each year. Each of these phones contains a few million lines of code in software. Obviously, Nokia does not start from scratch for each new phone. Rather they taylor and extend their previous generation software and use it in the next generation phone. The better the design of the old software the easier it is to add new features. Getting new features out a few months before the competitor is critical in the mobile phone industry (one of the reasons Ericsson is having so much trouble).
The type of blackboard reuse you are talking about is very hard to achieve. Basically COTS is a myth except for some generic GUI components and low level stuff like XML parsing. The problem is that creating a reusable component requires knowledge in advance of the requirements it needs to meet. Something every software developer knows is that unexpected requirements will pop up. Hence you will find yourself editing your carefully designed components after some time. Especially when you use your old components in a new product you will find that the requirements are different and that your components do not match 100% in the new situation.
This is why you need a good design: to limit the impact of these inevitable changes.
No sane software architect is going to unleash a fresh college graduate on his multi million dollars worth of software. Expect to do relatively uninteresting work like e.g. testing for a while if you are hired by a company doing embedded systems development.
Only when you prove your skills internally will they let you do some more interesting work. Also keep in mind that for the more cool kinds of jobs in companies doing embedded development there is quite a bit of competition internally. Nobody wants to do testing forever and the more experienced people usually end up getting the more interesting jobs simply because they are better at it and know the system better (it typically takes years to master even modestly sized systems).
Time to market these days means being able to reuse and adapt the previous product's software as quickly as possible. A good design is essential for that and companies that don't do good design are outcompeted by companies who manage to produce better quality software in a shorter timeframe.
.Net (which has yet to come to market) is good design. Sun spent a great deal of time thinking about security and flexibility as early as 1995. This investment has allowed Java to mature well before MS managed to get anything significant to market. SUN is actively working with industry partners in its much criticized JCP process. MS on the other hand is dictating standards. MS gets its standards out quicker but the ones that get through the JCP process are of such a quality that they are causing MS some very big headaches in for example the mobile applications domain.
The reality of today is that software systems are very large (think millions of lines of code) that represent an investment of many manyears. A quick fix on such code can have a desastrous impact on the time to market of future products. I know of companies that effectively did not bring out new products for two years because they were busy redesigning their software in order to be able to meet future requirements(Netscape is a good example in the public domain).
One of the reasons Java is currently so successful and has seen a quicker time to market than
I am from the academic world and (pretty rare for an acadamic) I frequently visit software developing companies to gather information for my research. The more successful of these companies invariably have very clever software designers in charge of the software development. Also these companies are very much aware that the quality of their software is their competitive edge.