Let's compare the Xbox to the PS2. The PlayStation 2 is a real product. In a couple of months, it will sell for a little over what just a PIII/733Mhz goes for (about $200). For expansion, it has FireWire, which allows hard disks and broadband to be plugged in. And it already boots Linux.
The fact that the PS2 doesn't have a hard disk, has FireWire instead of Ethernet, and doesn't use Intel are all good signs to me: Sony knows how to calculate with the thin margins of the consumer market; Microsoft doesn't seem to get it.
However, there is something good about the Xbox: the Xbox seems pretty well specified and PC compatible. It will almost certainly boot Linux. And Microsoft will have to wheel and deal to bring down the price, maybe even subsidize it, because the game market is price sensitive. So, for a few hundred dollars, we'll get a standardized low-end Linux box (although a PS2 with external disk may still be better).
Altogether, this is just business as usual for Microsoft. They do a precompetitive announcement years ahead of having anything real, trying to scare developers away from other platforms. They write a hardware spec that, if they could magically produce it today, would price them completely out of the market, and that will be uncompetitive by the time they get around to delivering it. And you can bet that they will mess it up with an unwieldy Windows-like UI. We already know that the APIs will be DirectX (yuck). We have seen exactly the same thing with PocketPC/WindowsCE, and they just don't seem to learn.
Apple did a bag o' research that showed that mis-hits were common amongst users learning new tasks.
That's my problem with Apple: they design for "users learning new tasks", not for experienced users. Making a UI that's easy to learn is a great way of hooking new users on your product, but it doesn't serve them well in the long run. I suppose Apple serves the masses as well as MacDonalds does, but thank goodness not all computers are designed by Apple.
I think it's a completely open question whether this is a sound technique (no pun intended).
In any case, on the legal front, you may notice that this was a little submarine patent, with an original application having been dormant since 1996, incorporated into this patent.
And, as usual, the NYT article seems to imply that any use of music other than by the purchaser on the original device is "infringing", which, of course, it is not. But that point has been made again and again; Lessig's book "Code Rules" is a must read. At least, we can still copy the content using analog means, like we always could. And whether consumers will go for this kind of system remains an open question--it has a lot of unpleasant practical restrictions even for completely non-infringing use.
While I think this kind of data should be protected (in fact, companies should not be permitted to keep it), I also suspect that protecting privacy is ultimately not going to work. The major worry, I think, is discrimination in insurance and employment.
If, say, medical insurance companies were required to set rates only based on their age, how long they have been insured, and (perhaps) state, and no other information, it wouldn't matter what kind of access they had to your medical records.
That's, in fact, how private medical insurance works in many countries. Insurance companies can still compete in all those areas where companies compete well in the free market: lowering costs, improving service, etc., they simply don't have the information to cherry-pick low-risk customers and leave the high risk customers to the public system.
The research projects described under Oxygen are excellent and worthwhile. But they hardly represent a new vision, as the press release seems to claim. Ubiquitous computing, human centered computing, wireless networking, deictic interactions, speech, vision, and all the other technologies mentioned in the Oxygen vision statement are technologies that have driven thousands of researchers for years, not only at MIT LCS, but at many research labs. I wonder whether Dertouzos really believes that he is articulating something new.
This article has caused me to browse around the MIT LCS pages a bit more, and I find it pretty depressing. Many pages are written like press releases, complete with quotations that make them look like journalism (the way press releases try to imitate journalistic style). Everything screamed "commercial relevance", "spinout", "efficiency", "scalability", "commerce", "break-through technology", and "invest now".
In part, that seems to reflect a genuine reorientation of research focus and motivation. In part, it also seems to reflect a misrepresentation of the reality of research: research is hard work, true breakthroughs are rare, and almost everything is built on other work, even at MIT.
I find these trends worrisome for the future of basic research. Where is basic research going to happen if even universities think about the commercial value of everything and graduate students are motivated by how they can sell the next billion dollar startup to VCs?
I'm not a laywer, and really don't care to become one, but why do you think the QPL is any different to the GPL for internal use? Section 6 has this line: These items, when distributed, are subject to the following requirements: It seems to me that Qt is find to use for internal research, as long as you don't distrubute it - same as the GPL.
If you read on, you will see that this section is actually ambiguous, since later it states that Troll Tech can always request software from you that you developed under the QPL. Furthermore, Troll Tech states in their QPL FAQ that it is the intent of their license that you must buy a commercial license even if you develop only for internal purposes.
Companies don't like ambiguity and they won't generally risk getting dragged into some legal spat, so making the QPL ambiguous and stating their intent in the FAQ essentially ensures that most companies who want to use Qt will license it, yet to the open source community, Troll Tech will appear as if their license is "almost like" the GPL. You have to decide for yourself whether this is legal incompetence or a Machiavellian plan. The fact remains that the QPL is much more restrictive than all of the other widely used, free or open source toolkits.
As for the quality, if you think Qt is worth the license fee, good for you. My point is that most people (including consultants, corporate developers and students) who pick Qt for development should view it as a commercial toolkit that costs between $1500 and $2400/developer, since most likely they will have to pay. Qt needs to be evaluated and compared to other toolkits on that basis. I suspect for the kind of money you are going to pay Troll Tech for all your developers, you could often already have some consultant or in-house developer do a significant amount of custom development and fix whatever shortcomings you see in one of the other toolkits.
The GPL permits making proprietary derivative works, as long as they are not distributed. The big difference is that Troll Tech wants to derive revenue even from internal usage (research, internal applications). Effectively, that means that every developer at a commercial site needs to get a commercial Qt license, an expensive proposition, even if they never produce a money making product.
It seems as though there is a decidedly hostile atmosphere surrounding open source software; when a company decides to open the source to their code, they seem to be opening themselves up to attacks against their business practices by the OSS legions, even when they had no problems when the source was closed!
Troll Tech is a business, and releasing Qt under the QPL isn't an act of charity, it's a business strategy. In particular, Troll Tech wants two things. First, they want bug fixes and code contributions from users. Second, they want lots of people (in particular, students) to get started using their toolkit so that when they move into companies, they'll buy the toolkit. I think it's valid to ask the question whether this is a good deal.
While your opinion may differ, I don't think it is. There are several high quality toolkits out there without such restrictions, and where bug fixes and code benefit everybody. And Qt is so expensive that I would have serious concerns about using it even as a purely commercial toolkit.
Just because a company dumps some source code on the world under some license doesn't make them immune from analysis. But to be clear, my view isn't that Troll Tech should change the license or that they have done anything "wrong". My view is that people should stop using Qt because it simply isn't a good deal and because there are good alternatives available.
Whether or not QPL is compatible with the GPL is one issue, but it isn't a very important one to me or lots of other people.
The main sticking point with the QPL is that it requires all software, even software written written for internal or research purposes, to be released, and to be released under the open source model. Troll Tech's intent is clearly to get every potential commercial user to pay for each of their developers, presumably under the assumption that commercial institutions have lots of money to spend. And at between $1500 and $2400/developer, Qt is (IMO) uncompetitively expensive.
Unlike many other libraries, GUI libraries are complex and require a significant amount of time on the part of the programmer to learn how to use them. So, you should ask yourself: if I invest this much time in the library, what do I get back? With Qt, you commit to either contributing code to Troll Tech (under the QPL) or money (under the commercial license).
If Qt were the only game in town, theremight be some justification for that kind of deal. But there are lots of good, free toolkits and there is no need to make such a tradeoff.
Incidentally, similar considerations apply to GPL'ed GUI libraries. If you invest a lot of time learning a GPL'ed GUI library, you severly limit your options later with what kind of GUI programs you can write. So, I think even placing Qt under the GPL wouldn't help much given the available alternatives. At least the GPL allows internal and research use, however.
Altogether, I doubt Qt is going to make it in the door where I work, and I wouldn't view knowledge of Qt as a big advantage when hiring. My recommendation is: learn GTK/Gnome, Tcl/Tk, wxWindows, FLTK, Java/Swing, even Motif or Win32/MFC.
Apparently, dropping the lawsuit was just a strategy to avoid giving Connectix ammunition for appeal. According to CNET, Sony is refiling the patent suit.
So, this wasn't a victory at all, it's an illustration of some of the more questionable aspects of the legal system. Apparently, Sony can keep trying until the get the lawsuit right, and force Connectix to waste more and more time and legal expenses on it. Imagine you were being sued and the company bringing the lawsuit could just file it again and again.
Linux (at least on the desktop) will not survive until we start developing quality apps for the non-geek majority. [...] This will be our downfall unless we spread the word and recruit outside experts who can share our views to work alongside developers as an integral part of the team.
Many of the design decisions in Linux (including GNU and X11) system are aimed at the power user. I use Linux precisely because its engineering tradeoffs are aimed at the power user.
If we followed your suggestion and "recruit outside experts" who know how to build applications for the "non-geek" majority, we'd end up with a system for the non-geek majority. If I wanted to use that kind of system, I already have multiple excellent choices, foremost Windows and MacOS. Windows and MacOS are well adapted to the needs of non-geek users, and the tradeoffs they made were driven by those needs. If Linux starts seriously addressing those needs as well, it will turn into a system that will not be very different from them. In fact, it has already started, where system administration and other parts of the system are driven by the needs of graphical configuration tools, rather than easy configurability with a text editor.
I don't want Linux to take over the desktop; I'm happy if it merely occupies a niche for powerusers. And I believe that niche can be large enough to keep companies interested in providing drivers and tools.
Well, I think community is nice, but living in the Bay Area and working at a very geeky place, I'm not sure I need a lot more of it. Even if I lived and worked in a more isolated place, I haven't found large trade shows, which are run primarily for selling stuff, particularly good community builders for geeks. They seem to cater mostly to salesmen and marketing folks (overheard in Boston in 1996 on a bus back from Internet World: "Isn't this new Internet thing great?" "Yeah, it's one big billboard, and we can advertise for free.").
I have used Corel PhotoPaint on Windows, and I think it's a good piece of software, in some way actually a bit better than the Gimp.
But I still won't download it. It isn't so much better than the Gimp that it's a "must have" for me. On the other hand, PhotoPaint would take away from the Gimp user community. Every bug report or feature request sent to Corel is a bug report or feature request not sent to the Gimp developers. The more people learn its UI, the less likely they will be to switch to a free software equivalent, no matter how good.
Software lives and dies by its users. The value of Microsoft Office isn't in the software itself (which is mediocre) but in the thousands of hours each serious user has invested in becoming familiar with its UI and quirks, the millions of files people have in its proprietary format, and the bug reports and feedback they have sent to Redmond. Even a very high quality free office suite can't displace MS Office at this point because it won't read all the old data flawlessly and because it just won't be familiar to users, quirks and all.
I'm not religious about not using proprietary software and I do use some. But if there is a "good enough" free package, I'll stick with that. In this case, I think there is. And much as I wish Corel success in general, I still hope others will do the same.
I don't have much of an incentive to go to trade shows. Almost all product information is on the web. If it isn't on the web yet because it's an upcoming product, there really isn't so much point in getting a heads-up at a trade show because it can take months anyway to get released. And for Linux, in particular, most of what I'm interested in is open source (that's the point behind Linux, after all).
I think trade shows made more sense for proprietary software in the pre-Internet days. As the PC shows show, some people still live in that world, but for Linux it is bound not to work too well.
What gatherings like that could still be good for is technical discussions, planning of new open source projects, etc. But for that, you don't need 60000 sq ft of exposition space. Instead, you need a convenient, pleasant, easy-to-get-to location.
I think we have seen that information is subject to a lot of restrictions in democracies as well. Cryptography, violent content, politically extreme or "undesirable" content, and sexual content have all been restricted by democratic governments. And technical information, criticism of products and corporate behavior, and other content that businesses don't like get shut down using the legal, patent, trademark, and copyright systems of democracies.
Something as simple as planning for secure tunnels through HTTP is not going to work because those accesses will stick out like a sore thumb among normal network traffic in restrictive environments. The presumption will simply be that if you use any such mechanisms, you must be doing something bad.
One way I see to address this problem is to design protocols such that everybody accesses the Web in a way that content is encrypted and distributed. But unless we can engineer a very good business reason for that, it won't happen because it's more expensive and more complex than the simple-minded plain-text HTTP approach being used right now.
There are many different kinds of radio waves with different propagation properties. If you take highly directional signals like microwaves or light, you can easily have almost unlimited bandwidth. Even with omnidirectional frequencies, you can get nearly unlimited bandwidth by making the power (and hence cell-size) smaller.
So, one can make cell sizes so small that only your personal devices matter (which means you get essentially the whole spectrum to yourself), and the relays in the cells can communicate wirelessly via non-interfering directional signals. Or, to put it differently, if you settle on a cell size, you can get as many bits across total as the number of cells you have multiplied by the capacity of the frequency bands you allocate.
Cell sizes can also be limited by other propagation properties. An extreme example of that is IR (as in your IR remote control). From a security point of view and from the point of view of sharing frequencies, that can actually be desirable.
As for an international FCC, the frequency bands used by personal devices do not travel far, so they don't need to be regulated internationally to prevent interference. But the ITU is an important international regulatory agency.
After the Itanium and Xeon, continuing with their tradition of naming processors after elements with a letter missing, Intel is announcing today the the Intel Odium. "We believe that the names we give to our processors should be representative of the relationship between the company and its customers", the Intel CEO said in a public statement announcing the release.
Rumors that Intel might be working on the Intel Oxgen, the Urnium, or the Lutonium processors were vigorously denied by the company.
Maybe you should take a closer look at C++? [...] "Connect to APIs" ? Don't know about you, but most of us don't have any problem with making a function call.
C++ and C# look similar to a programmer, but they are rather different languages with different implementations. You can't, in general, make calls between them work automatically. Nor is C++ a substitute for a safe language with garbage collection. (Incidentally, I have been using C++ since the 80's, and I still do most of my programming in it.)
I'm not surprised multicasting hasn't caught on, and I think the reasons for it are economic. With multicasting, no matter how many users your site serves, you only need a low-end server and a slow network connection; it would be difficult for the web hosting company to extract a lot of money that way. On the other hand, if you send a separate stream to each client, you need a high speed connection, and you need to pay for it. Thus, I think, the economic incentive for web hosting companies is not to install multicasting support.
NFS used to run without NFS checksumming, meaning that it relied on the error correction of the underlying Ethernet. Nowadays, I suppose it is mostly run with checksumming.
As for implementing "my own packet number in user code", what kind of argument is that? I could also implement some form of reliable byte streams based on UDP in user code fairly easily.
But standardizing these kinds of protocols, we get several advantages. For example, we get interoperability. And people don't have to reinvent the wheel every time and the problem can be solved well once and for all (even a simple strategy like "resend if no acknowledgement" has many parameters, and it isn't necessarily even the right thing over a WAN). And, with a standard protocol, routers and other infrastructure actually knows more about the traffic and can help it along.
You are right that reliable datagrams aren't hard to implement: that's an argument that they should become standardized and become part of the TCP/IP protocol. Because even they are simple to implement, standardizing them has many advantages.
I think it would be preferable to have a reliable datagram service in the kernel, as opposed to yet another messaging library built on top of TCP.
The need for reliable datagrams ("block exchanges") comes up frequently for file servers and similar systems (like the web), as well as distributed computing, and not having such a protocol as part of TCP/IP was a major omissions. For example, NFS simply assumes that UDP is reliable over a LAN, Plan 9 built a reliable datagram server into the kernel, and HTTP/1.0 just treated TCP as a (slow) reliable datagram service (send request/receive response).
An advantage of reliable datagrams is that it avoids most of the overhead of negotiating and establishing a TCP connection, so it can be almost as fast as UDP. Furthermore, reliable datagrams require fewer kernel resources to be maintained, and the send_to/receive paradigm is a better fit to many applications.
BXXP looks like it requires quite a bit of stuff: a TCP/IP implementation, the protocol implementation, and an XML parser. That's going to eat up a lot of space on small devices, and it's going to be unpleasant to implement and debug. The connections on which BXXP runs will also eat up kernel resources (file descriptors, etc.), both a problem on small devices and on very large servers, and it requires even more code and modeling to figure out when to bring up and tear down connections ("is the user going to request another page from that site?").
Furthermore, routers and other devices would have a much harder time understanding what is happening inside BXXP; that's important for things like multicasting and predicting bandwidth utilization. In comparison, reliable datagrams are a simple addition to a TCP/IP stack and require no protocols or parsing. And routers and other infrastructure can deal with them much more intelligently.
Plan 9 has a reliable datagram service called IL, although it is only optimized for LANs. People have also been working on reliable datagram services as part of IPv6, and for Linux.
On the libraries, what I meant was simply that there are no comprehensive libraries for it yet. Based on their past statements, I believe that their strategy is to expose as much of Win32/COM+ as possible, because it seems easy, familiar to their programmers, and ties people to their platform. That's also what they wanted to do with Java.
I also believe that that strategy is flawed: to me, beating Win32/COM+ into sufficient shape to work reliably and efficiently inside a safe, garbage collected language looks like a lot of work, and I think the end product would be of low quality.
If, on the other hand, they start from scratch with libraries, they are in a much worse position than Java: not only are they way behind, they will also be completely non-standard compared to Java.
Gates is right that it's all about APIs, and that will be their downfall: Windows is saddled with a lot of cumbersome legacy APIs. Sun OTOH invested in a brand new set of pretty well-designd, safe, OO APIs in Java, and their bet paid off: they are widely used and supported now. And that's why I think C# will have a very, very hard time even if they decide to push it.
Users are a spoiled bunch these days: plenty of free, high quality languages to choose from. Any company that wants to play in that space better provide something for free.
If there is significant interference with TCP, people will just move to UDP. That's a loss for the ISP: with TCP, they have a lot more information to manage the bandwidth intelligently. With UDP, they just get chunks of random looking bits floating back and forth.
Besides, people will want to do video conferencing and other data intensive services. If the current crop of ISPs don't provide those services, others will. After all, we went from no commercial ISPs to a thriving Internet economy: widespread demand will be satisfied.
Slashdot Mirror
The fact that the PS2 doesn't have a hard disk, has FireWire instead of Ethernet, and doesn't use Intel are all good signs to me: Sony knows how to calculate with the thin margins of the consumer market; Microsoft doesn't seem to get it.
However, there is something good about the Xbox: the Xbox seems pretty well specified and PC compatible. It will almost certainly boot Linux. And Microsoft will have to wheel and deal to bring down the price, maybe even subsidize it, because the game market is price sensitive. So, for a few hundred dollars, we'll get a standardized low-end Linux box (although a PS2 with external disk may still be better).
Altogether, this is just business as usual for Microsoft. They do a precompetitive announcement years ahead of having anything real, trying to scare developers away from other platforms. They write a hardware spec that, if they could magically produce it today, would price them completely out of the market, and that will be uncompetitive by the time they get around to delivering it. And you can bet that they will mess it up with an unwieldy Windows-like UI. We already know that the APIs will be DirectX (yuck). We have seen exactly the same thing with PocketPC/WindowsCE, and they just don't seem to learn.
That's my problem with Apple: they design for "users learning new tasks", not for experienced users. Making a UI that's easy to learn is a great way of hooking new users on your product, but it doesn't serve them well in the long run. I suppose Apple serves the masses as well as MacDonalds does, but thank goodness not all computers are designed by Apple.
In any case, on the legal front, you may notice that this was a little submarine patent, with an original application having been dormant since 1996, incorporated into this patent.
And, as usual, the NYT article seems to imply that any use of music other than by the purchaser on the original device is "infringing", which, of course, it is not. But that point has been made again and again; Lessig's book "Code Rules" is a must read. At least, we can still copy the content using analog means, like we always could. And whether consumers will go for this kind of system remains an open question--it has a lot of unpleasant practical restrictions even for completely non-infringing use.
If, say, medical insurance companies were required to set rates only based on their age, how long they have been insured, and (perhaps) state, and no other information, it wouldn't matter what kind of access they had to your medical records.
That's, in fact, how private medical insurance works in many countries. Insurance companies can still compete in all those areas where companies compete well in the free market: lowering costs, improving service, etc., they simply don't have the information to cherry-pick low-risk customers and leave the high risk customers to the public system.
This article has caused me to browse around the MIT LCS pages a bit more, and I find it pretty depressing. Many pages are written like press releases, complete with quotations that make them look like journalism (the way press releases try to imitate journalistic style). Everything screamed "commercial relevance", "spinout", "efficiency", "scalability", "commerce", "break-through technology", and "invest now".
In part, that seems to reflect a genuine reorientation of research focus and motivation. In part, it also seems to reflect a misrepresentation of the reality of research: research is hard work, true breakthroughs are rare, and almost everything is built on other work, even at MIT.
I find these trends worrisome for the future of basic research. Where is basic research going to happen if even universities think about the commercial value of everything and graduate students are motivated by how they can sell the next billion dollar startup to VCs?
If you read on, you will see that this section is actually ambiguous, since later it states that Troll Tech can always request software from you that you developed under the QPL. Furthermore, Troll Tech states in their QPL FAQ that it is the intent of their license that you must buy a commercial license even if you develop only for internal purposes.
Companies don't like ambiguity and they won't generally risk getting dragged into some legal spat, so making the QPL ambiguous and stating their intent in the FAQ essentially ensures that most companies who want to use Qt will license it, yet to the open source community, Troll Tech will appear as if their license is "almost like" the GPL. You have to decide for yourself whether this is legal incompetence or a Machiavellian plan. The fact remains that the QPL is much more restrictive than all of the other widely used, free or open source toolkits.
As for the quality, if you think Qt is worth the license fee, good for you. My point is that most people (including consultants, corporate developers and students) who pick Qt for development should view it as a commercial toolkit that costs between $1500 and $2400/developer, since most likely they will have to pay. Qt needs to be evaluated and compared to other toolkits on that basis. I suspect for the kind of money you are going to pay Troll Tech for all your developers, you could often already have some consultant or in-house developer do a significant amount of custom development and fix whatever shortcomings you see in one of the other toolkits.
The GPL permits making proprietary derivative works, as long as they are not distributed. The big difference is that Troll Tech wants to derive revenue even from internal usage (research, internal applications). Effectively, that means that every developer at a commercial site needs to get a commercial Qt license, an expensive proposition, even if they never produce a money making product.
Troll Tech is a business, and releasing Qt under the QPL isn't an act of charity, it's a business strategy. In particular, Troll Tech wants two things. First, they want bug fixes and code contributions from users. Second, they want lots of people (in particular, students) to get started using their toolkit so that when they move into companies, they'll buy the toolkit. I think it's valid to ask the question whether this is a good deal.
While your opinion may differ, I don't think it is. There are several high quality toolkits out there without such restrictions, and where bug fixes and code benefit everybody. And Qt is so expensive that I would have serious concerns about using it even as a purely commercial toolkit.
Just because a company dumps some source code on the world under some license doesn't make them immune from analysis. But to be clear, my view isn't that Troll Tech should change the license or that they have done anything "wrong". My view is that people should stop using Qt because it simply isn't a good deal and because there are good alternatives available.
The main sticking point with the QPL is that it requires all software, even software written written for internal or research purposes, to be released, and to be released under the open source model. Troll Tech's intent is clearly to get every potential commercial user to pay for each of their developers, presumably under the assumption that commercial institutions have lots of money to spend. And at between $1500 and $2400/developer, Qt is (IMO) uncompetitively expensive.
Unlike many other libraries, GUI libraries are complex and require a significant amount of time on the part of the programmer to learn how to use them. So, you should ask yourself: if I invest this much time in the library, what do I get back? With Qt, you commit to either contributing code to Troll Tech (under the QPL) or money (under the commercial license).
If Qt were the only game in town, theremight be some justification for that kind of deal. But there are lots of good, free toolkits and there is no need to make such a tradeoff.
Incidentally, similar considerations apply to GPL'ed GUI libraries. If you invest a lot of time learning a GPL'ed GUI library, you severly limit your options later with what kind of GUI programs you can write. So, I think even placing Qt under the GPL wouldn't help much given the available alternatives. At least the GPL allows internal and research use, however.
Altogether, I doubt Qt is going to make it in the door where I work, and I wouldn't view knowledge of Qt as a big advantage when hiring. My recommendation is: learn GTK/Gnome, Tcl/Tk, wxWindows, FLTK, Java/Swing, even Motif or Win32/MFC.
So, this wasn't a victory at all, it's an illustration of some of the more questionable aspects of the legal system. Apparently, Sony can keep trying until the get the lawsuit right, and force Connectix to waste more and more time and legal expenses on it. Imagine you were being sued and the company bringing the lawsuit could just file it again and again.
Many of the design decisions in Linux (including GNU and X11) system are aimed at the power user. I use Linux precisely because its engineering tradeoffs are aimed at the power user.
If we followed your suggestion and "recruit outside experts" who know how to build applications for the "non-geek" majority, we'd end up with a system for the non-geek majority. If I wanted to use that kind of system, I already have multiple excellent choices, foremost Windows and MacOS. Windows and MacOS are well adapted to the needs of non-geek users, and the tradeoffs they made were driven by those needs. If Linux starts seriously addressing those needs as well, it will turn into a system that will not be very different from them. In fact, it has already started, where system administration and other parts of the system are driven by the needs of graphical configuration tools, rather than easy configurability with a text editor.
I don't want Linux to take over the desktop; I'm happy if it merely occupies a niche for powerusers. And I believe that niche can be large enough to keep companies interested in providing drivers and tools.
Well, I think community is nice, but living in the Bay Area and working at a very geeky place, I'm not sure I need a lot more of it. Even if I lived and worked in a more isolated place, I haven't found large trade shows, which are run primarily for selling stuff, particularly good community builders for geeks. They seem to cater mostly to salesmen and marketing folks (overheard in Boston in 1996 on a bus back from Internet World: "Isn't this new Internet thing great?" "Yeah, it's one big billboard, and we can advertise for free.").
But I still won't download it. It isn't so much better than the Gimp that it's a "must have" for me. On the other hand, PhotoPaint would take away from the Gimp user community. Every bug report or feature request sent to Corel is a bug report or feature request not sent to the Gimp developers. The more people learn its UI, the less likely they will be to switch to a free software equivalent, no matter how good.
Software lives and dies by its users. The value of Microsoft Office isn't in the software itself (which is mediocre) but in the thousands of hours each serious user has invested in becoming familiar with its UI and quirks, the millions of files people have in its proprietary format, and the bug reports and feedback they have sent to Redmond. Even a very high quality free office suite can't displace MS Office at this point because it won't read all the old data flawlessly and because it just won't be familiar to users, quirks and all.
I'm not religious about not using proprietary software and I do use some. But if there is a "good enough" free package, I'll stick with that. In this case, I think there is. And much as I wish Corel success in general, I still hope others will do the same.
I think trade shows made more sense for proprietary software in the pre-Internet days. As the PC shows show, some people still live in that world, but for Linux it is bound not to work too well.
What gatherings like that could still be good for is technical discussions, planning of new open source projects, etc. But for that, you don't need 60000 sq ft of exposition space. Instead, you need a convenient, pleasant, easy-to-get-to location.
Something as simple as planning for secure tunnels through HTTP is not going to work because those accesses will stick out like a sore thumb among normal network traffic in restrictive environments. The presumption will simply be that if you use any such mechanisms, you must be doing something bad.
One way I see to address this problem is to design protocols such that everybody accesses the Web in a way that content is encrypted and distributed. But unless we can engineer a very good business reason for that, it won't happen because it's more expensive and more complex than the simple-minded plain-text HTTP approach being used right now.
So, one can make cell sizes so small that only your personal devices matter (which means you get essentially the whole spectrum to yourself), and the relays in the cells can communicate wirelessly via non-interfering directional signals. Or, to put it differently, if you settle on a cell size, you can get as many bits across total as the number of cells you have multiplied by the capacity of the frequency bands you allocate.
Cell sizes can also be limited by other propagation properties. An extreme example of that is IR (as in your IR remote control). From a security point of view and from the point of view of sharing frequencies, that can actually be desirable.
As for an international FCC, the frequency bands used by personal devices do not travel far, so they don't need to be regulated internationally to prevent interference. But the ITU is an important international regulatory agency.
Rumors that Intel might be working on the Intel Oxgen, the Urnium, or the Lutonium processors were vigorously denied by the company.
C++ and C# look similar to a programmer, but they are rather different languages with different implementations. You can't, in general, make calls between them work automatically. Nor is C++ a substitute for a safe language with garbage collection. (Incidentally, I have been using C++ since the 80's, and I still do most of my programming in it.)
I'm not surprised multicasting hasn't caught on, and I think the reasons for it are economic. With multicasting, no matter how many users your site serves, you only need a low-end server and a slow network connection; it would be difficult for the web hosting company to extract a lot of money that way. On the other hand, if you send a separate stream to each client, you need a high speed connection, and you need to pay for it. Thus, I think, the economic incentive for web hosting companies is not to install multicasting support.
As for implementing "my own packet number in user code", what kind of argument is that? I could also implement some form of reliable byte streams based on UDP in user code fairly easily.
But standardizing these kinds of protocols, we get several advantages. For example, we get interoperability. And people don't have to reinvent the wheel every time and the problem can be solved well once and for all (even a simple strategy like "resend if no acknowledgement" has many parameters, and it isn't necessarily even the right thing over a WAN). And, with a standard protocol, routers and other infrastructure actually knows more about the traffic and can help it along.
You are right that reliable datagrams aren't hard to implement: that's an argument that they should become standardized and become part of the TCP/IP protocol. Because even they are simple to implement, standardizing them has many advantages.
The need for reliable datagrams ("block exchanges") comes up frequently for file servers and similar systems (like the web), as well as distributed computing, and not having such a protocol as part of TCP/IP was a major omissions. For example, NFS simply assumes that UDP is reliable over a LAN, Plan 9 built a reliable datagram server into the kernel, and HTTP/1.0 just treated TCP as a (slow) reliable datagram service (send request/receive response).
An advantage of reliable datagrams is that it avoids most of the overhead of negotiating and establishing a TCP connection, so it can be almost as fast as UDP. Furthermore, reliable datagrams require fewer kernel resources to be maintained, and the send_to/receive paradigm is a better fit to many applications.
BXXP looks like it requires quite a bit of stuff: a TCP/IP implementation, the protocol implementation, and an XML parser. That's going to eat up a lot of space on small devices, and it's going to be unpleasant to implement and debug. The connections on which BXXP runs will also eat up kernel resources (file descriptors, etc.), both a problem on small devices and on very large servers, and it requires even more code and modeling to figure out when to bring up and tear down connections ("is the user going to request another page from that site?").
Furthermore, routers and other devices would have a much harder time understanding what is happening inside BXXP; that's important for things like multicasting and predicting bandwidth utilization. In comparison, reliable datagrams are a simple addition to a TCP/IP stack and require no protocols or parsing. And routers and other infrastructure can deal with them much more intelligently.
Plan 9 has a reliable datagram service called IL, although it is only optimized for LANs. People have also been working on reliable datagram services as part of IPv6, and for Linux.
I should have mentioned it: it's my own experience with J++ and COM that leads me to believe that this is not a good long-term approach.
On the libraries, what I meant was simply that there are no comprehensive libraries for it yet. Based on their past statements, I believe that their strategy is to expose as much of Win32/COM+ as possible, because it seems easy, familiar to their programmers, and ties people to their platform. That's also what they wanted to do with Java.
I also believe that that strategy is flawed: to me, beating Win32/COM+ into sufficient shape to work reliably and efficiently inside a safe, garbage collected language looks like a lot of work, and I think the end product would be of low quality.
If, on the other hand, they start from scratch with libraries, they are in a much worse position than Java: not only are they way behind, they will also be completely non-standard compared to Java.
Gates is right that it's all about APIs, and that will be their downfall: Windows is saddled with a lot of cumbersome legacy APIs. Sun OTOH invested in a brand new set of pretty well-designd, safe, OO APIs in Java, and their bet paid off: they are widely used and supported now. And that's why I think C# will have a very, very hard time even if they decide to push it.
Users are a spoiled bunch these days: plenty of free, high quality languages to choose from. Any company that wants to play in that space better provide something for free.
Besides, people will want to do video conferencing and other data intensive services. If the current crop of ISPs don't provide those services, others will. After all, we went from no commercial ISPs to a thriving Internet economy: widespread demand will be satisfied.