Not necessarily. For something like the Metrocard system the necessity of open source is not clear to me. The government would be much better off mandating the use of hardware available from multiple vendors and owning all of the rights to the software. That makes sense. If one vendor goes belly up or tries to negotiate for a lot more money when its renewal time, the government can go to another vendor with the software and ask them to continue support.
There are certain games where fancier graphics can help out. Simulation games of various sorts, especially wargaming and flight sims and sports games. Then there are 'world tour' games where you have some sort of adventure game where the whole point is to transport you to another world, not unlike a good book or movie.
The category of game that has been neglected with the rise of graphics are the highly abstract games, like poker and chess and even games like Monopoly or Clue. Games with highly artificial pieces and rules. Tetris is a good example of this. Even a game like Tempest falls into this category. Games that don't pretend to simulate anything. Chess vaguely has some ties to wargaming but not many, and what is poker simulating?
That's the place that shareware, freeware and open source developers should be heading. Skimp back on the graphics and just create simple games that don't suck down CPU power, except possibly for the AI. And take advantage of modern computing by having the facility for networked play.
Radio receiver built in for wireless capability. Local range only, perhaps to conserve battery drain it would be activated via a hotsynch button though hopefully it would be able to have it on all the time without too much trouble. Very small bitmapped display which is only used for alphanumerics and special characters that can be used as an abbreviation for full words. Screen space on a watch is valuable. Every character has to count. And a few buttons around it. Not like those old calculator watches, that goes too far. I want buttons around the sides so screen space is maximized as much as possible.
Note there is only receive on the wireless part. This thing is a data display device, and the buttons are for browsing. Just as the Palm people reinvented the user interface from the ground up this watch would have its user interface redesigned from the ground up. One button might be a display time/display pages/access database toggle. Hit the button a few times and you switch between the main common uses of the watch instantly, no fuss, from whereever you are, like the application icon on the Palm. Other buttons would probably be more modal.
This watch would function as a watch, as a pager (and maybe to notify when you have important mail), and a portable phone/email/address list. Maybe a few other things as well like sports scores (not that I'm that big a fan but others are), stock prices (ditto) and so forth. My current pager has a feature where it picks up news headlines. Not all that uninteresting a feature, as long as I had some way to filter for what I was interested in.
The watch has a small screen space, limited control/input capability and the power requirements have to be insanely low. The positive side it has the ultimate convenience factor of being always available, faster than a PDA. The computer watch has to play to these strengths if it is to ever really take off.
I think it is possible to set up a system that can be both easy to use at first and powerful later on. The trick is to get the foundation of the system right. At the foundation you need something essentially akin to Unix. A wide range of powerful and flexible tools that can be linked together in powerful arrangements under some sort of linking/scripting system. Then on top of that you build up a set of friendly and easy to use tools that let people do their basic tasks. And perhaps some midrange tools that provide more complexity for users who need more power. Or give those tools an advanced mode. These tools should be crafted under the scripting/linking system.
So users start off with the friendly tools, as they grow more comfortable they switch to the advanced mode. In time they might well grow so advanced that they craft their own tools under the scripting/linking system to automate tasks that they want to be done.
Essentially it would be taking the Unix 'find' command which is powerful but not easy to use and you write a new simple GUI front end to it, with a simple mode that allows for easy selection of the starting directory and a fill in the blank approach for the -name field with the default -print modifier. And the advanced mode invokes find with a few more fancy options. The power user then starts using find directly or creates their own little button on some control panel if they need say, something that will present a window of all their log files for the day.
What you need is to encourage the creation of these tools and make it easy to link them together under the language of your choice. GNOME and KDE are taking steps in the right direction with Bonbono and KParts respectively, but sometimes I wonder if that goes far enough in some ways.
Consoles and these DVCRs both have the same economic model. The boxes themselves are dirt cheap and the profits are made on the stuff around the boxes. Games in the case of consoles and the subscription service in the case of DVCRs. In theory there's a lot of overlap between the two pieces of hardware as well. Consoles would probably be overkill in hardware for the sort of rendering needed for these devices. In theory a company manufacturing a dual purpose machine might be willing to risk shaving more overhead from the machine because they'll have a dual source of income.
Personally I think you're risking 3DO syndrome in this case. The PSX2 is edging there but sticking a DVD player into a console with a DVD-ROM is so trivial whether or not to do it is a political decision instead of a technical or economic one. Until consoles hit the same point I don't think this will happen.
>KDE tried CORBA. It was bloated and slow. Kind of like GNOME itself. You really should work in marketing though: "Everyone else (for whom I can name absolutely zero examples) is invested in CORBA, so KDE needs to be using that just for the buzzword too!"
Go to www.corba.org and start from there to see who is behind it. I assumed the fact that CORBA was an independent standard invented by a coalition and supported elsewhere was rather obvious.
In an ideal world, technical issues would always win out and people would always choose the technically superior solution. That was the whole bleeding point of my article. The fact is that CORBA is more politically acceptable than KParts. I said that KDE tended to win on technical merits all over the place. But generally people choose the most politically acceptable solution. The history of the computer industry tends to drive that point home over and over. I didn't say it was a good thing that people tend to cling to buzzwords, but it's a fact of life. I've lost my youthful idealism on that point.
KDE has some pretty valid claims to technical superiority. However KDE has serious political flaws that doom it. The first is the dependence on a proprietary toolkit, Qt. That is the most serious one in my opinion. That is what scared most of the corporations off. They didn't want a repeat of the CDE scenario where they tried to make a common standard off of prioprietary licenced products. The fact is that the GNOME Foundation isn't a rehash of the CDE fiasco no matter how much some KDE people try to make it out to be as one.
A lesser one is the use of KParts rather than CORBA. Perhaps the consortium might have overlooked that but the fact is that everyone has a lot invested in CORBA these days. GNOME is more buzzword complaint than KDE and that's another political mark in its favor.
And so because GNOME was more politically acceptable and technically good enough for these companies to choose to endorse GNOME. The KDE people can harp on technical superiority, but the computer industry is littered with technically superior products that ended up niche players. Linux has for a very long time been technically inferior to every other form of Unix but the fact that it is politically superior has enabled it to last and have its technical failings addresed. Microsoft won because it was politically more adept than technically. The fact is in the long run you have to look at the political angles.
And there is the fact that if GNOME becomes too corporate, developers can vote with their keyboards and fork GNOME. Or can go back to KDE (or more likely start over with something new). Personally, I don't see the GNOME Foundation as being too far off from the Apache Foundation, and I have yet to see a single KDE developer use IBM's ruining of Apache as an example of why GNOME is doomed (hint, there's a reason for that). GNOME is GPL'd all the way down to the toolkits it depends on and that gives it a certain freedom KDE ultimately lacks.
[begin flame]
The fact is that the complaints about corporate control and how the KDE people are more pure and dedicated to the ideals of open source reek a little of hypocracy and a convenient ignoring of certain facts in KDE's history. The history of KDE is linked to the history of Qt because of the dependency and who remembers the Harmony project, the one time people tried to break KDE completely free of depending on TrollTech. The fact is that TrollTech has a few KDE developers working from it and while they've been mucking with the QPL, the fact is that they did their best to break a GPL'd version of Qt would would have lost their control over KDE entirely.
If Harmony had succeeded, KDE might well have been picked. But the fact is that people let themselves be seduced by TrollTech and compromised their open source principles instead of taking the hard path to being independent of them by getting Harmony to work and now the GNOME Foundation has showed them that politically they went down a proprietary dead end. To say that KDE is free and independent is to ignore it is rooted in something controlled by a single company.
[end flame]
My personal prediction is that in the long run KDE is going to be a niche player. TrollTech's greed and desire for control has doomed Qt and KDE in the long run, much as the other Unixes are doomed in the long run compared to Linux. Whatever lead KDE has now in support will slowly start to erode under official endorsement of GNOME for more major *nix variants than KDE does. Whatever technical superiorities KDE has currently will be eroded as more developers are piled on to GNOME, or they will become irrelevent as GNOME is good enough for most people. And it will get the lion's share of the development from various companies and develop a broader range of applications than KDE.
If the other site stole HTML and reworked it, then there's copyright issues involved, unless the Linux.com web code has been released into the public domain. If he reverse engineered his web page to look like Linux.com, then there isn't copyright issues involved. At best there might be trademark issues involved. As I vaguely recall, there are 'look and feel' issues that some people feel can be trademarked or owned (I could quite easily be wrong though). But in Linux.com case I sort of doubt they went that far.
In short, it depends on whether HTML was stolen or not. Otherwise, imitation is the sincerest form of flattery.
But then again a stripped down kernel might be small enough that its not worth reinventing the wheel for an embedded resource/process manager. Anyone have any figures for exactly how big the kernel in that puppy was? I think the memory stored in it was sort of overkill as well. Better to cut down the memory and increase the battery life. This is definitely a place that Crusoe-style power management technology would also be a win. Let the CPU in the thing only use as much power as it needed at any given moment.
Even so there are advantages to using Linux. It means the API is open and programmers can go and set up their own programs to run in the watch as well. Not that I can see a huge range of programs that people would want to run in their watch. A PDA is slightly more usable in that regard for general computing. But no doubt others will manage to think of uses for such a system beyond simple databases and pager/appointment notification. Oh yes, and telling the time as well.
But the interface shown in that one picture we had the other day won't cut it. You don't want any of the conventional command line shells here. GUIs won't hack it here either, I don't think. This is one of those cases where I think you'd be better off defining the thing as a TERM of some sort and uses curses or something similar to manipulate the screen. And I'm being unimaginative when I say that I can't quite see the full point of a color bitmap display there, but I'll say it anyway. A postage stamp screen just doesn't give you much manuvering room for graphics. A PDA is nearing the bottom end in my personal taste on such things.
The inputs are going to be the buttons on the watch. At best you can make them analog buttons and get some degree of pressure sensitivity but that is all. Something like a calculator watch isn't going to hack it. And given a bunch of other problems I don't see voice input on these things either. Too awkward holding your wrist up to your mouth. That defeats the whole purpose to having something on your wrist.
Its an interesting proof of concept but needs a bit of work in the usability area.
The Palm succeeded because it has an interface more suited for a PDA. A wristwatch is going to need something even more stripped down than that. Strangely enough, a GUI is not what is needed for a watch like this. Pure alphanumeric with a few graphical characters is probably what is needed here. Something for the user interface researchers to work on here. As cute as it is to see the command line on a watch, its not very practical.
To be blunt, a watch is a data display device only. Merging the watch with the pager makes perfect sense and putting your address and appointment book in it. Not sure I'd want to try reading some of my email with it. Maybe just a summary of what is in my PDA through wireless. That is what I really want. A wireless interface between my PDA and my watch to keep the data between them in sync and so I can use my PDA as the data entry device for my watch.
This falls into the Convergence thread we had elsewhere, about ergonomics and why you don't want a device for doing everything. A watch is good for displaying small amounts of text instantly and with minimal controls for wading through it. It also has a convenience factor to it that is unmatched by any other consumer device. You don't want to load too much gadgetry into it and try to make it do too much. You really just want it to be a specialist device among many. Its not there to replace a PDA any more than a PDA replaces a laptop or a laptop replaces a workstation.
The corralary is that things with similar ergonomics will be absorbed into one device. The one thing about my Palm that annoys me is that I can't play MP3's on it. No doubt were I younger I wouldn't mind something with more Gameboy like controls on it either, to better play handheld games. There's enough similarity in the ergonomics of those devices, the PDA, the MP3 player and the handheld game player that they could merge.
Technically your PDA could absorb your cellphone if you invested in a headset. If you've got earphones for listening to MP3's on your PDA, then adding a microphone to talk through it is a small leap. Then you've got the ergonomics that are physically comfortable. Of course people like cell phones anyway because you can pull them out and put them away.
Now that said, cell phones will pick up PDA-like features. The Palm succeeded because it wasn't a computer in your hand but stripped away down to the essential functionality. Cell phones will go the same way. People are going to strip out the excess functionality and get it down to what people really want and can use easily.
One piece of functionality that people might want in a cell phone is a solid state voice recorder, to fill the niche of handheld tape recorders today. Sure, people can leave messages on their answering machines but using wireless costs and the audio quality drops. And once the phone's memory is filled, hit a button and transmit it remotely to some location, compressed to save usage charges. That's the sort of convenience and functionality people might actually appreciate in a cell phone. You need to think of everything with similar functionality and ergonomics to a cell phone to figure out where its going.
Given the fact that to some extent for cameras and cell phones and even PDA's, form follows function and they have vastly different functions, trying to have one form that encompasses them all is foolish. You get something that is a jack of all trades and master of none. It's better to have devices that are optimized for complementary uses. The PDA is your generic data entry and display device. The cell phone is voice communication. The camera is to record visual data. The key is to make all of these specialists work together as a team.
Personally I wouldn't mind having a cell phone and a PDA but having the two of them talk to each other seamlessly. Indeed, I could see the PDA being bright enough to know that I have a cell phone and use it to do long range wireless, which would spread the load of work done across multiple batteries. And as for my electronic camera, if it can instantly transfer the photographs it takes over to my PDA, that would be fine and dandy. The PDA acts as the hub of my personal LAN, the brain controlling it, with cell phone and camera as periphials.
Come to think of it, that's the best analogy I can think of. Would you really want a personal computer with a printer and scanner built in? Or even a laptop that's built that way? It can be done and you could argue there's an all-in-one utility factor, but even for a laptop people tend to back down from that. The personal computer industry could have converged but didn't. They realized (consciously or not) that it was better to have those periphials separated from the main box. The iMac or laptops are the limit for integration there.
And so I think we're going to see the same thing on the personal devices level. The PDA takes the place of the computer and the other devices become things that connect via wireless to it.
Of course I don't see them as being completely dry either. The Open Source movement is quite capable of salvaging the best ideas from what is out there and innovating from there. From Napster came Gnutella, which will have a very long life even if the RIAA brings Napster down.
The analogy I'm trying to make is that the idea of having resources accessible on the Net from wherever you want to be is something that will appeal to a lot of people. However the real solution is for people to configure their home servers that way. I'd love to be able to set up a desktop at home that I could take wherever I went. And not some big networked server I can't control, but my personal computer that I am in control of.
In the end, things like Office are too easily reengineered by the Open Source movement. The operating and basic application suites are too easily recoded by independent developers. Microsoft trying to clamp down on piracy and going to a subscription model for Windows and Office will end up driving people over to Linux and the software suits being developed for them, where there are no such costs.
In the end I see the Open Source movement taking on the ASP's by letting everyone become their own ASP. Everyone loads the applications onto their home servers that they like and then software is developed to let them run it from anywhere they like. And since this software is going to be Open Source, there are no monthly access fees like Microsoft plans to charge for their efforts.
So that is how Microsoft will be defeated, when the Open Source movement takes what ideas from the whole.NET concept that make sense and are useful and leave out all the stuff that lets Microsoft remain in control and puts in all the stuff that gives the users control of their own systems.
Microsoft does not understand that the Net is too big for it to dominate and control the way it used to do with the personal computer industry. Or they haven't realized that they have an opponent that they can't simply beat in the end. The computer industry is growing sicker and sicker with Microsoft's control and everyone else is coming to the realization that while they can't control things themselves, with Open Source they can make sure no one controls them.
They'd need to do two things to make it work. First, they'd need an embedded version of GDK that worked straight to the display without X, to reduce the CPU/memory load on the system. Second, they'd need a custom window manager.
Even then it seems a little bit like overkill. Any application developed for GNOME is likely to be oriented towards a desktop display. The whole user interface would have to be rewritten for an app to be usable on the thing. That's the whole problem with WinCE (at least in its first two incarnations), its user interface was too complicated for a PDA.
My personal opinion is that we need yet another GPL'd GUI for PDA's. Yes, another API for developers to have to port their code to, but for running stuff on a handheld, you want to do a certain degree of rewriting to get the UI correct. Desktop apps and PDA apps are two different types of beasts in any case. I'm not sure we'd need as many layers as we do for the desktop environment. Probably a single integrated layer for graphics and display management which reduces the flexibility. But on a PDA every K counts.
In short, this is an interesting concept but I'm not sure I'd want to use it on anything less than a tablet display. For a handheld, forget it. I'd rather have some custom user interface set up.
I think that Hannibal is dead on with the whole idea of translation technology being built into future chips. I cannot believe that Intel is not trying to duplicate Transmeta's own clever innovations in a manner that does not infringe on patents. And once Intel does it, everyone else is going to have to follow suit.
That's the hardware end. Programs don't just run off a ISA, they also run off an API. What is the software technology that would best run in combination? Virtual machine technology. My gut feeling is that someone will build a PC with the ability to boot virtual Windows sessions where the programs there think they're on an x86 with all the requisite hardware while the rest of the computer is emulating some nicely streamlined ISA and you've got Java code running in some sandboxed virtual machine elsewhere on the system.
At this point you have support for legacy ISAs and legacy APIs in a nice simple format. As computer architectures die, they just end up virtualized and emulated/translated. And the computer is designed from the hardware through the operating system to seamlessly do it. In time everyone assumes they're on a virtual machine and the new operating system evolve to adapt to that environment.
No doubt such a setup will even allow for finetuning for things like emulating old Apple ][ systems as well as original IBM PCs running at 4.77 Mhz to get all those old games running just right. Or old Nintendo/Sega/whatever boxes. All those emulation setups get ported to the virtual machine setup and the appropriate ISA and you've really got emulation there.
Companies will like it because they can ditch old unsupported hardware but keep the software around forever. Especially companies with several brands of hardware/software that they can suddenly run under a single brand of hardware.
This is Microsoft's worst nightmare because all of a sudden switching to a new operating system does not preclude dropping old software. It can be done seamlessly and as gradually as people want. To Apple, it is also a bad nightmare, especially if other people work out Mac virutal machines on other hardware.
To Intel, they're already taking a bruising from the other CPU manufacturers. Intel will take to the translating setup with a vengence, but instead of going in the direction of power consumption (or alongside it) they're going to focus on performance, the niche they've always gone into. And their rivals will go and do the same.
To the PC vendors like Dell and Compaq (but not as I said, Apple) its something to be welcomed. They're already in the trenches competing against other machines that run all of the same software anyway. Anything that allows them to expand their range of software to run, the range of operating systems seamlessly is fine by them.
To operating system vendors (except for Microsoft and to a lesser extent Apple) it will be a major blessing. All of a sudden experimenting with a new operating system becomes easier and switching to it becomes useful. Niche operating systems can thrive being used for specialized applications on an existing machine.
Things like OpenBSD can suddenly start becoming really popular doing things like being the virtual machine that's the only one designated to see the DSL connection to the outside world while the Windows and Sega Genesis virtual machines are there for playing old games and the Linux or FreeBSD virtual machines are used for getting work done.
This is the direction I think the PC will be evolving in to compete with the small and specialized Internet appliances. They are going to take their strength, flexibility and go more so in that direction. The CPUs will become more flexible and the operating systems will capitalize on that and take virtual machines to the next level.
Berlin is not a replacement to GTK/Qt or to GNOME/KDE or to any of the window managers that run on top of any of the previous. It is a replacement for X, an attempt to redo what X did, only more intelligently, with a knowledge of the limitations of X and taking into account the developments of the computer industry and for that matter the new needs of the computer industry.
X is powerful but there are several areas where it cannot be revised and extended without breaking all the other applications which currently depend on X. Sooner or later you need to throw out the old software and do a clean start.
The real significant developments in Berlin are the fact that it uses CORBA for brokering the API, a well thought out approach to client/server distribution of resources over the network and the support of resolution independent graphics as well as other features of modern graphics hardware.
Why not use X? Because X was designed in a far more different era than the one we have now. It is better to have a system that is optimized for modern computing uses and has room for growth.
Why would anyone switch from X? As has been commented over on the Berlin site, one can create an XLib compatibility layer, and between that and ports of GTK and Qt, which are designed to be insulating layers between programs that use a GUI and the underlying graphics API, running existing software on Berlin shouldn't be that difficult. Modular software design in the Unix world has its overhead but there are advantages to it.
Unix needs to evolve with the times. Yes, there is power in continuity and well-hammered tools that have survived the test of time, but that should not be a barrier to progress. That includes things that are technically separate from Unix but closely associated with it, such as X. Apple keeps pushing the standard for graphics forward and OS X has raised the bar for graphics technology. The Berlin people have a moving target to hit.
People may wonder at the hype of a 0.2 release, but the fact is that Berlin is slowly starting to move from the 'interesting toy' level to something more along the lines of a serious prototype for a new windowing system. Hopefully it will start reaching the point where it attracts more developers interested in a cool windowing system.
The second step is the XLib and GTK/Qt porting support, at which point the number of applications that can run on Berlin shoots up dramatically.
The real goal is to get software driver support for Berlin on the order of support for XFree86. That is going to be a pain in the neck unless someone can figure out a brilliant way to get device drivers for X to be used by Berlin. Those systems with open source drivers will probably have drivers written by motivated developers.
I'd like to see a real competition for developer mindshare between Berlin and XFree86 on the order of GTK/Qt or GNOME/KDE. Competition can only benefit the consumer.
Personally I prefer something with the size of the Palm. I like something I can shove in a shirt pocket or pants pocket. With a device like that, I think you're best off building to a form factor and shoving everything you can into it. A webpad doesn't have that easy ability to be carried around with me at all times. Given what I'm sacrificing in functionality, that is the only thing the PDA really has going for it.
What I don't like about my Palm V is the lack of color, lack of memory, lack of CPU, lack of small removable storage. And better sound capability. I want to be able to toss out my portable MP3 player and just swap memory sticks in and out of my PDA with a good set of earphones. And to be able to plug in a small game controller and play stuff on it as well. There goes the Gameboy. Heck, even small movies on that screen if the removable storage has the space.
A webpad just doesn't do that for me. A webpad might work strictly as a specialized input device that I used strictly to enter data now and then and to dump immediately into a computer or into my PDA. But I wouldn't keep anything standing on it. Or with wireless capability as a remote terminal, which again puts it more in the data input category and ability to view remote data. Or if they used the size to have a DVD-ROM drive built into the thing, which is about the only thing that might justify the form factor. Even then I might just break down and go to a laptop.
A webpad strikes me as one of those nasty compromises that gives you the worst of two worlds. Not as large and comfortable and powerful as a laptop and not as conveniently portable as a PDA. As others have noted, this is where the Newton died. Ergonomics are critical for a device like this, and webpads just don't do it for me there.
I agree that GNOME should not be trying to emulate Windows 95. It should be trying to pull the best of Windows 95 and the Macintosh. Right now I'd say that GTK people need to start looking at Quartz (the new graphics engine in OS X) and start looking at trying to implement that functionality.
Emulation isn't a strike against GNOME or KDE. The Start Button isn't anything new. Look at the Apple menu. And Windows 95 was emulating the Macintosh, which was emulating the Xerox Star (I can't remember if anything came before that). I don't think that emulation is necessarily evil. And by the nature of Open Source, it is in some ways more difficult to emulate. A lot of what drives Open Source development is people seeing a feature on some other system and clamouring to use it on Linux (or BSD or whatever).
Still, as long as KDE and GNOME have enough modularity and flex built into them, people can experiment with stuff on top of them. The whole window manager issue is no doubt going to go through a lot of evolution over time, at least on the GNOME front. I don't think Sawmill is going to keep its position without a bloody fight.
KDE and GNOME are playing catch up to Windows and the Macintosh. Maybe to some extent they'll always be playing catch up (at least to Apple, which likes to innovate and push ahead). But maybe someday someone is going to look at some experimental setup out of some university doing work on innovative new user interfaces and decide they want that on their box (or that university may GPL the source code) and Linux GUI's will shoot ahead.
The thing that GNU/Linux can learn is a cleaned up and unified configuration system. To my mind the area where GNU/Linux really needs to clean things up is over in/etc (and maybe/dev and/var and a few of the other utilitarian filesystems). Create a unified, consistant and extendable XML setup for system, application and user configuration files.
The main advantage here is that it allows for the creation of universal configuration tools that don't have to be recoded every time a new application comes out. Just plop in a new XML file (and possibly a DTD) and all of a sudden you've got a whole new application to manipulate easily. Not to mention developers have a nice little API for creating and managing configurations that allows system defaults and user overrides of said defaults transparently.
Little things like file bundles should be included in this restructuring as well. There are some nice nifty little bits in Mac OS/X. Apple really cleaned up some of the nastier bits of Unix when they tossed out historical precedents. Not that I totally agree with all of their decisions, but a lot of Unix simply evolved rather than was desgined coherently. It's time those parts were cleaned up. A lot of the usability issues with Unix are going to be stalled until they are.
Note that this does not mean babyfying Linux in any way. The thing with file bundles is you can open them up if you want granularity. Going to XML for all the configuration files in/etc (as well as pulling in configuration files from elsewhere and giving them structure) is there to make things consistant. If anything it will be easier for those writing administration scripts to work if said configuration files are standardized and organized. Quite the opposite.
I'm using GNU/Linux here because some things are handled at the kernel level but a large chunk of it is in the GNU tools that are traditionally bundled with Linux. Both need some modification here to come up with a coherent and unified system.
Migration is going to be a nightmare (remember glibc?) however once migration is done things can really start to move forward in terms of usability. The GNOME/KDE people would love to be able to set up pretty GUI-based configuration tools to manage everything, and the Perl/Python people would be in heaven because they could write real libraries to manipulate those things (not to mention all the people who use those libraries).
Backwards compatibility is all fine and well, but we all know of how backwards compatibility can drag back progress in the computing world. This is one of those cases where things have reached the point that areas need to be scrapped and rebuilt in the name of future progress.
What we are seeing right now is the reverse of the Unix Wars, the big bang running in reverse. Where Unix splintered into countless variants, there is now a trend backwards towards consolidation in Linux. And IBM has very good reasons to start folding their AIX functionality into Linux (disclaimer: I have no knowledge of IBM's real motivations here, this is just guesswork).
IBM doesn't just have operating systems, they have a lot of software that runs on top of the operating system, in the area of Unix this means AIX. Linux has a lot more forward momentum than AIX does, or is likely to ever have. The more AIX functionality that Linux has, the easier it will be to port their server software onto Linux.
Why did they port JFS to Linux? Probably because SGI had upped the ante by dumping their journalling file system onto Linux. That means that if IBM wanted to retain the advantage of their experience with JFS, they would have to make sure their journalling file system caught on and became the dominant standard.
While Linux will have several journalling file systems supported under it, in the end support will probably dwindle to all but two, which most likely will have different reasons for surviving (speed versus reliability optimization would be a likely scenario). IBM wants to be sure that JFS is one of them. Likewise other extra bits of functionality that different proprietary Unixes have are going to battle it out for the defacto standard. IBM will probably start trundling out those other pieces in competition.
That is a point to counter the fork-FUDders. The fact is that branches can die. Happens all the time in evolutionary biology. Same in the computer industry. One might point out that word processing effectively splintered among dozens of different incompatble programs, and sort of consolidated in the end around Microsoft Word.
Yes, Linux can fork but what is going to keep both forks going forward? There needs to be drive and encouragement to sustain both (or more than two) prongs. In the *BSD camp, that happened because they fill different niches. OpenBSD says that they're going to be secure and that's that, anyone who doesn't like the limitations can go use some other *BSD variant.
So the Linux wars are going to be the opposite of the Unix wars, where everyone throws in their features and tries to get theirs to become the dominant functionality inside of Linux. And IBM has a lot of reason to want to win those wars.
Apple once again lurches into the forefront in key technical areas even if their user interface standards are slipping. Reading this article really makes me wish that Tog was still back at Apple. What he could do with the power of Quartz and all the things he could fix in the Aqua interface make me sigh with regret. I'm also regretful that Apple went with BSD instead of going over and contributing to the Linux movement, but I can understand their reasoning.
Even so, this setup makes it quite clear that there is a lot that can be done in future releases of Linux. The main parts that strictly concern the Linux kernel involve Apple's cleanup of the system directory structure, it's reorganization of resources and the use of XML heavily for configuration files.
The main problem with Linux for the masses is that managing system resources on a Linux system is nontrivial and really requires a trained system administrator. There are configuration tools that try to simplify it, but the lack of a standard configuration file format really cripples the effectiveness of these utilities. Also, the Linux filesystem really grew without systematic organization over various releases of Unix, rather than being planned out as a coherent and unified set of data files and a parser.
The thing I really like most about OS X is the whole/System layout, at least the concept of it. Linux really needs to sit down and think out a new directory structure from scratch to organize all the files that are needed to run the operating system, along with a few elegantly constructed libraries and tools for manipulating those files.
Such a porting sounds hideous but it can in fact be done in stages. A developer's release, probably Linux X.9 because the final result will be radical enough to warrant an point zero release, could create a filesystem like/System and over the course of various X.9.Y releases, move various system resources over to it.
Backwards compatibility can be maintained by leaving the old/usr,/etc and other filesystems in place./System would be where the operating system really lived and things like/etc/hosts could be created by special utilities from the XML files that contain host information. But the idea there is that would only be for legacy application support and developers would be encouraged to port to the new/System layout.
Bundles are an elegant compromise between the necessity of having a bunch of files together to run a single application while at the same time giving a convenient single box to be handled from outside. Average users will use the box as a whole, advanced users can open it up and play with the contents. This is another feature that Linux needs to come up with some equivalent for, if it is to succeed on the desktop.
Quartz is less critical, though in the long run it will probably make life easier for developers. The fancy stuff there isn't strictly necessary, not yet, though as the range of displays increases, going to PDF and breaking the dependency on DPI and viewing distances will be necessary for the range of devices that Linux will run on.
Unix wasn't so much designed as it evolved, and parts of the system show that. Apple has done a major boon by showing what Unix can evolve into, giving the Linux developers a clear target to aim at for their course of future evolution. Between/System, XML resource files, bundling and Quartz, Linux has plenty of ideas to copy and improve on through the open source movement.
Microsoft is a big corporation and they can afford to blow money working on projects that are more contingency plans that won't see the light of day. Office for Linux is merely an option, and managers are quite possibly seeing how difficult it is to do the port and how well it runs. Not to mention that it might be DOJ fodder.
Microsoft won't do an Office for Linux port until they are seeing steady erosion of the desktop market for Linux. I think Microsoft porting their server software to Linux is a far more likely scenario right now. If Windows 2000 continues to show lackluster performance, that possibility will keep going up. Especially if Linux somehow takes a higher percentage of the server market than Windows, and that could well be within a couple of years.
Of course that would effectively shoot themselves out of the server market, so they're not going to do that until they're ready to surrender. But that is a distinct possibility. Every generation of NT took more and more money to develop and forcing more and more gruesome licensing schemes to compensate and companies are starting to get into this idea of Linux in their servers. Even the popular press says that Linux is great as a server solution, even magazines that get lots of Microsoft funding.
Something to remember is that Microsoft has killed a lot of projects in the past. Bob is the most infamous example but there are other Microsoft projects that also have died. If a piece of software doesn't justify the investment, it dies. If Windows 200X projected sales doesn't make up for the investment in resources, then they'll look for a way to cut their losses. Customers who leave Windows 2000 for Linux are not likely to come back for Windows 200X and the licensing schemes that will be needed to make a profit off of that.
A more sane approach for Microsoft in that scenario is to conceed the server market and port their server software to it, their Active Directory solution et al. Lets Microsoft hop on the Linux bandwagon and take advantage of all the hype. They might try to take over the Linux standard, but I don't think they're going to manage it. There are too many other Linux vendors and if Microsoft comes up with their own standard, everyone will go off and make up their own. Remember MCA versus EISA?
Microsoft will hang onto the client side a lot longer. When that area starts eroding seriously, once again when it is no longer profitable for them to keep producing a new version of Windows, they'll hop on the Linux bandwagon for the desktop and produce a Office for Linux as well as porting all their other desktop application software. But that's four to five years away.
Around that time they'll start producing their own version of WINE for Linux with their claims of full Win32 comptability and make revenues off of legacy applications.
That assumes Microsoft as a single company. If applications and operating systems are broken up, all bets are off. That could be a very likely reason there's a project to do the port now. No one knows how its going to end up and the applications people don't want to be caught with their pants down when they are forced to compete on their own.
But that is just worst case planning here. I think we'll see Microsoft SAMBA long before we see Office for Linux.
Consoles work on the principle of standardized hardware running a single application. When one has standardized hardware and an application that has the whole system to itself, there is far less of a need for an operating system. Therefore, Microsoft, an operating system company, putting out a console is working out an exercise in futility here. Sure, it may be easier to port Windows apps, but console software developers are used to doing things like going from one console to another anyway.
Microsoft might win developers over only on the greater freedom to port software over to the system and low to possibly non-existant licensing fees (if they haven't gone this route, they are doomed). Conventional consoles require manufacturer approval for a licence to write software on that platform and get a certain amount of money per game sold. Consoles work on the give away the razor, sell the blades theory of economics.
Eventually there will be a console based on the PC economic model that might take off. If it runs an operating system, it will be probably Linux, due to the zero cost of the operating system (and in the console market, every dollar you shave off the price helps). Either that or there's going to be some lawsuit that opens up software development on conventional platforms and the console economic model is broken anyway.
But Microsoft trying to get into the console market is going to be a great bomb, I predict.
There are times when Open Source makes a lot of sense or is practically essential. There are other cases where it is more incidental.
Some might argue that the Crusoe morphing software is analogous to the situation with device drivers. Given that the morphing software is linked to the CPU itself, and the software is devoted to emulating an instruction set, below the level of API compatibility that operating systems worry about, the device driver argument isn't really valid.
The only other strong cases for open source are for reliability and security. As long as the code works reliably, that isn't an issue. Security isn't an issue for CPU firmware. Perhaps performance might be improved, but there's no assurance from that and there are reasons that Transmeta is avoiding releasing the code.
The benefits from opening up the code morphing software are extremely limited and the potential disadvantages given that there is a lot of investment made in the intellectual property, are much greater. That is a case where close source software is quite valid in my opinion. People doing things like voice recognition with natural language parsing and other cutting edge technologies to me can justify releasing the core elements in a close source form.
Linus is not a hypocrite for working on a closed source project. He's merely more reasonable than some people who would insist on forcing round pegs into square holes.
Not to beat the computers vs automobiles down, but this does in some way feel like back when the Japanese automobile manufacturers started taking on Detroit, with its low powered but cheap and fuel efficient cars those high powered gas guzzling models. And Detroit learned in the end people didn't need to be able to do 200 mph so much as they wanted 30 mpg.
The laptop market is going to go in the same direction. People don't use laptops, excuse me, most people don't use laptops to run Quake and other games at ridiculously high fps. In a laptop, having good enough performance and a long battery life are more than sufficient. They may be slower but the question is will most people really miss the performance. If one does not run graphics-heavy games (and Microsoft operating systems and applications), how much CPU power does one need?
The Transmeta people had some good ideas. Pity that it's the x86 instruction set they're stuck with, though it will be interesting to see how good a Java virtual machine they might get out of it. For some reason I like the idea of a standardized instruction set and then forcing the chips to run that everywhere very appealing.
As for Intel, I think they're going to have to eventually learn that they can't be all things to all people. Microsoft is starting to slowly come to that conclusion as well. Sooner or later you have to pick a market segment and hope that it stabilizes. Trying to go against AMD and Transmeta just seems a bit much for one company to do.
Slashdot Mirror
Not necessarily. For something like the Metrocard system the necessity of open source is not clear to me. The government would be much better off mandating the use of hardware available from multiple vendors and owning all of the rights to the software. That makes sense. If one vendor goes belly up or tries to negotiate for a lot more money when its renewal time, the government can go to another vendor with the software and ask them to continue support.
Open source? No. Owned source? Sure.
There are certain games where fancier graphics can help out. Simulation games of various sorts, especially wargaming and flight sims and sports games. Then there are 'world tour' games where you have some sort of adventure game where the whole point is to transport you to another world, not unlike a good book or movie.
The category of game that has been neglected with the rise of graphics are the highly abstract games, like poker and chess and even games like Monopoly or Clue. Games with highly artificial pieces and rules. Tetris is a good example of this. Even a game like Tempest falls into this category. Games that don't pretend to simulate anything. Chess vaguely has some ties to wargaming but not many, and what is poker simulating?
That's the place that shareware, freeware and open source developers should be heading. Skimp back on the graphics and just create simple games that don't suck down CPU power, except possibly for the AI. And take advantage of modern computing by having the facility for networked play.
Radio receiver built in for wireless capability. Local range only, perhaps to conserve battery drain it would be activated via a hotsynch button though hopefully it would be able to have it on all the time without too much trouble. Very small bitmapped display which is only used for alphanumerics and special characters that can be used as an abbreviation for full words. Screen space on a watch is valuable. Every character has to count. And a few buttons around it. Not like those old calculator watches, that goes too far. I want buttons around the sides so screen space is maximized as much as possible.
Note there is only receive on the wireless part. This thing is a data display device, and the buttons are for browsing. Just as the Palm people reinvented the user interface from the ground up this watch would have its user interface redesigned from the ground up. One button might be a display time/display pages/access database toggle. Hit the button a few times and you switch between the main common uses of the watch instantly, no fuss, from whereever you are, like the application icon on the Palm. Other buttons would probably be more modal.
This watch would function as a watch, as a pager (and maybe to notify when you have important mail), and a portable phone/email/address list. Maybe a few other things as well like sports scores (not that I'm that big a fan but others are), stock prices (ditto) and so forth. My current pager has a feature where it picks up news headlines. Not all that uninteresting a feature, as long as I had some way to filter for what I was interested in.
The watch has a small screen space, limited control/input capability and the power requirements have to be insanely low. The positive side it has the ultimate convenience factor of being always available, faster than a PDA. The computer watch has to play to these strengths if it is to ever really take off.
I think it is possible to set up a system that can be both easy to use at first and powerful later on. The trick is to get the foundation of the system right. At the foundation you need something essentially akin to Unix. A wide range of powerful and flexible tools that can be linked together in powerful arrangements under some sort of linking/scripting system. Then on top of that you build up a set of friendly and easy to use tools that let people do their basic tasks. And perhaps some midrange tools that provide more complexity for users who need more power. Or give those tools an advanced mode. These tools should be crafted under the scripting/linking system.
So users start off with the friendly tools, as they grow more comfortable they switch to the advanced mode. In time they might well grow so advanced that they craft their own tools under the scripting/linking system to automate tasks that they want to be done.
Essentially it would be taking the Unix 'find' command which is powerful but not easy to use and you write a new simple GUI front end to it, with a simple mode that allows for easy selection of the starting directory and a fill in the blank approach for the -name field with the default -print modifier. And the advanced mode invokes find with a few more fancy options. The power user then starts using find directly or creates their own little button on some control panel if they need say, something that will present a window of all their log files for the day.
What you need is to encourage the creation of these tools and make it easy to link them together under the language of your choice. GNOME and KDE are taking steps in the right direction with Bonbono and KParts respectively, but sometimes I wonder if that goes far enough in some ways.
Consoles and these DVCRs both have the same economic model. The boxes themselves are dirt cheap and the profits are made on the stuff around the boxes. Games in the case of consoles and the subscription service in the case of DVCRs. In theory there's a lot of overlap between the two pieces of hardware as well. Consoles would probably be overkill in hardware for the sort of rendering needed for these devices. In theory a company manufacturing a dual purpose machine might be willing to risk shaving more overhead from the machine because they'll have a dual source of income.
Personally I think you're risking 3DO syndrome in this case. The PSX2 is edging there but sticking a DVD player into a console with a DVD-ROM is so trivial whether or not to do it is a political decision instead of a technical or economic one. Until consoles hit the same point I don't think this will happen.
>KDE tried CORBA. It was bloated and slow. Kind of like GNOME itself. You really should work in marketing though: "Everyone else (for whom I can name absolutely zero examples) is invested in CORBA, so KDE needs to be using that just for the buzzword too!"
Go to www.corba.org and start from there to see who is behind it. I assumed the fact that CORBA was an independent standard invented by a coalition and supported elsewhere was rather obvious.
In an ideal world, technical issues would always win out and people would always choose the technically superior solution. That was the whole bleeding point of my article. The fact is that CORBA is more politically acceptable than KParts. I said that KDE tended to win on technical merits all over the place. But generally people choose the most politically acceptable solution. The history of the computer industry tends to drive that point home over and over. I didn't say it was a good thing that people tend to cling to buzzwords, but it's a fact of life. I've lost my youthful idealism on that point.
KDE has some pretty valid claims to technical superiority. However KDE has serious political flaws that doom it. The first is the dependence on a proprietary toolkit, Qt. That is the most serious one in my opinion. That is what scared most of the corporations off. They didn't want a repeat of the CDE scenario where they tried to make a common standard off of prioprietary licenced products. The fact is that the GNOME Foundation isn't a rehash of the CDE fiasco no matter how much some KDE people try to make it out to be as one.
A lesser one is the use of KParts rather than CORBA. Perhaps the consortium might have overlooked that but the fact is that everyone has a lot invested in CORBA these days. GNOME is more buzzword complaint than KDE and that's another political mark in its favor.
And so because GNOME was more politically acceptable and technically good enough for these companies to choose to endorse GNOME. The KDE people can harp on technical superiority, but the computer industry is littered with technically superior products that ended up niche players. Linux has for a very long time been technically inferior to every other form of Unix but the fact that it is politically superior has enabled it to last and have its technical failings addresed. Microsoft won because it was politically more adept than technically. The fact is in the long run you have to look at the political angles.
And there is the fact that if GNOME becomes too corporate, developers can vote with their keyboards and fork GNOME. Or can go back to KDE (or more likely start over with something new). Personally, I don't see the GNOME Foundation as being too far off from the Apache Foundation, and I have yet to see a single KDE developer use IBM's ruining of Apache as an example of why GNOME is doomed (hint, there's a reason for that). GNOME is GPL'd all the way down to the toolkits it depends on and that gives it a certain freedom KDE ultimately lacks.
[begin flame]
The fact is that the complaints about corporate control and how the KDE people are more pure and dedicated to the ideals of open source reek a little of hypocracy and a convenient ignoring of certain facts in KDE's history. The history of KDE is linked to the history of Qt because of the dependency and who remembers the Harmony project, the one time people tried to break KDE completely free of depending on TrollTech. The fact is that TrollTech has a few KDE developers working from it and while they've been mucking with the QPL, the fact is that they did their best to break a GPL'd version of Qt would would have lost their control over KDE entirely.
If Harmony had succeeded, KDE might well have been picked. But the fact is that people let themselves be seduced by TrollTech and compromised their open source principles instead of taking the hard path to being independent of them by getting Harmony to work and now the GNOME Foundation has showed them that politically they went down a proprietary dead end. To say that KDE is free and independent is to ignore it is rooted in something controlled by a single company.
[end flame]
My personal prediction is that in the long run KDE is going to be a niche player. TrollTech's greed and desire for control has doomed Qt and KDE in the long run, much as the other Unixes are doomed in the long run compared to Linux. Whatever lead KDE has now in support will slowly start to erode under official endorsement of GNOME for more major *nix variants than KDE does. Whatever technical superiorities KDE has currently will be eroded as more developers are piled on to GNOME, or they will become irrelevent as GNOME is good enough for most people. And it will get the lion's share of the development from various companies and develop a broader range of applications than KDE.
If the other site stole HTML and reworked it, then there's copyright issues involved, unless the Linux.com web code has been released into the public domain. If he reverse engineered his web page to look like Linux.com, then there isn't copyright issues involved. At best there might be trademark issues involved. As I vaguely recall, there are 'look and feel' issues that some people feel can be trademarked or owned (I could quite easily be wrong though). But in Linux.com case I sort of doubt they went that far.
In short, it depends on whether HTML was stolen or not. Otherwise, imitation is the sincerest form of flattery.
But then again a stripped down kernel might be small enough that its not worth reinventing the wheel for an embedded resource/process manager. Anyone have any figures for exactly how big the kernel in that puppy was? I think the memory stored in it was sort of overkill as well. Better to cut down the memory and increase the battery life. This is definitely a place that Crusoe-style power management technology would also be a win. Let the CPU in the thing only use as much power as it needed at any given moment.
Even so there are advantages to using Linux. It means the API is open and programmers can go and set up their own programs to run in the watch as well. Not that I can see a huge range of programs that people would want to run in their watch. A PDA is slightly more usable in that regard for general computing. But no doubt others will manage to think of uses for such a system beyond simple databases and pager/appointment notification. Oh yes, and telling the time as well.
But the interface shown in that one picture we had the other day won't cut it. You don't want any of the conventional command line shells here. GUIs won't hack it here either, I don't think. This is one of those cases where I think you'd be better off defining the thing as a TERM of some sort and uses curses or something similar to manipulate the screen. And I'm being unimaginative when I say that I can't quite see the full point of a color bitmap display there, but I'll say it anyway. A postage stamp screen just doesn't give you much manuvering room for graphics. A PDA is nearing the bottom end in my personal taste on such things.
The inputs are going to be the buttons on the watch. At best you can make them analog buttons and get some degree of pressure sensitivity but that is all. Something like a calculator watch isn't going to hack it. And given a bunch of other problems I don't see voice input on these things either. Too awkward holding your wrist up to your mouth. That defeats the whole purpose to having something on your wrist.
Its an interesting proof of concept but needs a bit of work in the usability area.
The Palm succeeded because it has an interface more suited for a PDA. A wristwatch is going to need something even more stripped down than that. Strangely enough, a GUI is not what is needed for a watch like this. Pure alphanumeric with a few graphical characters is probably what is needed here. Something for the user interface researchers to work on here. As cute as it is to see the command line on a watch, its not very practical.
To be blunt, a watch is a data display device only. Merging the watch with the pager makes perfect sense and putting your address and appointment book in it. Not sure I'd want to try reading some of my email with it. Maybe just a summary of what is in my PDA through wireless. That is what I really want. A wireless interface between my PDA and my watch to keep the data between them in sync and so I can use my PDA as the data entry device for my watch.
This falls into the Convergence thread we had elsewhere, about ergonomics and why you don't want a device for doing everything. A watch is good for displaying small amounts of text instantly and with minimal controls for wading through it. It also has a convenience factor to it that is unmatched by any other consumer device. You don't want to load too much gadgetry into it and try to make it do too much. You really just want it to be a specialist device among many. Its not there to replace a PDA any more than a PDA replaces a laptop or a laptop replaces a workstation.
The corralary is that things with similar ergonomics will be absorbed into one device. The one thing about my Palm that annoys me is that I can't play MP3's on it. No doubt were I younger I wouldn't mind something with more Gameboy like controls on it either, to better play handheld games. There's enough similarity in the ergonomics of those devices, the PDA, the MP3 player and the handheld game player that they could merge.
Technically your PDA could absorb your cellphone if you invested in a headset. If you've got earphones for listening to MP3's on your PDA, then adding a microphone to talk through it is a small leap. Then you've got the ergonomics that are physically comfortable. Of course people like cell phones anyway because you can pull them out and put them away.
Now that said, cell phones will pick up PDA-like features. The Palm succeeded because it wasn't a computer in your hand but stripped away down to the essential functionality. Cell phones will go the same way. People are going to strip out the excess functionality and get it down to what people really want and can use easily.
One piece of functionality that people might want in a cell phone is a solid state voice recorder, to fill the niche of handheld tape recorders today. Sure, people can leave messages on their answering machines but using wireless costs and the audio quality drops. And once the phone's memory is filled, hit a button and transmit it remotely to some location, compressed to save usage charges. That's the sort of convenience and functionality people might actually appreciate in a cell phone. You need to think of everything with similar functionality and ergonomics to a cell phone to figure out where its going.
Given the fact that to some extent for cameras and cell phones and even PDA's, form follows function and they have vastly different functions, trying to have one form that encompasses them all is foolish. You get something that is a jack of all trades and master of none. It's better to have devices that are optimized for complementary uses. The PDA is your generic data entry and display device. The cell phone is voice communication. The camera is to record visual data. The key is to make all of these specialists work together as a team.
Personally I wouldn't mind having a cell phone and a PDA but having the two of them talk to each other seamlessly. Indeed, I could see the PDA being bright enough to know that I have a cell phone and use it to do long range wireless, which would spread the load of work done across multiple batteries. And as for my electronic camera, if it can instantly transfer the photographs it takes over to my PDA, that would be fine and dandy. The PDA acts as the hub of my personal LAN, the brain controlling it, with cell phone and camera as periphials.
Come to think of it, that's the best analogy I can think of. Would you really want a personal computer with a printer and scanner built in? Or even a laptop that's built that way? It can be done and you could argue there's an all-in-one utility factor, but even for a laptop people tend to back down from that. The personal computer industry could have converged but didn't. They realized (consciously or not) that it was better to have those periphials separated from the main box. The iMac or laptops are the limit for integration there.
And so I think we're going to see the same thing on the personal devices level. The PDA takes the place of the computer and the other devices become things that connect via wireless to it.
Of course I don't see them as being completely dry either. The Open Source movement is quite capable of salvaging the best ideas from what is out there and innovating from there. From Napster came Gnutella, which will have a very long life even if the RIAA brings Napster down.
.NET concept that make sense and are useful and leave out all the stuff that lets Microsoft remain in control and puts in all the stuff that gives the users control of their own systems.
The analogy I'm trying to make is that the idea of having resources accessible on the Net from wherever you want to be is something that will appeal to a lot of people. However the real solution is for people to configure their home servers that way. I'd love to be able to set up a desktop at home that I could take wherever I went. And not some big networked server I can't control, but my personal computer that I am in control of.
In the end, things like Office are too easily reengineered by the Open Source movement. The operating and basic application suites are too easily recoded by independent developers. Microsoft trying to clamp down on piracy and going to a subscription model for Windows and Office will end up driving people over to Linux and the software suits being developed for them, where there are no such costs.
In the end I see the Open Source movement taking on the ASP's by letting everyone become their own ASP. Everyone loads the applications onto their home servers that they like and then software is developed to let them run it from anywhere they like. And since this software is going to be Open Source, there are no monthly access fees like Microsoft plans to charge for their efforts.
So that is how Microsoft will be defeated, when the Open Source movement takes what ideas from the whole
Microsoft does not understand that the Net is too big for it to dominate and control the way it used to do with the personal computer industry. Or they haven't realized that they have an opponent that they can't simply beat in the end. The computer industry is growing sicker and sicker with Microsoft's control and everyone else is coming to the realization that while they can't control things themselves, with Open Source they can make sure no one controls them.
They'd need to do two things to make it work. First, they'd need an embedded version of GDK that worked straight to the display without X, to reduce the CPU/memory load on the system. Second, they'd need a custom window manager.
Even then it seems a little bit like overkill. Any application developed for GNOME is likely to be oriented towards a desktop display. The whole user interface would have to be rewritten for an app to be usable on the thing. That's the whole problem with WinCE (at least in its first two incarnations), its user interface was too complicated for a PDA.
My personal opinion is that we need yet another GPL'd GUI for PDA's. Yes, another API for developers to have to port their code to, but for running stuff on a handheld, you want to do a certain degree of rewriting to get the UI correct. Desktop apps and PDA apps are two different types of beasts in any case. I'm not sure we'd need as many layers as we do for the desktop environment. Probably a single integrated layer for graphics and display management which reduces the flexibility. But on a PDA every K counts.
In short, this is an interesting concept but I'm not sure I'd want to use it on anything less than a tablet display. For a handheld, forget it. I'd rather have some custom user interface set up.
I think that Hannibal is dead on with the whole idea of translation technology being built into future chips. I cannot believe that Intel is not trying to duplicate Transmeta's own clever innovations in a manner that does not infringe on patents. And once Intel does it, everyone else is going to have to follow suit.
That's the hardware end. Programs don't just run off a ISA, they also run off an API. What is the software technology that would best run in combination? Virtual machine technology. My gut feeling is that someone will build a PC with the ability to boot virtual Windows sessions where the programs there think they're on an x86 with all the requisite hardware while the rest of the computer is emulating some nicely streamlined ISA and you've got Java code running in some sandboxed virtual machine elsewhere on the system.
At this point you have support for legacy ISAs and legacy APIs in a nice simple format. As computer architectures die, they just end up virtualized and emulated/translated. And the computer is designed from the hardware through the operating system to seamlessly do it. In time everyone assumes they're on a virtual machine and the new operating system evolve to adapt to that environment.
No doubt such a setup will even allow for finetuning for things like emulating old Apple ][ systems as well as original IBM PCs running at 4.77 Mhz to get all those old games running just right. Or old Nintendo/Sega/whatever boxes. All those emulation setups get ported to the virtual machine setup and the appropriate ISA and you've really got emulation there.
Companies will like it because they can ditch old unsupported hardware but keep the software around forever. Especially companies with several brands of hardware/software that they can suddenly run under a single brand of hardware.
This is Microsoft's worst nightmare because all of a sudden switching to a new operating system does not preclude dropping old software. It can be done seamlessly and as gradually as people want. To Apple, it is also a bad nightmare, especially if other people work out Mac virutal machines on other hardware.
To Intel, they're already taking a bruising from the other CPU manufacturers. Intel will take to the translating setup with a vengence, but instead of going in the direction of power consumption (or alongside it) they're going to focus on performance, the niche they've always gone into. And their rivals will go and do the same.
To the PC vendors like Dell and Compaq (but not as I said, Apple) its something to be welcomed. They're already in the trenches competing against other machines that run all of the same software anyway. Anything that allows them to expand their range of software to run, the range of operating systems seamlessly is fine by them.
To operating system vendors (except for Microsoft and to a lesser extent Apple) it will be a major blessing. All of a sudden experimenting with a new operating system becomes easier and switching to it becomes useful. Niche operating systems can thrive being used for specialized applications on an existing machine.
Things like OpenBSD can suddenly start becoming really popular doing things like being the virtual machine that's the only one designated to see the DSL connection to the outside world while the Windows and Sega Genesis virtual machines are there for playing old games and the Linux or FreeBSD virtual machines are used for getting work done.
This is the direction I think the PC will be evolving in to compete with the small and specialized Internet appliances. They are going to take their strength, flexibility and go more so in that direction. The CPUs will become more flexible and the operating systems will capitalize on that and take virtual machines to the next level.
Berlin is not a replacement to GTK/Qt or to GNOME/KDE or to any of the window managers that run on top of any of the previous. It is a replacement for X, an attempt to redo what X did, only more intelligently, with a knowledge of the limitations of X and taking into account the developments of the computer industry and for that matter the new needs of the computer industry.
X is powerful but there are several areas where it cannot be revised and extended without breaking all the other applications which currently depend on X. Sooner or later you need to throw out the old software and do a clean start.
The real significant developments in Berlin are the fact that it uses CORBA for brokering the API, a well thought out approach to client/server distribution of resources over the network and the support of resolution independent graphics as well as other features of modern graphics hardware.
Why not use X? Because X was designed in a far more different era than the one we have now. It is better to have a system that is optimized for modern computing uses and has room for growth.
Why would anyone switch from X? As has been commented over on the Berlin site, one can create an XLib compatibility layer, and between that and ports of GTK and Qt, which are designed to be insulating layers between programs that use a GUI and the underlying graphics API, running existing software on Berlin shouldn't be that difficult. Modular software design in the Unix world has its overhead but there are advantages to it.
Unix needs to evolve with the times. Yes, there is power in continuity and well-hammered tools that have survived the test of time, but that should not be a barrier to progress. That includes things that are technically separate from Unix but closely associated with it, such as X. Apple keeps pushing the standard for graphics forward and OS X has raised the bar for graphics technology. The Berlin people have a moving target to hit.
People may wonder at the hype of a 0.2 release, but the fact is that Berlin is slowly starting to move from the 'interesting toy' level to something more along the lines of a serious prototype for a new windowing system. Hopefully it will start reaching the point where it attracts more developers interested in a cool windowing system.
The second step is the XLib and GTK/Qt porting support, at which point the number of applications that can run on Berlin shoots up dramatically.
The real goal is to get software driver support for Berlin on the order of support for XFree86. That is going to be a pain in the neck unless someone can figure out a brilliant way to get device drivers for X to be used by Berlin. Those systems with open source drivers will probably have drivers written by motivated developers.
I'd like to see a real competition for developer mindshare between Berlin and XFree86 on the order of GTK/Qt or GNOME/KDE. Competition can only benefit the consumer.
Personally I prefer something with the size of the Palm. I like something I can shove in a shirt pocket or pants pocket. With a device like that, I think you're best off building to a form factor and shoving everything you can into it. A webpad doesn't have that easy ability to be carried around with me at all times. Given what I'm sacrificing in functionality, that is the only thing the PDA really has going for it.
What I don't like about my Palm V is the lack of color, lack of memory, lack of CPU, lack of small removable storage. And better sound capability. I want to be able to toss out my portable MP3 player and just swap memory sticks in and out of my PDA with a good set of earphones. And to be able to plug in a small game controller and play stuff on it as well. There goes the Gameboy. Heck, even small movies on that screen if the removable storage has the space.
A webpad just doesn't do that for me. A webpad might work strictly as a specialized input device that I used strictly to enter data now and then and to dump immediately into a computer or into my PDA. But I wouldn't keep anything standing on it. Or with wireless capability as a remote terminal, which again puts it more in the data input category and ability to view remote data. Or if they used the size to have a DVD-ROM drive built into the thing, which is about the only thing that might justify the form factor. Even then I might just break down and go to a laptop.
A webpad strikes me as one of those nasty compromises that gives you the worst of two worlds. Not as large and comfortable and powerful as a laptop and not as conveniently portable as a PDA. As others have noted, this is where the Newton died. Ergonomics are critical for a device like this, and webpads just don't do it for me there.
I agree that GNOME should not be trying to emulate Windows 95. It should be trying to pull the best of Windows 95 and the Macintosh. Right now I'd say that GTK people need to start looking at Quartz (the new graphics engine in OS X) and start looking at trying to implement that functionality.
Emulation isn't a strike against GNOME or KDE. The Start Button isn't anything new. Look at the Apple menu. And Windows 95 was emulating the Macintosh, which was emulating the Xerox Star (I can't remember if anything came before that). I don't think that emulation is necessarily evil. And by the nature of Open Source, it is in some ways more difficult to emulate. A lot of what drives Open Source development is people seeing a feature on some other system and clamouring to use it on Linux (or BSD or whatever).
Still, as long as KDE and GNOME have enough modularity and flex built into them, people can experiment with stuff on top of them. The whole window manager issue is no doubt going to go through a lot of evolution over time, at least on the GNOME front. I don't think Sawmill is going to keep its position without a bloody fight.
KDE and GNOME are playing catch up to Windows and the Macintosh. Maybe to some extent they'll always be playing catch up (at least to Apple, which likes to innovate and push ahead). But maybe someday someone is going to look at some experimental setup out of some university doing work on innovative new user interfaces and decide they want that on their box (or that university may GPL the source code) and Linux GUI's will shoot ahead.
The thing that GNU/Linux can learn is a cleaned up and unified configuration system. To my mind the area where GNU/Linux really needs to clean things up is over in /etc (and maybe /dev and /var and a few of the other utilitarian filesystems). Create a unified, consistant and extendable XML setup for system, application and user configuration files.
/etc (as well as pulling in configuration files from elsewhere and giving them structure) is there to make things consistant. If anything it will be easier for those writing administration scripts to work if said configuration files are standardized and organized. Quite the opposite.
The main advantage here is that it allows for the creation of universal configuration tools that don't have to be recoded every time a new application comes out. Just plop in a new XML file (and possibly a DTD) and all of a sudden you've got a whole new application to manipulate easily. Not to mention developers have a nice little API for creating and managing configurations that allows system defaults and user overrides of said defaults transparently.
Little things like file bundles should be included in this restructuring as well. There are some nice nifty little bits in Mac OS/X. Apple really cleaned up some of the nastier bits of Unix when they tossed out historical precedents. Not that I totally agree with all of their decisions, but a lot of Unix simply evolved rather than was desgined coherently. It's time those parts were cleaned up. A lot of the usability issues with Unix are going to be stalled until they are.
Note that this does not mean babyfying Linux in any way. The thing with file bundles is you can open them up if you want granularity. Going to XML for all the configuration files in
I'm using GNU/Linux here because some things are handled at the kernel level but a large chunk of it is in the GNU tools that are traditionally bundled with Linux. Both need some modification here to come up with a coherent and unified system.
Migration is going to be a nightmare (remember glibc?) however once migration is done things can really start to move forward in terms of usability. The GNOME/KDE people would love to be able to set up pretty GUI-based configuration tools to manage everything, and the Perl/Python people would be in heaven because they could write real libraries to manipulate those things (not to mention all the people who use those libraries).
Backwards compatibility is all fine and well, but we all know of how backwards compatibility can drag back progress in the computing world. This is one of those cases where things have reached the point that areas need to be scrapped and rebuilt in the name of future progress.
What we are seeing right now is the reverse of the Unix Wars, the big bang running in reverse. Where Unix splintered into countless variants, there is now a trend backwards towards consolidation in Linux. And IBM has very good reasons to start folding their AIX functionality into Linux (disclaimer: I have no knowledge of IBM's real motivations here, this is just guesswork).
IBM doesn't just have operating systems, they have a lot of software that runs on top of the operating system, in the area of Unix this means AIX. Linux has a lot more forward momentum than AIX does, or is likely to ever have. The more AIX functionality that Linux has, the easier it will be to port their server software onto Linux.
Why did they port JFS to Linux? Probably because SGI had upped the ante by dumping their journalling file system onto Linux. That means that if IBM wanted to retain the advantage of their experience with JFS, they would have to make sure their journalling file system caught on and became the dominant standard.
While Linux will have several journalling file systems supported under it, in the end support will probably dwindle to all but two, which most likely will have different reasons for surviving (speed versus reliability optimization would be a likely scenario). IBM wants to be sure that JFS is one of them. Likewise other extra bits of functionality that different proprietary Unixes have are going to battle it out for the defacto standard. IBM will probably start trundling out those other pieces in competition.
That is a point to counter the fork-FUDders. The fact is that branches can die. Happens all the time in evolutionary biology. Same in the computer industry. One might point out that word processing effectively splintered among dozens of different incompatble programs, and sort of consolidated in the end around Microsoft Word.
Yes, Linux can fork but what is going to keep both forks going forward? There needs to be drive and encouragement to sustain both (or more than two) prongs. In the *BSD camp, that happened because they fill different niches. OpenBSD says that they're going to be secure and that's that, anyone who doesn't like the limitations can go use some other *BSD variant.
So the Linux wars are going to be the opposite of the Unix wars, where everyone throws in their features and tries to get theirs to become the dominant functionality inside of Linux. And IBM has a lot of reason to want to win those wars.
Apple once again lurches into the forefront in key technical areas even if their user interface standards are slipping. Reading this article really makes me wish that Tog was still back at Apple. What he could do with the power of Quartz and all the things he could fix in the Aqua interface make me sigh with regret. I'm also regretful that Apple went with BSD instead of going over and contributing to the Linux movement, but I can understand their reasoning.
/System layout, at least the concept of it. Linux really needs to sit down and think out a new directory structure from scratch to organize all the files that are needed to run the operating system, along with a few elegantly constructed libraries and tools for manipulating those files.
/System and over the course of various X.9.Y releases, move various system resources over to it.
/usr, /etc and other filesystems in place. /System would be where the operating system really lived and things like /etc/hosts could be created by special utilities from the XML files that contain host information. But the idea there is that would only be for legacy application support and developers would be encouraged to port to the new /System layout.
/System, XML resource files, bundling and Quartz, Linux has plenty of ideas to copy and improve on through the open source movement.
Even so, this setup makes it quite clear that there is a lot that can be done in future releases of Linux. The main parts that strictly concern the Linux kernel involve Apple's cleanup of the system directory structure, it's reorganization of resources and the use of XML heavily for configuration files.
The main problem with Linux for the masses is that managing system resources on a Linux system is nontrivial and really requires a trained system administrator. There are configuration tools that try to simplify it, but the lack of a standard configuration file format really cripples the effectiveness of these utilities. Also, the Linux filesystem really grew without systematic organization over various releases of Unix, rather than being planned out as a coherent and unified set of data files and a parser.
The thing I really like most about OS X is the whole
Such a porting sounds hideous but it can in fact be done in stages. A developer's release, probably Linux X.9 because the final result will be radical enough to warrant an point zero release, could create a filesystem like
Backwards compatibility can be maintained by leaving the old
Bundles are an elegant compromise between the necessity of having a bunch of files together to run a single application while at the same time giving a convenient single box to be handled from outside. Average users will use the box as a whole, advanced users can open it up and play with the contents. This is another feature that Linux needs to come up with some equivalent for, if it is to succeed on the desktop.
Quartz is less critical, though in the long run it will probably make life easier for developers. The fancy stuff there isn't strictly necessary, not yet, though as the range of displays increases, going to PDF and breaking the dependency on DPI and viewing distances will be necessary for the range of devices that Linux will run on.
Unix wasn't so much designed as it evolved, and parts of the system show that. Apple has done a major boon by showing what Unix can evolve into, giving the Linux developers a clear target to aim at for their course of future evolution. Between
Microsoft is a big corporation and they can afford to blow money working on projects that are more contingency plans that won't see the light of day. Office for Linux is merely an option, and managers are quite possibly seeing how difficult it is to do the port and how well it runs. Not to mention that it might be DOJ fodder.
Microsoft won't do an Office for Linux port until they are seeing steady erosion of the desktop market for Linux. I think Microsoft porting their server software to Linux is a far more likely scenario right now. If Windows 2000 continues to show lackluster performance, that possibility will keep going up. Especially if Linux somehow takes a higher percentage of the server market than Windows, and that could well be within a couple of years.
Of course that would effectively shoot themselves out of the server market, so they're not going to do that until they're ready to surrender. But that is a distinct possibility. Every generation of NT took more and more money to develop and forcing more and more gruesome licensing schemes to compensate and companies are starting to get into this idea of Linux in their servers. Even the popular press says that Linux is great as a server solution, even magazines that get lots of Microsoft funding.
Something to remember is that Microsoft has killed a lot of projects in the past. Bob is the most infamous example but there are other Microsoft projects that also have died. If a piece of software doesn't justify the investment, it dies. If Windows 200X projected sales doesn't make up for the investment in resources, then they'll look for a way to cut their losses. Customers who leave Windows 2000 for Linux are not likely to come back for Windows 200X and the licensing schemes that will be needed to make a profit off of that.
A more sane approach for Microsoft in that scenario is to conceed the server market and port their server software to it, their Active Directory solution et al. Lets Microsoft hop on the Linux bandwagon and take advantage of all the hype. They might try to take over the Linux standard, but I don't think they're going to manage it. There are too many other Linux vendors and if Microsoft comes up with their own standard, everyone will go off and make up their own. Remember MCA versus EISA?
Microsoft will hang onto the client side a lot longer. When that area starts eroding seriously, once again when it is no longer profitable for them to keep producing a new version of Windows, they'll hop on the Linux bandwagon for the desktop and produce a Office for Linux as well as porting all their other desktop application software. But that's four to five years away.
Around that time they'll start producing their own version of WINE for Linux with their claims of full Win32 comptability and make revenues off of legacy applications.
That assumes Microsoft as a single company. If applications and operating systems are broken up, all bets are off. That could be a very likely reason there's a project to do the port now. No one knows how its going to end up and the applications people don't want to be caught with their pants down when they are forced to compete on their own.
But that is just worst case planning here. I think we'll see Microsoft SAMBA long before we see Office for Linux.
Consoles work on the principle of standardized hardware running a single application. When one has standardized hardware and an application that has the whole system to itself, there is far less of a need for an operating system. Therefore, Microsoft, an operating system company, putting out a console is working out an exercise in futility here. Sure, it may be easier to port Windows apps, but console software developers are used to doing things like going from one console to another anyway.
Microsoft might win developers over only on the greater freedom to port software over to the system and low to possibly non-existant licensing fees (if they haven't gone this route, they are doomed). Conventional consoles require manufacturer approval for a licence to write software on that platform and get a certain amount of money per game sold. Consoles work on the give away the razor, sell the blades theory of economics.
Eventually there will be a console based on the PC economic model that might take off. If it runs an operating system, it will be probably Linux, due to the zero cost of the operating system (and in the console market, every dollar you shave off the price helps). Either that or there's going to be some lawsuit that opens up software development on conventional platforms and the console economic model is broken anyway.
But Microsoft trying to get into the console market is going to be a great bomb, I predict.
There are times when Open Source makes a lot of sense or is practically essential. There are other cases where it is more incidental.
Some might argue that the Crusoe morphing software is analogous to the situation with device drivers. Given that the morphing software is linked to the CPU itself, and the software is devoted to emulating an instruction set, below the level of API compatibility that operating systems worry about, the device driver argument isn't really valid.
The only other strong cases for open source are for reliability and security. As long as the code works reliably, that isn't an issue. Security isn't an issue for CPU firmware. Perhaps performance might be improved, but there's no assurance from that and there are reasons that Transmeta is avoiding releasing the code.
The benefits from opening up the code morphing software are extremely limited and the potential disadvantages given that there is a lot of investment made in the intellectual property, are much greater. That is a case where close source software is quite valid in my opinion. People doing things like voice recognition with natural language parsing and other cutting edge technologies to me can justify releasing the core elements in a close source form.
Linus is not a hypocrite for working on a closed source project. He's merely more reasonable than some people who would insist on forcing round pegs into square holes.
Not to beat the computers vs automobiles down, but this does in some way feel like back when the Japanese automobile manufacturers started taking on Detroit, with its low powered but cheap and fuel efficient cars those high powered gas guzzling models. And Detroit learned in the end people didn't need to be able to do 200 mph so much as they wanted 30 mpg.
The laptop market is going to go in the same direction. People don't use laptops, excuse me, most people don't use laptops to run Quake and other games at ridiculously high fps. In a laptop, having good enough performance and a long battery life are more than sufficient. They may be slower but the question is will most people really miss the performance. If one does not run graphics-heavy games (and Microsoft operating systems and applications), how much CPU power does one need?
The Transmeta people had some good ideas. Pity that it's the x86 instruction set they're stuck with, though it will be interesting to see how good a Java virtual machine they might get out of it. For some reason I like the idea of a standardized instruction set and then forcing the chips to run that everywhere very appealing.
As for Intel, I think they're going to have to eventually learn that they can't be all things to all people. Microsoft is starting to slowly come to that conclusion as well. Sooner or later you have to pick a market segment and hope that it stabilizes. Trying to go against AMD and Transmeta just seems a bit much for one company to do.