Discussions like this show that browser wars are back on the agenda. IMHO that is largely the result of Mozilla adoption which has a modest but growing market share (yes also on my desktop). For a while the browser field has been fragmented you had netscape 3.x, 4.x, opera, mozilla milestones, various IE versions, konqueror. However, the non IE versions are all becoming more and more standards compliant (or disappearing). So effectively there's only two camps: the standards compliant camp and the MS camp.
While the latter camp has the largest marketshare (95% according to some sources), the standards compliant share is made up of a group of very active net users (mostly techies) who do a lot of online shopping, browse a lot of sites and see a lot of ads. For that reason, webdevelopers have an interest in keeping that part of the internet community happy and adhering to standards enough to make their sites usable in alternative browsers.
I've installed it at home and at work. The only problem is that there are very few ported X applications to run with it and most things do not compile out of the box.
I'm running it with a port of windowmaker in fullscreen mode and it looks great. However, the thrill of running xcalc and xclock on windows xp wears off quickly:-). You can of course use it to run remote applications on a unix server (this works perfect).
Another issue I found is that it is not possible to cut and paste between X apps and windows apps. So if you are surfing using mozilla or IE and want to paste some command from a howto into your xterm, you have a problem. You can paste into a bash terminal (i.e. outside X).
The cygwin installation is pretty smooth (lots of great stuff other than X too). However you do need to set a path to/usr/X11R6/bin manually before you can type startx in bash. In addition you'll want to change the windowmanager (windowmaker works fine for me). Configuring X on windows XP is actually easier than on linux:-).
The likely scenario Walmart is counting on is that users buy the machine, even though both are aware that lindows is crap. Once home, the user pops in one of those windows setup cds (e.g. borrowed from neighbour).
What won't happen is that linux users will buy this machine and pop in a mandrake or debian cd. The reason is that linux users generally spend more money on their hardware and are unlikely to want a low budget PC.
In any case, Lindows is indeed likely to fail unless they add loads of value to their product. Right now any user friendly linux distribution beats them easily (Mandrake, Suse,...) and if there's only a slight sign of pre-installed linux working, they'll jump on it.
Get your facts straight. One of the first high quality xml parsers was xml4j from IBM. I used it nearly four years ago. At the time there were very few xml parsers and Java was about your only option if you wanted to do XML.
A quote from the Xerces pages: The Xerces Java Parser 1.4.4 supports the XML 1.0 recommendation and contains advanced parser functionality, such as support for the W3C's XML Schema recommendation version 1.0, DOM Level 2 version 1.0, and SAX Version 2, in addition to supporting the industry-standard DOM Level 1 and SAX version 1 APIs.
Note that because some of the standards are still not complete, the stable API will definitely be different from its current form in Xerces-J 1.4.4. This is your chance to give us feedback on the features that are important to you, and let us know whether the APIs that we are providing are the right ones. Please direct your feedback to the Xerces-J mailing list.
As you can see Xerces supports all the latest standards and even appologizes that some of the API calls will change because the standards are not stable yet. The moment these standards stabilize the 'mature' options you mention will of course suffer from the same problem. However, it wouldn't surprise me if xerces was updated first.
Regarding soap, there are many java implementations from, among others, apache and IBM.
So in reply to your comments, Java XML: - Java usually is among the first languages to support XML related w3c standards. Third parties like apache and IBM play an important role here. - Java is actually pretty damn fast (hence the popularity of server side Java). - Very mature (see first two points) - Standards compliant.
I fully agree with your comments regarding the necessity of IDEs. Though, given your comments about visual cafe it is very clear that you haven't tried any of the fancy Java IDEs released in the new milennium since VC is long gone (hint, try Idea or Eclipse for a change). Of course with.Net you only have one realistic option: visual studio.
The reviewer seems to be worried about the information density in this book. I would say it is a good thing that this book doesn't bother explaining how to compile hello world. If you don't understand the Java syntax, you're reading the wrong book.
Another good thing is that it doesn't include API documentation. API documentation seems to be a popular way of wasting dead trees but IMHO it is much easier to browse/search in HTML form. That leaves more room to content you'll actually need. There's so many Java books out there that use more than half of the pages for introductory stuff and API documentation and then try to squeeze the stuff you really need in ten pages or so.
The calendar project is very much unfinished work, I don't think it would be a good idea to distribute it to non technical users right now. Currently the work seems to focus on getting the basic features of a calendering tool right. I suspect it will take quite a bit of time before somebody will start thinking about how to export to specific PDAs.
The tool itself looks really cool already (a zoom option would be nice, I don't like scrolling) and no doubt it will continue to develop rapidly. I think that it will be moved into the Mozilla source tree once it is in a more useable state. I don't think that that will happen before 1.1, though.
Server performance has more to do with IO overhead than with execution speed. BTW. part of the coolness of java on the serverside is being able to use stuff like loadbalancing, caching, etc. in a more or less transparent way.
Hardware acceleration makes sense on embedded platforms where there are not enough resources to properly do on the fly compilation and optization (basically a non issue on servers).
As for your comments regarding pocketlinux, I suspect they were simply outcompeted by other pda oses who managed to produce a more usable os & apps. Users don't care about kernels, they do care about whether they can do stuff on a PDA: read mail, edit word documents, read pdf, manage agenda's, synchronize with popular pc applicatins, etc.
I downloaded and installed OOo right after it was released. I generally like the software. However, there is one show stopper issue that keeps me from migrating completely. It is currently not possible to make crossreferences to paragraph numbers. If for instance you have a document with a numbered list of references at the end, it is not possible to insert a cross-reference in the text to one of these numbers. The same applies to tables, figures, sections, formulas and headings.
Since I write scientific articles and need to be able to do all of the above, I can't use OOo (I use framemaker right now). I checked with issuezilla and this is something they are aware of, even though there doesn't seem to be much activity on the issue. I really hope they fix this soon.
Ok, now you're saying something else. Maybe you've discovered a bug in the JDK or something that maybe affects one or two applets. That is something else than claiming that thousands of applets suddenly stop working.
There's no one size fits all process for testing. How much effort you need to spend on testing depends on a lot of factors including but certainly not limited to: code size, amount of developers, customer requirements, life cycle of the system etc.
That being said, here are some remarks that make sense for any project:
In general a testing procedure that gives you no defects just indicates your testing procedure is bogus: defect free code does not exist and no test procedure (especially no automated procedure) will reveal all defects.
The XP way of determining when a product is good enough: write a test for a feature before you write code. If your code passes the test it is good enough. This makes sense and I have seen it applied successfully.
A second guideline is to write regression tests: when you fix a bug, write an automated test so you can avoid this bug in the future. Regression tests should be run as often as possible (e.g. on nightly builds). All large software organizations I've encountered do this. Combined with the first approach this will provide you with a growing set of automated tests that will assure your code is doing what its supposed to do without breaking stuff.
Thirdly, make sure code is reviewed (by an expert and not the new script kiddie on the block) before it is checked in. Don't accept code that is not up to the preset standards. Once you start accepting bad code you're code base will start to deteriorate rapidly.
In short, unless you have a very good reason (i.e. you know what you are doing) to write your own parsers, you should be using a parser generator (use google with the right keywords and you will find plenty of resources) or regular expressions (for the simple stuff, again: google is your best friend).
SUNs JVM is very much compatible even with the old 1.0.2 and 1.1 jvms. It is just that the MS implementation never was compatible (this is MS'fault) and that people wrote applets for that non compliant JVM and forgot to properly test their stuff with compliant JVMs. Sad, but you can't blame SUN for that. They certainly did everything to make MS comply with the standard they licensed.
I'm running jdk1.4.0 and it runs most applets I encounter just fine in internet explorer and mozilla. If a particular applet doesn't work that means that its developer hasn't bothered to update the code in years and doesn't care about non IE/MS JVM users. That should make you wonder whether you actually want to run such old, obsolete, abandoned code. I couldn't care less.
Re:rpm/deb solves the wrong problem
on
Is RPM Doomed?
·
· Score: 2
Been there, done that. Lets just say it does not work as advertised. IMHO it fully deserves the label unstable.
Than the next obvious question would be which file system structure. Which immediately poses the question what distribution to standardize on which in turn makes it very clear that the first is infeasible.
The problem (depending on your point of view) with OSS is that you cannot require developers to work in a certain way. Attempting to do so usually results in flamewars. OSS projects exist because the members don't like similar OSS projects and decide to do things their way.
Re:rpm/deb solves the wrong problem
on
Is RPM Doomed?
·
· Score: 2
Eeeew!!!!, compile time fixing of deployment directories! Compilation != configuration management. The fact that it is for most unix programs is the problem, not the solution.
A registry would be the simple solution. A better solution is an ldap configuration database. Information like where icons are supposed to go should come from such a database, not from compile time flags and certainly not from a binary package.
rpm/deb solves the wrong problem
on
Is RPM Doomed?
·
· Score: 4, Insightful
The key to figuring out why a particular solution is not working is trying to figure out what problem it is trying to solve. Why do we need a package format like rpm? Because linux applications tend to consist of a lot of files which need to be put in the right places. Doing this manually takes time and is error prone. Types of files may be icons, images, executables, man pages, fonts,.... In addition to these files scripts are bundled that may do configuration, clean up after removal, move files to the right directory etc. Making this work requires that the creator of the package makes a lot of assumptions like where do icons go on this system? What is the right place for an executable? Where do the man pages go? How do I add a menu item to whatever window manager is installed?...
Efforts to improve package system have focused on providing answers to such questions: standardization. Standardization is good but if you take a step back you realize that it is not relevant to provide answers to these questions. Specifying that this or that icon should go to some kde specific directory is totally wrong. It is the task of the package manager to provide such information, not to require it. All the package should provide is an icon.
A package is a set of files with some meta information, not a set of files that scatter itself all over the place based on some assumptions the package creator made. Given the meta information and the files the package manager should do the rest: copy files, insert menu items in relevant menus, etc. This is how apple bundles work. Another example of this approach is the war package format for servlet applications.
There's a lot of debate on whether.deb or.rpm is better. IMHO they are equally flawed. The only reason.deb works better is because there are fewer.deb based distributions (i.e. debian and a handfull of very small debian derrivatives). The.deb format is not plagued by differences between distributions because there's effectively only one distribution: it avoids the issues rather than solving them. Try unleashing potato based kde.debs on the latest unstable debian and you will find yourself in.deb hell (ironically most debian potato users end up trying to do the reverse: install the latest kde.debs on a potato system).
I use the mozilla rc3 version. It is nice, but much slower than IE in some things. Particularly opening new windows is slow (I use the quickloader of course). However, popup killing is cool and so is tabbed browsing and bookmark groups.
Other than opening new windows, it is pretty fast. Especially the HTML rendering component has a nice performance. It needs good performance because the entire GUI runs on top of it!
Yes you are right. Too bad, it used to be quite a nice application. Pitty that it requires Java 2 though.
The nice thing about mindterm was that it didn't require Java 2 so you could even launch it from a crappy box with only netscape 4 on it. However, with netscape 4 (nearly) burried and MS no longer shipping a jvm, the days of jdk 1.1 seem numbered and it is entirely understandable that people adopt the much better 1.3+ generation of JVMs.
BTW. a google search for mindterm applet still reveals some sites offering old applet versions of mindterm:-).
Putty and its lesser known brother winscp2 are great tools. Also great is mindterm (google it). It is actually a Java application that can also be deployed as an applet. The great thing about the applet version is that you can launch it from any Java enabled browser and use it to connect to your system securely. Great when you are stuck in an internet cafe or somewhere else with limited browsing facilities.
The obvious solution is standardization in combination with version management that's how regular distributions pull it off.
As I pointed out compilation is no real solution because software is released faster than it can be compiled sequentially. Mozilla for example has a nightly release. Many PC's would have a hard time already keeping up to date with just Mozilla. Many open source projects have short release cycles. E.g. KDE seems to come with a new stable version every few months, the same applies to the kernel and many other projects. Keeping a stable up to date setup
The one reason I have not yet downloaded this is recompilation. I mean, compiling is pretty much a deterministic activity. Given similar compiler settings you'd expect the result to be the same each time. Apart from being deterministic it is also time consuming. Just compiling a pretty bare bones installation with gnome, kde, open office, mozilla would likely take me weeks by which time most of the packages would need recompilation because of updates!!! I'm all in favour of optionally compiling a few key things but I'm even more in favour of using pre-packaged binaries. Most of us probably would go for the 686 type code, so create binaries for all popular variants of X86 and distribute those (and maybe also other processors).
An alternative, admittedly far fetched, idea would (imagination going beserk here) be p2p compilation. Compilation can be distributed over computers and there likely is a small subset of all possible compiler settings that is most frequently used. Simply cache the results for such compilations and given a match in source code version processor architecture and compiler settings, reuse the result (and offer the replicated binary for download). If there is no match, compile yourself and offer the result. This should quickly eliminate redundant compilations and offer most of the advantages of compiling everything yourself.
Rumours, no facts. Since about half a year limewire and most other gnutella clients support so-called super peers. Super peers are the main reason gnutella didn't collapse when morpheus collapsed. It handled all the new users just fine (about a ten fold increase in users in a matter of days). Too bad most of them ended up installing a version of gnucleus ripped by morpheus. That particular version did not yet support super peers and other important gnutella features. Consequently it was limewire that prevented the gnutella network from collapsing (by providing the super peer nodes in the network).
Super peers also greatly reduce the amount of trafick and make it possible for e.g. modem users to use the gnutella network. Before super peers this was not really feasible because each peer had to handle incoming trafic from other nodes.
Limewire and other gnutella clients such as bearshare and gnucleus support swarmed downloads. Recently a feature called hashing has been implemented in several clients to improve reliability of swarming. Before hashing a more simple test was used to determine whether files were equal.
The main reason the gnutella network seems less responsive than the Kazaa network is that it is much smaller. On top of that there are still a lot of legacy gnutella clients which don't support all the latest features. The Kazaa network has the advantage of more users (1.6 million right now) that mostly bother to upgrade when they are prompted to do so. Naturally more content is offered on large networks than on smaller networks.
If you don't like spyware (like me), you might want to download the GPL'ed source code of limewire from the cvs servers and compile it yourself (easy if you know what you are doing). I've done so and it got me rid of the banners and bundled stuff. Alternatively download the java only install from their page (still includes advertisements though).
Gnutella is definately not a perfect network. However, the clients are getting better and better. Big features to land in the coming few months are meta information searches (already in limewire but other clients need to adopt this too in order to make it work properly) and browsing other user's files. I'm confident that gnutella will be there in better shape than ever to take over things when/if the Kazaa network collapses.
Until then, I'll keep kazaa lite running (need to complete those downloads:-)
True, however sharing from a NAT connection to another NAT is problematic since there is no way for one of the parties to address the other (as is required for a peer to peer connection). If only one of the parties is NATed, it can still initiate connections with a regular connection (this is how Kazaa and gnutella clients allow uploading for clients behind a firewall). However nobody can initiate a connection with the NATed box because it doesn't have an address. Thus if the majority of users is behind NAT, that would effectively kill p2p networks because it would be hard to establish a connection between the majority of nodes in the network.
However, broadband providers have an interest in p2p since it is a major reason for their clients to have broadband in the first place. A cheap modem connection will handle mail and instant messaging pretty effectively. Only when you start downloading mp3/movies/... you need the bandwidth they offer. Healthy p2p networks create a demand for broadband.
My hope is that as ipv4 addresses get scarcer, adoption of ipv6 will finally happen. This would largely remove the need for NAT.
I've never seen a method over 20 lines that really needed to be that long. Long methods are usually the result of poor design. If you have to maintain such methods, you lose a great deal of time figuring out what they do. Because they are so long, the method name is not a great help in figuring out what it's supposed to do.
Slashdot Mirror
Discussions like this show that browser wars are back on the agenda. IMHO that is largely the result of Mozilla adoption which has a modest but growing market share (yes also on my desktop). For a while the browser field has been fragmented you had netscape 3.x, 4.x, opera, mozilla milestones, various IE versions, konqueror. However, the non IE versions are all becoming more and more standards compliant (or disappearing). So effectively there's only two camps: the standards compliant camp and the MS camp.
While the latter camp has the largest marketshare (95% according to some sources), the standards compliant share is made up of a group of very active net users (mostly techies) who do a lot of online shopping, browse a lot of sites and see a lot of ads. For that reason, webdevelopers have an interest in keeping that part of the internet community happy and adhering to standards enough to make their sites usable in alternative browsers.
thx I saw it and will try it. It's not in the setup program yet so I think it is not entirely stable yet.
I've installed it at home and at work. The only problem is that there are very few ported X applications to run with it and most things do not compile out of the box.
:-). You can of course use it to run remote applications on a unix server (this works perfect).
/usr/X11R6/bin manually before you can type startx in bash. In addition you'll want to change the windowmanager (windowmaker works fine for me). Configuring X on windows XP is actually easier than on linux :-).
I'm running it with a port of windowmaker in fullscreen mode and it looks great. However, the thrill of running xcalc and xclock on windows xp wears off quickly
Another issue I found is that it is not possible to cut and paste between X apps and windows apps. So if you are surfing using mozilla or IE and want to paste some command from a howto into your xterm, you have a problem. You can paste into a bash terminal (i.e. outside X).
The cygwin installation is pretty smooth (lots of great stuff other than X too). However you do need to set a path to
The likely scenario Walmart is counting on is that users buy the machine, even though both are aware that lindows is crap. Once home, the user pops in one of those windows setup cds (e.g. borrowed from neighbour).
...) and if there's only a slight sign of pre-installed linux working, they'll jump on it.
What won't happen is that linux users will buy this machine and pop in a mandrake or debian cd. The reason is that linux users generally spend more money on their hardware and are unlikely to want a low budget PC.
In any case, Lindows is indeed likely to fail unless they add loads of value to their product. Right now any user friendly linux distribution beats them easily (Mandrake, Suse,
Get your facts straight. One of the first high quality xml parsers was xml4j from IBM. I used it nearly four years ago. At the time there were very few xml parsers and Java was about your only option if you wanted to do XML.
.Net you only have one realistic option: visual studio.
A quote from the Xerces pages:
The Xerces Java Parser 1.4.4 supports the XML 1.0 recommendation and contains advanced parser functionality, such as support for the W3C's XML Schema recommendation version 1.0, DOM Level 2 version 1.0, and SAX Version 2, in addition to supporting the industry-standard DOM Level 1 and SAX version 1 APIs.
Note that because some of the standards are still not complete, the stable API will definitely be different from its current form in Xerces-J 1.4.4. This is your chance to give us feedback on the features that are important to you, and let us know whether the APIs that we are providing are the right ones. Please direct your feedback to the Xerces-J mailing list.
As you can see Xerces supports all the latest standards and even appologizes that some of the API calls will change because the standards are not stable yet. The moment these standards stabilize the 'mature' options you mention will of course suffer from the same problem. However, it wouldn't surprise me if xerces was updated first.
Regarding soap, there are many java implementations from, among others, apache and IBM.
So in reply to your comments, Java XML:
- Java usually is among the first languages to support XML related w3c standards. Third parties like apache and IBM play an important role here.
- Java is actually pretty damn fast (hence the popularity of server side Java).
- Very mature (see first two points)
- Standards compliant.
I fully agree with your comments regarding the necessity of IDEs. Though, given your comments about visual cafe it is very clear that you haven't tried any of the fancy Java IDEs released in the new milennium since VC is long gone (hint, try Idea or Eclipse for a change). Of course with
The reviewer seems to be worried about the information density in this book. I would say it is a good thing that this book doesn't bother explaining how to compile hello world. If you don't understand the Java syntax, you're reading the wrong book.
Another good thing is that it doesn't include API documentation. API documentation seems to be a popular way of wasting dead trees but IMHO it is much easier to browse/search in HTML form. That leaves more room to content you'll actually need. There's so many Java books out there that use more than half of the pages for introductory stuff and API documentation and then try to squeeze the stuff you really need in ten pages or so.
The calendar project is very much unfinished work, I don't think it would be a good idea to distribute it to non technical users right now. Currently the work seems to focus on getting the basic features of a calendering tool right. I suspect it will take quite a bit of time before somebody will start thinking about how to export to specific PDAs.
The tool itself looks really cool already (a zoom option would be nice, I don't like scrolling) and no doubt it will continue to develop rapidly. I think that it will be moved into the Mozilla source tree once it is in a more useable state. I don't think that that will happen before 1.1, though.
Server performance has more to do with IO overhead than with execution speed. BTW. part of the coolness of java on the serverside is being able to use stuff like loadbalancing, caching, etc. in a more or less transparent way.
Hardware acceleration makes sense on embedded platforms where there are not enough resources to properly do on the fly compilation and optization (basically a non issue on servers).
As for your comments regarding pocketlinux, I suspect they were simply outcompeted by other pda oses who managed to produce a more usable os & apps. Users don't care about kernels, they do care about whether they can do stuff on a PDA: read mail, edit word documents, read pdf, manage agenda's, synchronize with popular pc applicatins, etc.
I downloaded and installed OOo right after it was released. I generally like the software. However, there is one show stopper issue that keeps me from migrating completely. It is currently not possible to make crossreferences to paragraph numbers. If for instance you have a document with a numbered list of references at the end, it is not possible to insert a cross-reference in the text to one of these numbers. The same applies to tables, figures, sections, formulas and headings.
Since I write scientific articles and need to be able to do all of the above, I can't use OOo (I use framemaker right now). I checked with issuezilla and this is something they are aware of, even though there doesn't seem to be much activity on the issue. I really hope they fix this soon.
Ok, now you're saying something else. Maybe you've discovered a bug in the JDK or something that maybe affects one or two applets. That is something else than claiming that thousands of applets suddenly stop working.
There's no one size fits all process for testing. How much effort you need to spend on testing depends on a lot of factors including but certainly not limited to: code size, amount of developers, customer requirements, life cycle of the system etc.
That being said, here are some remarks that make sense for any project:
In general a testing procedure that gives you no defects just indicates your testing procedure is bogus: defect free code does not exist and no test procedure (especially no automated procedure) will reveal all defects.
The XP way of determining when a product is good enough: write a test for a feature before you write code. If your code passes the test it is good enough. This makes sense and I have seen it applied successfully.
A second guideline is to write regression tests: when you fix a bug, write an automated test so you can avoid this bug in the future. Regression tests should be run as often as possible (e.g. on nightly builds). All large software organizations I've encountered do this. Combined with the first approach this will provide you with a growing set of automated tests that will assure your code is doing what its supposed to do without breaking stuff.
Thirdly, make sure code is reviewed (by an expert and not the new script kiddie on the block) before it is checked in. Don't accept code that is not up to the preset standards. Once you start accepting bad code you're code base will start to deteriorate rapidly.
In short, unless you have a very good reason (i.e. you know what you are doing) to write your own parsers, you should be using a parser generator (use google with the right keywords and you will find plenty of resources) or regular expressions (for the simple stuff, again: google is your best friend).
SUNs JVM is very much compatible even with the old 1.0.2 and 1.1 jvms. It is just that the MS implementation never was compatible (this is MS'fault) and that people wrote applets for that non compliant JVM and forgot to properly test their stuff with compliant JVMs. Sad, but you can't blame SUN for that. They certainly did everything to make MS comply with the standard they licensed.
I'm running jdk1.4.0 and it runs most applets I encounter just fine in internet explorer and mozilla. If a particular applet doesn't work that means that its developer hasn't bothered to update the code in years and doesn't care about non IE/MS JVM users. That should make you wonder whether you actually want to run such old, obsolete, abandoned code. I couldn't care less.
Been there, done that. Lets just say it does not work as advertised. IMHO it fully deserves the label unstable.
Than the next obvious question would be which file system structure. Which immediately poses the question what distribution to standardize on which in turn makes it very clear that the first is infeasible.
The problem (depending on your point of view) with OSS is that you cannot require developers to work in a certain way. Attempting to do so usually results in flamewars. OSS projects exist because the members don't like similar OSS projects and decide to do things their way.
Eeeew!!!!, compile time fixing of deployment directories! Compilation != configuration management. The fact that it is for most unix programs is the problem, not the solution.
A registry would be the simple solution. A better solution is an ldap configuration database. Information like where icons are supposed to go should come from such a database, not from compile time flags and certainly not from a binary package.
The key to figuring out why a particular solution is not working is trying to figure out what problem it is trying to solve. Why do we need a package format like rpm? Because linux applications tend to consist of a lot of files which need to be put in the right places. Doing this manually takes time and is error prone. Types of files may be icons, images, executables, man pages, fonts, .... In addition to these files scripts are bundled that may do configuration, clean up after removal, move files to the right directory etc. Making this work requires that the creator of the package makes a lot of assumptions like where do icons go on this system? What is the right place for an executable? Where do the man pages go? How do I add a menu item to whatever window manager is installed? ...
.deb or .rpm is better. IMHO they are equally flawed. The only reason .deb works better is because there are fewer .deb based distributions (i.e. debian and a handfull of very small debian derrivatives). The .deb format is not plagued by differences between distributions because there's effectively only one distribution: it avoids the issues rather than solving them. Try unleashing potato based kde .debs on the latest unstable debian and you will find yourself in .deb hell (ironically most debian potato users end up trying to do the reverse: install the latest kde .debs on a potato system).
Efforts to improve package system have focused on providing answers to such questions: standardization. Standardization is good but if you take a step back you realize that it is not relevant to provide answers to these questions. Specifying that this or that icon should go to some kde specific directory is totally wrong. It is the task of the package manager to provide such information, not to require it. All the package should provide is an icon.
A package is a set of files with some meta information, not a set of files that scatter itself all over the place based on some assumptions the package creator made. Given the meta information and the files the package manager should do the rest: copy files, insert menu items in relevant menus, etc. This is how apple bundles work. Another example of this approach is the war package format for servlet applications.
There's a lot of debate on whether
I use the mozilla rc3 version. It is nice, but much slower than IE in some things. Particularly opening new windows is slow (I use the quickloader of course). However, popup killing is cool and so is tabbed browsing and bookmark groups.
Other than opening new windows, it is pretty fast. Especially the HTML rendering component has a nice performance. It needs good performance because the entire GUI runs on top of it!
Yes you are right. Too bad, it used to be quite a nice application. Pitty that it requires Java 2 though.
:-).
The nice thing about mindterm was that it didn't require Java 2 so you could even launch it from a crappy box with only netscape 4 on it. However, with netscape 4 (nearly) burried and MS no longer shipping a jvm, the days of jdk 1.1 seem numbered and it is entirely understandable that people adopt the much better 1.3+ generation of JVMs.
BTW. a google search for mindterm applet still reveals some sites offering old applet versions of mindterm
Putty and its lesser known brother winscp2 are great tools. Also great is mindterm (google it). It is actually a Java application that can also be deployed as an applet. The great thing about the applet version is that you can launch it from any Java enabled browser and use it to connect to your system securely. Great when you are stuck in an internet cafe or somewhere else with limited browsing facilities.
The obvious solution is standardization in combination with version management that's how regular distributions pull it off.
As I pointed out compilation is no real solution because software is released faster than it can be compiled sequentially. Mozilla for example has a nightly release. Many PC's would have a hard time already keeping up to date with just Mozilla. Many open source projects have short release cycles. E.g. KDE seems to come with a new stable version every few months, the same applies to the kernel and many other projects. Keeping a stable up to date setup
The one reason I have not yet downloaded this is recompilation. I mean, compiling is pretty much a deterministic activity. Given similar compiler settings you'd expect the result to be the same each time. Apart from being deterministic it is also time consuming. Just compiling a pretty bare bones installation with gnome, kde, open office, mozilla would likely take me weeks by which time most of the packages would need recompilation because of updates!!! I'm all in favour of optionally compiling a few key things but I'm even more in favour of using pre-packaged binaries. Most of us probably would go for the 686 type code, so create binaries for all popular variants of X86 and distribute those (and maybe also other processors).
An alternative, admittedly far fetched, idea would (imagination going beserk here) be p2p compilation. Compilation can be distributed over computers and there likely is a small subset of all possible compiler settings that is most frequently used. Simply cache the results for such compilations and given a match in source code version processor architecture and compiler settings, reuse the result (and offer the replicated binary for download). If there is no match, compile yourself and offer the result. This should quickly eliminate redundant compilations and offer most of the advantages of compiling everything yourself.
Rumours, no facts. Since about half a year limewire and most other gnutella clients support so-called super peers. Super peers are the main reason gnutella didn't collapse when morpheus collapsed. It handled all the new users just fine (about a ten fold increase in users in a matter of days). Too bad most of them ended up installing a version of gnucleus ripped by morpheus. That particular version did not yet support super peers and other important gnutella features. Consequently it was limewire that prevented the gnutella network from collapsing (by providing the super peer nodes in the network).
:-)
Super peers also greatly reduce the amount of trafick and make it possible for e.g. modem users to use the gnutella network. Before super peers this was not really feasible because each peer had to handle incoming trafic from other nodes.
Limewire and other gnutella clients such as bearshare and gnucleus support swarmed downloads. Recently a feature called hashing has been implemented in several clients to improve reliability of swarming. Before hashing a more simple test was used to determine whether files were equal.
The main reason the gnutella network seems less responsive than the Kazaa network is that it is much smaller. On top of that there are still a lot of legacy gnutella clients which don't support all the latest features. The Kazaa network has the advantage of more users (1.6 million right now) that mostly bother to upgrade when they are prompted to do so. Naturally more content is offered on large networks than on smaller networks.
If you don't like spyware (like me), you might want to download the GPL'ed source code of limewire from the cvs servers and compile it yourself (easy if you know what you are doing). I've done so and it got me rid of the banners and bundled stuff. Alternatively download the java only install from their page (still includes advertisements though).
Gnutella is definately not a perfect network. However, the clients are getting better and better. Big features to land in the coming few months are meta information searches (already in limewire but other clients need to adopt this too in order to make it work properly) and browsing other user's files. I'm confident that gnutella will be there in better shape than ever to take over things when/if the Kazaa network collapses.
Until then, I'll keep kazaa lite running (need to complete those downloads
True, however sharing from a NAT connection to another NAT is problematic since there is no way for one of the parties to address the other (as is required for a peer to peer connection). If only one of the parties is NATed, it can still initiate connections with a regular connection (this is how Kazaa and gnutella clients allow uploading for clients behind a firewall). However nobody can initiate a connection with the NATed box because it doesn't have an address. Thus if the majority of users is behind NAT, that would effectively kill p2p networks because it would be hard to establish a connection between the majority of nodes in the network.
However, broadband providers have an interest in p2p since it is a major reason for their clients to have broadband in the first place. A cheap modem connection will handle mail and instant messaging pretty effectively. Only when you start downloading mp3/movies/... you need the bandwidth they offer. Healthy p2p networks create a demand for broadband.
My hope is that as ipv4 addresses get scarcer, adoption of ipv6 will finally happen. This would largely remove the need for NAT.
I've never seen a method over 20 lines that really needed to be that long. Long methods are usually the result of poor design. If you have to maintain such methods, you lose a great deal of time figuring out what they do. Because they are so long, the method name is not a great help in figuring out what it's supposed to do.