This style of naming has as a disadvantage that that some OS have path length limits. Also when you burn them to a cd you encounter such limitations. Consequently I prefer to have a directory for each artist and then one for each album of that artist. This way I can strip that information from the filename. The tracknummer is essential for sorting the files in a playlist though so I leave that (and even add it if it is missing).
The cache is a nice gimmick which I've found useful quite a few times, however the main reason I keep returning to google is that I actually find what I need fast. Yesterday I needed some background on C++ templates. I entered the terms "C++ templates tutorial" in the ie google toolbar (that is a great feauture IMHO) and found what I needed at the top of the returned results. 15 seconds later the stuff I needed was on its way to the printer.
That kind of convenience is hard to beat by a general purpose search engine. The story changes if you start using meta information to narrow the search. Google does not do that as far as I know. However, using meta information inevitably narrows the scope of a search engine. Efficient distributed search engines for multimedia are currently emerging. E.g. morpheus actually uses meta information attached to a mp3 allowing for searches for tracks of a particular album, more albums of the same artist and so on.
.. they managed to keep their users from revolting (a normal reaction when you take away their favorite programs) until I read this:
-quote-
Networks and thin clients are not new to Largo (motto: "City of Progress"). The city started down this path in 1992 with SCO (now Caldera) Unixware and its Motif-based IXI desktop that, Dave says, "looked a lot like Windows 3.1." Later they started using KDE 1 on both OpenServer and Unixware, and finally, in July 2001, made the switch to Red Hat Linux 7.1 and KDE 2.1.1, a change Dave says "has gone really well."
-end qoute-
Apparently these users were never exposed to a wintel system at their job (well, perhaps a previous job). Nothing bad about linux, but going from KDE 1.0 to 2.1 would make most users happy but it is something different than going from e.g. a properly installed and administered win2k system to kde 2.1.
That being said, I agree that KDE is userfriendly enough for normal people. You still have to learn some odd system specific things but not much more then on windows.
The real issue is application maturity (they run a closed source word processor to bypass that). Kword looks promising but is not ready. Staroffice seems reasonably functional but the 5.2 version is a rather peculiar thing and it is sort of difficult to use in a multi user environment because it installs a copy per user (never understood why).
The same goes for email clients, web browsers, spreadsheets. There are acceptable versions of each but getting it all together results in a rather inconsistent GUI and these programs generally do not integrate well with each other. So either you use one office suit (e.g. Koffice or gnome office) getting integration but also lacking features or you pick the best apps from various office suits getting a reasonable set of features and a near total lack of integration. Neither option is very appealing to someone used to a MS Office environment where you get any feature you need and excellent integration of the various applications.
Re:Buffer overflow vulnerabilities
on
Code Red III
·
· Score: 2, Insightful
Ah coding practices. Sorry, Murphy's law you know. If it can go wrong it will go wrong (and he porves himself right a lot lately). That's why even prorgams that have been around since the early days of UNIX are sometimes caught with their pants down (recent BIND bug anyone).
Any manual check can be forgotten and be a potential security hole. Once it is forgotten it merely depends on who finds the hole first: script kiddie or code maintainer.
And lets rub this in deeply, there are plenty of languages that protect you against the single most frequent cause of security leaks that is costing the world billions of dollars in damage annually (and it sure isn't C). Any program that is going to be exposed to hackers (i.e. any internet server software) should never ever be programmed in C. You simply cannot guarantee that the compiler and libraries are correct. Even if your program is correct, those still can be a potential source of bugs. Your average UNIX system likely has dozens of undiscovered potential buffer overflows.
Us java programmers are laughing our asses of each time a buffer overflow is wreaking havoc on the internet. We don't have to worry about such things. Java may not be the greatest thing, but you can rest assure that buffer overflows won't happen.
The situation without passport is even more insecure because:
- it relies on individual vendors to provide security for communication
- consumers trust these vendors to do so in most cases
- any vendor protocol is subject to the same security risks as passport
- most vendors are script kiddies rather than security experts (i.e. they are quite clueless about implementing proper security)
Any solution that improves the current situation is a step forward. That being said, the real issue is trust and I am a bit hesitant to trust a commercial company with privacy sensitive information (this is not anti MS, I wouldn't trust Red Hat with it either). The only way I could trust a passport server would be if it were protected by laws making every kind of abuse (including using the information for marketing purposes) illegal AND if it were maintained by an organization (preferably governmental) that has no interest in abusing this information. MS fails both requirements.
Interestingly, laws for the first requirement exist in some countries. It wouldn't surprise me if MS would run into legal trouble at some point for violating such privacy protecting laws.
There's also such a thing as correlation, often misunderstood for a causal relation. The article tells us that kids who play a lot of games tend to end up in college (i.e. there is a correlation between playing a lot of games as a kid and ending up in college). It would however be misguided to conclude that playing a lot of games causes people to end up in college (i.e. playing more games makes you intelligent).
With this in mind a logical explanation of the above phenomena could be that kids who played a lot of games as a kid and ended up in college must have been playing games in the early nineties/late eighties. In those days, computers were typically not found in lower class families but rather in middle/upper class families. So the above study could be seen as a difficult way of saying that if you grow up in a middle/upper class family, you are more likely to end up in college.
Disclaimer: I have only read Katz's biased summary, not the original paper.
Re:Mandrake is a company that understands desktop
on
Mandrakesoft To IPO
·
· Score: 2
My experience exactly. People keep claiming how user friendly mandrake is. I have tried each version from 7.0 and each time I had the the same feeling: "which idiot decided to call *this* stable". Using mandrake brings back memories of the early windows 95. Random lock ups, stuff failing randomly. Ok there's no BSODs but I consider an X crash to be pretty much the same as the only realistic option for a newby user is to reboot. The 7.x version had a few nice bugs that made urpmi fuck up its database from time to time (this makes using the rpm packaging tools pretty risky, especially for newbies who can't figure out how to recover the db). Using the configuration utilities more than once during a session on 8.0 also reveals some interesting bugs. I recently tried to configure adsl with mandrake (which apparently is possible in my area). While it is nice that this can be done, I found the procedure to be unstable (segfaults!) so I did things from the commandline. In addition, using both kde and gnome on mandrake 8.0 I have experienced several lock ups in X.
In my experience Mandrakes testing procedures do not go beyond "works for me". They consistently release too early, meaning that there are serious bugs in off the shelf mandrake distributions.
I think this is unfortunate because there are some good ideas behind the distribution. The configuration tools have the potential to be very nice. However, their current instability makes using them somewhat dangerous since you may very well end up with a misconfigured system. Linuxconf is a good replacement in most cases though.
Exactly, compiling kernels is not rocket science. If you're reasonably smart and work your way through various howto's and readme's it is by all means an easy thing to do. The thing is that most users don't really want to spend that much time on getting a kernel to work and generally have better things to do than study the kernels internals and fiddle with the make files interesting as it may be for people interested in operating system guts. Don't get me wrong, I have played around with slackware on 40 disks or so 5 years ago. At that time recompiling the kernel was more or less mandatory if you wanted sound in doom. What strikes me as odd is that since then the process of kernel configuration has hardly improved. Make config became make xconfig. But essentially nothing changed apart from that. The whole procedure breathes *not for newbies, nerds only* and I don't think that is entirely justified anymore given the modular architecture of the kernel and linux' status as an increasingly dominating server platform.
All I am saying is that it can all be done a lot more easier and that this benefits all users, including power users. There's this misconception in the unix world that obscure = flexible AND user friendly = unflexible. By my experience, a well designed software system can be both flexible and user friendly.
It is true that for most users it is not really necessary to compile kernels. OTOH it is also true that kernel updates fix bugs, add hardware support, improve features improve security, etc. Considering that, most users would probably upgrade their kernels if there were a convenient way of doing so. There isn't, so they don't. It's pretty sad that you need red hat (ot whatever linux distributor) to recompile the kernel in order for mainstream users to get better support for new devices (e.g. usb devices), security fixes and other kernel goodies.
Contrary what you are saying, I would claim distributors like red hat actually benefit from the kernel configuration's obscurity since in most cases the only way to get a new pre-configured kernel is by installing a new version of a linux distribution. In other words, by preventing their customers from upgrading in a convenient way themselves additional revenue is created because people keep buying new red hat cds to stay up to date.
Red Hat proves my point exactly, you download 7.0 or whatever is the latest version and you are provided with a kernel that is already obsolete the day the distribution was released.
I believe that flexibility and configurabilty go together very well and that the current lack of configurability is a sign that there is room for more flexibility.
I agree that kernel developers should not bother with providing compiled kernels for end users. However, they could facilitate making it easy for others to do so. I imagine a high quality configuration systems is beneficial for them as well as it saves time not configuring obvious things.
The price of not making kernel compilation & deployment easy is that adoptation of new kernel releases is slowed down. A good example of this is that only now the first few 2.4.x kernels start to appear in distributions. In addition, since x still very low, there are frequent, very relevant kernel updates that most users would want to have if they were running a 2.4.x kernel. But because updating is non-trivial for most users, many people don't bother to update.
Most of the options in the kernel configuration are meaningless to me and the help information in the generally primitive configuration tools is usually far from helpful for people not into kernel hacking. Luckily kernel configuration/compilation is rarely needed by users like me. Unless you need to upgrade (e.g. because of security fixes). Then it really doesn't matter how user friendly your distribution is because your only real option is to get your hands dirty and compile the bloody kernel. Meaning you have to fiddle with all the options you don't understand. A person like me could easily make some mistakes resulting in unstable or unsecure kernels.
It's time this part of linux is brought into the 21 century as well. Most users don't really need to recompile, they just need to put binary modules together. 95% of the users don't have scsi, do not have obsolete bus architectures, run x86 processors, would like to be able to mount their dos/windows drives. Why not build a set of kernels for different architectures for the most common desktop configurations and leave the compiling to people who really need it (i.e. those with older, more exotic hardware or those wanting to tweak optimization settings and so on).
It's nice to have the flexibility to compile the kernel, it is bad that it is the only way of getting a usable kernel. Maybe having binaries is not an option but in any case the configuration tools could be a lot more user friendly by for instance doing some hardware recognition, recognizing that certain options exclude each other, offering some presets which make sense on common architectures like x86 pc's. A nice option would be to automatically duplicate the settings from the running kernel into the new kernel, only prompting for settings that are new or require changes. That would make kernel updates a lot more painless. Even for the advanced users that would mean they could spend less stuff on the trivial stuff and instead focus on the important stuff.
I had a similar discussion today. My position is that it is more usefull to learn how to build a compiler because that forces you think about high level structures like classes, functions and objects are represented at the machine level while simultaneously forcing you to do some none trivial programming and allowing you to pick up some classic CS stuff.
Sloppy programming, as you put it, is simply avoiding to optimize by hand. In C this is a necessety, in Java the run-time environment does most of it for you, allowing you to focus on elegant code a little more. But I agree that it doesn't hurt to understand how your programming environment really works.
The whole argument in favor of X is based on the assumption that network transparency is essential. However, particularly on slow connections with high latency (typical for mobile networks), the last thing I want to do is to display my ui remote. Instead I want to do that locally (memory/cpu is no longer an issue, Jim's own argument) and only use the connection to send data. The whole concept of single tier, server based applications is dead. These most server apps have at least 2 tiers and an additional client tier.
The added value of running a network transparent xserver over a framebuffer based approach is limited, especially when considering that X alone does not provide enough functionality to do things locally, you need additional stuff like qt/gtk anyway (unless you want to write your programs on top of X). Embedded gtk/qt will be both faster and smaller, which unlike Jim Getty is suggesting is still important in the embedded world.
Users primarily want functionality. Besides, I doubt the use of Java will have a large impact on it. Most energy in e.g. mobile phones is used when actually using the connection.
As for your questions, I've seen a mpg player written in Java, I believe the java compiler is a java program, I have seen a few nice games in Java although it isn't quake of course. I have just spent my afternoon hacking away in netbeans, agreat Java IDE and of course written in Java.
I just think you should revise your opinion regarding bloatedness. The very least you could consider is wondering why the heck all these mobile hardware guys are deploying Java despite your argument. Presumably they know what they are doing and maybe your arguments are not valid?
Well cell phones are no longer the limited machines they used to be. They have quite a lot of processing power, can be equiped with several MB of memory. Once you have that, coding C is a waste of time and time is the difference between profit or loss in the mobile market. A two month delay can literally make the difference. A company like Nokia produces dozens of different mobile phone types each year. That's why they love cross platform and couldn't care less that they would have to spend a few dollars more on the hardware. Besides, Moore's law also applies to the mobile market. Mobile hardware is doubling in speed just as fast as desktop and server hardware. Current mobile architectures such as applied in pda's, mobile phones etc. have plenty of horsepower and most of these architectures already have JVMs running on top of them.
Java programs are crossplatform. In the mobile market this means that once you have a JVM ported to your phone, you can run a rapidly growing number of programs without any change. That cuts back development time dramatically. C doesn't give you the same advantages because you have to recompile, test and debug before you can expect even the most portable C code to run without a hitch.
Re:This is Freshmeat stuff. Not Slashdot.
on
Mozilla 0.9.1 Out
·
· Score: 2
Its news for nerds, stuff that matters. The appeal of this site has always been that the editors pick stuff that interests them rather than posting anything that comes along. While I don't always appreciate the articles and, admittedly, information stress occasionally causes the editors to miss out on stuff that IMHO matters, they do a pretty good job overall and have been a primary source of tech news for me for nearly three years now.
Mozilla 0.9.1 is an important build for a few reasons:
- It gets good reviews (just read the replies to the article)
- It is marked in the roadmap as a beta branch point for netscape and others.
- It seems to have dealt with most of the performance issues that have been plagueing mozilla.
Opera on the other hand is also nice but closed source and not that revolutionary compared to the betas and the previous version. I do agree that should've deserved a mention though.
Works for me, I have the jdk installed and mozilla detects it when I launch it. I have had some trouble getting Java to work with mozilla on linux though (haven't tried recently so maybe things have improved by now).
In any case, jdk1.3.1 has the same changes as jdk1.3.0_1 that enable it to work with mozilla and so will all future versions as far as I can tell. Did someone test with jdk1.4 beta?
Opera is great on machines with little memory. I just installed it on my fathers five year old pentium 120/16Mb over the weekend. It runs great & fast too, unlike nutscrape!
Microsoft has a lot of capital. That alone will keep them alive. However, if you look at what they have been producing I see only evolutionary improvements in products they've had for years. The innovation mostly consists of adding features and integrating their various products. While that improves usability somewhat, it is not true innovation. Rather it is inertia. People buy ms products today because they bought them yesterday. Some of them will probably buy them again tomorrow, but some won't.
Of course the underlying question when such an article is posted on slashdot is whether they will continue be able to compete with open source software and the answer is yes of course. MS has plenty of money and can afford to experiment with their strategy as much as they like. Right now they are trying to see how much money they can squeeze out of their customers and it turns out to be quite a lot (and why shouldn't they, I have no sympathy for idiots so lets rip them off). On the other hand they are losing a few customers which is bad in the long term. Probably they will become a bit more moderate if they start losing too much customers. However considering their installed base, they will have a revenue stream for years to come, no matter what they do, no matter how crazy they act.
However, open source has a similar advantage. It's free now, it's free tomorrow. It will always be the cheaper option. The quality of some open source products is also quite good and if MS continues to make life hard for home users (with activation bullshit and all), it becomes increasingly attractive to let mandrake reorganize my disk a bit, removing all dependencies on legacy software such as outlook and notepad.
If you have too much money you should consider giving it to charity or something instead of funding unsound business models. I a company can't make money perhaps they should convert to a non-profit organization. Keeping unhealthy companies alive by charity is just a waste of resources, especially when considering that the average.com personel should be capable of taking care of themselves.
If I look at Mandrake, I see a company with a nice product (i.e. they should be capable of selling it too customers). However they are competing with free products. In fact the only value Mandrake adds to their products is support, integration, testing (could be better though) and ease of use. Keeping the distance with their numerous competitors is a lost battle since it requires constant investments in research and development (growing cost and they are also helping their competitors).
The linux market is growing rapidly, there's plenty of new customers. Not being able to make a profit is a symptom of a bad business model (i.e. there's a structural problem with the revenue vs. the cost).
Perhaps a good business model for an open source company would be to separate the source of cost from the source of revenue. Mandrake could for instance host their development team in a non-profit organization like debian (thus stimulating external developers to partipate) and create a consulting/support company to support the products the non profit organization produces. Cost can then be regulated by limiting funding of the non profit organization. The for profit organization can then focus on the stuff that really matters (i.e. selling support & services and shipping cd's) while the non profit organization is no longer bothered with marketing departments and so on. There wouldn't be any problem with intellectual property since the company was already putting their stuff under GPL anyway. The only real value in an open source company is knowledge of the software, not the software itself.
The idea above is already being applied in Mozilla, open office, netbeans and other projects. In the case of netbeans you have netbeans.org working on the development and Sun shipping commercial products (forte) based on netbeans releases (check it out if you haven't already).
open source makes sense for games but not the GPL (unless of course you don't care about revenue). If a bsd style license would be used, game developers could choose to open source parts of the game (3d rendering engine etc.) and bundle it with their closed source game specific scripts and models. So open source the technology but protect artwork/game specifics.
Linux gaming has always been a niche market, not in the last place due to the cumbersome way 3d, sound and other gaming hardware is handled under linux. A few small companies have managed to draw some revenue from porting games to it. However, if games can be run using wine (and contrary to what people have been stating, wine is not an emulator by definition), that would likely kill that market since only an idiot would spent time and money porting games that already run on linux (on top of wine) IMHO.
That's bad news for those few companies making a living out of porting games to linux but on the other hand why halt progress for a lousy businessplan? Linux might ultimately benefit by attracting new users if new game releases can be run on it. One of the reasons I'm still running windows is games.
Re:not the java performance myth again
on
SQL Over FreeNet
·
· Score: 3
"Of course the real bottleneck is the P2P aspect of the application itself."
The fact that freenet runs on Java is completely irrelevant from the point of view of network performance since the bottleneck is not execution speed or memory usage but network throughput and IO. Implementing it in for instance C would have no other effect than seriously slowing development (assuming you use the same software architecture).
Applications like limewire (IMHO one of the best gnutella clients available) prove that Java is a very good platform for developing p2p software. My limewire gnutella client has no trouble processing the trafic generated by 13000 hosts and there's plenty of processor time left for other apps. And if you are wondering: I'm on a 450 Mhz pII with 128 Mb of ram running win2k.
I've tried out freenet as well. Performance currently sucks but that's not a Java issue but an issue of the freenet architecture in combination with the problem of lots of transient nodes and limited available content.
Slashdot Mirror
you can actually use google to do site searches: just add site:yourdomain to the query. Or use the google toolbar and use the search site button.
You can also include a form on your site that does this for you and google can customize the search results page to match the layout of your site.
This style of naming has as a disadvantage that that some OS have path length limits. Also when you burn them to a cd you encounter such limitations. Consequently I prefer to have a directory for each artist and then one for each album of that artist. This way I can strip that information from the filename. The tracknummer is essential for sorting the files in a playlist though so I leave that (and even add it if it is missing).
The cache is a nice gimmick which I've found useful quite a few times, however the main reason I keep returning to google is that I actually find what I need fast. Yesterday I needed some background on C++ templates. I entered the terms "C++ templates tutorial" in the ie google toolbar (that is a great feauture IMHO) and found what I needed at the top of the returned results. 15 seconds later the stuff I needed was on its way to the printer.
That kind of convenience is hard to beat by a general purpose search engine. The story changes if you start using meta information to narrow the search. Google does not do that as far as I know. However, using meta information inevitably narrows the scope of a search engine. Efficient distributed search engines for multimedia are currently emerging. E.g. morpheus actually uses meta information attached to a mp3 allowing for searches for tracks of a particular album, more albums of the same artist and so on.
.. they managed to keep their users from revolting (a normal reaction when you take away their favorite programs) until I read this:
-quote-
Networks and thin clients are not new to Largo (motto: "City of Progress"). The city started down this path in 1992 with SCO (now Caldera) Unixware and its Motif-based IXI desktop that, Dave says, "looked a lot like Windows 3.1." Later they started using KDE 1 on both OpenServer and Unixware, and finally, in July 2001, made the switch to Red Hat Linux 7.1 and KDE 2.1.1, a change Dave says "has gone really well."
-end qoute-
Apparently these users were never exposed to a wintel system at their job (well, perhaps a previous job). Nothing bad about linux, but going from KDE 1.0 to 2.1 would make most users happy but it is something different than going from e.g. a properly installed and administered win2k system to kde 2.1.
That being said, I agree that KDE is userfriendly enough for normal people. You still have to learn some odd system specific things but not much more then on windows.
The real issue is application maturity (they run a closed source word processor to bypass that). Kword looks promising but is not ready. Staroffice seems reasonably functional but the 5.2 version is a rather peculiar thing and it is sort of difficult to use in a multi user environment because it installs a copy per user (never understood why).
The same goes for email clients, web browsers, spreadsheets. There are acceptable versions of each but getting it all together results in a rather inconsistent GUI and these programs generally do not integrate well with each other. So either you use one office suit (e.g. Koffice or gnome office) getting integration but also lacking features or you pick the best apps from various office suits getting a reasonable set of features and a near total lack of integration. Neither option is very appealing to someone used to a MS Office environment where you get any feature you need and excellent integration of the various applications.
Ah coding practices. Sorry, Murphy's law you know. If it can go wrong it will go wrong (and he porves himself right a lot lately). That's why even prorgams that have been around since the early days of UNIX are sometimes caught with their pants down (recent BIND bug anyone).
Any manual check can be forgotten and be a potential security hole. Once it is forgotten it merely depends on who finds the hole first: script kiddie or code maintainer.
And lets rub this in deeply, there are plenty of languages that protect you against the single most frequent cause of security leaks that is costing the world billions of dollars in damage annually (and it sure isn't C). Any program that is going to be exposed to hackers (i.e. any internet server software) should never ever be programmed in C. You simply cannot guarantee that the compiler and libraries are correct. Even if your program is correct, those still can be a potential source of bugs. Your average UNIX system likely has dozens of undiscovered potential buffer overflows.
Us java programmers are laughing our asses of each time a buffer overflow is wreaking havoc on the internet. We don't have to worry about such things. Java may not be the greatest thing, but you can rest assure that buffer overflows won't happen.
The situation without passport is even more insecure because:
- it relies on individual vendors to provide security for communication
- consumers trust these vendors to do so in most cases
- any vendor protocol is subject to the same security risks as passport
- most vendors are script kiddies rather than security experts (i.e. they are quite clueless about implementing proper security)
Any solution that improves the current situation is a step forward. That being said, the real issue is trust and I am a bit hesitant to trust a commercial company with privacy sensitive information (this is not anti MS, I wouldn't trust Red Hat with it either). The only way I could trust a passport server would be if it were protected by laws making every kind of abuse (including using the information for marketing purposes) illegal AND if it were maintained by an organization (preferably governmental) that has no interest in abusing this information. MS fails both requirements.
Interestingly, laws for the first requirement exist in some countries. It wouldn't surprise me if MS would run into legal trouble at some point for violating such privacy protecting laws.
There's also such a thing as correlation, often misunderstood for a causal relation. The article tells us that kids who play a lot of games tend to end up in college (i.e. there is a correlation between playing a lot of games as a kid and ending up in college). It would however be misguided to conclude that playing a lot of games causes people to end up in college (i.e. playing more games makes you intelligent).
With this in mind a logical explanation of the above phenomena could be that kids who played a lot of games as a kid and ended up in college must have been playing games in the early nineties/late eighties. In those days, computers were typically not found in lower class families but rather in middle/upper class families. So the above study could be seen as a difficult way of saying that if you grow up in a middle/upper class family, you are more likely to end up in college.
Disclaimer: I have only read Katz's biased summary, not the original paper.
My experience exactly. People keep claiming how user friendly mandrake is. I have tried each version from 7.0 and each time I had the the same feeling: "which idiot decided to call *this* stable". Using mandrake brings back memories of the early windows 95. Random lock ups, stuff failing randomly. Ok there's no BSODs but I consider an X crash to be pretty much the same as the only realistic option for a newby user is to reboot. The 7.x version had a few nice bugs that made urpmi fuck up its database from time to time (this makes using the rpm packaging tools pretty risky, especially for newbies who can't figure out how to recover the db). Using the configuration utilities more than once during a session on 8.0 also reveals some interesting bugs. I recently tried to configure adsl with mandrake (which apparently is possible in my area). While it is nice that this can be done, I found the procedure to be unstable (segfaults!) so I did things from the commandline. In addition, using both kde and gnome on mandrake 8.0 I have experienced several lock ups in X.
In my experience Mandrakes testing procedures do not go beyond "works for me". They consistently release too early, meaning that there are serious bugs in off the shelf mandrake distributions.
I think this is unfortunate because there are some good ideas behind the distribution. The configuration tools have the potential to be very nice. However, their current instability makes using them somewhat dangerous since you may very well end up with a misconfigured system. Linuxconf is a good replacement in most cases though.
Exactly, compiling kernels is not rocket science. If you're reasonably smart and work your way through various howto's and readme's it is by all means an easy thing to do. The thing is that most users don't really want to spend that much time on getting a kernel to work and generally have better things to do than study the kernels internals and fiddle with the make files interesting as it may be for people interested in operating system guts. Don't get me wrong, I have played around with slackware on 40 disks or so 5 years ago. At that time recompiling the kernel was more or less mandatory if you wanted sound in doom. What strikes me as odd is that since then the process of kernel configuration has hardly improved. Make config became make xconfig. But essentially nothing changed apart from that. The whole procedure breathes *not for newbies, nerds only* and I don't think that is entirely justified anymore given the modular architecture of the kernel and linux' status as an increasingly dominating server platform.
All I am saying is that it can all be done a lot more easier and that this benefits all users, including power users. There's this misconception in the unix world that obscure = flexible AND user friendly = unflexible. By my experience, a well designed software system can be both flexible and user friendly.
It is true that for most users it is not really necessary to compile kernels. OTOH it is also true that kernel updates fix bugs, add hardware support, improve features improve security, etc. Considering that, most users would probably upgrade their kernels if there were a convenient way of doing so. There isn't, so they don't. It's pretty sad that you need red hat (ot whatever linux distributor) to recompile the kernel in order for mainstream users to get better support for new devices (e.g. usb devices), security fixes and other kernel goodies.
Contrary what you are saying, I would claim distributors like red hat actually benefit from the kernel configuration's obscurity since in most cases the only way to get a new pre-configured kernel is by installing a new version of a linux distribution. In other words, by preventing their customers from upgrading in a convenient way themselves additional revenue is created because people keep buying new red hat cds to stay up to date.
Red Hat proves my point exactly, you download 7.0 or whatever is the latest version and you are provided with a kernel that is already obsolete the day the distribution was released.
I believe that flexibility and configurabilty go together very well and that the current lack of configurability is a sign that there is room for more flexibility.
I agree that kernel developers should not bother with providing compiled kernels for end users. However, they could facilitate making it easy for others to do so. I imagine a high quality configuration systems is beneficial for them as well as it saves time not configuring obvious things.
The price of not making kernel compilation & deployment easy is that adoptation of new kernel releases is slowed down. A good example of this is that only now the first few 2.4.x kernels start to appear in distributions. In addition, since x still very low, there are frequent, very relevant kernel updates that most users would want to have if they were running a 2.4.x kernel. But because updating is non-trivial for most users, many people don't bother to update.
Most of the options in the kernel configuration are meaningless to me and the help information in the generally primitive configuration tools is usually far from helpful for people not into kernel hacking. Luckily kernel configuration/compilation is rarely needed by users like me. Unless you need to upgrade (e.g. because of security fixes). Then it really doesn't matter how user friendly your distribution is because your only real option is to get your hands dirty and compile the bloody kernel. Meaning you have to fiddle with all the options you don't understand. A person like me could easily make some mistakes resulting in unstable or unsecure kernels.
It's time this part of linux is brought into the 21 century as well. Most users don't really need to recompile, they just need to put binary modules together. 95% of the users don't have scsi, do not have obsolete bus architectures, run x86 processors, would like to be able to mount their dos/windows drives. Why not build a set of kernels for different architectures for the most common desktop configurations and leave the compiling to people who really need it (i.e. those with older, more exotic hardware or those wanting to tweak optimization settings and so on).
It's nice to have the flexibility to compile the kernel, it is bad that it is the only way of getting a usable kernel. Maybe having binaries is not an option but in any case the configuration tools could be a lot more user friendly by for instance doing some hardware recognition, recognizing that certain options exclude each other, offering some presets which make sense on common architectures like x86 pc's. A nice option would be to automatically duplicate the settings from the running kernel into the new kernel, only prompting for settings that are new or require changes. That would make kernel updates a lot more painless. Even for the advanced users that would mean they could spend less stuff on the trivial stuff and instead focus on the important stuff.
I had a similar discussion today. My position is that it is more usefull to learn how to build a compiler because that forces you think about high level structures like classes, functions and objects are represented at the machine level while simultaneously forcing you to do some none trivial programming and allowing you to pick up some classic CS stuff.
Sloppy programming, as you put it, is simply avoiding to optimize by hand. In C this is a necessety, in Java the run-time environment does most of it for you, allowing you to focus on elegant code a little more. But I agree that it doesn't hurt to understand how your programming environment really works.
The whole argument in favor of X is based on the assumption that network transparency is essential. However, particularly on slow connections with high latency (typical for mobile networks), the last thing I want to do is to display my ui remote. Instead I want to do that locally (memory/cpu is no longer an issue, Jim's own argument) and only use the connection to send data. The whole concept of single tier, server based applications is dead. These most server apps have at least 2 tiers and an additional client tier.
The added value of running a network transparent xserver over a framebuffer based approach is limited, especially when considering that X alone does not provide enough functionality to do things locally, you need additional stuff like qt/gtk anyway (unless you want to write your programs on top of X). Embedded gtk/qt will be both faster and smaller, which unlike Jim Getty is suggesting is still important in the embedded world.
Users primarily want functionality. Besides, I doubt the use of Java will have a large impact on it. Most energy in e.g. mobile phones is used when actually using the connection.
As for your questions, I've seen a mpg player written in Java, I believe the java compiler is a java program, I have seen a few nice games in Java although it isn't quake of course. I have just spent my afternoon hacking away in netbeans, agreat Java IDE and of course written in Java.
I just think you should revise your opinion regarding bloatedness. The very least you could consider is wondering why the heck all these mobile hardware guys are deploying Java despite your argument. Presumably they know what they are doing and maybe your arguments are not valid?
Well cell phones are no longer the limited machines they used to be. They have quite a lot of processing power, can be equiped with several MB of memory. Once you have that, coding C is a waste of time and time is the difference between profit or loss in the mobile market. A two month delay can literally make the difference. A company like Nokia produces dozens of different mobile phone types each year. That's why they love cross platform and couldn't care less that they would have to spend a few dollars more on the hardware. Besides, Moore's law also applies to the mobile market. Mobile hardware is doubling in speed just as fast as desktop and server hardware. Current mobile architectures such as applied in pda's, mobile phones etc. have plenty of horsepower and most of these architectures already have JVMs running on top of them.
Java programs are crossplatform. In the mobile market this means that once you have a JVM ported to your phone, you can run a rapidly growing number of programs without any change. That cuts back development time dramatically. C doesn't give you the same advantages because you have to recompile, test and debug before you can expect even the most portable C code to run without a hitch.
Its news for nerds, stuff that matters. The appeal of this site has always been that the editors pick stuff that interests them rather than posting anything that comes along. While I don't always appreciate the articles and, admittedly, information stress occasionally causes the editors to miss out on stuff that IMHO matters, they do a pretty good job overall and have been a primary source of tech news for me for nearly three years now.
Mozilla 0.9.1 is an important build for a few reasons:
- It gets good reviews (just read the replies to the article)
- It is marked in the roadmap as a beta branch point for netscape and others.
- It seems to have dealt with most of the performance issues that have been plagueing mozilla.
Opera on the other hand is also nice but closed source and not that revolutionary compared to the betas and the previous version. I do agree that should've deserved a mention though.
Works for me, I have the jdk installed and mozilla detects it when I launch it. I have had some trouble getting Java to work with mozilla on linux though (haven't tried recently so maybe things have improved by now).
In any case, jdk1.3.1 has the same changes as jdk1.3.0_1 that enable it to work with mozilla and so will all future versions as far as I can tell. Did someone test with jdk1.4 beta?
Opera is great on machines with little memory. I just installed it on my fathers five year old pentium 120/16Mb over the weekend. It runs great & fast too, unlike nutscrape!
Microsoft has a lot of capital. That alone will keep them alive. However, if you look at what they have been producing I see only evolutionary improvements in products they've had for years. The innovation mostly consists of adding features and integrating their various products. While that improves usability somewhat, it is not true innovation. Rather it is inertia. People buy ms products today because they bought them yesterday. Some of them will probably buy them again tomorrow, but some won't.
Of course the underlying question when such an article is posted on slashdot is whether they will continue be able to compete with open source software and the answer is yes of course. MS has plenty of money and can afford to experiment with their strategy as much as they like. Right now they are trying to see how much money they can squeeze out of their customers and it turns out to be quite a lot (and why shouldn't they, I have no sympathy for idiots so lets rip them off). On the other hand they are losing a few customers which is bad in the long term. Probably they will become a bit more moderate if they start losing too much customers. However considering their installed base, they will have a revenue stream for years to come, no matter what they do, no matter how crazy they act.
However, open source has a similar advantage. It's free now, it's free tomorrow. It will always be the cheaper option. The quality of some open source products is also quite good and if MS continues to make life hard for home users (with activation bullshit and all), it becomes increasingly attractive to let mandrake reorganize my disk a bit, removing all dependencies on legacy software such as outlook and notepad.
If you have too much money you should consider giving it to charity or something instead of funding unsound business models. I a company can't make money perhaps they should convert to a non-profit organization. Keeping unhealthy companies alive by charity is just a waste of resources, especially when considering that the average .com personel should be capable of taking care of themselves.
If I look at Mandrake, I see a company with a nice product (i.e. they should be capable of selling it too customers). However they are competing with free products. In fact the only value Mandrake adds to their products is support, integration, testing (could be better though) and ease of use. Keeping the distance with their numerous competitors is a lost battle since it requires constant investments in research and development (growing cost and they are also helping their competitors).
The linux market is growing rapidly, there's plenty of new customers. Not being able to make a profit is a symptom of a bad business model (i.e. there's a structural problem with the revenue vs. the cost).
Perhaps a good business model for an open source company would be to separate the source of cost from the source of revenue. Mandrake could for instance host their development team in a non-profit organization like debian (thus stimulating external developers to partipate) and create a consulting/support company to support the products the non profit organization produces. Cost can then be regulated by limiting funding of the non profit organization. The for profit organization can then focus on the stuff that really matters (i.e. selling support & services and shipping cd's) while the non profit organization is no longer bothered with marketing departments and so on. There wouldn't be any problem with intellectual property since the company was already putting their stuff under GPL anyway. The only real value in an open source company is knowledge of the software, not the software itself.
The idea above is already being applied in Mozilla, open office, netbeans and other projects. In the case of netbeans you have netbeans.org working on the development and Sun shipping commercial products (forte) based on netbeans releases (check it out if you haven't already).
open source makes sense for games but not the GPL (unless of course you don't care about revenue). If a bsd style license would be used, game developers could choose to open source parts of the game (3d rendering engine etc.) and bundle it with their closed source game specific scripts and models. So open source the technology but protect artwork/game specifics.
Linux gaming has always been a niche market, not in the last place due to the cumbersome way 3d, sound and other gaming hardware is handled under linux. A few small companies have managed to draw some revenue from porting games to it. However, if games can be run using wine (and contrary to what people have been stating, wine is not an emulator by definition), that would likely kill that market since only an idiot would spent time and money porting games that already run on linux (on top of wine) IMHO.
That's bad news for those few companies making a living out of porting games to linux but on the other hand why halt progress for a lousy businessplan? Linux might ultimately benefit by attracting new users if new game releases can be run on it. One of the reasons I'm still running windows is games.
"Of course the real bottleneck is the P2P aspect of the application itself."
The fact that freenet runs on Java is completely irrelevant from the point of view of network performance since the bottleneck is not execution speed or memory usage but network throughput and IO. Implementing it in for instance C would have no other effect than seriously slowing development (assuming you use the same software architecture).
Applications like limewire (IMHO one of the best gnutella clients available) prove that Java is a very good platform for developing p2p software. My limewire gnutella client has no trouble processing the trafic generated by 13000 hosts and there's plenty of processor time left for other apps. And if you are wondering: I'm on a 450 Mhz pII with 128 Mb of ram running win2k.
I've tried out freenet as well. Performance currently sucks but that's not a Java issue but an issue of the freenet architecture in combination with the problem of lots of transient nodes and limited available content.