This approach may be fine for you and I; we're all comfortable with:./configure; vi Makefile; make all; su # make install
Unfortunately, that isn't all that suitable for "naive lusers" who will react to this with a big Huh?!?
Rather than GNU Stow, I'd think the direction of BSD Ports would be suitable; that provides the merit of automating the process of setting up configuration info for lots of packages that hasn't yet been done with Stow. You may want to believe that
Dependencies could be added to Stow by someone without a lot of trouble.
I remain quite skeptical, as it has taken years for distributions like Red Hat, Slackware, and Debian to become richly functional.
Note that Ports, like Stow, uses nothing that anybody gets tangled into thinking is somehow "proprietary." (Not that RPM or DPKG actually use anything proprietary; it's mostly Slackware bigots, with emphasis on bigot, not on Slackware, that claim, dishonestly, that RPM/DPKG are somehow proprietary formats...)
But that misses the point.
Your proposal may be suitable for you and I, albeit marginally so, as I'd much rather that the administration of package installation for the 99% of packages where "default is fine" be dealt with by someone else; it is NOT, by any stretch of the imagination, suitable for making Linux deployable in other than highly UNIX literate environments.
Transmeta has been marketing to some very particular vendors, as opposed to "people off the street."
In particular, the fact that they've been working with IBM is pretty crucial. If they sell to IBM, and sell to Diamond, and sell to a few other OEMs, it is no problem to Transmeta that they aren't pushing product at your engineering buddies.
Transmeta will succeed or fail based on whatever product deployments come out over the next six months, and with product lead times being what they are, the engineers that will be working on those products probably are already working hard on them.
As much as I'd like to buy a Transmeta PC mobo/CPU combination, that's really not what they're trying to sell. They're aiming at things like laptops and portable devices, and there are likely a bunch of those in the design/implementation pipeline.
I had been wondering what jwz was going to do "after AOL."
I had half expected that he might do something like buying Harlequin, and "open sourcing" Liquid Common Lisp. (Which would have been rather interesting...) Or perhaps seeking to build a Lisp Machine environment to run atop Linux. Or perhaps something more quixotic like building such atop FreeBSD.
It's very interesting that he has instead proceeded to do "political system" hacking. I expect he'll get back to the computer variety at some point.
After all, he appears to be a significant participant here; any time major discussions of Motif or Mozilla come up, he's quite visible in the discussions!
I'm no "clubber," and I'm not entirely convinced he's after something that's unambiguously a good thing, but it's sort of nice to see some action oriented to a local community taking place.
I've written around 3MB of DocBook material, much of which used to be in qwertz form.
Why would this be a good thing? Because DocBook is vastly more expressive.
It supports diagrams and pictures, well.
It supports interlinking between document components, and does so very well.
It supports man page markup, so that one can combine man page documentation with tutorial material and other reference material, interlinking as needed.
It provides a vastly richer set of structural tags for providing logical markup.
Strewing fonts across pages, like chunky peanut butter across bread, does not lead to building decent documents.
It is, on the other hand, reasonably useful to have tags to indicate such things as a filename , application, command line, perhaps even differentiating between what you type in, what the system responds with, and what is a variable to be entered.
I've got a copy of the O'Reilly DocBook manual.
If Eric Raymond found it useless, then I daresay that says more about him than it does about the book.
I remember him doing some "bungee management" on the SGMLTools mailing list; he bounced in for a couple days, saying (essentially) that "It's really, really critical that you do these things that I think you need to do," and then bouncing on to whatever else it is that he does. He also spent a lot of time claiming that Trove was tremendously important, and we've not seen a useful release of that yet, after a goodly two years.
It could be well worthwhile to try to find some people amongst the much-maligned "religious right" that:
Are concerned about the freedom of speech issues
Which after all are a legitimate concern once you get past the stridency of "little Johnnie may see something inappropriate"
Know the "lingo" and how to meaningfully communicate with others in the "religious right."
After all, if what they say to you doesn't penetrate your head as being meaningful, the converse is likely to be true as well.
In a "debate"/"heated discussion" on censorship, I took issue with the comments of someone who was feeling particularly strident about protecting the world from "evil." I pointed out that a law based on his definitions would actually outlaw publishing the Bible.
He then headed off into "never-never land" indicating that he didn't care, and that if the Bible was outlawed, he'd feel religiously persecuted, and would break that law.
Unfortunately, I never got around to underlining the point that he was proposing to break law that he had proposed in the first place.
At any rate, the critical point is to bring the focus away from the technological tools that allow them to believe that there is some sort of And Now We See A Miracle and back to the three crucial issues:
Who are the censors?
They have to be properly appointed by a body that is answerable to the public that is being censored.
For it to be someone in the back room at NetNanny, that is utterly improper.
What rules are they required abide by?
Disclosure of policies and procedures needs to be mandatory, if they are to behave as a governing body.
What is the definition of the improper material that is to be censored?
This is the truly thorny issue that can show there to be a true problem with the whole attempt; there is no unambiguous definition of "obscenity."
A bunch of 8-year-olds sniggering at an anatomy textbook probably counts as "improper," although calling it obscene is not particularly appropriate.
In contrast, medical students obviously need such a reference....And are probably also capable at sniggering over parts of it...
The Canadian NFB documentary "Not A Love Story" sought to educate people on the degradation of women that results from the pornography industry. And showings of the film are often accompanied by arrests due to the display of obscenity.
How about Venus de Milo?
How about a set of "artistic magazines" with particularly perverse topics?
How about an issue of Abnormal Psychology that excerpts material from such magazines to assist psychologists that are treating (say) pedophiles?
ARMLinux is a port of Linux to run on a number of the ARM family of microprocessors.
There is a "distribution" directed at assisting owners of Acorn RISC and related computers to install ARMLinux on their systems; this likely will bear minimal resemblance to what would be installed on a PDA.
A PDA represents an embedded application; it is highly unlikely that someone building such would use anything that would be recognized as a "distribution" (in the archetypes of Slackware, Red Hat, or Debian).
Quite to the contrary, it is possible that a PDA would not have an init process as we usually know it, and it is unlikely that it would have a "userspace" that would be recognizable.
If they build a PDA, they'd be likely to create a custom init that starts up whatever set of work processes are necessary ( e.g. - X, a "system manager," perhaps something like cron, and so forth), and this init might be highly attuned to the specifics of the nature of what functionality they wish to "embed."
Probably some Spyglass/Mosaic derivative. There have been a number of embedded platforms built up using that.
USB.
Well, the code is coming along. Take a look at the web site. Linux-USB.org
As for the GPL, it implies that they have to offer to provide a copy of the source code to all GPLed code that they provide.
This is probably most economically done by sticking a source code TARBALL on the CD that comes with the product.
They don't have to redistribute the source code to Spyglass Mosaic, if that's what they use as the web browser, and so long as it runs as a separate process.
They may have to include sources to customizations to GPLed or LGPLed libraries; this does not mandate releasing source code to applications that aren't linked to GPLed code.
In short, if there's a 660MB CD in the box, it won't likely hurt too much if they drop a couple tarballs in that occupy 50MB of it. Alternatively, they may take the approach Tivo did, and offer to send out a CD with relevant source code for a relatively nominal cost.
I don't disagree that if all the FSes got integrated in, there wouldn't be a big problem in keeping them maintained.
But that wasn't my concern.
My concern was, and is, that it is likely to be prohibitively difficult to get all of these filesystems integrated all at once into the official kernel stream.
They all have somewhat differing expectations as to the interfaces used to get at such things as disk cache. This should not be a big surprise; they were designed independently, and thus have differing ideas as to how to interface with the kernel.
The problem is that since they simultaneously require:
Quite tight integration, so that they can provide robustness and performance guarantees, and
Somewhat differing approaches to connecting to the rest of the kernel,
this will make the integration of all of them at once a daunting task to Linus/Alan/Stephen.
Note that namespace issues have already come up; ReiserFS and EXT2 had clashes due to trying to define functions by the same names. Other similar things are likely to happen.
The point is that doing justice to integration of each FS will take time and effort.
In contrast, doing justice to the wide world of Linux users that may have concerns other than just that of having cool filesystems may involve deciding that instead of working on JFS or XFS integration, they'll work on something else.
Furthermore, the issue isn't necessarily of "justice to Linux users;" it may instead be that Linus will integrate in some FSes, and then decide that the notion of adding in more bores him, and say:
**** off. I want to spend my time adding in USB drivers instead.
The thing that is relevant in the context of this discussion is not the backup software, but rather the Veritas File System, which is used as the journalling filesystem by a number of vendors, notably including Sun.
Reportedly there are other UNIX vendors integrating it, likely including SCO and HP.
I was apparently wrong about there being a JFS dependancy on Veritas FS; there is, in any case, zero relevancy in this thread to their backup software.
At some point, whatever journalling "options" get officially supported will require some attention by the "senior kernel folk," whether that be Linus, Alan Cox, or (fairly likely!) Stephen Tweedy.
These filesystems are not as simple to interface in as the "Amiga filesystem" or other such stuff, as these FSes have expectations to be able to control somewhat how the kernel manages caches. They're not merely "drop in a patch and all will be well."
As a result, while I agree that it's good to have some diversity now to allow some experimentation, I am far less sure that it will be wise to have four (or more, if rumors of Compaq contribution of AdvFS code turn out to be true...) filesystems integrated in to the "official" kernel stream. There may be merit to having a couple of them, but not likely all of them.
So while I agree that it's quite OK for there to be 5 of them (and that ignores GFS, NTFS, and other stranger options that may be of less direct relevance), I think that there will be, ultimately, a need for several of the "integration projects" to fail.
Otherwise, Linus and others won't have time to fix up NFS3, improve memory management, implement ACLs, implement capabilities, implement IA-64 support, and all the other sorts of things that need to occupy some of their time.
The GUI comparison was pretty good; I agree with Per that it is a Good Thing that we have GNOME and KDE, as this is sufficient diversity to ensure that there is some competition whilst not being so much as to be completely fragmenting. It is unfortunate that this leaves some potentially good toolkits like FLTK or Tk or Amulet or Garnet or InterViews "out in the cold."
The point is that variety is useful at the point in time at which you're not sure what the results should look like.
But after that point, variety comes at the cost of having to support additional "development streams," and while there is logic to "letting the best man win," this has the side effect that if you agree with this, you have to also agree with the notion that the "not quite best men" need to be able to lose.
Being GPLed, it's fair game to take components of it and join them with other GPLed code.
Which means that if it has (say) a useful B-tree implementation, that may be usable with things completely unrelated to filesystems.
The question, at this point, is to what degree it is actually usable with Linux.
If it's merely a "source code dump" of the AIX code base, that's not immediately useful.
If it's a Linux kernel patch, that would be rather cool.
I wouldn't find it surprising if actually using it would require adding in components that aren't there.
People may recall that the Mozilla source code "dump" had to take out big chunks, notably including bits of Rogue Wave libraries, RSA crypto code, and some ORB whose name escapes me. As well as (for the UNIX edition) Motif.
Is IBM JFS based on Veritas? If so, then the source code that IBM is free to release doesn't include things at the low level that will be needed. That would parallel the notion of NCC having to strip out Motif support from Mozilla, with the further issue that you can't presently get anything that is quite equivalent to Veritas on Linux.
It is intended as a "printer-agnostic" scheme for getting at printing capabilities.
It is somewhat unfortunate that there have been few realistic attempts to really upgrade printing; this is a weakness for business applications.
I don't know but that Corel is creating another "island" not unlike CUPS ; I'd be more impressed if Corel was putting some programmers into something like Display Postscript so as to both make it functional and to help provide whatever integration is possible with XFree86. (There's some "license impedance" that, regardless of any flaming that might take place on Slashdot, is unlikely to change any time soon...)
One merit of GTK (and QT) over Motif is that they actually abstract away from X, and are getting deployed on multiple platforms...
As for the "appearance" issue, you've picked one of the appearances that I like least. I have no problem agreeing that the "default" GTK look is pretty klunky. (And I'm not hot on the WM theme that you're using either.)
Dell was likely paying MSFT substantially less than $100 in return for buying a whole pile of copies of Win9x. Likely something more like $50. Or perhaps even less than that for Huge Quantity Discounts as well as Exclusively Installing Win9x So As To Block Out Alternatives.
Secondly, some of the amount that more likely resembles $50 is likely going to LinuxCare.
ported Linux to run on their network terminals would suggest that IBM was replacing the (embedded OS, perhaps OS/2? perhaps something else?) on the NCs with Linux.
On the other hand, International Business Machines Corp. (NYSE:IBM - news) on Monday said its line of network computer terminals can now run on the alternative software system Linux could be read to indicate that IBM was providing the server-side software so that rather than requiring NT/AIX to boot up the NCs, one could boot them from a Linux host. The former is more impressive than the latter, as well as being rather a lot more "invasive" of functionality.
Frankly, I'd be happy enough having the Network Stations run something embedded and tiny and just plain have lots of support for them to connect to Linux boxen.
NORSAM HD-ROM is impervious to electromagnetic disturbances and has the ability, where needed, to store data on materials that are extremely durable and resistant to abrasion, atmospheric contamination, heat and other types of physical deterioration.
It's not quite ready for people to have an HDROM burner in their home PCs, but I suspect that when the patents run out in a dozen years, many will take interest in the technology...
I always saw Gartner Group as being "trained monkeys" subscribing to whatever IBM and Amdahl and Hitachi told them to believe.
Or maybe we saw different sections of their reviews... The last time I had access (about a year ago) there was a whopping lot of material on things like "Parallel Sysplex" and cost structures for CMOS mainframes and the likes.
My parents live right near Carleton University which, for a while, was known in Canada as Last Chance U. They had the self-serving policy that they'd not allow tuition refunds after midterms, with the salutory result that they'd get to keep tuition from any students that didn't drop out before having any grading feedback.
I guess that the situation in Arizona begs the question of whether or not they were having worse "weeding out" than usual. If not, then the claim that they need to "clean up" because of bad academic results is just dishonest.
It doesn't make the "porn-meisters" a good thing; it says is that things haven't changed much. Ten years ago, back when IRC didn't exist, I had an "office mate" in grad school who was into Relay, and the "groups" he was into back then were at least as sleazy as anything we'd see now. He didn't get invited to very many parties, suffice it to say...
Slashdot Mirror
Unfortunately, that isn't all that suitable for "naive lusers" who will react to this with a big Huh?!?
Rather than GNU Stow, I'd think the direction of BSD Ports would be suitable; that provides the merit of automating the process of setting up configuration info for lots of packages that hasn't yet been done with Stow. You may want to believe that
I remain quite skeptical, as it has taken years for distributions like Red Hat, Slackware, and Debian to become richly functional.Note that Ports, like Stow, uses nothing that anybody gets tangled into thinking is somehow "proprietary." (Not that RPM or DPKG actually use anything proprietary; it's mostly Slackware bigots, with emphasis on bigot, not on Slackware, that claim, dishonestly, that RPM/DPKG are somehow proprietary formats...)
But that misses the point.
Your proposal may be suitable for you and I, albeit marginally so, as I'd much rather that the administration of package installation for the 99% of packages where "default is fine" be dealt with by someone else; it is NOT, by any stretch of the imagination, suitable for making Linux deployable in other than highly UNIX literate environments.
In particular, the fact that they've been working with IBM is pretty crucial. If they sell to IBM, and sell to Diamond, and sell to a few other OEMs, it is no problem to Transmeta that they aren't pushing product at your engineering buddies.
Transmeta will succeed or fail based on whatever product deployments come out over the next six months, and with product lead times being what they are, the engineers that will be working on those products probably are already working hard on them.
As much as I'd like to buy a Transmeta PC mobo/CPU combination, that's really not what they're trying to sell. They're aiming at things like laptops and portable devices, and there are likely a bunch of those in the design/implementation pipeline.
- Suggests that they support that MD5 is hard to "spoof,"
- Means that some verification of correctness is possible.
I'd be more impressed if they offered a 1-800 number where you could call in to verify the MD5 checksum.Better still would be to encourage people to call their local FBI office to get that number, which makes it Rather Harder to Spoof...
Abuse had at least the game sequencing written in Lisp.
And a "bloated" Common Lisp implementation looks positively svelte when put beside either a Java or a C++ "IDE" environment.
I had half expected that he might do something like buying Harlequin, and "open sourcing" Liquid Common Lisp. (Which would have been rather interesting...) Or perhaps seeking to build a Lisp Machine environment to run atop Linux. Or perhaps something more quixotic like building such atop FreeBSD.
It's very interesting that he has instead proceeded to do "political system" hacking. I expect he'll get back to the computer variety at some point.
After all, he appears to be a significant participant here; any time major discussions of Motif or Mozilla come up, he's quite visible in the discussions!
I'm no "clubber," and I'm not entirely convinced he's after something that's unambiguously a good thing, but it's sort of nice to see some action oriented to a local community taking place.
Why would this be a good thing? Because DocBook is vastly more expressive.
Strewing fonts across pages, like chunky peanut butter across bread, does not lead to building decent documents.
It is, on the other hand, reasonably useful to have tags to indicate such things as a filename , application, command line, perhaps even differentiating between what you type in, what the system responds with, and what is a variable to be entered.
If Eric Raymond found it useless, then I daresay that says more about him than it does about the book.
I remember him doing some "bungee management" on the SGMLTools mailing list; he bounced in for a couple days, saying (essentially) that "It's really, really critical that you do these things that I think you need to do," and then bouncing on to whatever else it is that he does. He also spent a lot of time claiming that Trove was tremendously important, and we've not seen a useful release of that yet, after a goodly two years.
Unfortunately, they are still no further in the transition from qwertz to DocBook than they were three months ago.
There is not going to be a substantial change in the quality of the material until that happens.
It's easy to agree that there's some seriously nasty stuff out there.
Pinning it down in a way that can be "legislated on" is the problem.
Pinning it down in a way that provides useful "NetNanny" rules (or the likes) is even more difficult.
It is crucial to keep from turning "automated censor tools" into some sort of deus ex machina, as seems to be happening.
That pushes off the issue of deciding what is to be considered offensive to people that are minimally answerable to anyone.If there's to be censorship, it needs to be based on clearly deciding what is to be censored.
Which after all are a legitimate concern once you get past the stridency of "little Johnnie may see something inappropriate"
After all, if what they say to you doesn't penetrate your head as being meaningful, the converse is likely to be true as well.
In a "debate"/"heated discussion" on censorship, I took issue with the comments of someone who was feeling particularly strident about protecting the world from "evil." I pointed out that a law based on his definitions would actually outlaw publishing the Bible.
He then headed off into "never-never land" indicating that he didn't care, and that if the Bible was outlawed, he'd feel religiously persecuted, and would break that law.
Unfortunately, I never got around to underlining the point that he was proposing to break law that he had proposed in the first place.
At any rate, the critical point is to bring the focus away from the technological tools that allow them to believe that there is some sort of And Now We See A Miracle and back to the three crucial issues:
They have to be properly appointed by a body that is answerable to the public that is being censored.
For it to be someone in the back room at NetNanny, that is utterly improper.
Disclosure of policies and procedures needs to be mandatory, if they are to behave as a governing body.
This is the truly thorny issue that can show there to be a true problem with the whole attempt; there is no unambiguous definition of "obscenity."
In contrast, medical students obviously need such a reference. ...And are probably also capable at sniggering over parts of it ...
There is a "distribution" directed at assisting owners of Acorn RISC and related computers to install ARMLinux on their systems; this likely will bear minimal resemblance to what would be installed on a PDA.
A PDA represents an embedded application; it is highly unlikely that someone building such would use anything that would be recognized as a "distribution" (in the archetypes of Slackware, Red Hat, or Debian).
Quite to the contrary, it is possible that a PDA would not have an init process as we usually know it, and it is unlikely that it would have a "userspace" that would be recognizable.
If they build a PDA, they'd be likely to create a custom init that starts up whatever set of work processes are necessary ( e.g. - X, a "system manager," perhaps something like cron, and so forth), and this init might be highly attuned to the specifics of the nature of what functionality they wish to "embed."
Probably some Spyglass/Mosaic derivative. There have been a number of embedded platforms built up using that.
Well, the code is coming along. Take a look at the web site. Linux-USB.org
This is probably most economically done by sticking a source code TARBALL on the CD that comes with the product.
They don't have to redistribute the source code to Spyglass Mosaic, if that's what they use as the web browser, and so long as it runs as a separate process.
They may have to include sources to customizations to GPLed or LGPLed libraries; this does not mandate releasing source code to applications that aren't linked to GPLed code.
In short, if there's a 660MB CD in the box, it won't likely hurt too much if they drop a couple tarballs in that occupy 50MB of it. Alternatively, they may take the approach Tivo did, and offer to send out a CD with relevant source code for a relatively nominal cost.
But that wasn't my concern.
My concern was, and is, that it is likely to be prohibitively difficult to get all of these filesystems integrated all at once into the official kernel stream.
They all have somewhat differing expectations as to the interfaces used to get at such things as disk cache. This should not be a big surprise; they were designed independently, and thus have differing ideas as to how to interface with the kernel.
The problem is that since they simultaneously require:
- Quite tight integration, so that they can provide robustness and performance guarantees, and
- Somewhat differing approaches to connecting to the rest of the kernel,
this will make the integration of all of them at once a daunting task to Linus/Alan/Stephen.Note that namespace issues have already come up; ReiserFS and EXT2 had clashes due to trying to define functions by the same names. Other similar things are likely to happen.
The point is that doing justice to integration of each FS will take time and effort.
In contrast, doing justice to the wide world of Linux users that may have concerns other than just that of having cool filesystems may involve deciding that instead of working on JFS or XFS integration, they'll work on something else.
Furthermore, the issue isn't necessarily of "justice to Linux users;" it may instead be that Linus will integrate in some FSes, and then decide that the notion of adding in more bores him, and say:
Reportedly there are other UNIX vendors integrating it, likely including SCO and HP.
I was apparently wrong about there being a JFS dependancy on Veritas FS; there is, in any case, zero relevancy in this thread to their backup software.
These filesystems are not as simple to interface in as the "Amiga filesystem" or other such stuff, as these FSes have expectations to be able to control somewhat how the kernel manages caches. They're not merely "drop in a patch and all will be well."
As a result, while I agree that it's good to have some diversity now to allow some experimentation, I am far less sure that it will be wise to have four (or more, if rumors of Compaq contribution of AdvFS code turn out to be true...) filesystems integrated in to the "official" kernel stream. There may be merit to having a couple of them, but not likely all of them.
So while I agree that it's quite OK for there to be 5 of them (and that ignores GFS, NTFS, and other stranger options that may be of less direct relevance), I think that there will be, ultimately, a need for several of the "integration projects" to fail.
Otherwise, Linus and others won't have time to fix up NFS3, improve memory management, implement ACLs, implement capabilities, implement IA-64 support, and all the other sorts of things that need to occupy some of their time.
The GUI comparison was pretty good; I agree with Per that it is a Good Thing that we have GNOME and KDE, as this is sufficient diversity to ensure that there is some competition whilst not being so much as to be completely fragmenting. It is unfortunate that this leaves some potentially good toolkits like FLTK or Tk or Amulet or Garnet or InterViews "out in the cold."
The point is that variety is useful at the point in time at which you're not sure what the results should look like.
But after that point, variety comes at the cost of having to support additional "development streams," and while there is logic to "letting the best man win," this has the side effect that if you agree with this, you have to also agree with the notion that the "not quite best men" need to be able to lose.
Which means that if it has (say) a useful B-tree implementation, that may be usable with things completely unrelated to filesystems.
The question, at this point, is to what degree it is actually usable with Linux.
People may recall that the Mozilla source code "dump" had to take out big chunks, notably including bits of Rogue Wave libraries, RSA crypto code, and some ORB whose name escapes me. As well as (for the UNIX edition) Motif.
Is IBM JFS based on Veritas? If so, then the source code that IBM is free to release doesn't include things at the low level that will be needed. That would parallel the notion of NCC having to strip out Motif support from Mozilla, with the further issue that you can't presently get anything that is quite equivalent to Veritas on Linux.
It is intended as a "printer-agnostic" scheme for getting at printing capabilities.
It is somewhat unfortunate that there have been few realistic attempts to really upgrade printing; this is a weakness for business applications.
I don't know but that Corel is creating another "island" not unlike CUPS ; I'd be more impressed if Corel was putting some programmers into something like Display Postscript so as to both make it functional and to help provide whatever integration is possible with XFree86. (There's some "license impedance" that, regardless of any flaming that might take place on Slashdot, is unlikely to change any time soon...)
As for the "appearance" issue, you've picked one of the appearances that I like least. I have no problem agreeing that the "default" GTK look is pretty klunky. (And I'm not hot on the WM theme that you're using either.)
But redo that with the GTKstep theme and get something looking more like this fileselector or this scrolled window.
Other looks may be found at gtk.themes.org.
Dell was likely paying MSFT substantially less than $100 in return for buying a whole pile of copies of Win9x. Likely something more like $50. Or perhaps even less than that for Huge Quantity Discounts as well as Exclusively Installing Win9x So As To Block Out Alternatives.
I'd say the more the merrier.
The only thing you get support on is installation support.
If you bought a system where Linux was preinstalled, then you don't need installation support.
ported Linux to run on their network terminals would suggest that IBM was replacing the (embedded OS, perhaps OS/2? perhaps something else?) on the NCs with Linux.
On the other hand, International Business Machines Corp. (NYSE:IBM - news) on Monday said its line of network computer terminals can now run on the alternative software system Linux could be read to indicate that IBM was providing the server-side software so that rather than requiring NT/AIX to boot up the NCs, one could boot them from a Linux host. The former is more impressive than the latter, as well as being rather a lot more "invasive" of functionality.
Frankly, I'd be happy enough having the Network Stations run something embedded and tiny and just plain have lots of support for them to connect to Linux boxen.
They had a test done at Los Alamos National Labs where they tested the media for corruption after exposure to extreme heat and corrosive conditions.
It's not quite ready for people to have an HDROM burner in their home PCs, but I suspect that when the patents run out in a dozen years, many will take interest in the technology...
Note that there is an Objective C binding for GTK...
- Firstly, there are likely some components of QT that aren't Apple's to give away.
- Secondly, one of the points to QT has been to be an Apple technology, a licensable thing that they have collected fees for.
- Thirdly, Apple makes money from selling computers.
- Fourthly, a "free QT" may be usable by evil competitors to injure Apple. Oh, say, Microsoft?
Pushing Apple to pretend to do something nice for Linux whilst providing incentive for them to play licensing games is just not my idea of wisdom.A "free QT" that doesn't help sell Apple computers and doesn't provide licensing fees is a somewhat worse deal for Apple.
Or maybe we saw different sections of their reviews... The last time I had access (about a year ago) there was a whopping lot of material on things like "Parallel Sysplex" and cost structures for CMOS mainframes and the likes.
I do note that IBM has VisualAge COBOL, but where are the Qt bindings?
Which one of the COBOL environments provides a metaobject protocol? (Just as CLOS - Common Lisp Object System has, as does C++ as does Guile with GOOPS
Hmm? Hmm? Inquiring minds want to know...
My parents live right near Carleton University which, for a while, was known in Canada as Last Chance U. They had the self-serving policy that they'd not allow tuition refunds after midterms, with the salutory result that they'd get to keep tuition from any students that didn't drop out before having any grading feedback.
I guess that the situation in Arizona begs the question of whether or not they were having worse "weeding out" than usual. If not, then the claim that they need to "clean up" because of bad academic results is just dishonest.
It doesn't make the "porn-meisters" a good thing; it says is that things haven't changed much. Ten years ago, back when IRC didn't exist, I had an "office mate" in grad school who was into Relay, and the "groups" he was into back then were at least as sleazy as anything we'd see now. He didn't get invited to very many parties, suffice it to say...