I don't know about the Los Alamos cluster referenced, but the Big Mac cluster went all out on Inifiniband interconnect, inferring a potentially extremely better network interconnecting the cluster.
Only beta software? SuSE and Redhat both have official, supported releases for Opteron. Others probably do as well that can be considered better than beta quality, but even sticking strictly to supported platforms you don't need to go beta.
Other than that, I didn't really take time to comprehend most of that post. I think OSX is an excellent OS, but have found Apple hardware poor in both performance and reliability and customer service to be about as hostile as I've had experience dealing with. I've sworn off Apple, as much as I would like to applaud the software developers for OSX, the hardware and service has been unbearable. Even Compaq has historically provided me better support than Apple, and I'm not crazy about their support either. Apple was more interested in treating me like dirt for calling them on a warranty repair.
Is that drivers are *still* a huge deal, but for different reasons. Given equal hardware, well-written drivers that work only with that hardware, doing things in the best possible way with the hardware in mind can make worlds of difference. On top of that, companies often enter restrictive license agreements with other companies to get more optimized code into their drivers, so even if the company was willing to compromise the effort they put into the driver for the good of the linux community, the license agreements prevent them.
Of course, all this seems to sidestep your issue, hardware specs, which in theory hold no secrets (interface shouldn't reveal much about implementation), could be released without giving out the critical secrets which make their drivers so good. In this respect, I would say first that theory does not hold, the interface to the hardware functionality can give extremly enlightening insight into implementation details. Seeing how the data is expected to be passed into the hardware gives a good idea as to the hardware designer's strategy in their implementation. Even assuming the interface itself meets these theoretical requirements, there likely exists no interface specification without extensive comments and notes that do reveal secrets, and cleaning up a spec would take time and money.
Finally, even if all the moons were aligned for a spec release to allow the community to develop a driver around it, it still may not be desirable to the company, for it dilutes the image of their hardware. For example, take the current nVidia situation. The open source driver only has 2D support, so no one gives it a second thought in terms of evaluation. Now imagine nVidia releases spec and the open source nVidia driver takes those specs along with the work for the current ATI offering and implements a driver that would be extremely similar to the ATI software wise. Then presume that the nVidia offering with this driver looks much much poorer than the ATI offering. Reviewers would pounce on this driver to show the hardware on a 'level playing field' to compare the *hardware* independent of software. If the magic of a piece of hardware consists mainly in the free software piece rather than the card, it feels less valuable. On top of that, some hardcore OSS purist reviewers would ignore nVidia drivers now that there was an alternative, degrading nVidia benchmark performance. In addition, if there is a large discrepency between the open source and the binary-only driver, there would be a lot of suspicion cast on the 'optimizations' of the binary driver. What shortcuts must they be taking to perform so well? In your terms, we no longer value simple compatibility, we look at features with the expectation that a hardware company implements them all in *hardware*, and if that is not true, it is worth something to keep the public from knowing.
Ultimately, I wish things were as simple as you say, and I favor open source drivers when available. The reality is that between complex business relations, desire to keep funded driver developer secrets from the hands of competitors, and what the public could do with a more acceptable alternative, the reality is that binary drivers are still much more preferable to hardware vendors.
You may want to clarify that you want to get rid of the Open Sound System OSS, not Open Source Software OSS;) I am pretty certain that 2.6 won't be the death of the latter OSS.
How ready is it? Is there a site that breaks down which hardware drivers support/do not support the sleep states? I remember during the test releases it was documented that many drivers had not yet been updated to support the sleep states.
APM support has gotten me so far, but some things on this laptop would be more doable if I had acpi support, and I have another laptop which doesn't support apm at all.
I've been working with an Opteron platform as well and I've seen several issues when the memory gets above 4GB. A lot of it has to do with them recycling the 32-bit code used for BIOS operations before that breaks under those conditions. In our case, the problems are mostly solved. We have seen a couple of dirvers, however, that had issues (some really picky portions that really relied on addresses being 32 bit values). The 32-bit capability is a double-edged sword, gives greater compatiblity, but someimtes companies take shortcuts with what they have since it at least gives the initial impression of working, when the reality is that the shortcuts break things in some obscure ways.
As Itanium is ia64, an entirely different instruction set. That statement is akin to saying code compiled for Sparc runs better on Pentium processors..
I actually think this is a more correct behavior. In the event of an unclean shutdown, the filesystem is dirty and refuses to mount rw, and only mounts ro. When you mount ro, under ext3, xfs, and reiserfs, it seems that all of them replay journal data. Note that intuitively this seems wrong, you are mounting a partition read-only, it is reasonable to expect that bytes on the disk will not be touched. Replaying the journal log on read-only mounts is incorrect behavior from this look.
Mounting rw, while it is unreasonable to expect no modifiactions to happen at that point, it seems odd that the mere action of mounting an fs results in significant changes to the data on disk. JFS implementation of putting the responsibility of journal replay into fsck seems reasonable. And I have not noticed any performance issues with that journal replay versus XFS (which, in my experience on a 360 GB volume, takes forever to complete Journal replay, and it feels more painful because it occurs after a mount and provides no visual feedback as to how things are going, if there are problems and such. I always assume the journal is being replayed, but it could be the case that IO errors are happening, etc.) This strategy allows first the kernel driver not to be bloated by FS consistency restoration code that will only rarely be used on unclean mounts at mount time, and allows a more robust implementation be implemented in fsck. Feedback on replay progress, and in instances where Journal is corrupt, smoothly transitions to a full FS check, and in XFS when the Journal replay fails, it gets real messy real fast.
On the other hand, JFS has annoyed be significantly in that the Journalling frequently fails to protect against having an invalid FS structure. I frequently have to drop into a forced full fsck for the FS to realize that a FS entry is corrupt. My lost+found directory is filled with all kinds of stuff I have yet to identify. XFS has performed well in terms of consistant FS structure, but has lost data for me.
Reiser, btw, was way too much of a pain in the ass. Tried, and on failure, sometimes things would break to the point of a --rebuild-tree, which is only allowed on a completely unmounted volume, which means a simple task like fsck your root volume requires a rescue disk boot.
Ext3 has been slow to me, but pretty reliable. I use mainly JFS and Ext3 now, but the apparent issues with Journalling not adequately protecting FS consistency are making me want to simply go Ext3 all the way.
I would dare say that Python is *extraordinarily* easy to get up and running, more so than Java. You can do extremely powerful things and very easy things with Python. And if you want clean cross-platform development environment, it fits well, even with GUI if you accept wxPython. I've been blown away at the ease of things when I did PyGTK, and when I wanted something that looked less out of place in Windows and that would work on OSX, I picked up wxPython and was simply amazed at how cleanly it slipped into Windows and OSX, with native widgets and all.
I know Java, and it truly does provide a far richer development environment when compared to C/C++ (well, C/C++ nearly catches up if you allow for MFC/KDE/Gnome/Cocoa/host of other libraries, but those are all platform dependent), but the syntax isn't that much easier to handle, so it isn't a good VB-killer candidate. Python syntax is extremely simple and scales well for complex tasks. I don't want to inflame perl advocates, perl is more powerful and easy for many tasks, but the syntax of python caters well to readability for learning and for the average programming tasks.
Ok, I know of some closed source SCSI controller modules. The issue here is, to interact with the SCSI subsystem, a lot of things have to happen, including a '#include ' statement. That means any binary only SCSI module contains the scsi_module.c file contents compiled into the binary. Whatever the nature of other bits of code and include, clearly the implementaition of scsi_module.c is contained, and that c file is GPL.
With this in mind, is it true that all companies shipping binary-only SCSI modules are in violation of the GPL? One prominent example is Adaptec's 1210SA SATA card, which implements itself as a SCSI driver on the Adaptec website. It annoys me because to use the card, I have to stick to their compiled binaries, which doesn't have anything newer than RH8.0, or SuSE 8.1, and certainly is far removed from Gentoo, my distro of choice, but annoyance aside, is Adaptec violating the GPL? I wanted to use the siimage driver, but it simply wouldn't work for me with that particular card (found out after buying it).
Not always true, for example, I bought a while back a XP 1700+. I may be getting confused, but I think that was the Palomino core. Well, in any event, user error ended up frying the processor about a year later. I bought a really cheap XP1800+ at the time, plugged it in and..... had to get a new motherboard that supported the Thoroughbred core, wouldn't post in my MB and it was a known issue, and manufacturer said the circuitry on the MB was physically incapable of handling the changes, and that no BIOS fix would do it. They may keep the packaging the same, but beware that core changes are not always transparent to the motherboard, or simply require a BIOS update.
But, again, how is *this* move 'shooting themselves in the foot'? I can see an argument for shooting everyone *else* in the foot, but MS has nothing at all to lose from *this* one move. Now if they start pounding on Open Source implementations causing platforms to drop support for reading FAT filesystems, then I could see a potential for self-foot-shooting, as open platforms drop support, some current dual booters may ultimately drop MS OS that they had previously used out of laziness when the pain of data sharing between platforms becomes incredibly great. But until that move in the strategy is announced, you can't claim they are making a stupid move.
I don't see how this is shooting themselves in the foot. Right now: -Media comes preformatted FAT, and software is written to manipulate FAT. MS gets no money. Any platform is equally capable of manipulating FAT, so MS doesn't even enjoy a platform advantage for this media. They get absolutely nothing.
Future with this policy: -Most media will stay preformatted FAT, software stay the same, and MS collects money. -Some high volume companies will decide they can beat the 250k price point by moving to something like ext3 or jfs or something proprietary. If they use any existing FS technology, the companies will port that FS to Windows if not already there, because Windows is essentially a requirement for mass-market media. Other option is they will invent a proprietary filesystem and likely only write software for it under MS Windows and *maybe* OSX, which will give MS a boost in supported hardware under Windows. So MS either gets money, gets more filesystem support for free, or gets hardware that works better with Windows than other platforms, hardly shooting themselves in the foot.
How bout categroy c, which this guy belongs to, working for a company, just not driving to it. Some people in the marketing group where I work have this setup, and it works well, it is just a job and they don't have to leave the house.
Actually, though it may seem bad, it doesn't say that much about dissatisfaction. That 10% of non-renewed subscriptions represents dissatisfied customers and customers that will stick to their current release level of RHEL and don't see a support need that warrants a renewal. I would daresay at least 10% of those customers could represent those with a really strong internal IT dept that has never called Redhat for anything and therefore the chances are low that they will do it again. And the chance they would want to risk a migration within a year of their entire infrastructure is low. Of those 10%, I would wager a good chunk will return in a couple of years when they feel the need to upgrade.
Exactly why I think SuSE has a great window of opportunity, their 'Professional Linux' distribution is still reasonably priced for the support offered. And frankly, once one looks past previous RedHat training experience, a lot will realize that SuSE does quite a few things better.
Well, for one support. For another, Fedora is becoming their development platform with little regard to having to support or promise stability. So while bugfixes will be applied to the distro, you can bet an equal amount of broken feature enhancements will come in to offset stability benefits. Like running Debian unstable, essentially, but likely to be more bleeding edge and off the beaten path (i.e. the X based init, the kernel with nptl support, and a host of other things that are neat, but not well tested in Fedora).
So if you want to stay redhat-ish, on your servers and workstations for other people you support, RH enterprise is cool, but for your own desktop if competent, I would say the Fedora 'releases' are neat and any breakage can be worked around by an expert.
Of course, I think SuSE has the most appropriate business/pricing model in terms of being competitive against MS. SuSE professional is reasonably priced compared against what the actual cost of an MS OS license is for a workstation, whereas Redhat is really really expensive in the Workstation context. I'm quickly becoming a SuSE fan.
What a *huge* waste of resources. It is *easy* for a single channel to offer this stuff.
Use SAP to allow selection of your audio language (typically done in shows to offer alternative spanish sound in the US), and use closed captioning for subtitles.
I know, closed captioning is ugly, but no company is going to piss away the resources to allocate two channels for what is an admittedly niche group in general. Dub anime is more widespread, and making the push for Closed Captioning/SAP delivery of subtitle format is a far easier sale. Besides, it is more flexible for those who want Japanese without subs.
Number one, they already have docking stations, if you don't mind having a separate Keyboard, Mouse, and display (etc). Put it in, good to go. And for the few with Bluetooth enabled laptops, they have bluetooth mice and keyboards, in which case you just plug power and a monitor in and it is good to go.
Second, when you start talking about a system where the keyboard and display fold out to more friendly desktop dimensions, I think I remember seeing a Thinkpad prototype at some point that did just that, the keyboard came out and down, and the screen could be elevated to an appropriate height. I thought the whole thing silly, but I guess some people are interested. I prefer docking station where you have a nicer display and a less compromising keyboard.
While not the whole projects (they have no place in the Xserver), it would be nice to have more sophisticated primitives in the Xserver (i.e. a 'button' primitive, compressed canvas formats, and it's ilk), so that a) whatever the toolkit, they end up using the same rendering engine and style on an Xserver with that extension b) more sophisticated applications operate much smoother over the network. RDP, for example, exposes more useful primitives and really really flies as a result. The architecture isn't as flexible as X, but the performance really gives X a black eye... This could turn the tide in X's favor, if anyone stepped up to the bat that is... If only I had more free time..
Slashdot Mirror
I don't know about the Los Alamos cluster referenced, but the Big Mac cluster went all out on Inifiniband interconnect, inferring a potentially extremely better network interconnecting the cluster.
Only beta software? SuSE and Redhat both have official, supported releases for Opteron. Others probably do as well that can be considered better than beta quality, but even sticking strictly to supported platforms you don't need to go beta.
Other than that, I didn't really take time to comprehend most of that post. I think OSX is an excellent OS, but have found Apple hardware poor in both performance and reliability and customer service to be about as hostile as I've had experience dealing with. I've sworn off Apple, as much as I would like to applaud the software developers for OSX, the hardware and service has been unbearable. Even Compaq has historically provided me better support than Apple, and I'm not crazy about their support either. Apple was more interested in treating me like dirt for calling them on a warranty repair.
Xenogears uses the Star Trek computer beep sounds in the intro movie.
An El Hazard alternative world episode used the sound of a terran transport unload at some point...
offers some good competition here.... during his infamous 'monkey boy' performance.
Is that drivers are *still* a huge deal, but for different reasons. Given equal hardware, well-written drivers that work only with that hardware, doing things in the best possible way with the hardware in mind can make worlds of difference. On top of that, companies often enter restrictive license agreements with other companies to get more optimized code into their drivers, so even if the company was willing to compromise the effort they put into the driver for the good of the linux community, the license agreements prevent them.
Of course, all this seems to sidestep your issue, hardware specs, which in theory hold no secrets (interface shouldn't reveal much about implementation), could be released without giving out the critical secrets which make their drivers so good. In this respect, I would say first that theory does not hold, the interface to the hardware functionality can give extremly enlightening insight into implementation details. Seeing how the data is expected to be passed into the hardware gives a good idea as to the hardware designer's strategy in their implementation. Even assuming the interface itself meets these theoretical requirements, there likely exists no interface specification without extensive comments and notes that do reveal secrets, and cleaning up a spec would take time and money.
Finally, even if all the moons were aligned for a spec release to allow the community to develop a driver around it, it still may not be desirable to the company, for it dilutes the image of their hardware. For example, take the current nVidia situation. The open source driver only has 2D support, so no one gives it a second thought in terms of evaluation. Now imagine nVidia releases spec and the open source nVidia driver takes those specs along with the work for the current ATI offering and implements a driver that would be extremely similar to the ATI software wise. Then presume that the nVidia offering with this driver looks much much poorer than the ATI offering. Reviewers would pounce on this driver to show the hardware on a 'level playing field' to compare the *hardware* independent of software. If the magic of a piece of hardware consists mainly in the free software piece rather than the card, it feels less valuable. On top of that, some hardcore OSS purist reviewers would ignore nVidia drivers now that there was an alternative, degrading nVidia benchmark performance. In addition, if there is a large discrepency between the open source and the binary-only driver, there would be a lot of suspicion cast on the 'optimizations' of the binary driver. What shortcuts must they be taking to perform so well? In your terms, we no longer value simple compatibility, we look at features with the expectation that a hardware company implements them all in *hardware*, and if that is not true, it is worth something to keep the public from knowing.
Ultimately, I wish things were as simple as you say, and I favor open source drivers when available. The reality is that between complex business relations, desire to keep funded driver developer secrets from the hands of competitors, and what the public could do with a more acceptable alternative, the reality is that binary drivers are still much more preferable to hardware vendors.
You may want to clarify that you want to get rid of the Open Sound System OSS, not Open Source Software OSS ;) I am pretty certain that 2.6 won't be the death of the latter OSS.
How ready is it? Is there a site that breaks down which hardware drivers support/do not support the sleep states? I remember during the test releases it was documented that many drivers had not yet been updated to support the sleep states.
APM support has gotten me so far, but some things on this laptop would be more doable if I had acpi support, and I have another laptop which doesn't support apm at all.
I've been working with an Opteron platform as well and I've seen several issues when the memory gets above 4GB. A lot of it has to do with them recycling the 32-bit code used for BIOS operations before that breaks under those conditions. In our case, the problems are mostly solved. We have seen a couple of dirvers, however, that had issues (some really picky portions that really relied on addresses being 32 bit values). The 32-bit capability is a double-edged sword, gives greater compatiblity, but someimtes companies take shortcuts with what they have since it at least gives the initial impression of working, when the reality is that the shortcuts break things in some obscure ways.
As Itanium is ia64, an entirely different instruction set. That statement is akin to saying code compiled for Sparc runs better on Pentium processors..
HAH! you were wrong.... that was not distant at all! It was duped in the past before you even posted your comment, so there!
I actually think this is a more correct behavior. In the event of an unclean shutdown, the filesystem is dirty and refuses to mount rw, and only mounts ro. When you mount ro, under ext3, xfs, and reiserfs, it seems that all of them replay journal data. Note that intuitively this seems wrong, you are mounting a partition read-only, it is reasonable to expect that bytes on the disk will not be touched. Replaying the journal log on read-only mounts is incorrect behavior from this look.
Mounting rw, while it is unreasonable to expect no modifiactions to happen at that point, it seems odd that the mere action of mounting an fs results in significant changes to the data on disk. JFS implementation of putting the responsibility of journal replay into fsck seems reasonable. And I have not noticed any performance issues with that journal replay versus XFS (which, in my experience on a 360 GB volume, takes forever to complete Journal replay, and it feels more painful because it occurs after a mount and provides no visual feedback as to how things are going, if there are problems and such. I always assume the journal is being replayed, but it could be the case that IO errors are happening, etc.) This strategy allows first the kernel driver not to be bloated by FS consistency restoration code that will only rarely be used on unclean mounts at mount time, and allows a more robust implementation be implemented in fsck. Feedback on replay progress, and in instances where Journal is corrupt, smoothly transitions to a full FS check, and in XFS when the Journal replay fails, it gets real messy real fast.
On the other hand, JFS has annoyed be significantly in that the Journalling frequently fails to protect against having an invalid FS structure. I frequently have to drop into a forced full fsck for the FS to realize that a FS entry is corrupt. My lost+found directory is filled with all kinds of stuff I have yet to identify. XFS has performed well in terms of consistant FS structure, but has lost data for me.
Reiser, btw, was way too much of a pain in the ass. Tried, and on failure, sometimes things would break to the point of a --rebuild-tree, which is only allowed on a completely unmounted volume, which means a simple task like fsck your root volume requires a rescue disk boot.
Ext3 has been slow to me, but pretty reliable. I use mainly JFS and Ext3 now, but the apparent issues with Journalling not adequately protecting FS consistency are making me want to simply go Ext3 all the way.
I would dare say that Python is *extraordinarily* easy to get up and running, more so than Java. You can do extremely powerful things and very easy things with Python. And if you want clean cross-platform development environment, it fits well, even with GUI if you accept wxPython. I've been blown away at the ease of things when I did PyGTK, and when I wanted something that looked less out of place in Windows and that would work on OSX, I picked up wxPython and was simply amazed at how cleanly it slipped into Windows and OSX, with native widgets and all.
I know Java, and it truly does provide a far richer development environment when compared to C/C++ (well, C/C++ nearly catches up if you allow for MFC/KDE/Gnome/Cocoa/host of other libraries, but those are all platform dependent), but the syntax isn't that much easier to handle, so it isn't a good VB-killer candidate. Python syntax is extremely simple and scales well for complex tasks. I don't want to inflame perl advocates, perl is more powerful and easy for many tasks, but the syntax of python caters well to readability for learning and for the average programming tasks.
Ok, I know of some closed source SCSI controller modules. The issue here is, to interact with the SCSI subsystem, a lot of things have to happen, including a '#include ' statement. That means any binary only SCSI module contains the scsi_module.c file contents compiled into the binary. Whatever the nature of other bits of code and include, clearly the implementaition of scsi_module.c is contained, and that c file is GPL.
With this in mind, is it true that all companies shipping binary-only SCSI modules are in violation of the GPL? One prominent example is Adaptec's 1210SA SATA card, which implements itself as a SCSI driver on the Adaptec website. It annoys me because to use the card, I have to stick to their compiled binaries, which doesn't have anything newer than RH8.0, or SuSE 8.1, and certainly is far removed from Gentoo, my distro of choice, but annoyance aside, is Adaptec violating the GPL? I wanted to use the siimage driver, but it simply wouldn't work for me with that particular card (found out after buying it).
And I would be puzzled as the card would be one undefined color (I'm red-green colorblind geek you insensitive clod ;)
Not always true, for example, I bought a while back a XP 1700+. I may be getting confused, but I think that was the Palomino core. Well, in any event, user error ended up frying the processor about a year later. I bought a really cheap XP1800+ at the time, plugged it in and..... had to get a new motherboard that supported the Thoroughbred core, wouldn't post in my MB and it was a known issue, and manufacturer said the circuitry on the MB was physically incapable of handling the changes, and that no BIOS fix would do it. They may keep the packaging the same, but beware that core changes are not always transparent to the motherboard, or simply require a BIOS update.
But, again, how is *this* move 'shooting themselves in the foot'? I can see an argument for shooting everyone *else* in the foot, but MS has nothing at all to lose from *this* one move. Now if they start pounding on Open Source implementations causing platforms to drop support for reading FAT filesystems, then I could see a potential for self-foot-shooting, as open platforms drop support, some current dual booters may ultimately drop MS OS that they had previously used out of laziness when the pain of data sharing between platforms becomes incredibly great. But until that move in the strategy is announced, you can't claim they are making a stupid move.
I don't see how this is shooting themselves in the foot. Right now:
-Media comes preformatted FAT, and software is written to manipulate FAT. MS gets no money. Any platform is equally capable of manipulating FAT, so MS doesn't even enjoy a platform advantage for this media. They get absolutely nothing.
Future with this policy:
-Most media will stay preformatted FAT, software stay the same, and MS collects money.
-Some high volume companies will decide they can beat the 250k price point by moving to something like ext3 or jfs or something proprietary. If they use any existing FS technology, the companies will port that FS to Windows if not already there, because Windows is essentially a requirement for mass-market media. Other option is they will invent a proprietary filesystem and likely only write software for it under MS Windows and *maybe* OSX, which will give MS a boost in supported hardware under Windows. So MS either gets money, gets more filesystem support for free, or gets hardware that works better with Windows than other platforms, hardly shooting themselves in the foot.
No, a patent allows *just* that. You loose trademarks if you allow it to occur generically, patents can be abused this way just fine.
How bout categroy c, which this guy belongs to, working for a company, just not driving to it. Some people in the marketing group where I work have this setup, and it works well, it is just a job and they don't have to leave the house.
Actually, though it may seem bad, it doesn't say that much about dissatisfaction. That 10% of non-renewed subscriptions represents dissatisfied customers and customers that will stick to their current release level of RHEL and don't see a support need that warrants a renewal. I would daresay at least 10% of those customers could represent those with a really strong internal IT dept that has never called Redhat for anything and therefore the chances are low that they will do it again. And the chance they would want to risk a migration within a year of their entire infrastructure is low. Of those 10%, I would wager a good chunk will return in a couple of years when they feel the need to upgrade.
Exactly why I think SuSE has a great window of opportunity, their 'Professional Linux' distribution is still reasonably priced for the support offered. And frankly, once one looks past previous RedHat training experience, a lot will realize that SuSE does quite a few things better.
Well, for one support.
For another, Fedora is becoming their development platform with little regard to having to support or promise stability. So while bugfixes will be applied to the distro, you can bet an equal amount of broken feature enhancements will come in to offset stability benefits. Like running Debian unstable, essentially, but likely to be more bleeding edge and off the beaten path (i.e. the X based init, the kernel with nptl support, and a host of other things that are neat, but not well tested in Fedora).
So if you want to stay redhat-ish, on your servers and workstations for other people you support, RH enterprise is cool, but for your own desktop if competent, I would say the Fedora 'releases' are neat and any breakage can be worked around by an expert.
Of course, I think SuSE has the most appropriate business/pricing model in terms of being competitive against MS. SuSE professional is reasonably priced compared against what the actual cost of an MS OS license is for a workstation, whereas Redhat is really really expensive in the Workstation context. I'm quickly becoming a SuSE fan.
What a *huge* waste of resources.
It is *easy* for a single channel to offer this stuff.
Use SAP to allow selection of your audio language (typically done in shows to offer alternative spanish sound in the US), and use closed captioning for subtitles.
I know, closed captioning is ugly, but no company is going to piss away the resources to allocate two channels for what is an admittedly niche group in general. Dub anime is more widespread, and making the push for Closed Captioning/SAP delivery of subtitle format is a far easier sale. Besides, it is more flexible for those who want Japanese without subs.
Number one, they already have docking stations, if you don't mind having a separate Keyboard, Mouse, and display (etc). Put it in, good to go. And for the few with Bluetooth enabled laptops, they have bluetooth mice and keyboards, in which case you just plug power and a monitor in and it is good to go.
Second, when you start talking about a system where the keyboard and display fold out to more friendly desktop dimensions, I think I remember seeing a Thinkpad prototype at some point that did just that, the keyboard came out and down, and the screen could be elevated to an appropriate height. I thought the whole thing silly, but I guess some people are interested. I prefer docking station where you have a nicer display and a less compromising keyboard.
While not the whole projects (they have no place in the Xserver), it would be nice to have more sophisticated primitives in the Xserver (i.e. a 'button' primitive, compressed canvas formats, and it's ilk), so that
a) whatever the toolkit, they end up using the same rendering engine and style on an Xserver with that extension
b) more sophisticated applications operate much smoother over the network. RDP, for example, exposes more useful primitives and really really flies as a result. The architecture isn't as flexible as X, but the performance really gives X a black eye... This could turn the tide in X's favor, if anyone stepped up to the bat that is...
If only I had more free time..