I've written a number of pretty substantial multithreaded programs, and I have never used a debugger for fixing them. I don't even know what I'd be looking for with a debugger: serious bugs in multithreaded programs tend to be subtle race conditions, and that's not the kind of thing that's easy to track down with a debugger.
A better way is to avoid bugs in the first place. And for multithreaded programs, a message passing paradigm is generally the best approach in my experience.
I also use assertions and consistency check liberally, so that problems are caught close to where they occur. As a result, the few serious bugs that I have had were usually solvable by inspection of the source code alone.
If you are looking for languages that make avoiding bugs easier, look beyond C++. Java is slightly better than C++ for multithreaded programs because errors tend to be more localized, but Java doesn't have much in the way of useful higher-level abstractions for building multithreaded programs. The currently conceptually best languages for multithreaded programs, in my opinion, are SML/NJ, OCAML, and Erlang.
Yes, the Bell Labs folks write nice, clean, small code, and Inferno and Plan9 are powerful and well-designed systems. But there is no free lunch. The original Java VM was pretty small and light, too. Today's Java runtimes, however, are big and complex because people wanted them to do a lot.
Java itself offers several levels of tradeoff between functionality and size. To me, the most logical choice for a browser plugin wouldn't be an entirely new language and runtime, something that requires a lot of retraining and retooling, it would be a version of Personal Java, something that could easily fit into a few hundred kbytes.
Yes, it sucks that Fraunhofer has patented a lot of basic methods for audio compression. But why doesn't the open source community innovate a bit more? Ogg-Vorbis seems to use roughly the same conservative approach as the MP3 folks. Well, if you take roughly the same approach as your commercial predecessors, it's much harder to avoid stepping on their patents. Even wavelets, themselves hardly cutting edge anymore, were too new-fangled for the Ogg-Vorbis developers according to the FAQ.
Unfortunately, this seems to be symptomatic and a lot of open source development is permeated by conservatism that would make a stodgy company proud. Ogg-Vorbis is still based on decades old ideas about signal processing, the Linux kernel is still monolithically written in C like kernels were in the 1970s, and Gnome and KDE have barely progressed into the 1980s when it comes to GUI technologies.
Besides having a lot of upside potential (i.e., it may work better in the long run), going with newer, less proven ideas has the advantage that an open source effort has a much better chance of not treading on a well-patented path already. So, be adventuresome when you embark on your next open source project. Don't be content with just doing a slightly better job at something that has been around for a few years.
And if you are developing a new audio coder in particular, get out of the engineering straightjacket. Look at some new ideas in neural networks and pattern recognition and come up with something different from all the other audio coders in the market. Who knows, you may not just satisfy an open source need but actually contribute to the state of the art.
I don't see anything negative about Microsoft using Linux in any way. If they develop new drivers or file systems for it, they have to share them. If they add support for some of the more obscure features of the NT kernel, they have to share that, too. That's good.
If they come out with a mix of proprietary code, GNU command line utilities, and a Linux kernel (similar to what Apple did), that's good, too: no matter what, the end result will be closer to Linux than their current offerings.
In fact, I see Microsoft's market dominance through proprietary standards diminishing anyway. While the Windows 3.x series (including 98 and ME) was such a mess that nobody could hope to clone all of it, Windows NT is sufficiently well modularized that people will be able to implement it well as a "personality" on top of all sorts of kernels. And C#/.NET drives the abstraction even higher, making it even easier for others to clone. The irony is that the complexity of software development forces Microsoft to clean up their act, but the same thing also means that they lose their market position.
While the Linux kernel is very useful, it is also quite antiquated in its feature set, architecture, and extensibility. That's why kernel releases become ever more complex and take longer and longer: everything can potentially depend on everything else, and many kernel extensions need to be recompiled for every new release.
Mach-like kernels attempt to address this problem by dividing the kernel into "servers". Other kernels address it by using languages that have better support for modularization (SML, Java, etc.). Because the Linux kernel is monolithic and written in C, there aren't a whole lot of choices for how to achieve this. Exploring putting a system like CORBA into the kernel seems like a sensible approach. I don't think CORBA and kORBit is going to be the long term solution, but it may be a good testbed for these ideas.
While it may be nice for a mid-level manager to be able to point the finger for a software problem and for the company to be able to blame a vendor when the stock holders get annoyed, none of that helps the company's business. It doesn't recover any significant damages (EULA/UCITA...), and it won't get the software fixed.
To continue business operations, the software needs to get fixed as quickly as possible. And having the sources to the application gives a company the best chance of doing that as quickly as possible: they can contract out support, hire consultants, or develop the in-house expertise.
Besides, unlike hardware, software doesn't just usually wear out and go bad. Almost always, serious software problems are triggered by an insufficiently tested upgrade or by an untested change in business procedures. And as a stop-gap measure, it's usually feasible to undo whatever was done.
Problem size or volume can also get too large for software to handle. That's a specification, testing, and sizing problem, not a software bug, and closed-source vendors won't help with that either other than by selling more, more expensive software and hardware.
The main class of unexpected bugs that occur is security problems, and the record of open source software is considerably better of fixes than for proprietary, closed-source software. And with the closed-source software, nobody can even review the bug fix to make sure it doesn't cause more problems.
This is the same twisted logic that makes end users pay for the bug fixes they contributed for free to the company. The primary value of software is not in the programming, it is in the user community and the contributions of the user community. That is why it is bogus to say that Microsoft created the value in their software. And it is also why you should seriously consider using free software: with free software, you don't pay for your own contributions or the contributions other people make freely.
If you must submit a bug to a commercial software company, indicate that you do not transfer copyright to them. Or, even better, submit it to BugTraq first.
If you go to "Smarthome.COM, they have pretty much all the gadgets and interfaces: switches, dimmers, sensors, thermostat interfaces, voice control, etc. For interfacing it with a computer and for getting all the home networking, the new wireless 802.11 networks (like this) give you everything you need without expensive cables, and you can control X10 devices using the X10 serial port interface. x10.com also has wireless audio, video, and remote control transmitters/receivers. Even a really fancy system will only set you back a few thousand dollars.
Is it worth it? I bought some X10 controllers because it was cheaper and more convenient than having an electrician do a lot of rewiring. The thermostat may help save you energy since you can leave your heating off and turn it on remotely with a telephone call or via the Internet before you get home. Beyond that, it seems like it's a gimmick.
Linux isn't quite ready, but Id made mistakes, too
on
id On Linux: Bad News
·
· Score: 3
I think it's pretty clear that Linux isn't quite ready yet for 3D games. Getting hardware accelerated OpenGL to work under XFree86 3.* was a really dicey affair, and under XFree86 4.* it wasn't ready for prime time as of a few months ago (and probably still isn't).
But having said that, I think Q3 also was not well packaged for Linux. If you accidentally ran Q3 with software emulated 3D, it could take you minutes to get out of it because you just couldn't really talk to the UI, and if you tried to shortcut out of it, it would leave the video card in a bad state. Id should have provided a simple test program (rotating cube) and simple code to try different configurations. They could also have provided some additional software to help the user configure their X server; it's not that hard to figure out what to do even if the script doesn't know what distribution it's running on. Autoconf solves much harder configuration problems every day.
Also keep in mind that the beginnings of 3D hardware accelerated graphics on Windows were considerably more awful than what has been happening on Linux. On Windows, it was customary that games would conflict or trash the whole system.
So, yes, Linux 3D and game support in the year 2000 isn't as good yet as Windows. But for its brief existence, it is doing a whole lot better than Windows did in its beginnings. For the initial Windows releases of 3D accelerated games, vendors had a "can do" attitude. The variety of hardware and installation they had to deal with was much more complex than anything in the Linux world today. But it seems like they are losing their touch.
The shared memory transport under X-Window has never been implemented,
Shared memory transport for X11 has been around for over a decade. If you are running XFree86, you almost certainly have the MIT-SHM extension installed. It is widely used by programs that need high performance graphics.
Some vendors have additionally created server and Xlib implementations that use shared memory instead of sockets, although that never seemed to result in an interesting additional speedup. Eventually, I think people stopped bothering.
since in the beginning [X11] was not designed for fast graphic routine for personal computing, etc.
X11 was designed for implementing high-performance graphics workstation applications on what is fairly modest hardware by modern standards. That's why X11 is actually quite fast, efficient, and gives you a lot of low-level hooks.
However, X has advantage: although it's slower, it has network transparency so that you can run app over other computer via network. [...] Oh, by the way, the graphic display in MS-Windows is faster not only because of its driver is better + DirectX accel support, but also because it uses shared memory transport.
It's a myth that X11 is slower than the Win32 API. In fact, whenever I have compared the two, X11 wins hands down. The reason is probably that the Win32 API uses a lot more synchronous calls and forces more context switches.
In fact, in these days of accelerated graphics cards with their own processors, the X11 model is much closer to what is going on under the hood than the antiquated and inefficient Win32 "graphics library" model.
The main thing that comes to mind seeing this is: it's pretty pathetic. Do these people really have so little imagination to think that a nice, comfortable house is one with miles of cables, enormous numbers of video screens, and computers everywhere? And this kind of technology becomes obsolete so fast that they'll spend more time planning and updating their homes than enjoying them. I suppose it's a hobby like anything else.
Here's a suggestion: spend the money differently. Instead of a gigantic stereo system, hire real musicians. If it seems to aristocratic having musicians play for you privately, invite your friends over. Instead of a big video screen with tacky furniture, get some decent interior design advice and tuck the video safely out of sight. And instead of whiz-bang gadgets that don't work most of the time, hire some human household help; they may get sick occasionally, but they usually have a fully-functional, self-installing replacement available quickly.
but theyre a lot less evil than other software companies
It's not a question of being evil, it's a question of negative effects onto free or open source software. When Microsoft or some other company puts out a proprietary toolkit, that doesn't affect the open source or free software community negatively. When Troll Tech puts out a "semi-free" toolkit, that interferes with the development of truly free toolkits.
You don't like it? You do better. Thats what open source is all about, isn't it? [...] The fact that [xterm+twm on a PDA] is just shit for real world usage is completely unimportant, right?
Not at all. But if people adopt QPE on Linux PDAs widely, alternatives will be very slow in coming, both because QPE will take away the incentive of developing anything else and because it doesn't co-exist with other toolkits.
[Troll Tech's contribution] should not be ignored, much less denigrated by people like you
I don't "denigrate" their contribution; they do what every money-making corporation would do. In fact, there is lots of software that companies offer under lots of oddball licenses. That's neither good nor evil.
The people I criticize are people like you, who put short term expediency ahead of long term interests and claim it is in the interest of open source or free software. Develop for KDE or QPE all you want, but it is my opinion that in the long run, you are doing serious harm to Linux and open source software by doing so.
"Because QPE writes to the screen directly, it doesn't provide the ability to share the screen among
different toolkits the way you do in the X11 world. "
You mean networked protocol ?
No, I mean share the screen among different toolkits at all.
As to the price for QPE...
Direct quote from trolltech site
"Also released today is the Qt Palmtop Environment, which is the first Personal Information Management
(PIM) package for embedded Linux released under the GPL."
My point was about commercial developers. You may think "to hell with them", but the fact is that it is commercial developers that made the Palm successful.
Who is to say whether the identical bits are "yours" or "theirs"? If you copy files with "rsync", are you actually copying them? If you use transparent duplicate file elimination with copy-on-write, are there actually separate files?
If MP3.COM had provided a solution that had every user rip and encode the tracks on their machine, and then send the resulting MP3 to a my.mp3.com locker, they wouldn't have been hammered in court.
What mp3.com does is just a very optimized version of rsync. Forcing people to waste additional bandwidth by using a less efficient copying mechanism doesn't change the copy protocols, it is merely an attempt to make mp3.com as inconvenient to use as possible in order to boost distribution channels that the RIAA prefers.
Because QPE writes to the screen directly, it doesn't provide the ability to share the screen among different toolkits the way you do in the X11 world. QPE developers licenses cost between $2000 and $3000 per developer, which is a lot of money for small developers of commercial handheld applications. At those prices, the Palm would never have developed a thriving application market.
I think Troll Tech is merely using the open source community. If they manage to establish themselves as the preferred environment for handheld Linux systems, they stand to make a lot of money from commercial licenses because developers won't have a choice but to license their toolkit. And that comes at the cost of Linux on handhelds, because it makes Linux uncompetitive with Windows CE or Palm. This is considerably worse than the KDE/Qt situation, where at least non-Qt applications can co-exist with Qt applications on the same screen and exchange data.
I find this alliance between Troll Tech and some folks in the open source community a Faustian bargain. This kind of arrangement is going to come back and haunt us for years to come. Some "free" stuff is best not taken.
What people see when they get started with LaTeX is actually pretty close to what you want for a document format for the web: it has semantic markup, it's high-level, and it's fairly easy to enter.
Unfortunately, because of it's TeX heritage, the way LaTeX describes styles and macros is pretty clunky. Underneath the covers, it's more like a machine language, with numbered registers, side-effects, and odd processing hooks. XML/XSL is probably a better choice: it's more formally defined than LaTeX. The XSL transformation model is easier to understand and more predictable to most people.
The biggest problem with XML in my view is cosmetic: it's a pain to type. XSL is somewhat more limited than LaTeX when it comes to specifying physical page layout in a device-independent way, but those limitations probably can be overcome in the long run, and they don't matter that much on the web: for physical layout on the web, XSL has most of what you need.
I think XML and LaTeX are slowly growing together anyway. LaTeX 3 will probably have some built-in XML support. There are already several packages that can go from XML to LaTeX and from LaTeX to XML. In the long run, we may see that LaTeX will become an alternative input syntax for XML and that TeX/LaTeX will be used more and more for producing actual printed representations of XML documents.
Yes, I agree. I am a tech worker in the United States.
So, you probably enjoy good healthcare, have a choice of good jobs, and live in a nice place. The fact remains: in the areas I mentioned, health care, crime, transportation (as well as some that I didn't, like education and infant mortality), Europe is doing considerably better than the US.
As one of the select group of scarce and pampered tech workers, none of that may matter much to you. In fact, the US is very kind to its best and brightest, which makes it a great place to work and live if you are one of them. But that makes your sarcasm and disdain for those concerns all the more unkind and inappropriate.
If you have a larger application, with complex processing, the
memory manager can stall your application for hundreds of milliseconds
The same is true for C/C++ applications. And it happens in practice, for many reasons.
And pretty much the same tricks avoid this problem in both cases: create your own object pools.
No multiple inheritance. None. Which means you either klidge your design, or use
aggregation.
Java has multiple inheritance for interfaces. Not having implementation inheritance means a little more typing when you implement your design, but it doesn't affect the design itself. And if you really want to, you can automate the necessary delegation with a preprocessor. I'm glad Java left out implementation MI: it would have greatly complicated the language with little benefit to most programmers, who don't use MI even in languages where it is available. But I will admit that this must be a major nuisance to programmers who really plan out their implementations in terms of MI.
Java' VM is very immature (the could take a page or five from the Smalltalk people
who've been improving theirs since 1980,) and it shows.
Java the suite of libraries is in the same state as the VM and again could learn from
the folks who've been at it a lot longer.
Many of the people designing and developing Java have been deeply involved in Lisp and Smalltalk for decades (in addition to many Objective-C/NeXT and Taligent developers). And that shows. Many of the Java libraries are excellent, based on many years of experience in those other environments.
And the current Sun Java implementation is very powerful, with generational garbage collection, dynamic code generation, sandboxing, and a host of other features. Smalltalk and Lisp runtimes never reached that level of completeness and sophistication.
Java continues the tradition of the Smalltalk and Lisp communities. What distinguishes it is that it adds a lot of features that make it suitable for mainstream and "industrial strength" use, and that's why it has succeeded where Smalltalk and Lisp haven't. When I'm by myself, I still like programming in Smalltalk or Lisp better because they "get in the way less". But maximum comfort is not the main goal of an industrial programming language, and for an industrial programming language, Java is the best compromise around as far as I'm concerned.
Well, if Europe is the third world, what is the US, then? Europeans have better health care, better public transportation, better roads, many more cultural choices, smaller prison populations, and less crime. You can get a similar standard of living in the US if you live in a few wealthy communities and are at the top of the income distribution. But for most people, the standard of living in the US does not seem to be all that great.
Besides, suggesting that European countries are "socialist" is pretty ridiculous. European countries are free market economies. Their governments simply aren't as laissez faire and right wing as US governments.
The same is true in the US: foreign workers pay taxes for services (unemployment insurance, social security, medicare) they cannot take advantage of.
In fact, my experience working as a foreigner in Europe was that I was taxed at a lower rate than citizens; the government did not make me pay for many of the services that I couldn't take advantage of, while the US government keeps curtailing services to foreign residents without providing tax relief.
Also, while US taxes are nominally lower, the differences are actually not that large, and you have to buy a lot of additional services yourself in the US to achieve a similar level of security and standard of living.
Still, European wages in high tech are lower than they are in the US. And as a temporary worker, you will not have many of the advantages of the European social net. You won't get fabulously rich working in high tech in Europe, but it can be a nice experience.
Libertarianism is groovy, baby, but tell that to the PRC. ICANN is more democratic than the governments under which most of the world's population lives (which isn't saying much for democracy in the world today).
The problem isn't with whether ICANN is democratic, it's with centralization of the domain name system. As long as software is written assuming that there are central authorities who run everything in a benign and democratic fashion, countries like the PRC have easy, central targets for censorship: they know what they have to block. (And, no, I'm not a libertarian and I don't think this is a libertarian issue.)
It could work itself out so that real free spech was available only to Unix sysadmins with the time and motivation needed to create their own alternative DNS tables.
Unlikely. If it was widely accepted that end users mess around with name resolution, the process would become much simpler and would enjoy pervasive support in operating systems. That would make it harder, not easier, for countries like the PRC to censor because they don't have easily identifyable targets anymore, and they probably can't change everybody's operating system either.
That's my point: they are all somewhat different. So the very concept of "BSD surpassing Linux" because OSX gets used more widely doesn't make much sense.
Yes, if you count OSX as a "BSD platform", BSD might "leapfrog" Linux. But that's a pretty pointless comparison: OSX and BSD have different kernels, different drivers, and different user land utilities. Realistically, Linux is as similar to BSD as OSX.
Altogether, we should be happy. We have a good number of free, high quality UNIX-like systems. It seems pointless to engage in semantic debates about whether BSD will surpass Linux by the subtle historical argument of counting OSX as an implementation of BSD. For practical purposes, all these systems are very similar.
Since the thing runs Qt/Embedded, rather than an X11 based toolkit, you can't share the screen among apps written in different toolkits. So, if you want to develop shareware or small commercial applications, you can start by paying $2300 to $3000 per developer to TrollTech.
Even all concerns about the proprietary nature of Qt/Embedded aside, this simply doesn't make any business sense. At those prices, Palm would never have taken off and developed a market in small, useful applications.
Slashdot Mirror
A better way is to avoid bugs in the first place. And for multithreaded programs, a message passing paradigm is generally the best approach in my experience.
I also use assertions and consistency check liberally, so that problems are caught close to where they occur. As a result, the few serious bugs that I have had were usually solvable by inspection of the source code alone.
If you are looking for languages that make avoiding bugs easier, look beyond C++. Java is slightly better than C++ for multithreaded programs because errors tend to be more localized, but Java doesn't have much in the way of useful higher-level abstractions for building multithreaded programs. The currently conceptually best languages for multithreaded programs, in my opinion, are SML/NJ, OCAML, and Erlang.
Java itself offers several levels of tradeoff between functionality and size. To me, the most logical choice for a browser plugin wouldn't be an entirely new language and runtime, something that requires a lot of retraining and retooling, it would be a version of Personal Java, something that could easily fit into a few hundred kbytes.
Unfortunately, this seems to be symptomatic and a lot of open source development is permeated by conservatism that would make a stodgy company proud. Ogg-Vorbis is still based on decades old ideas about signal processing, the Linux kernel is still monolithically written in C like kernels were in the 1970s, and Gnome and KDE have barely progressed into the 1980s when it comes to GUI technologies.
Besides having a lot of upside potential (i.e., it may work better in the long run), going with newer, less proven ideas has the advantage that an open source effort has a much better chance of not treading on a well-patented path already. So, be adventuresome when you embark on your next open source project. Don't be content with just doing a slightly better job at something that has been around for a few years.
And if you are developing a new audio coder in particular, get out of the engineering straightjacket. Look at some new ideas in neural networks and pattern recognition and come up with something different from all the other audio coders in the market. Who knows, you may not just satisfy an open source need but actually contribute to the state of the art.
If they come out with a mix of proprietary code, GNU command line utilities, and a Linux kernel (similar to what Apple did), that's good, too: no matter what, the end result will be closer to Linux than their current offerings.
In fact, I see Microsoft's market dominance through proprietary standards diminishing anyway. While the Windows 3.x series (including 98 and ME) was such a mess that nobody could hope to clone all of it, Windows NT is sufficiently well modularized that people will be able to implement it well as a "personality" on top of all sorts of kernels. And C#/.NET drives the abstraction even higher, making it even easier for others to clone. The irony is that the complexity of software development forces Microsoft to clean up their act, but the same thing also means that they lose their market position.
Mach-like kernels attempt to address this problem by dividing the kernel into "servers". Other kernels address it by using languages that have better support for modularization (SML, Java, etc.). Because the Linux kernel is monolithic and written in C, there aren't a whole lot of choices for how to achieve this. Exploring putting a system like CORBA into the kernel seems like a sensible approach. I don't think CORBA and kORBit is going to be the long term solution, but it may be a good testbed for these ideas.
To continue business operations, the software needs to get fixed as quickly as possible. And having the sources to the application gives a company the best chance of doing that as quickly as possible: they can contract out support, hire consultants, or develop the in-house expertise.
Besides, unlike hardware, software doesn't just usually wear out and go bad. Almost always, serious software problems are triggered by an insufficiently tested upgrade or by an untested change in business procedures. And as a stop-gap measure, it's usually feasible to undo whatever was done.
Problem size or volume can also get too large for software to handle. That's a specification, testing, and sizing problem, not a software bug, and closed-source vendors won't help with that either other than by selling more, more expensive software and hardware.
The main class of unexpected bugs that occur is security problems, and the record of open source software is considerably better of fixes than for proprietary, closed-source software. And with the closed-source software, nobody can even review the bug fix to make sure it doesn't cause more problems.
If you must submit a bug to a commercial software company, indicate that you do not transfer copyright to them. Or, even better, submit it to BugTraq first.
Is it worth it? I bought some X10 controllers because it was cheaper and more convenient than having an electrician do a lot of rewiring. The thermostat may help save you energy since you can leave your heating off and turn it on remotely with a telephone call or via the Internet before you get home. Beyond that, it seems like it's a gimmick.
But having said that, I think Q3 also was not well packaged for Linux. If you accidentally ran Q3 with software emulated 3D, it could take you minutes to get out of it because you just couldn't really talk to the UI, and if you tried to shortcut out of it, it would leave the video card in a bad state. Id should have provided a simple test program (rotating cube) and simple code to try different configurations. They could also have provided some additional software to help the user configure their X server; it's not that hard to figure out what to do even if the script doesn't know what distribution it's running on. Autoconf solves much harder configuration problems every day.
Also keep in mind that the beginnings of 3D hardware accelerated graphics on Windows were considerably more awful than what has been happening on Linux. On Windows, it was customary that games would conflict or trash the whole system.
So, yes, Linux 3D and game support in the year 2000 isn't as good yet as Windows. But for its brief existence, it is doing a whole lot better than Windows did in its beginnings. For the initial Windows releases of 3D accelerated games, vendors had a "can do" attitude. The variety of hardware and installation they had to deal with was much more complex than anything in the Linux world today. But it seems like they are losing their touch.
Shared memory transport for X11 has been around for over a decade. If you are running XFree86, you almost certainly have the MIT-SHM extension installed. It is widely used by programs that need high performance graphics.
Some vendors have additionally created server and Xlib implementations that use shared memory instead of sockets, although that never seemed to result in an interesting additional speedup. Eventually, I think people stopped bothering.
since in the beginning [X11] was not designed for fast graphic routine for personal computing, etc.
X11 was designed for implementing high-performance graphics workstation applications on what is fairly modest hardware by modern standards. That's why X11 is actually quite fast, efficient, and gives you a lot of low-level hooks.
However, X has advantage: although it's slower, it has network transparency so that you can run app over other computer via network. [...] Oh, by the way, the graphic display in MS-Windows is faster not only because of its driver is better + DirectX accel support, but also because it uses shared memory transport.
It's a myth that X11 is slower than the Win32 API. In fact, whenever I have compared the two, X11 wins hands down. The reason is probably that the Win32 API uses a lot more synchronous calls and forces more context switches.
In fact, in these days of accelerated graphics cards with their own processors, the X11 model is much closer to what is going on under the hood than the antiquated and inefficient Win32 "graphics library" model.
Here's a suggestion: spend the money differently. Instead of a gigantic stereo system, hire real musicians. If it seems to aristocratic having musicians play for you privately, invite your friends over. Instead of a big video screen with tacky furniture, get some decent interior design advice and tuck the video safely out of sight. And instead of whiz-bang gadgets that don't work most of the time, hire some human household help; they may get sick occasionally, but they usually have a fully-functional, self-installing replacement available quickly.
It's not a question of being evil, it's a question of negative effects onto free or open source software. When Microsoft or some other company puts out a proprietary toolkit, that doesn't affect the open source or free software community negatively. When Troll Tech puts out a "semi-free" toolkit, that interferes with the development of truly free toolkits.
You don't like it? You do better. Thats what open source is all about, isn't it? [...] The fact that [xterm+twm on a PDA] is just shit for real world usage is completely unimportant, right?
Not at all. But if people adopt QPE on Linux PDAs widely, alternatives will be very slow in coming, both because QPE will take away the incentive of developing anything else and because it doesn't co-exist with other toolkits.
[Troll Tech's contribution] should not be ignored, much less denigrated by people like you
I don't "denigrate" their contribution; they do what every money-making corporation would do. In fact, there is lots of software that companies offer under lots of oddball licenses. That's neither good nor evil.
The people I criticize are people like you, who put short term expediency ahead of long term interests and claim it is in the interest of open source or free software. Develop for KDE or QPE all you want, but it is my opinion that in the long run, you are doing serious harm to Linux and open source software by doing so.
You mean networked protocol ?
No, I mean share the screen among different toolkits at all.
As to the price for QPE ...
Direct quote from trolltech site
"Also released today is the Qt Palmtop Environment, which is the first Personal Information Management
(PIM) package for embedded Linux released under the GPL."
My point was about commercial developers. You may think "to hell with them", but the fact is that it is commercial developers that made the Palm successful.
Who is to say whether the identical bits are "yours" or "theirs"? If you copy files with "rsync", are you actually copying them? If you use transparent duplicate file elimination with copy-on-write, are there actually separate files?
If MP3.COM had provided a solution that had every user rip and encode the tracks on their machine, and then send the resulting MP3 to a my.mp3.com locker, they wouldn't have been hammered in court.
What mp3.com does is just a very optimized version of rsync. Forcing people to waste additional bandwidth by using a less efficient copying mechanism doesn't change the copy protocols, it is merely an attempt to make mp3.com as inconvenient to use as possible in order to boost distribution channels that the RIAA prefers.
I think Troll Tech is merely using the open source community. If they manage to establish themselves as the preferred environment for handheld Linux systems, they stand to make a lot of money from commercial licenses because developers won't have a choice but to license their toolkit. And that comes at the cost of Linux on handhelds, because it makes Linux uncompetitive with Windows CE or Palm. This is considerably worse than the KDE/Qt situation, where at least non-Qt applications can co-exist with Qt applications on the same screen and exchange data.
I find this alliance between Troll Tech and some folks in the open source community a Faustian bargain. This kind of arrangement is going to come back and haunt us for years to come. Some "free" stuff is best not taken.
Unfortunately, because of it's TeX heritage, the way LaTeX describes styles and macros is pretty clunky. Underneath the covers, it's more like a machine language, with numbered registers, side-effects, and odd processing hooks. XML/XSL is probably a better choice: it's more formally defined than LaTeX. The XSL transformation model is easier to understand and more predictable to most people.
The biggest problem with XML in my view is cosmetic: it's a pain to type. XSL is somewhat more limited than LaTeX when it comes to specifying physical page layout in a device-independent way, but those limitations probably can be overcome in the long run, and they don't matter that much on the web: for physical layout on the web, XSL has most of what you need.
I think XML and LaTeX are slowly growing together anyway. LaTeX 3 will probably have some built-in XML support. There are already several packages that can go from XML to LaTeX and from LaTeX to XML. In the long run, we may see that LaTeX will become an alternative input syntax for XML and that TeX/LaTeX will be used more and more for producing actual printed representations of XML documents.
You can find lots of related links here.
So, you probably enjoy good healthcare, have a choice of good jobs, and live in a nice place. The fact remains: in the areas I mentioned, health care, crime, transportation (as well as some that I didn't, like education and infant mortality), Europe is doing considerably better than the US.
As one of the select group of scarce and pampered tech workers, none of that may matter much to you. In fact, the US is very kind to its best and brightest, which makes it a great place to work and live if you are one of them. But that makes your sarcasm and disdain for those concerns all the more unkind and inappropriate.
The same is true for C/C++ applications. And it happens in practice, for many reasons. And pretty much the same tricks avoid this problem in both cases: create your own object pools.
Java has multiple inheritance for interfaces. Not having implementation inheritance means a little more typing when you implement your design, but it doesn't affect the design itself. And if you really want to, you can automate the necessary delegation with a preprocessor. I'm glad Java left out implementation MI: it would have greatly complicated the language with little benefit to most programmers, who don't use MI even in languages where it is available. But I will admit that this must be a major nuisance to programmers who really plan out their implementations in terms of MI.
Many of the people designing and developing Java have been deeply involved in Lisp and Smalltalk for decades (in addition to many Objective-C/NeXT and Taligent developers). And that shows. Many of the Java libraries are excellent, based on many years of experience in those other environments. And the current Sun Java implementation is very powerful, with generational garbage collection, dynamic code generation, sandboxing, and a host of other features. Smalltalk and Lisp runtimes never reached that level of completeness and sophistication.
Java continues the tradition of the Smalltalk and Lisp communities. What distinguishes it is that it adds a lot of features that make it suitable for mainstream and "industrial strength" use, and that's why it has succeeded where Smalltalk and Lisp haven't. When I'm by myself, I still like programming in Smalltalk or Lisp better because they "get in the way less". But maximum comfort is not the main goal of an industrial programming language, and for an industrial programming language, Java is the best compromise around as far as I'm concerned.
Besides, suggesting that European countries are "socialist" is pretty ridiculous. European countries are free market economies. Their governments simply aren't as laissez faire and right wing as US governments.
Also, while US taxes are nominally lower, the differences are actually not that large, and you have to buy a lot of additional services yourself in the US to achieve a similar level of security and standard of living.
Still, European wages in high tech are lower than they are in the US. And as a temporary worker, you will not have many of the advantages of the European social net. You won't get fabulously rich working in high tech in Europe, but it can be a nice experience.
The problem isn't with whether ICANN is democratic, it's with centralization of the domain name system. As long as software is written assuming that there are central authorities who run everything in a benign and democratic fashion, countries like the PRC have easy, central targets for censorship: they know what they have to block. (And, no, I'm not a libertarian and I don't think this is a libertarian issue.)
It could work itself out so that real free spech was available only to Unix sysadmins with the time and motivation needed to create their own alternative DNS tables.
Unlikely. If it was widely accepted that end users mess around with name resolution, the process would become much simpler and would enjoy pervasive support in operating systems. That would make it harder, not easier, for countries like the PRC to censor because they don't have easily identifyable targets anymore, and they probably can't change everybody's operating system either.
That's my point: they are all somewhat different. So the very concept of "BSD surpassing Linux" because OSX gets used more widely doesn't make much sense.
Altogether, we should be happy. We have a good number of free, high quality UNIX-like systems. It seems pointless to engage in semantic debates about whether BSD will surpass Linux by the subtle historical argument of counting OSX as an implementation of BSD. For practical purposes, all these systems are very similar.
Even all concerns about the proprietary nature of Qt/Embedded aside, this simply doesn't make any business sense. At those prices, Palm would never have taken off and developed a market in small, useful applications.