M14 is impressive, but I think it's still quite far away from being mature enough for a consumer release, even a beta. If they release too early, that could further damage the reputation of open source.
Re:Apple: Pick any pointing device, as long...
on
Apple's New Trackpad?
·
· Score: 2
Pardon my typo: the last sentence should, of course, read " I'll seriously consider an Apple laptop again when they have some pointing device other than a touchpad."
The pointing device on a laptop matters a great deal to me. IBM's TrackPoint and thumb-operated trackballs are fine. I loathe Apple's trackpads (and I think there is HCI evidence that they aren't very effective) and Toshiba's pointing stick (which is a poor TrackPoint clone).
The problem with Apple laptops is that, as in so many other areas, Apple just doesn't give you a choice. Apple has the "one size fits all" attitude even worse than Microsoft. I'll seriously consider an Apple laptop again when they have some pointing device other than a trackpoint.
Borland's tools are useful. They are fun. They may even be "professional" (people get paid for the work they do with them, which defines "professional").
What I object to is Borland's implication that Emacs and GNU C/C++ don't represent professional tools. Think about it this way:
The Linux kernel, the GNU tools, the UNIX kernel and tools, most telecom applications, most large web sites, etc. were all developed with command line tools. Borland's tools have mostly been used for consumer Windows applications and in-house RAD. With that in mind, is there any justification for calling Borland's tools "professional" and the command line tools not?
If you had to choose to hire a programmer for the long term, someone who needs to be flexible and work in a variety of environments, would you rather hire someone with 5 years of Delphi experience or 5 years of Emacs and GNU C/C++ experience? In all the places I have worked, the Delphi programmer wouldn't even get invited to an interview.
If we allow companies like Borland to redefine "professionalism" in terms of their GUI and RAD products, I think we are lowering our standards. I have no objection to their products being called "useful" and "professional", but the gold standard of skill to me is still that a programmer is comfortable and productive without all that handholding. That kind of "under the covers" understanding is important even if you spend all your time in VC++ or Borland, because the debuggers and GUI builders in those tools simply aren't getting the job done some of the time.
Not every professional programmer needs to achieve proficiency in vi, Emacs, and command line tools, but more ought to aspire to it. And appreciating those tools as professional and worthy of mastery is the first step towards that.
The problem with Apple's changes to GNU C in the past has not been that they haven't made the source available under the GPL (they are obliged to do that by the license, the FSF's curious obsession with copyright assignments notwithstanding), but that their code was too difficult to merge back into the main tree.
So, the question is: are we going to get Apple's current version of Objective-C/Objective-C++ into the main branch of GNU C? And what about Apple's Objective-C runtime (not all the libraries, just the runtime)? Is that available as part of Darwin?
The results of the survey indicate that developers are seeking RAD, database enablement, and GUI design - all strong evidence that Linux is ready for mainstream professional application development.
I, for one, find these kinds of statements by Borland insulting. Linux has "mainstream professional development tools" (Emacs, GNU C/C++, etc.). Those are the kinds of tools professional developers have been using for decades, before PCs or Borland were even around.
It's not all that different from cameras: lots of people use point-and-shoot cameras for all sorts of business applications, but the true "professional" cameras are still the Nikon F4's and Hasselblads, clunky and slow by consumer standards, but they get the job done in the hands of the professionals.
Maybe Borland and Microsoft tools have grown up to be professional tools in their own right, for their own market niche (just like there are a lot of high-tech "professional cameras" now, not just manual ones). And they may get some following once more application developers move from Windows to Linux. But I haven't been holding my breath for those kinds of tools on Linux, and I doubt many current Linux developers have either.
Well, who is going to maintain the NT box after the person "turned the key"? Schools that don't hire a dedicated administrator for their NT network are in for trouble. Maybe some schools will be naive enough to do that, but I suspect most won't.
Linux's success in schools, like anywhere else, depends on being able to put together turnkey solutions that provide the functionality people want at a lower price and with less work. Linux has all the ingredients to do a better job there: Linux works just fine in "appliance servers" with virtually no maintenance, it runs on the lowest-cost hardware on the planet, and it supports a suite of protocols (X11, VNC, HTTP, etc.) that make building network-based "plug-and-play" solutions really easy.
If you sell schools a box that doesn't need to be maintained and just plugs into their network and gets the job done year after year, I think you have a good value proposition. Of course, if you position your product as "here is some software, but you need a system administrator to install Linux for you and configure it", a lot of the advantage of Linux goes away, because at least on the surface, that doesn't sound too different from NT.
The goal shouldn't be to "beat Microsoft" for the sake of beating Microsoft. But I think doing well in the education market really matters for the future of any OS, and that's why Linux needs to catch on there more. What are the issues?
The idea that PCs are easier to maintain is a myth. Current PCs require software installation and administration on every machine (Microsoft terminal server is immature, not compatible with a lot of software, difficult to administer, NT only, and very expensive). The windows deployment model is an administrative nightmare. Indeed, people have struggled turning on and off Windows machines because not even that is simple.
In contrast, with Linux and similar systems, you can set up a number of centrally administered servers together with lots of low end clients. Since schools get a lot of donated hardware, the ability to run a Linux client (just X11 or VNC) on a 386 or 486 is an added bonus, and there is very little students or teachers can mess up on the machines they interact with.
A PC with Linux, software development tools, data analysis tools, state-of-the-art statistical software, and a development system is a fraction of the cost of an equivalent PC with Windows and corresponding Windows applications. Windows software is enormously expensive.
Whatever students will start off learning, they will likely want to stick with. Do we really want to turn our schools into advertisers and trainig facilities for one large corporation? Microsoft's APIs are proprietary and rapidly changing; with Linux, BSD, and similar systems, students learn an official, widely-used standard.
No, we shouldn't try to "beat Microsoft" for the sake of beating Microsoft. And I have no problem with upper middle class families buying as much expensive Microsoft software as they like. However, for something as cost sensitive as schools (and paid for by my tax dollars), Microsoft is really a gold plated boondoggle. Systems like Linux get the job done much cheaper, with less system administration and less work by the end user. That's why Linux ought to play a big role, both in school administration and in teaching.
(Incidentally, I was involved in getting a networked system of computers installed at my high school, paid for by donations, so I have some experience with the kind of usage these systems see. And, no, it wasn't running Linux--this was pre-Linux.)
People may think this sort of thing can't work, but of course it can. If you keep MP3s out, you kill off a market for portable players, software based players, etc.
A government can go a step further and outlaw all on-line audio and video formats that don't incorporate copy protection; if you break those laws, they would be able to confiscate your equipment and assess penalties, and any dealer who sells or distributes such equipment would face stiff penalties as well.
This is clearly where the RIAA, the MPAA, and their equivalents in other countries would like things to go. They want to replace all open audio and video formats with proprietary formats, formats that incorporate copy protection and per-use payments. Restrictions on reverse engineering and "breaking copyright protections" make open implementations impossible. Patented compression and encryption schemes would further limit the ability of others to legally access that content.
Even personal content you create would be subject to those restrictions. If you want to be able to look at your kid growing up in copy-protected, proprietary video 20 years from now, think again. The proprietary players will not work on the new hardware and software, and since they never got documented or reverse engineered, your data will be lost. And if you are a small artist, you will, of course, have to pay the "inventors" of those proprietary formats a pretty penny for the privilege of using their technology; funny that the same "inventors" are also your big name competition in the media markets.
Media companies want to control the distribution channels (Sony music, Polygram, and all those others sites, of course, wouldn't get blocked, but small artists would) and the formats (have you tried making a consumer-readable DVD recently? why do you think it's so expensive?).
It's not surprising that these organizations have a sympathetic ear in Germany, where free speech is not quite as cherished as in the US. But in both countries, everybody should get scared by this. Allowing big media companies to control the formats by which we communicate is a direct attack on our most basic rights. Streaming MP3 and MPEG-2 will likely become the formats of choice for audio and video mail and conferencing once bandwidth catches up (their quality is too low for real music enjoyment anyway). MP3 and similar formats are the direct equivalent of the air, paper, and wires we communicate over today. Do we want to hand control over those to a few large companies?
I hope politicians will get sufficiently frightened by such a future to prevent it. Open media formats and open access to those media formats is essential in a free, democratic society. Most other considerations ought to be secondary.
The fact that AOL could pull Gnutella should serve as an important reminder to many people: you probably don't own the software you write.
In the US, whether you work for a large corporation, for a small corporation, or whether you are a student at a university, whether you develop software in your "spare time" or during work hours, most likely, any work you do probably belongs to your employer or your school according to your contract with your employer. The only common exceptions to this are if your employer simply isn't at all in the computer field (and which employer these days isn't?) or if you are a freelancer or consultant.
This also raises interesting questions about what happens if an employee or student releases software under the GPL but it later turns out that they didn't own the software in the first place because of their employment contract. I suspect that the actual owner's rights would take precedence in that case and the GPL license would be void. In fact, that's probably the case with Gnutella. And if you put a lot of the GPL'ed software that is out there under a legal microscope, you'd probably find that a lot of it is actually owned by some university or company.
The UNIX of today is already very different from the UNIX of 20 years ago. What UNIX has managed to do like no other system, however, is to preserve logical and functional continuity.
Programs I wrote for UNIX 10 years ago still work just fine and take full advantage of the larger memory and faster processors. That is not at all true of systems like Windows.
UNIX is also a particular approach to writing kernels, based around a monolithic, fairly simple privileged core. UNIX kernels are also pretty closely tied to the C language. That's very different from microkernels, Windows, or other systems. And UNIX is a set of conventions for where and how to represent system configuration information, command line programs, etc.
That kind of continuity can't last forever, and eventually people will start using systems that can't realistically be called "UNIX" anymore.
Sooner or later, kernels will have to be written differently and in languages other than C, the file system will change into some different kind of database, etc. People will also build new replacements for system configuration information, the init/login sequence, etc.
I suspect, however, that the transition from UNIX to its successors will be fairly gradual, and that any successors will continue to offer reasonable POSIX implementations for a long time to come.
Plan 9 and Mach are both examples of successors to UNIX that really have some good continuity with it, and that's probably what's in store both commercially and in the open source community.
Well, C++ was already old technology by the time it was "invented" in the 1980's. The lack of runtime safety, dependence on storage layouts, and static approach to OOP it represents is more characteristic of the languages of the 1960's and 1970's. By the 1980's, dynamic OOP was already widely available.
Kdelibs must be frozen to the point that they will not become binary incompatible again for a long time, at least a year or more. However, we do not want to preclude the possibility of making important fixes and additions after the release. For this possibility to exist, we must add private member pointers to each class,
This is one of the reasons why C++ is such a poor choice for implementing toolkits and other large libraries. Worse yet, if you break binary compatibility, most likely, you'll get memory corruption, often in some unrelated piece of code. The workaround that the KDE folks are taking, adding private member pointers, is also pretty cumbersome (I find that there are better approaches).
Altogether, I find this pretty depressing. We are in the year 2000, and people are still writing software and using tools like it's the 1970's.
pre-electronic versions
on
Date Pagers
·
· Score: 2
We already have a lot of pre-electronic versions of these, and they work rather well: wedding rings, muscles, dress, hair style, jewelry, gadgets, books, etc. all tell you a lot about the other person. Those are already deliberate broadcasts of availability, interests, socio-economic status, etc. So, I wouldn't get all pushed out of shape about an electronic version: it doesn't do anything different from what people have already been doing for thousands of years.
The idea, btw, is pretty old. The problem is mainly that you need a critical mass of this kind of device to make it work. If they get it down to a couple of dollars, make it credit-card sized, and can hand it out with a drink at a nightclub, perhaps they'll catch on more.
I don't expect any "good-will gestures" from Sun. Sun is a large corporation, and they will do anything legal to maximize stock holder value and return, just like Microsoft or IBM.
However, Sun's business circumstances forces them to behave in ways that are currently more in-line with the long term interests of their customers. I also think that Sun is technically more competent than Microsoft.
As for Java, I have to disagree. I have been responsible languages for various development projects and groups in the past. In my judgement, the Java designers made a number of essential, pragmatic choices that simply make the Java system more suitable and cost effective for many application developers than Smalltalk. In fact, I had evaluated, and programmed in, Smalltalk just before Java came out and decided that it simply wasn't an acceptable choice for our needs. I think most other developers came to the same conclusion.
It's common for developers and inventors of other languages to dismiss the success of languages like C++ and Java as irrational. I think that attitude is self-defeating. Eiffel, Ada, and Smalltalk are marginal languages because C++ and Java, despite their myriad of well-known limitations, met the needs of actual developers better. If you want to understand this, I suggest reading Steele's "Growing a Language" and Gabriel's "Worse is Better".
I don't understand what your problem with Sun is. Even if Sun didn't release anything open source or under their community license, the fact that they have brought to market a programming environment that offers runtime safety, security, a very complete GUI toolkit, and reflection in itself is important. The commercial availability of that kind of environment represents a fundamental advance over the existing C++/COM and Objective-C based environments.
The fact that Sun's systems are documented well enough that reasonably compatible third party implementations are plausible, the fact that Sun has released chunks of their system under open source and community licenses, and the fact that Sun is supporting ports for other platforms (Linux, Win32) are icing on the cake.
So, I strongly disagree when you imply that Sun's current success is just due to misleading marketing. To me, Sun has a good product and their open source efforts and support for non-Sun platforms are meaningful. All of those are in sharp contrast to Microsoft. People choose Sun over Microsoft because of technical advantages and despite Microsoft's installed base and despite Microsoft's marketing prowess.
The first thing to realize is that this is a lot harder in practice than it seems like it ought to be. So, don't be too frustrated: everybody is struggling with this, and if you managed to build a high-volume dynamic site by yourself, that's already a big achievement.
The best way of dealing with complexity is to simplify and limit features to the essentials. JavaScript, graphics, fancy layout, etc. all can present an bottomless hole for time and bandwidth.
Another thing to realize is that the relational database you are using is probably one of your biggest bottlenecks. Relational databases are slow. MySQL is actually one of the faster ones, but that's because it doesn't make a lot of the guarantees or provide a lot of the features that a "real" relational database provides. You can get a lot of performance from your relational database by tuning it, but ultimately, the architecture and functionality itself present a limit. If speed is of the essence, consider using dbm, plain files, or memory mapped files (Apache has several "databases" internally, and that's its approach.)
For a single person project, Java is probably not the best implementation language. It really shines for multiprogrammer projects. You may find that Python, PHP, or Ruby are better choices. Perl and Tcl are also widely used, but they are also the oldest of the scripting languages and have a lot of rough edges and clunkiness. The performance of all of them is excellent when used as server plug-ins. Perl and PHP have by far the largest libraries and toolsets.
Some of the packages I haven't used but that look interesting are the following. Enhydra takes a much better approach to dynamic HTML than most other packages, I think. Erlang / Eddie address scalability, reliability, and clustering in a really clean way (but you have to learn a new language). Zope I think has a lot of good ideas, but I'm not sure I'd use it for a large server.
Most load balancing solutions use some kind of network routing hacks. That's efficient, but can be a pain to configure. However, there is now a load balancing module for Apache that works as a proxy; that's probably also worth looking into.
The Coda file system is a free, next-generation AFS; while I'm not sure Coda is mature enough yet to be used in heavy-duty applications, systems like it help with scalability by replicating files automatically and have been used on some really large web sites.
I would stay away from commercial "application server platforms". They often are mostly repackaged open source software, and they are expensive and complex, and while they claim to be general, they are also usually created with fairly specific commercial applications in mind ("shopping cart", etc.). I think those kinds of packages are worthwhile for corporate developers that work with large teams of programmers and need consistency, documentation, training, and support.
So, to recap, this kind of stuff is still a lot of work and it seems like you are ahead actually. But there are a lot of proven open source tools available that have been used on really big projects. There are also a lot of open source developments coming around that may make this kind of project a easier.
I read the HRA in a way that it simply doesn't apply to home computers (or other devices, like PDAs, whose primary purpose isn't music reproduction).
If that reading is correct, the opposite of what the RIAA claims is true: in fact, within the bounds of existing copyright law and fair use, you can do whatever you want to with digital recordings. You are only restricted if you use one of the formats or devices that are actually covered by the act.
Sure it does: the RIAA is using the DCMA to the capabilities and availability of devices for distributing free music. MP3 narrowly made it out, but most MP3 players have functional limitations to discourage copying of music, whether it be free or not.
So, the whole point of this furor over Napster and DeCSS is that, if their legal challenges are succesful, the RIAA/MPAA get more control over content than they should according to copyright law.
In different words, when taken together with its legal interpretation and fundamental technological principles, the effect of the DCMA is to limit the availability of free music as well. And, frankly, I suspect the RIAA is quite happy about that, too.
Something I don't often see pointed out is our culture's view of the whole situation. Pirating has been around as long as intellectual property, but keep in mind that "stealing" intellectual property is considered bad in our society.
In this regard, it's perhaps worth pointing out that some of the greatest works of classical music would be considered "stolen" by today's definition of intellectual property, borrowing themes, ideas, and whole passages from previous works. The same is true of many great works of literature.
The notions of "intellectual property" and "piracy" in today's US society are being shaped by commercial and corporate interests. They may, in some areas, overlap with societal interests, but in other areas, they clearly do not.
With ECP, cellular carriers simply say "our channels are secure because nobody can legally listen in to them". And people believe them because, after all, they can't just go out and buy a scanner that picks up cellular phone conversations.
Of course, in practice, it's trivial for anybody who wants to to listen in on the cell phone bands anyway. All ECP did is remove the responsibilty for cell phone carriers to worry about security.
ECP has made cellular phone security a lot worse because it removed any incentive for cellular carriers to make the investments necessary to make their systems actually secure.
As for the cost of implementing encryption and deciding on keylengths, those are pretty trivial. Cellular phone companies roll out new protocols and phones with steady regularity; adding encryption with a reasonably secure key length would not be a big deal. Furthermore, key lengths that are reasonably secure by today's standards would be sufficient because cell phone streams are real-time, not recorded (and it would be impractical to do so for an adversary in a properly designed system).
I don't condone people listening in on private conversations, but the ECP has made the situation worse, not better.
MP3 and similar digital media allow cultural content to be created and exchanged at very low cost compared to traditional media. That allows people (musicians, amateurs, etc.) who previously couldn't afford to publish to finally publish and participate in our cultural life. No more are we dependent on recording companies to make the decisions for us.
I don't know whether the widespread existence of MP3 and similar media is a long term threat to recording companies or not. It may be a threat. The recording companies sure seem to see it that way. And that's why they have been systematically trying to attack and dismantle a free and open media infrastructure. For example, they intend to replace CDs with DVDs with copyright protection. They go aggressively after consumer devices capable of playing MP3 (they lost the first round, but not try to limit capabilities and supporting infrastructure).
Furthermore, the alternatives they propose not only enforce their copyrights, they also limit the ability of others who are not part of their consortia to participate. In fact, without special cryptographic hardware, you can't have an open format that enforces play restrictions.
If there are free, open digital media, people will be able to use them for redistributing copyrighted works. As a society, we have to choose whether we want a world in which only recording companies get to control what gets published or whether we want to give everybody the ability to publish.
The answer is pretty clear to me: the narrow commercial interests of recording companies are secondary to the societal interests in a democracy to allow the free sharing of non-proprietary information, even if the mechanisms for such sharing limit the potential profits of the recording companies by not letting them impose play restrictions. If recording companies want to impose additional restrictions, the burden ought to be on them to figure out how to do that; they already wield enough commercial and market power and don't need the legal system to support their escapades.
You shouldn't have to take up a slot with a card that pretends to be a graphics card because some tiny BIOS program can't be bothered talking to the serial port directly. So, I don't think this solution is "proper", as in "the right thing to do".
That doesn't make it any less useful if you are stuck with a machine that doesn't have serial BIOS support.
I hope, however, that PC vendors will start to adopt the (open firmware standard). People are working on an open source implementation for PCs.
Mostly what X11 lacks is antialiased fonts and antialised graphics, but that's no reason to throw out X11.
X11 has a widely-used extension mechanism that makes it easy to add those. That extension mechanism is already used for, for example, direct graphics, low bandwidth transmissions, video mode extensions, double buffering, power management, shaped windows, video, graphics tablets, and a lot of other features you probably consider "standard" (check "xdpyinfo" to see all the extensions your server has). Some extensions that have been created by not included in XFree86 are server-side image compression/decompression, server-side image processing, and server-side video.
Adding antialiased fonts and graphics via such a mechanism isn't hard (the hard part is implementing the low level graphics routines in the server).
It may be good to start from scratch in the long run (as Berlin does), but for practical purposes, I think you can get a lot more mileage out of X11 with much less effort. And there is a lot of infrastructure and functionality in and around X11 that will take a long time to replicate in another system.
Besides Berlin, don't overlook Java. In the long run, it may well be the best replacement for X11. While it is currently only loosely coupled to in client/server applications, you can use it in a way that's similar to Display PostScript. And it improves over DPS in security, stability, and (with a good implementation) performance. Your next C++ toolkit may well be automatically generated bindings to remote Java UI objects.
A few years ago, when awk, shell, and Motif, were the only games in town, that would have been great news. I used to write a lot of scripts in awk and shell. But these days, almost every machine has Perl, and you can get Tcl/Tk and Perl/Tk easily. Those tools are hardly without flaws, but for day-to-day scripting, I prefer them greatly to anything shell based.
Slashdot Mirror
M14 is impressive, but I think it's still quite far away from being mature enough for a consumer release, even a beta. If they release too early, that could further damage the reputation of open source.
Pardon my typo: the last sentence should, of course, read " I'll seriously consider an Apple laptop again when they have some pointing device other than a touchpad."
The problem with Apple laptops is that, as in so many other areas, Apple just doesn't give you a choice. Apple has the "one size fits all" attitude even worse than Microsoft. I'll seriously consider an Apple laptop again when they have some pointing device other than a trackpoint.
What I object to is Borland's implication that Emacs and GNU C/C++ don't represent professional tools. Think about it this way:
If we allow companies like Borland to redefine "professionalism" in terms of their GUI and RAD products, I think we are lowering our standards. I have no objection to their products being called "useful" and "professional", but the gold standard of skill to me is still that a programmer is comfortable and productive without all that handholding. That kind of "under the covers" understanding is important even if you spend all your time in VC++ or Borland, because the debuggers and GUI builders in those tools simply aren't getting the job done some of the time.
Not every professional programmer needs to achieve proficiency in vi, Emacs, and command line tools, but more ought to aspire to it. And appreciating those tools as professional and worthy of mastery is the first step towards that.
So, the question is: are we going to get Apple's current version of Objective-C/Objective-C++ into the main branch of GNU C? And what about Apple's Objective-C runtime (not all the libraries, just the runtime)? Is that available as part of Darwin?
I, for one, find these kinds of statements by Borland insulting. Linux has "mainstream professional development tools" (Emacs, GNU C/C++, etc.). Those are the kinds of tools professional developers have been using for decades, before PCs or Borland were even around.
It's not all that different from cameras: lots of people use point-and-shoot cameras for all sorts of business applications, but the true "professional" cameras are still the Nikon F4's and Hasselblads, clunky and slow by consumer standards, but they get the job done in the hands of the professionals.
Maybe Borland and Microsoft tools have grown up to be professional tools in their own right, for their own market niche (just like there are a lot of high-tech "professional cameras" now, not just manual ones). And they may get some following once more application developers move from Windows to Linux. But I haven't been holding my breath for those kinds of tools on Linux, and I doubt many current Linux developers have either.
Linux's success in schools, like anywhere else, depends on being able to put together turnkey solutions that provide the functionality people want at a lower price and with less work. Linux has all the ingredients to do a better job there: Linux works just fine in "appliance servers" with virtually no maintenance, it runs on the lowest-cost hardware on the planet, and it supports a suite of protocols (X11, VNC, HTTP, etc.) that make building network-based "plug-and-play" solutions really easy.
If you sell schools a box that doesn't need to be maintained and just plugs into their network and gets the job done year after year, I think you have a good value proposition. Of course, if you position your product as "here is some software, but you need a system administrator to install Linux for you and configure it", a lot of the advantage of Linux goes away, because at least on the surface, that doesn't sound too different from NT.
In contrast, with Linux and similar systems, you can set up a number of centrally administered servers together with lots of low end clients. Since schools get a lot of donated hardware, the ability to run a Linux client (just X11 or VNC) on a 386 or 486 is an added bonus, and there is very little students or teachers can mess up on the machines they interact with.
No, we shouldn't try to "beat Microsoft" for the sake of beating Microsoft. And I have no problem with upper middle class families buying as much expensive Microsoft software as they like. However, for something as cost sensitive as schools (and paid for by my tax dollars), Microsoft is really a gold plated boondoggle. Systems like Linux get the job done much cheaper, with less system administration and less work by the end user. That's why Linux ought to play a big role, both in school administration and in teaching.
(Incidentally, I was involved in getting a networked system of computers installed at my high school, paid for by donations, so I have some experience with the kind of usage these systems see. And, no, it wasn't running Linux--this was pre-Linux.)
A government can go a step further and outlaw all on-line audio and video formats that don't incorporate copy protection; if you break those laws, they would be able to confiscate your equipment and assess penalties, and any dealer who sells or distributes such equipment would face stiff penalties as well.
This is clearly where the RIAA, the MPAA, and their equivalents in other countries would like things to go. They want to replace all open audio and video formats with proprietary formats, formats that incorporate copy protection and per-use payments. Restrictions on reverse engineering and "breaking copyright protections" make open implementations impossible. Patented compression and encryption schemes would further limit the ability of others to legally access that content.
Even personal content you create would be subject to those restrictions. If you want to be able to look at your kid growing up in copy-protected, proprietary video 20 years from now, think again. The proprietary players will not work on the new hardware and software, and since they never got documented or reverse engineered, your data will be lost. And if you are a small artist, you will, of course, have to pay the "inventors" of those proprietary formats a pretty penny for the privilege of using their technology; funny that the same "inventors" are also your big name competition in the media markets.
Media companies want to control the distribution channels (Sony music, Polygram, and all those others sites, of course, wouldn't get blocked, but small artists would) and the formats (have you tried making a consumer-readable DVD recently? why do you think it's so expensive?).
It's not surprising that these organizations have a sympathetic ear in Germany, where free speech is not quite as cherished as in the US. But in both countries, everybody should get scared by this. Allowing big media companies to control the formats by which we communicate is a direct attack on our most basic rights. Streaming MP3 and MPEG-2 will likely become the formats of choice for audio and video mail and conferencing once bandwidth catches up (their quality is too low for real music enjoyment anyway). MP3 and similar formats are the direct equivalent of the air, paper, and wires we communicate over today. Do we want to hand control over those to a few large companies?
I hope politicians will get sufficiently frightened by such a future to prevent it. Open media formats and open access to those media formats is essential in a free, democratic society. Most other considerations ought to be secondary.
In the US, whether you work for a large corporation, for a small corporation, or whether you are a student at a university, whether you develop software in your "spare time" or during work hours, most likely, any work you do probably belongs to your employer or your school according to your contract with your employer. The only common exceptions to this are if your employer simply isn't at all in the computer field (and which employer these days isn't?) or if you are a freelancer or consultant.
This also raises interesting questions about what happens if an employee or student releases software under the GPL but it later turns out that they didn't own the software in the first place because of their employment contract. I suspect that the actual owner's rights would take precedence in that case and the GPL license would be void. In fact, that's probably the case with Gnutella. And if you put a lot of the GPL'ed software that is out there under a legal microscope, you'd probably find that a lot of it is actually owned by some university or company.
Programs I wrote for UNIX 10 years ago still work just fine and take full advantage of the larger memory and faster processors. That is not at all true of systems like Windows.
UNIX is also a particular approach to writing kernels, based around a monolithic, fairly simple privileged core. UNIX kernels are also pretty closely tied to the C language. That's very different from microkernels, Windows, or other systems. And UNIX is a set of conventions for where and how to represent system configuration information, command line programs, etc.
That kind of continuity can't last forever, and eventually people will start using systems that can't realistically be called "UNIX" anymore.
Sooner or later, kernels will have to be written differently and in languages other than C, the file system will change into some different kind of database, etc. People will also build new replacements for system configuration information, the init/login sequence, etc.
I suspect, however, that the transition from UNIX to its successors will be fairly gradual, and that any successors will continue to offer reasonable POSIX implementations for a long time to come.
Plan 9 and Mach are both examples of successors to UNIX that really have some good continuity with it, and that's probably what's in store both commercially and in the open source community.
Well, C++ was already old technology by the time it was "invented" in the 1980's. The lack of runtime safety, dependence on storage layouts, and static approach to OOP it represents is more characteristic of the languages of the 1960's and 1970's. By the 1980's, dynamic OOP was already widely available.
This is one of the reasons why C++ is such a poor choice for implementing toolkits and other large libraries. Worse yet, if you break binary compatibility, most likely, you'll get memory corruption, often in some unrelated piece of code. The workaround that the KDE folks are taking, adding private member pointers, is also pretty cumbersome (I find that there are better approaches).
Altogether, I find this pretty depressing. We are in the year 2000, and people are still writing software and using tools like it's the 1970's.
The idea, btw, is pretty old. The problem is mainly that you need a critical mass of this kind of device to make it work. If they get it down to a couple of dollars, make it credit-card sized, and can hand it out with a drink at a nightclub, perhaps they'll catch on more.
However, Sun's business circumstances forces them to behave in ways that are currently more in-line with the long term interests of their customers. I also think that Sun is technically more competent than Microsoft.
As for Java, I have to disagree. I have been responsible languages for various development projects and groups in the past. In my judgement, the Java designers made a number of essential, pragmatic choices that simply make the Java system more suitable and cost effective for many application developers than Smalltalk. In fact, I had evaluated, and programmed in, Smalltalk just before Java came out and decided that it simply wasn't an acceptable choice for our needs. I think most other developers came to the same conclusion.
It's common for developers and inventors of other languages to dismiss the success of languages like C++ and Java as irrational. I think that attitude is self-defeating. Eiffel, Ada, and Smalltalk are marginal languages because C++ and Java, despite their myriad of well-known limitations, met the needs of actual developers better. If you want to understand this, I suggest reading Steele's "Growing a Language" and Gabriel's "Worse is Better".
The fact that Sun's systems are documented well enough that reasonably compatible third party implementations are plausible, the fact that Sun has released chunks of their system under open source and community licenses, and the fact that Sun is supporting ports for other platforms (Linux, Win32) are icing on the cake.
So, I strongly disagree when you imply that Sun's current success is just due to misleading marketing. To me, Sun has a good product and their open source efforts and support for non-Sun platforms are meaningful. All of those are in sharp contrast to Microsoft. People choose Sun over Microsoft because of technical advantages and despite Microsoft's installed base and despite Microsoft's marketing prowess.
The best way of dealing with complexity is to simplify and limit features to the essentials. JavaScript, graphics, fancy layout, etc. all can present an bottomless hole for time and bandwidth.
Another thing to realize is that the relational database you are using is probably one of your biggest bottlenecks. Relational databases are slow. MySQL is actually one of the faster ones, but that's because it doesn't make a lot of the guarantees or provide a lot of the features that a "real" relational database provides. You can get a lot of performance from your relational database by tuning it, but ultimately, the architecture and functionality itself present a limit. If speed is of the essence, consider using dbm, plain files, or memory mapped files (Apache has several "databases" internally, and that's its approach.)
For a single person project, Java is probably not the best implementation language. It really shines for multiprogrammer projects. You may find that Python, PHP, or Ruby are better choices. Perl and Tcl are also widely used, but they are also the oldest of the scripting languages and have a lot of rough edges and clunkiness. The performance of all of them is excellent when used as server plug-ins. Perl and PHP have by far the largest libraries and toolsets.
Some of the packages I haven't used but that look interesting are the following. Enhydra takes a much better approach to dynamic HTML than most other packages, I think. Erlang / Eddie address scalability, reliability, and clustering in a really clean way (but you have to learn a new language). Zope I think has a lot of good ideas, but I'm not sure I'd use it for a large server.
Most load balancing solutions use some kind of network routing hacks. That's efficient, but can be a pain to configure. However, there is now a load balancing module for Apache that works as a proxy; that's probably also worth looking into.
The Coda file system is a free, next-generation AFS; while I'm not sure Coda is mature enough yet to be used in heavy-duty applications, systems like it help with scalability by replicating files automatically and have been used on some really large web sites.
I would stay away from commercial "application server platforms". They often are mostly repackaged open source software, and they are expensive and complex, and while they claim to be general, they are also usually created with fairly specific commercial applications in mind ("shopping cart", etc.). I think those kinds of packages are worthwhile for corporate developers that work with large teams of programmers and need consistency, documentation, training, and support.
So, to recap, this kind of stuff is still a lot of work and it seems like you are ahead actually. But there are a lot of proven open source tools available that have been used on really big projects. There are also a lot of open source developments coming around that may make this kind of project a easier.
If that reading is correct, the opposite of what the RIAA claims is true: in fact, within the bounds of existing copyright law and fair use, you can do whatever you want to with digital recordings. You are only restricted if you use one of the formats or devices that are actually covered by the act.
So, the whole point of this furor over Napster and DeCSS is that, if their legal challenges are succesful, the RIAA/MPAA get more control over content than they should according to copyright law.
In different words, when taken together with its legal interpretation and fundamental technological principles, the effect of the DCMA is to limit the availability of free music as well. And, frankly, I suspect the RIAA is quite happy about that, too.
In this regard, it's perhaps worth pointing out that some of the greatest works of classical music would be considered "stolen" by today's definition of intellectual property, borrowing themes, ideas, and whole passages from previous works. The same is true of many great works of literature.
The notions of "intellectual property" and "piracy" in today's US society are being shaped by commercial and corporate interests. They may, in some areas, overlap with societal interests, but in other areas, they clearly do not.
Of course, in practice, it's trivial for anybody who wants to to listen in on the cell phone bands anyway. All ECP did is remove the responsibilty for cell phone carriers to worry about security.
ECP has made cellular phone security a lot worse because it removed any incentive for cellular carriers to make the investments necessary to make their systems actually secure.
As for the cost of implementing encryption and deciding on keylengths, those are pretty trivial. Cellular phone companies roll out new protocols and phones with steady regularity; adding encryption with a reasonably secure key length would not be a big deal. Furthermore, key lengths that are reasonably secure by today's standards would be sufficient because cell phone streams are real-time, not recorded (and it would be impractical to do so for an adversary in a properly designed system).
I don't condone people listening in on private conversations, but the ECP has made the situation worse, not better.
I don't know whether the widespread existence of MP3 and similar media is a long term threat to recording companies or not. It may be a threat. The recording companies sure seem to see it that way. And that's why they have been systematically trying to attack and dismantle a free and open media infrastructure. For example, they intend to replace CDs with DVDs with copyright protection. They go aggressively after consumer devices capable of playing MP3 (they lost the first round, but not try to limit capabilities and supporting infrastructure).
Furthermore, the alternatives they propose not only enforce their copyrights, they also limit the ability of others who are not part of their consortia to participate. In fact, without special cryptographic hardware, you can't have an open format that enforces play restrictions.
If there are free, open digital media, people will be able to use them for redistributing copyrighted works. As a society, we have to choose whether we want a world in which only recording companies get to control what gets published or whether we want to give everybody the ability to publish.
The answer is pretty clear to me: the narrow commercial interests of recording companies are secondary to the societal interests in a democracy to allow the free sharing of non-proprietary information, even if the mechanisms for such sharing limit the potential profits of the recording companies by not letting them impose play restrictions. If recording companies want to impose additional restrictions, the burden ought to be on them to figure out how to do that; they already wield enough commercial and market power and don't need the legal system to support their escapades.
That doesn't make it any less useful if you are stuck with a machine that doesn't have serial BIOS support.
I hope, however, that PC vendors will start to adopt the (open firmware standard). People are working on an open source implementation for PCs.
X11 has a widely-used extension mechanism that makes it easy to add those. That extension mechanism is already used for, for example, direct graphics, low bandwidth transmissions, video mode extensions, double buffering, power management, shaped windows, video, graphics tablets, and a lot of other features you probably consider "standard" (check "xdpyinfo" to see all the extensions your server has). Some extensions that have been created by not included in XFree86 are server-side image compression/decompression, server-side image processing, and server-side video.
Adding antialiased fonts and graphics via such a mechanism isn't hard (the hard part is implementing the low level graphics routines in the server).
It may be good to start from scratch in the long run (as Berlin does), but for practical purposes, I think you can get a lot more mileage out of X11 with much less effort. And there is a lot of infrastructure and functionality in and around X11 that will take a long time to replicate in another system.
Besides Berlin, don't overlook Java. In the long run, it may well be the best replacement for X11. While it is currently only loosely coupled to in client/server applications, you can use it in a way that's similar to Display PostScript. And it improves over DPS in security, stability, and (with a good implementation) performance. Your next C++ toolkit may well be automatically generated bindings to remote Java UI objects.
A few years ago, when awk, shell, and Motif, were the only games in town, that would have been great news. I used to write a lot of scripts in awk and shell. But these days, almost every machine has Perl, and you can get Tcl/Tk and Perl/Tk easily. Those tools are hardly without flaws, but for day-to-day scripting, I prefer them greatly to anything shell based.