My whole point is that you don't have to "crack" anything in order to get the bitstream. Any PC emulator can be easily hacked up to replay any encrypted audio or multimedia stream as often as you like; users don't need any special expertise for that, and it doesn't require any work specific to the particular content stream.
Replaying executions, emulation, etc. are all essential parts of computer science and software development. Nonsensical claims that encryption somehow makes content technically secure and un-replayable are really just attempts to get the legal system to define as "cracking" activities and tools that are vital to computer science. And that should concern us.
ZDNet suggested that in-process programming worked better for all the hairy e-commerce they decided to test. [...] Besides PHP and Mod_Perl, where can Linux go to improve?
Apache has a perfectly good in-process module API; mod_perl is written in it. You can write that kind of code yourself if you want to write C/C++ extensions to the Apache server.
I consider it pretty foolish, however, to write web server extensions for an E-commerce site in a language without runtime error checking or fault isolation. Applications specific modules simply can't receive the testing and debugging that Apache itself has received. You are lucky if the server crashes due to a bug; more likely, you are going to ship an unpredictable quantity of widgets to an unpredictable address as a stray pointer leads to overwriting some of your order data.
The performance difference between native code and Perl, Tcl, Python, Java, or PHP3 simply don't matter in most web applications: applications are generally bandwidth or database bound. Given that simple fact, you should use the safest and easiest language to program in. For single programmer projects, that's likely to be a scripting language. For large, component-based multi-programmer projects, that's likely to be Java, OO Pascal, Eiffel, or something of that kind.
ZDNet used multiprocessor servers. All religious handwaving aside, why did NT fare better by spinning threads than Apache could do by spinning processes?
Probably because people don't bother tuning the Linux kernel for good SMP performance on web tasks.
Why would that be? Because it doesn't make sense to pay the premium for four processors in a box when for less money you can get four processors in four boxes and quadruple your disk and network bandwidth. People use SMP on Windows mostly because of software licensing costs, because of per-box colocation costs, or because it sounds good. In my experience, SMP on Linux is mostly used for getting really high performance on numerical and scientific tasks.
It's pretty clear that the ability to convert and save RealAudio files has substantial non-copyright infringing uses (in particular, a lot of the content streamed with RealAudio may be copied freely). I believe that means that the DMCA grudgingly allows that kind of technology (but I might be wrong).
More generally, I find RealNetworks has gone bad. The biggies are:
Real promised to open up their protocols when they started out; instead, they have become more secretive and proprietary.
Real has secretly transmitted information from user's hard disks to their servers.
Real is trying to prevent content authored in their format to be converted to other formats.
I don't think I need another reason to remove Real software from my systems (in fact, I already have). MP3 satisfies many streaming needs, and if we really need to do better on the low bandwidth streaming side, there are a number of open protocols and encodings available.
There are new technologies in the pipeline to be released very soon, which will allow content providers to control access to their media to a much greater degree than is currently possible. I'm not just talking about the RIAA's MP3 replacement, but all downloadable digital media. What they do is to wrap the content up in an encrypted packet with a programmatic key which allows you to open it only once for each time you pay.
That's logically impossible unless you also incorporate cryptographically secure and sealed hardware. Otherwise, the encrypted content and the media stream can always be replayed.
Furthermore, you can, of course, always capture a copy at the device output, always in analog, and often even in digital format.
Claims like the one you make worry me because legislators may say that "well, if that is technically possible, anything that tries to circumvent it must be devious and should be made illegal".
Let's repeat this again: copyright enforcement via technology is intrinsically impossible. The most technology can contribute is means for detecting infringement when infringing works are redistributed to a public audience. And, actually, I think that's good enough, because it closely reflects the traditional dividing line between fair use (private copies) and infringing use (public distribution).
I have been using C++ since before the first compiler was available commercially, and I have a lot of experience with the various UNIX compilers. I always liked and preferred GNU C++, but it was also behind in terms of robust implementations of new language features compared to other UNIX implementations (and I have reported quite a few bugs in it over the years, including some code generation bugs).
As I said before, I don't think that's a problem at all. Free software doesn't have to be first to market. In fact, I think it's bad to set up such expectations. Because free software has been oversold as delivering not only the best, most extensible, and most robust product, but also being first to market, people are unreasonably declaring projects like Mozilla failures or at least off-target.
In my experience, free software is often not first to market.
It took Emacs decades to mature. And GNU C++ didn't become a reasonably complete C++ compiler years after good commercial implementations were already out there. Mature C/C++-based GUI toolkits took a few years to come out after mature commercial C/C++ GUI toolkits. Same for free, mature, powerful UNIX-like kernels.
It will take Mozilla quite some time to catch up with Internet Explorer in terms of features and stability. And free versions of Java will likely take years to catch up with Sun Java in terms of features and performance.
And I think there is nothing wrong with that. While it is nice when free software actually is first (and it sometimes is), the utility and importance of free software isn't diminished by coming out later.
YMMV, but I don't get too pushed out of shape about monitor info. I believe any modern 15" monitor should handle 1024x768, a modern 17" monitor should handle 1280x1024 at 70Hz, and a 20"+ monitor should handle 1600x1280 at 60Hz+. And, furthermore, I expect a well-built modern monitor not to die immediately because it gets the wrong video signal (but some undoubtedly will).
I figure it's not worth the hassle trying to track down old monitor specs, so if there is nothing obvious, I just make one up that has very generous ranges. I can then read off the actual frequencies from the console output of the X11 server. If a monitor were to die using that procedure, well, they have gotten pretty cheap and I probably didn't want it anymore anyway. But after installing Linux with dozens of different monitors, so far, I have not had a problem.
Of course, if Linux wants to take over the desktop, I think a more plug-and-play approach is needed. IT departments want easy installation on a variety of hardware.
I see no ethical, moral, or religious implications from reconstituting a cell in the way Venter proposes. Rather, his suggestion that this is somehow controversial is simply a standard PR tactic. Even P. T. Barnum used to do the same thing, writing pseudonymous letters to newspapers attacking himself.
Genetic testing in general, of course, has some privacy and insurance implications. The best solution to those is to have a strong participatory democracy, create strong legal protections for consumer privacy, and consider nationalizing health care, since health insurance would likely be the biggest abuser of this kind of data.
BTW, genetic discrimination is already widely practiced: all sorts of inherited conditions keep you from doing all sorts of things or getting all sorts of jobs, in some cases without much reason (e.g., inherited myopia will keep you from becoming an airforce pilot).
I understand their decision and don't actually see much benefit from having Java go through a standards body. Sun has been doing an excellent job on designing the language and the libraries; HP, Microsoft, and other "standards" participants would likely make things worse. So, from a practical point of view, I think it doesn't matter.
So far, Sun's Java specs are explicitly open: you can use them to build your own compatible implementation (you just can't call it "Java"). And Sun's Java specs are detailed and quite complete. This is in stark contrast to the Win32 API specs, which are so poorly documented that for practical purposes, it's not possible to make a complete independent implementation.
However, dropping the standardization effort also is bad PR because it gives the impression that Sun is renegging on their commitments.
One point of concern is that Sun every now and then seems to make some fuzzy claims about intellectual property related to the Java APIs. No matter who drives the evolution of the Java platform (Sun or a standards body), those parts of the Java specs would clearly not be acceptable to most users of Java, and that is something users need clarity on up-front.
If Sun does make IP claims related to parts of the APIs (rather than their implementation), that would be a serious matter and would have to be identified up front. That is a point, I think, Sun needs to be pressed on so that we don't end up in a situation analogous to GIF/Unisys. Those APIs would likely be only a small part of the Java platform and easily replaced by alternative de-facto standards developed outside Sun.
The emphasis there should be on "I". For group projects, this freedom can become a big problem as every programmer may adopt completely different (and maybe incompatible) ways of doing things. At the very least, you need to do a lot more work defining and enforcing coding standards than in more constrained languages.
"TIMTOWTDI" may be fun and even productive for individual programming, but there are lots of different contexts in which programming happens, and, not surprisingly, they all have different tools and languages.
I don't buy a lot of CDs, and when I do, it's only of (modern) classics, something I might want to listen to again ten years from now. MP3's aren't going to get me to go out and buy a lot of new CDs. And with all the new media and distribution channels, I suspect that the long term outlook for CD sales in general is not particularly good.
But MP3s have gotten me interested in genres of music I haven't previously listened to, and I'm much more likely to go to performances of music that I would otherwise not have considered going to.
According to the article, Microsoft didn't "sell" Visual J++, they stopped internal development and "signed a deal for [...] Rational Software to continue development of Visual J++". The article also didn't mention anything about the Microsoft Java virtual machine, so we may infer that they will retain control over that (Rational doesn't strike me like the kind of company to do runtime development). Also keep in mind that only a few months ago, Microsoft contracted with Transvirtual to add the Microsoft Java modifications to Kaffe.
If that is an accurate description of what happened, Microsoft will retain control over the direction and APIs in Visual J++.
The market, in particular the US consumer market, selects for things that are easy to use for novices, rather than things that are efficient for experienced users. Easy adoption underlies business success.
That's pretty much why systems like Windows and MacOS, systems that look easy to get started with, have been so successful. As an added bonus, because those systems lack a lot of power out of the box, there is a thriving market for add-ons for power users.
If you want hardware that is designed for professionals and experienced users, you have to pay a premium. That's true for computers just like it is for cameras. And often, you end up paying more for getting less (but the right kind of less). Fortunately, for software, the "professional" versions are often open source and free.
reasonable keyboards/pointing devices exist
on
Interface Zen
·
· Score: 2
I don't have a big problem with the standard IBM PC layout, although I generally find anything other than the main key group superfluous. I don't use the arrow keys, function keys, or numeric keypad if I don't have to.
Of course, under Windows, I have to use those parts of the keyboard because the Windows keybindings are so awful. On UNIX, of course, keybindings are usually very programmable and often optimized for skilled keyboard users.
One aspect of human/computer interaction I do find pretty awful is the mouse. But I bought Trackpoint keyboards for all my computers and hardly use the mouse anymore. A pointing stick device like that also lets me avoid using the inconvenient keybindings under Windows. Keyboards with a trackball under the thumb also seem very effective to me, and you can get them a lot cheaper.
If key shape rather than pointing device is your biggest problem, there are some manufacturers of older keyboards. In terms of key shapes and feel, the Symbolics Lisp machine keyboard was very good: it had solid keys, and all the peripheral keys were very big.
So, I think you can get the keyboards you want. With IBM PC keyboards, just ignore the useless keys or get one without them. I'd pay attention to the pointing device; Trackpoint (not the imitations) and trackballs under the thumb seem very efficient to me. And, try to use software that was designed for keyboard use and prefereably allows reasonable remapping.
Reading the extended summary on the WTO site, the TRIPS agreement seems less drastic than I had feared it might be.
The most obvious deviation that I see is that it requires compilation/database copyrights, something that raises serious concerns for science and other public areas of discourse. It also seems quite unrelated to free trade issues and far beyond the scope of the WTO.
As I read the summary, TRIPS allows the exclusion of many kinds of life forms from patentability. Although this is to be welcomed, it should give us pause to think that the document seems to assume that the WTO, in fact, has the authority to make sweeping decisions in this area.
TRIPS does seem to write into stone a 20 year minimum for patent protection, making any discussions of shortening patent protection for software moot.
I think even thought TRIPS is less serious than it could have been, it pretty clearly goes into a direction that is desired primarily by large multinational corporations, even though many of its provisions are not desired and have actually failed passage in WTO member countries. As such, it is another indication that WTO is far removed from the democratic accountabilities and decision processes by which we set social and economic policies.
TRIPS also looks like an attempt to bring developing countries into line that, so far, have had valid concerns about adopting and enforcing the IP laws of developed countries wholesale.
The WTO looks like a gigantic social and political experiment to me; free trade and global uniformity of regulations has never been tried on that kind of scale. I think slowing down and making the organization more accountable would be good.
The claims of the patent aren't limited to applying distributed computing techniques between an ISP and their customer, and it's the claims that ultimately matter.
I think I said pretty clearly what I want: I want people who choose a toolkit for building free software to read about and think about the license of that toolkit carefully. I'm not a commercial Troll Tech customer. I'm a CS researcher who prototypes a lot and occasionally releases software, some free, some not.
I looked at the Qt license, and I don't find it satisfactory. I think it is pretty clearly designed to create a potential market of future commercial software developers for Qt, and it funnels a lot of energy towards helping to improve a commercial toolkit. I also don't find the current QPL and KDE Qt Foundation sufficiently legally grounded to guarantee what it tries to guarantee.
People may have well have legitimate differences of opinion on whether that's a fair bargain. But I think anybody choosing Qt as a toolkit should at least carefully consider these issues and implications. In particular, I feel the KDE portrayal of Qt as just another open source GUI toolkit is misleading. For myself, I concluded that I couldn't live with the Qt license, that Tk and Gtk+ were good enough, and that I would better spend my time working with and on them.
I'm sorry, but I re-read the KDE Free Qt Foundation documents again, and I still don't get much reassurance.
The stated purpose of the Foundation is to "secure the availability and practicability of the Qt toolkit for developing free software for the X Window System". But what about "securing the availability" of the Qt toolkit for developing commercial software?
Also, the procedures for releasing Qt under a more liberal license look very vague to me. It talks about whether the Foundation 'regards the said edition for stopped or discontinued [sic]'. There are no definitions for when a majority vote is sufficient. Why is the KDE Qt Foundation agreement so vague?
In fact, I do pick any software that requires a significant investment in terms of time, training, and effort very carefully. While Troll Tech's technology may be good, Troll Tech wouldn't meet my criteria in terms of stability and long-term support for a commercial toolkit vendor (nor, in fact, the purchasing criteria of companies I have worked or consulted for). And if I invest time and effort in using Qt for free software, I'm implicitly choosing Troll Tech as a commercial vendor as well, since it would be a waste of time tooling up for one toolkit and then choosing a different vendor for commercial development.
In addition, I'm still unconvinced that the current agreements guarantee the continued viability even of the free edition of Qt because of the vagueness of the agreement between Troll Tech and the KDE Qt Foundation.
To me, both the free and the commercial Qt licenses are riddled with legal ambiguities, and I have decided that I can't live with those. I hope others will also look at the license and its implications in detail, rather than relying on vague reassurances. Nice as Qt may be, there are lots of alternatives available to it, under licenses that are much better defined.
Thanks for engaging in a discussion. Lots of other posters seem to consider any concerns about the Qt license to be merely flamebait without any basis in fact. I looked carefully at a number of toolkits and their licenses, and I simply cannot figure out how to commit to using Qt, even though it is the most mature of the bunch.
If an app you're developing is so great that you seriously believe people will send you money for it, $1500 is trivial.
I think that's a valid point, and I don't actually have a problem with paying $1500 for a toolkit that I'm going to use for a commercial application.
The problem I still have with QPL is that it means, effectively, that I'm committing to Troll Tech as a commercial vendor even when I start developing with their free version. Once I have invested in learning and tooling around a commercial system like that, I'm tied to them.
So, if I develop a mix of commercial and free software, my future options are greatly limited. And commitments to vendors are not one-time payments, they are an ongoing commitment to paying for maintenance, as well as confidence in the company's future.
If the situation came to this point, they will come to a conclusion that is in the best interest of the free software community.
I have no problem believing that the members of the Free Qt foundation have the best interests of the free software community at heart. But that still doesn't fill me with much confidence. If Troll Tech runs into trouble and push comes to shove, I can imagine many reasons why a unanimous vote may not be achievable; the Free Qt Foundation agreement simply looks to me like it's legally very vague, with lots of opportunities for problems.
While the Free Qt foundation is well-intentioned, it still doesn't fill me with any confidence that, should Troll Tech run into trouble, continued commercial support of Qt is assured. That's another reason why picking Troll Tech as a commercial vendor seems kind of iffy to me.
Even Bruce Perens considers Qt to be free software theese days.
I consider KDE "free software" as well (and high quality free software at that). That doesn't change my concerns about the license. Not all "free software" has licenses that work well for their intended purposes.
Read the QPL license and stop FUDding around.
I did read the QPL; that's why I'm concerned. I suggest you read it more carefully, too. I think you will find that it differs fundamentally from the LGPL. QPL is more of a GPL-style license, and that causes all sorts of problems for developers, even developers of software that may ultimately be released free.
I'm not associated with either GNOME or KDE; I'm simply a user and deveoper trying to decide for myself between GNOME and KDE. I'd love to develop KDE and Qt, because they seem somewhat more mature, but I don't see how I can, given the licenses. So, I do the next best thing: I develop for GNOME but use the good bits and pieces of KDE.
As for the license, this is not a question of "opinion" or "discussion" or "FUD"; just read the QPL yourself and understand it. You can find it at http://www.troll.no/qpl/.
There are many subtle differences between the QPL license and the GNOME/Gtk license, but there is also a big, fundamental difference: GNOME/Gtk is licensed under LGPL, while QPL is licensed under something resembling GPL. RMS and FSF got a lot of heat for GPL and the problems it caused, and LGPL was invented for that reason. I couldn't use Qt even if it came with a straight GPL license. Whether RMS calls QPL "open source" or not makes no difference to me; what matters is what the license itself requires.
Some other key items to notice with QPL are:
The distinction between "free" and "professional" edition exists, as it always did.
The intent behind QPL is stated as allowing the development of non-commercial software with it; for anything commercial, you have to pay. ("The QPL prohibits the development of proprietary software.")
If you read the "Free Qt Foundation" document carefully, you will see that the foundation can only grant a BSD-style license on Qt by unanimous vote of its members; what kind of safety is that?
I suggest that if you are serious about QPL/Qt and have actually read the licenses, you contribute some facts and analysis instead of anonymously complaining of "FUD". I have no personal investment in either GNOME or KDE; I'm just looking at it as a CS researcher who need to build GUIs occasionally, and as such I look carefully at the licenses of the software I use. And I still think the QPL doesn't cut it, for all the reasons I mention above.
KDE is a very useful desktop, and the development effort is impressive.
But, as far as I can tell, the fundamental legal situation around KDE's toolkit, Qt, hasn't changed: it's still proprietary, it still hasn't been ported to other platforms in a free form, and it will only be released under a true open source license if the "Free Qt Widget Foundation" decides to do so by unanimous vote, which seems unlikely to me given its probable membership.
I'll continue to use some KDE desktop components, but I will develop for GNOME myself. I hope other people in free software community will follow suit. For all the quality and enthusiasm that KDE brings to free software, I think KDE and Qt are setting a dangerous precedent.
For nerds and touch typists, I don't know of any better input device than the IBM Trackpoint. That's the same input device IBM uses on their laptops. It lets you type and mouse around without reaching for any kind of input device.
It takes a few days to get used to it, but once you are, it's a really efficient way to move the mouse pointer around.
I think a lot of people don't like the Trackpoint because they tried the knockoffs by Toshiba and HP; their "eraserhead" pointing devices don't work anywhere near as well as the IBM one. The trick to making those kinds of pointing devices work comfortably is in getting the mapping from force to pointer movement just right, and IBM did many years of user research and performance testing to improve that (even between IBM's different trackpoint models, there are noticeable differences: Trackpoint 4 is quite a bit more efficient than the older models).
You don't have to include a CD with sources with every system, but you do have to make the software available to customers who ask, and you have to let them know that they can ask. The risk if you don't include the source with every system is that it may look like you are trying to hide the source and circument the GPL.
If you include the source on CD, it shows good will and openness and pretty much avoids any risk that people will think you are trying to get around the GPL.
I wouldn't worry that people in large numbers recompile and alter your software; it's way too much work. For anything important, you should probably checksum the binaries on the deployed system and integrate checksum checks into your support structure (you can do this by hand or use the rpm system for it).
Slashdot Mirror
Replaying executions, emulation, etc. are all essential parts of computer science and software development. Nonsensical claims that encryption somehow makes content technically secure and un-replayable are really just attempts to get the legal system to define as "cracking" activities and tools that are vital to computer science. And that should concern us.
Apache has a perfectly good in-process module API; mod_perl is written in it. You can write that kind of code yourself if you want to write C/C++ extensions to the Apache server.
I consider it pretty foolish, however, to write web server extensions for an E-commerce site in a language without runtime error checking or fault isolation. Applications specific modules simply can't receive the testing and debugging that Apache itself has received. You are lucky if the server crashes due to a bug; more likely, you are going to ship an unpredictable quantity of widgets to an unpredictable address as a stray pointer leads to overwriting some of your order data.
The performance difference between native code and Perl, Tcl, Python, Java, or PHP3 simply don't matter in most web applications: applications are generally bandwidth or database bound. Given that simple fact, you should use the safest and easiest language to program in. For single programmer projects, that's likely to be a scripting language. For large, component-based multi-programmer projects, that's likely to be Java, OO Pascal, Eiffel, or something of that kind.
Probably because people don't bother tuning the Linux kernel for good SMP performance on web tasks.
Why would that be? Because it doesn't make sense to pay the premium for four processors in a box when for less money you can get four processors in four boxes and quadruple your disk and network bandwidth. People use SMP on Windows mostly because of software licensing costs, because of per-box colocation costs, or because it sounds good. In my experience, SMP on Linux is mostly used for getting really high performance on numerical and scientific tasks.
More generally, I find RealNetworks has gone bad. The biggies are:
- Real promised to open up their protocols when they started out; instead, they have become more secretive and proprietary.
- Real has secretly transmitted information from user's hard disks to their servers.
- Real is trying to prevent content authored in their format to be converted to other formats.
I don't think I need another reason to remove Real software from my systems (in fact, I already have). MP3 satisfies many streaming needs, and if we really need to do better on the low bandwidth streaming side, there are a number of open protocols and encodings available.That's logically impossible unless you also incorporate cryptographically secure and sealed hardware. Otherwise, the encrypted content and the media stream can always be replayed.
Furthermore, you can, of course, always capture a copy at the device output, always in analog, and often even in digital format.
Claims like the one you make worry me because legislators may say that "well, if that is technically possible, anything that tries to circumvent it must be devious and should be made illegal".
Let's repeat this again: copyright enforcement via technology is intrinsically impossible. The most technology can contribute is means for detecting infringement when infringing works are redistributed to a public audience. And, actually, I think that's good enough, because it closely reflects the traditional dividing line between fair use (private copies) and infringing use (public distribution).
As I said before, I don't think that's a problem at all. Free software doesn't have to be first to market. In fact, I think it's bad to set up such expectations. Because free software has been oversold as delivering not only the best, most extensible, and most robust product, but also being first to market, people are unreasonably declaring projects like Mozilla failures or at least off-target.
It took Emacs decades to mature. And GNU C++ didn't become a reasonably complete C++ compiler years after good commercial implementations were already out there. Mature C/C++-based GUI toolkits took a few years to come out after mature commercial C/C++ GUI toolkits. Same for free, mature, powerful UNIX-like kernels.
It will take Mozilla quite some time to catch up with Internet Explorer in terms of features and stability. And free versions of Java will likely take years to catch up with Sun Java in terms of features and performance.
And I think there is nothing wrong with that. While it is nice when free software actually is first (and it sometimes is), the utility and importance of free software isn't diminished by coming out later.
I figure it's not worth the hassle trying to track down old monitor specs, so if there is nothing obvious, I just make one up that has very generous ranges. I can then read off the actual frequencies from the console output of the X11 server. If a monitor were to die using that procedure, well, they have gotten pretty cheap and I probably didn't want it anymore anyway. But after installing Linux with dozens of different monitors, so far, I have not had a problem.
Of course, if Linux wants to take over the desktop, I think a more plug-and-play approach is needed. IT departments want easy installation on a variety of hardware.
Genetic testing in general, of course, has some privacy and insurance implications. The best solution to those is to have a strong participatory democracy, create strong legal protections for consumer privacy, and consider nationalizing health care, since health insurance would likely be the biggest abuser of this kind of data.
BTW, genetic discrimination is already widely practiced: all sorts of inherited conditions keep you from doing all sorts of things or getting all sorts of jobs, in some cases without much reason (e.g., inherited myopia will keep you from becoming an airforce pilot).
So far, Sun's Java specs are explicitly open: you can use them to build your own compatible implementation (you just can't call it "Java"). And Sun's Java specs are detailed and quite complete. This is in stark contrast to the Win32 API specs, which are so poorly documented that for practical purposes, it's not possible to make a complete independent implementation.
However, dropping the standardization effort also is bad PR because it gives the impression that Sun is renegging on their commitments.
One point of concern is that Sun every now and then seems to make some fuzzy claims about intellectual property related to the Java APIs. No matter who drives the evolution of the Java platform (Sun or a standards body), those parts of the Java specs would clearly not be acceptable to most users of Java, and that is something users need clarity on up-front.
If Sun does make IP claims related to parts of the APIs (rather than their implementation), that would be a serious matter and would have to be identified up front. That is a point, I think, Sun needs to be pressed on so that we don't end up in a situation analogous to GIF/Unisys. Those APIs would likely be only a small part of the Java platform and easily replaced by alternative de-facto standards developed outside Sun.
"TIMTOWTDI" may be fun and even productive for individual programming, but there are lots of different contexts in which programming happens, and, not surprisingly, they all have different tools and languages.
But MP3s have gotten me interested in genres of music I haven't previously listened to, and I'm much more likely to go to performances of music that I would otherwise not have considered going to.
If that is an accurate description of what happened, Microsoft will retain control over the direction and APIs in Visual J++.
That's pretty much why systems like Windows and MacOS, systems that look easy to get started with, have been so successful. As an added bonus, because those systems lack a lot of power out of the box, there is a thriving market for add-ons for power users.
If you want hardware that is designed for professionals and experienced users, you have to pay a premium. That's true for computers just like it is for cameras. And often, you end up paying more for getting less (but the right kind of less). Fortunately, for software, the "professional" versions are often open source and free.
Of course, under Windows, I have to use those parts of the keyboard because the Windows keybindings are so awful. On UNIX, of course, keybindings are usually very programmable and often optimized for skilled keyboard users.
One aspect of human/computer interaction I do find pretty awful is the mouse. But I bought Trackpoint keyboards for all my computers and hardly use the mouse anymore. A pointing stick device like that also lets me avoid using the inconvenient keybindings under Windows. Keyboards with a trackball under the thumb also seem very effective to me, and you can get them a lot cheaper.
If key shape rather than pointing device is your biggest problem, there are some manufacturers of older keyboards. In terms of key shapes and feel, the Symbolics Lisp machine keyboard was very good: it had solid keys, and all the peripheral keys were very big.
So, I think you can get the keyboards you want. With IBM PC keyboards, just ignore the useless keys or get one without them. I'd pay attention to the pointing device; Trackpoint (not the imitations) and trackballs under the thumb seem very efficient to me. And, try to use software that was designed for keyboard use and prefereably allows reasonable remapping.
The most obvious deviation that I see is that it requires compilation/database copyrights, something that raises serious concerns for science and other public areas of discourse. It also seems quite unrelated to free trade issues and far beyond the scope of the WTO.
As I read the summary, TRIPS allows the exclusion of many kinds of life forms from patentability. Although this is to be welcomed, it should give us pause to think that the document seems to assume that the WTO, in fact, has the authority to make sweeping decisions in this area.
TRIPS does seem to write into stone a 20 year minimum for patent protection, making any discussions of shortening patent protection for software moot.
I think even thought TRIPS is less serious than it could have been, it pretty clearly goes into a direction that is desired primarily by large multinational corporations, even though many of its provisions are not desired and have actually failed passage in WTO member countries. As such, it is another indication that WTO is far removed from the democratic accountabilities and decision processes by which we set social and economic policies.
TRIPS also looks like an attempt to bring developing countries into line that, so far, have had valid concerns about adopting and enforcing the IP laws of developed countries wholesale.
The WTO looks like a gigantic social and political experiment to me; free trade and global uniformity of regulations has never been tried on that kind of scale. I think slowing down and making the organization more accountable would be good.
The claims of the patent aren't limited to applying distributed computing techniques between an ISP and their customer, and it's the claims that ultimately matter.
I looked at the Qt license, and I don't find it satisfactory. I think it is pretty clearly designed to create a potential market of future commercial software developers for Qt, and it funnels a lot of energy towards helping to improve a commercial toolkit. I also don't find the current QPL and KDE Qt Foundation sufficiently legally grounded to guarantee what it tries to guarantee.
People may have well have legitimate differences of opinion on whether that's a fair bargain. But I think anybody choosing Qt as a toolkit should at least carefully consider these issues and implications. In particular, I feel the KDE portrayal of Qt as just another open source GUI toolkit is misleading. For myself, I concluded that I couldn't live with the Qt license, that Tk and Gtk+ were good enough, and that I would better spend my time working with and on them.
The stated purpose of the Foundation is to "secure the availability and practicability of the Qt toolkit for developing free software for the X Window System". But what about "securing the availability" of the Qt toolkit for developing commercial software?
Also, the procedures for releasing Qt under a more liberal license look very vague to me. It talks about whether the Foundation 'regards the said edition for stopped or discontinued [sic]'. There are no definitions for when a majority vote is sufficient. Why is the KDE Qt Foundation agreement so vague?
In fact, I do pick any software that requires a significant investment in terms of time, training, and effort very carefully. While Troll Tech's technology may be good, Troll Tech wouldn't meet my criteria in terms of stability and long-term support for a commercial toolkit vendor (nor, in fact, the purchasing criteria of companies I have worked or consulted for). And if I invest time and effort in using Qt for free software, I'm implicitly choosing Troll Tech as a commercial vendor as well, since it would be a waste of time tooling up for one toolkit and then choosing a different vendor for commercial development.
In addition, I'm still unconvinced that the current agreements guarantee the continued viability even of the free edition of Qt because of the vagueness of the agreement between Troll Tech and the KDE Qt Foundation.
To me, both the free and the commercial Qt licenses are riddled with legal ambiguities, and I have decided that I can't live with those. I hope others will also look at the license and its implications in detail, rather than relying on vague reassurances. Nice as Qt may be, there are lots of alternatives available to it, under licenses that are much better defined.
If an app you're developing is so great that you seriously believe people will send you money for it, $1500 is trivial.
I think that's a valid point, and I don't actually have a problem with paying $1500 for a toolkit that I'm going to use for a commercial application.
The problem I still have with QPL is that it means, effectively, that I'm committing to Troll Tech as a commercial vendor even when I start developing with their free version. Once I have invested in learning and tooling around a commercial system like that, I'm tied to them.
So, if I develop a mix of commercial and free software, my future options are greatly limited. And commitments to vendors are not one-time payments, they are an ongoing commitment to paying for maintenance, as well as confidence in the company's future.
If the situation came to this point, they will come to a conclusion that is in the best interest of the free software community.
I have no problem believing that the members of the Free Qt foundation have the best interests of the free software community at heart. But that still doesn't fill me with much confidence. If Troll Tech runs into trouble and push comes to shove, I can imagine many reasons why a unanimous vote may not be achievable; the Free Qt Foundation agreement simply looks to me like it's legally very vague, with lots of opportunities for problems.
While the Free Qt foundation is well-intentioned, it still doesn't fill me with any confidence that, should Troll Tech run into trouble, continued commercial support of Qt is assured. That's another reason why picking Troll Tech as a commercial vendor seems kind of iffy to me.
I consider KDE "free software" as well (and high quality free software at that). That doesn't change my concerns about the license. Not all "free software" has licenses that work well for their intended purposes.
Read the QPL license and stop FUDding around.
I did read the QPL; that's why I'm concerned. I suggest you read it more carefully, too. I think you will find that it differs fundamentally from the LGPL. QPL is more of a GPL-style license, and that causes all sorts of problems for developers, even developers of software that may ultimately be released free.
As for the license, this is not a question of "opinion" or "discussion" or "FUD"; just read the QPL yourself and understand it. You can find it at http://www.troll.no/qpl/.
There are many subtle differences between the QPL license and the GNOME/Gtk license, but there is also a big, fundamental difference: GNOME/Gtk is licensed under LGPL, while QPL is licensed under something resembling GPL. RMS and FSF got a lot of heat for GPL and the problems it caused, and LGPL was invented for that reason. I couldn't use Qt even if it came with a straight GPL license. Whether RMS calls QPL "open source" or not makes no difference to me; what matters is what the license itself requires.
Some other key items to notice with QPL are:
I suggest that if you are serious about QPL/Qt and have actually read the licenses, you contribute some facts and analysis instead of anonymously complaining of "FUD". I have no personal investment in either GNOME or KDE; I'm just looking at it as a CS researcher who need to build GUIs occasionally, and as such I look carefully at the licenses of the software I use. And I still think the QPL doesn't cut it, for all the reasons I mention above.
But, as far as I can tell, the fundamental legal situation around KDE's toolkit, Qt, hasn't changed: it's still proprietary, it still hasn't been ported to other platforms in a free form, and it will only be released under a true open source license if the "Free Qt Widget Foundation" decides to do so by unanimous vote, which seems unlikely to me given its probable membership.
I'll continue to use some KDE desktop components, but I will develop for GNOME myself. I hope other people in free software community will follow suit. For all the quality and enthusiasm that KDE brings to free software, I think KDE and Qt are setting a dangerous precedent.
It takes a few days to get used to it, but once you are, it's a really efficient way to move the mouse pointer around.
I think a lot of people don't like the Trackpoint because they tried the knockoffs by Toshiba and HP; their "eraserhead" pointing devices don't work anywhere near as well as the IBM one. The trick to making those kinds of pointing devices work comfortably is in getting the mapping from force to pointer movement just right, and IBM did many years of user research and performance testing to improve that (even between IBM's different trackpoint models, there are noticeable differences: Trackpoint 4 is quite a bit more efficient than the older models).
You can get several desktop versions of the Trackpoint keyboard from IBM. I bought Trackpoint 4 keyboards in "Stealth Black" for all my machines.
If you include the source on CD, it shows good will and openness and pretty much avoids any risk that people will think you are trying to get around the GPL.
I wouldn't worry that people in large numbers recompile and alter your software; it's way too much work. For anything important, you should probably checksum the binaries on the deployed system and integrate checksum checks into your support structure (you can do this by hand or use the rpm system for it).