I am afraid I have to look at these points in exactly the opposite manner.
Big companies like Dell and IBM have staff that remember what happened when some uncareful deals were made with Microsoft.
If it hadn't been for some real sharp intellectual property lawyers, Microsoft would probably have been a bit of "IBM toe jam."
It may be cheaper to keep several Linux vendors alive and kicking than to commit to one.
After all, Macmillan Publishing was "devoted" to Red Hat Software until they became "devoted" to Linux/Mandrake...
Playing the My Kernel Developer Is Better Than Your Kernel Developer game is none too safe.
Look, for instance, at the VA Linux Systems Ubergeek List. Note that they've "got" Ted T'so and H.J. Lu, amongst quite a list of important "Kernelmeisters."
Red Hat has some notable kernel hackers, notably Alan Cox and Stephen Tweedie; it is not vastly apparent that they have infinite clout in this regard.
The Only Works With RedHat Linux label came long ago, and can't afford to stay.
This should not be misread as a prediction of impending failure, but merely to say that the commonly misperceived "infinite clout" just isn't that "infinite," even if they do have some on-paper billionaires...
I really hope that the device does include some proportion of quirky commentary on Life, The Universe and Everything.
If it's too serious a tome, it will doubtless become a target for hackers who will make sure that there's a way for the universe to add a little bit of entertainment...
The best proof of ownership is if the software will only run on Apple's hardware.
Hopefully there is still some ability of recent versions of MacOS to run on some of the clones ( e.g. UMAX, StarMax, Motorola,...), but outside of the rather small population of "clones," there's hardly any hardware out there that MacOS will run on that isn't from Apple.
I suspect that you've missed the flame wars surrounding contentions over whether successive editions of MacOS will continue to support pre-"G3" PPC Macs...
Ten Digit Dialing Is Not A Solution
on
CNN On IPv6
·
· Score: 2
In the the most recent two regions in which I have lived, Toronto and Dallas, it is already pretty much required that people dial all 10 digits.
The problem is not that.
The problem is that even ten digits may not be enough...
It is more than likely that ZD is trying to jump on the publicity bandwagon discovered by Slashdot readers, and is merely pouring gasoline on the fire.
It would be useful for developers to complain about abuses of their code; for advokiddies too gripe about this is a waste of bits...
There is still an overflow...
on
CNN On IPv6
·
· Score: 2
Adding an extra digit is a slick idea, in a way, but enters its own problems.
After all, there are doubtless lots of software packages out there that assume that telephone numbers are exactly ten digits long.
This doesn't break the phone system itself, but it breaks systems that track telephone numbers.
The upshot is that this breaks just any sort of "business" system that uses telephone numbers...
Happily, one of these systems that breaks will be the Circuit City systems that track who you are based on your telephone number. Customers may be quite happy about this, but Circuit City doubtless won't be...
The reasons why Linux is not used on IRC are not particularly related to Dvorak's discussion of how "Linux is apparently not suited to IRC."
For that reason, it is reasonably fair to say that the Dvorak essay is significantly flawed.
It is, after all, not particularly informative when Dvorak comments that Linux isn't used on the big IRC servers when he makes no comment on what is actually used for the purpose, or why.
The only implication that the gentle reader could reasonably guess, from the vendors mentioned in the article, is that the big IRC servers are all running on NT.
Is it therefore a "Pro-MSFT, Anti-Linux" piece? Probably not.
It's certainly not a "Well-written, well-argued, well-defended" pice.
Re:Telephone # problems similar to IP address issu
on
CNN On IPv6
·
· Score: 2
Possible technical quibbling aside, that sounds not too distant from reality.
The wastage of numbers via ineffective use of exchanges does indeed suggest another vector via which "name space" may vapor away. The only good news is that cell phones and pagers are likely to "pack in" more effectively as they are not forced into a tiny geographic zone as would be the case for a local exchange.
The merely makes the "crunch" happen quicker; as the numbers of phone numbers per person grow, the population of needed numbers is still growing pretty rapidly.
The issue is not, in this case, one where there is a sudden date when everything breaks (as with Y2K, but rather something more like a ``brown-out'' where it becomes increasingly difficult to manage systems, and where new subscribers cannot be admitted, which will hit some geographic areas before others...
It may result in businesses moving to ``economically depressed'' areas where there are exchanges with space free:-).
The Great Telephone Number Explosion...
on
CNN On IPv6
·
· Score: 3
Note that there's another likely crisis, namely that North America is liable to run out of area codes some time soon.
After all, there are only a theoretical billion numbers, which get cut down due to positional issues ( e.g. can't start either an area code or a local number with a 0 or 1, amongst other constraints).
When you count up telephone numbers used by home phones, business phones, fax machines, pagers, cell phones, and start tossing in Internet usage, the system will be running out of room at some point.
I hear rumor of some ideas the Telcos are working on to consolidate numbers; it won't be trivial...
I think the point that you're trying to make is that the expiry dates for the "protections" provided by current mechanisms are somewhat too long.
Supposing there were some equivalent to copyright that retained proprietary rights to software and/or data that expired, putting the material into the public domain, after (say) five years, this would provide a substantially better "regime" than the present situation where:
Copyright protects for longer than an author's lifetime, and corporations are trying to turn it into perpetual control, and
Patents protect for longer than anyone could conceivably wait for an "Internet technology."
I'm not sure what the "excuse" would be for cutting the expiry times; in order to push this through legal channels, it would have to be shown that this provided some benefit over the present "expiry regime."
The point is that if a company wants a database that is satisfactory for building systems that are not allowed to go down, they are likely to find things like DB/2 or Oracle more satisfactory than PostgreSQL or MySQL.
There exist tools to help keep the pricy proprietary products up and running very near to 24x7x365, whereas the free products simply weren't built with that in mind.
In the jurisdiction in which Corel is incorporated, it would be a Crown Attorney that could be relevant, and that only if this were a criminal matter. (With court session probably to be held a couple blocks from my old high school, but I digress...)
The firestorm that would arise from taking such action would have Unintended Consequences that would likely be widely injurious to the free software community.
It makes a lot more sense for one or three of the people that are developers of software known to be included with "Corel Linux" to calmly request that the language in the "Beta License" be toned down a little to correctly reflect the licensing of the free software being distributed.
It is highly probable that the high-handed wording resulted from some lawyers that having arbitrarily applied the sorts of licensing terms they have always applied to beta editions of things like WordPerfect or CorelDraw! without having properly read the free software licenses.
Does it make more sense to:
Try to burn them in oil, and certainly discourage them from ever considering free software ever again? or
Respectfully requesting some form of "cease and desist" that provides an avenue for them to back down gracefully, provide a more satisfactory license, and learn something from the process?
One problem that the Byte article displays is that those that ignore whether software is "free" or not leave themselves vulnerable to the vagaries of licensing choices on the part of the vendor.
Those that were using SOLID for things that Solid no longer supports have committed the exact opposite mistake to that of Ideology getting in the way.
In effect, by not letting a preference for free software push them away from the "Solid choice," they have been boxed into a different corner.
The implication is that a preference for free software does not necessarily represent ideology; it can represent a solid preference for software that doesn't leave you dependent on the good graces of a software vendor...
From a practical standpoint, the people that will care about this announcement are those that construct embedded systems. The microwave oven you buy next year could conceivably contain an "eZ-80."
On the other hand, the larger memory space and (seemingly built-in?) TCP/IP stack offers the opportunity to build a "RetroWeb Server." Note that ZSDOS, a ZCPR variant, is now available under the GPL.
The possibilities are immense, I mean, minscule. A complete web server could probably fit in a volume of 2 cubic inches...
The stuff that is not "releaseable" is what is called Confidential Information, defined as
... nonpublic information that Corel designates as being confidential, or which, under the circumstances surrounding disclosure ought to be treated as confidential.
Confidential information does not include any information which the User can conclusively establish was (i) in the possession of the user at the time of the disclosure; (ii) prior to or after the time of disclosure becomes publicly available without the act or omission of the User; (iii) is disclosed to the User by a third party under no legal obligation to maintain the confidentiality of such information; or (iv) was independently developed by the user.
Software that represents part of the Debian body of code will fall under item (iii) above, and thus represent stuff that is Not Confidential Information.
It is pretty evident that the lawyers "went a little ape" on this; as likely as not someone needs to wander over to Gowling and Henderson (the big Ottawa law firm) and have words with them.
It is not, however, evident that this represents a clear violation of the GPL.
The only stuff it seems would legally be able to be treated as "Confidential" would be code that Corel themselves produce and provide.
The situation with Solid displays nicely that the use of non-free software provides exposure to the risk that a vendor will decide to "Change their Business Strategy."
If Solid decides to move from selling licenses at $300 targeted at web servers to selling $10000 licenses targetted at use in embedded systems (speaking loosely of "embedded," of course), there is little that the customer can do.
If IBM decides not to provide an upgrade next year for Linux, and push users over to running DB/2 on Monterrey, there may be little that the customer can do.
On the other hand, there are some tasks such as writing documentation and building test suites to verify compliance with standards that aren't "sexy" tasks and which thus have a tendancy to suffer on "free" DB platforms.
I suppose the given is that there are some significant risks regardless of the approach you take.
The observation that code should be written to be, as much as possible, independent of the DB engine, is certainly true. This diminishes the extent to which you're locked in.
This is valuable whether we're talking about Oracle or MySQL.
Related to this, it seems to me that people should be looking into using transactioning/messaging "proxies" like BEA Tuxedo (proprietary) or less proprietary things like the Isect message queuing system.
OpenDoc suffered from the problem that it provided and required the use/implementation of a rich API of document object manipulators.
Thus, while it would be neat to have a whole lot of those "little applications," if it's Rather Difficult to write them, they may not be as little as you'd think/hope.
The document CORBA and You alludes to this somewhat indirectly, indicating that
Keep interface exposition at a high level. Not only does exposing low-level interfaces cause increased dependence upon the internal organization of a software system, but it also means you have to put more code into exporting your interfaces, introducing the risk for more bugs and increasing bloat.
The difference between an ``embedded processor'' and a ``general purpose processor'' is as much marketing as anything else
At one point, the StrongARM was being strongly promoted as a Network Computer (aka ``X-Terminal'') device. Note the announcement of 1997 of the Digital Network Appliance Design.
And note that it is the processor used in the Rebel/Sidewinder that Corel Computers used to hawk.
The point of all of this is that the CPU is clearly not so ``embedded'' that it would be inherently useless in a ``desktop'' role.
It ought to have been possible to build motherboards integrating a CPU, video chipset, and Ethernet that could retail for less than $150, and this could have brought us $300 computers a year or so ago, and provided slick little boxes to velcro to the sides of 17" monitors.
If I could have bought a StrongARM motherboard for $100, I probably would have built a machine by now.
But no motherboard leads to no systems. Note that exactly the same reasoning may be used with MIPS...
The funniest thing that I heard yesterday at the Amarillo LUG Conference was the thought that RMS tends to behave himself better at conferences when he considers that he has been "Honored."
A vendor (who shall remain nameless!) suggested that he'd be game to help sponsor some "RMS Award" at every Linux conference if this would result in him behaving a bit better. It appeared that there was sufficient support that they could put together enough to:
Double the FSF's annual budget, by
Having on the order of $25K for each of the "national" conferences/conventions...
... And it was entertaining how many at Amarillo weren't familiar with the term "Solipsist."
I tend to agree with the "technological" issues mentioned surrounding AFS, Arla and Coda. They are more or less credible possible alternatives to the getting increasingly creaky NFS system.
In particular, Coda is really cool, and the RVM facility is particularly neat stuff.
Unfortunately, there's a downside to making this use of all that "extra disk space," and that is that this may diminish the overall reliability of the whole system, and a not particularly unusual case would be for reliability to degrade to the "reliability of the weakest system on the net."
The "ideal" situation would be to be able to "somehow publish" that extra space, and allocate it perhaps as follows:
1/3 as "new space."
1/3 as cache for stuff that normally lives on other boxes.
1/3 as backup of material on other boxes.
I'm not proposing that the parameters here are necessarily "religious doctrine;" the point is that it is important to distribute some backups (analagous to RAID) such that if a drive goes bad, the rest of the system doesn't have to suffer.
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
-- Andrew S. Tanenbaum, Computer Networks, Second Edition, p. 57
In Cramer's series on TCP/IP, I seem to recall an analysis done of the use of carrier pigeons to carry "information traffic" between an observatory in the mountains and a more normally "connected" site, and it didn't prove out as badly as one might expect. In the days when data-oriented communications infrastructure was a rarity, and cell phones out of "Dick Tracy," there were some creative answers.
I remember hearing the possibly-apocryphal tale that New Zealand's Usenet news feed was, for a time, fed via tapes that were flown in from Australia on a weekly basis.
Long and short is that I would be reluctant to underestimate the ingenuity of those that would do peculiar things with bandwidth in New Zealand...
The only portion of the install that particularly "phased" me was the scheme for establishing disk "slices."
This results since the BSDs did not start with an attempt at interoperability with the MS-DOS partitioning scheme.
Aside from partitioning, the install scheme has seemed to have less differences between it and (say) Slackware's install scheme than there is between the triad of (Debian, Slackware, Red Hat).
I expect that there will be some phone lines and cable modems "burning" through tonight; if I were interested in doing a 3.3 install, I'd probably order a CD today, and let the bandwidth come via the mail system...
Slashdot Mirror
- Big companies like Dell and IBM have staff that remember what happened when some uncareful deals were made with Microsoft.
- It may be cheaper to keep several Linux vendors alive and kicking than to commit to one.
- Playing the My Kernel Developer Is Better Than Your Kernel Developer game is none too safe.
- The Only Works With RedHat Linux label came long ago, and can't afford to stay.
This should not be misread as a prediction of impending failure, but merely to say that the commonly misperceived "infinite clout" just isn't that "infinite," even if they do have some on-paper billionaires...If it hadn't been for some real sharp intellectual property lawyers, Microsoft would probably have been a bit of "IBM toe jam."
After all, Macmillan Publishing was "devoted" to Red Hat Software until they became "devoted" to Linux/Mandrake...
Look, for instance, at the VA Linux Systems Ubergeek List. Note that they've "got" Ted T'so and H.J. Lu, amongst quite a list of important "Kernelmeisters."
Red Hat has some notable kernel hackers, notably Alan Cox and Stephen Tweedie; it is not vastly apparent that they have infinite clout in this regard.
I really hope that the device does include some proportion of quirky commentary on Life, The Universe and Everything.
If it's too serious a tome, it will doubtless become a target for hackers who will make sure that there's a way for the universe to add a little bit of entertainment...
Hopefully there is still some ability of recent versions of MacOS to run on some of the clones ( e.g. UMAX, StarMax, Motorola, ...), but outside of the rather small population of "clones," there's hardly any hardware out there that MacOS will run on that isn't from Apple.
I suspect that you've missed the flame wars surrounding contentions over whether successive editions of MacOS will continue to support pre-"G3" PPC Macs...
The problem is not that.
The problem is that even ten digits may not be enough...
It is more than likely that ZD is trying to jump on the publicity bandwagon discovered by Slashdot readers, and is merely pouring gasoline on the fire.
It would be useful for developers to complain about abuses of their code; for advokiddies too gripe about this is a waste of bits...
After all, there are doubtless lots of software packages out there that assume that telephone numbers are exactly ten digits long.
This doesn't break the phone system itself, but it breaks systems that track telephone numbers.
The upshot is that this breaks just any sort of "business" system that uses telephone numbers...
Happily, one of these systems that breaks will be the Circuit City systems that track who you are based on your telephone number. Customers may be quite happy about this, but Circuit City doubtless won't be...
For that reason, it is reasonably fair to say that the Dvorak essay is significantly flawed.
It is, after all, not particularly informative when Dvorak comments that Linux isn't used on the big IRC servers when he makes no comment on what is actually used for the purpose, or why.
The only implication that the gentle reader could reasonably guess, from the vendors mentioned in the article, is that the big IRC servers are all running on NT.
Is it therefore a "Pro-MSFT, Anti-Linux" piece? Probably not.
It's certainly not a "Well-written, well-argued, well-defended" pice.
The wastage of numbers via ineffective use of exchanges does indeed suggest another vector via which "name space" may vapor away. The only good news is that cell phones and pagers are likely to "pack in" more effectively as they are not forced into a tiny geographic zone as would be the case for a local exchange.
The merely makes the "crunch" happen quicker; as the numbers of phone numbers per person grow, the population of needed numbers is still growing pretty rapidly.
The issue is not, in this case, one where there is a sudden date when everything breaks (as with Y2K, but rather something more like a ``brown-out'' where it becomes increasingly difficult to manage systems, and where new subscribers cannot be admitted, which will hit some geographic areas before others...
It may result in businesses moving to ``economically depressed'' areas where there are exchanges with space free :-).
After all, there are only a theoretical billion numbers, which get cut down due to positional issues ( e.g. can't start either an area code or a local number with a 0 or 1, amongst other constraints).
When you count up telephone numbers used by home phones, business phones, fax machines, pagers, cell phones, and start tossing in Internet usage, the system will be running out of room at some point.
I hear rumor of some ideas the Telcos are working on to consolidate numbers; it won't be trivial...
Supposing there were some equivalent to copyright that retained proprietary rights to software and/or data that expired, putting the material into the public domain, after (say) five years, this would provide a substantially better "regime" than the present situation where:
I'm not sure what the "excuse" would be for cutting the expiry times; in order to push this through legal channels, it would have to be shown that this provided some benefit over the present "expiry regime."
There exist tools to help keep the pricy proprietary products up and running very near to 24x7x365, whereas the free products simply weren't built with that in mind.
In the jurisdiction in which Corel is incorporated, it would be a Crown Attorney that could be relevant, and that only if this were a criminal matter. (With court session probably to be held a couple blocks from my old high school, but I digress...)
The firestorm that would arise from taking such action would have Unintended Consequences that would likely be widely injurious to the free software community.
It makes a lot more sense for one or three of the people that are developers of software known to be included with "Corel Linux" to calmly request that the language in the "Beta License" be toned down a little to correctly reflect the licensing of the free software being distributed.
It is highly probable that the high-handed wording resulted from some lawyers that having arbitrarily applied the sorts of licensing terms they have always applied to beta editions of things like WordPerfect or CorelDraw! without having properly read the free software licenses.
Does it make more sense to:
- Try to burn them in oil, and certainly discourage them from ever considering free software ever again? or
- Respectfully requesting some form of "cease and desist" that provides an avenue for them to back down gracefully, provide a more satisfactory license, and learn something from the process?
I know which option I'd rather go with...One problem that the Byte article displays is that those that ignore whether software is "free" or not leave themselves vulnerable to the vagaries of licensing choices on the part of the vendor.
Those that were using SOLID for things that Solid no longer supports have committed the exact opposite mistake to that of Ideology getting in the way.
In effect, by not letting a preference for free software push them away from the "Solid choice," they have been boxed into a different corner.
The implication is that a preference for free software does not necessarily represent ideology; it can represent a solid preference for software that doesn't leave you dependent on the good graces of a software vendor...
On the other hand, the larger memory space and (seemingly built-in?) TCP/IP stack offers the opportunity to build a "RetroWeb Server." Note that ZSDOS, a ZCPR variant, is now available under the GPL.
The possibilities are immense, I mean, minscule. A complete web server could probably fit in a volume of 2 cubic inches...
Software that represents part of the Debian body of code will fall under item (iii) above, and thus represent stuff that is Not Confidential Information.
It is pretty evident that the lawyers "went a little ape" on this; as likely as not someone needs to wander over to Gowling and Henderson (the big Ottawa law firm) and have words with them.
It is not, however, evident that this represents a clear violation of the GPL.
The only stuff it seems would legally be able to be treated as "Confidential" would be code that Corel themselves produce and provide.
- PostgreSQL for "heavy-duty-functionality" versus
- MySQL for "speed."
What is unfortunate is that neither of these are really strong with regards to reliability even in the wake of hardware problems.If Solid decides to move from selling licenses at $300 targeted at web servers to selling $10000 licenses targetted at use in embedded systems (speaking loosely of "embedded," of course), there is little that the customer can do.
If IBM decides not to provide an upgrade next year for Linux, and push users over to running DB/2 on Monterrey, there may be little that the customer can do.
I suppose the given is that there are some significant risks regardless of the approach you take.
The observation that code should be written to be, as much as possible, independent of the DB engine, is certainly true. This diminishes the extent to which you're locked in.
This is valuable whether we're talking about Oracle or MySQL.
Related to this, it seems to me that people should be looking into using transactioning/messaging "proxies" like BEA Tuxedo (proprietary) or less proprietary things like the Isect message queuing system.
Thus, while it would be neat to have a whole lot of those "little applications," if it's Rather Difficult to write them, they may not be as little as you'd think/hope.
The document CORBA and You alludes to this somewhat indirectly, indicating that
The difference between an ``embedded processor'' and a ``general purpose processor'' is as much marketing as anything else
At one point, the StrongARM was being strongly promoted as a Network Computer (aka ``X-Terminal'') device. Note the announcement of 1997 of the Digital Network Appliance Design.
And note that it is the processor used in the Rebel/Sidewinder that Corel Computers used to hawk.
The point of all of this is that the CPU is clearly not so ``embedded'' that it would be inherently useless in a ``desktop'' role.
It ought to have been possible to build motherboards integrating a CPU, video chipset, and Ethernet that could retail for less than $150, and this could have brought us $300 computers a year or so ago, and provided slick little boxes to velcro to the sides of 17" monitors.
If I could have bought a StrongARM motherboard for $100, I probably would have built a machine by now.
But no motherboard leads to no systems. Note that exactly the same reasoning may be used with MIPS...
At one point, it apparently was a "genius" idea to centralize Palm as part of 3Com's largely networking-oriented organization.
Now, it is apparently time to run through the other side of the argument.
Which is opposite to what happened last year, but everyone thinks this is a brilliant idea too.
Scott Adams would be proud...
If you look at the various architectures on which Linux runs, there are three varieties, in general:
There are a boatload of IA-32-based Linux systems.
There are a fair number of such systems.
PPC is hard to assess; it is easy to buy a PPC Mac from Apple, but fairly difficult to buy just a motherboard.
If PPC motherboards were readily available, PPC would be vastly more popular...
A vendor (who shall remain nameless!) suggested that he'd be game to help sponsor some "RMS Award" at every Linux conference if this would result in him behaving a bit better. It appeared that there was sufficient support that they could put together enough to:
In particular, Coda is really cool, and the RVM facility is particularly neat stuff.
Unfortunately, there's a downside to making this use of all that "extra disk space," and that is that this may diminish the overall reliability of the whole system, and a not particularly unusual case would be for reliability to degrade to the "reliability of the weakest system on the net."
The "ideal" situation would be to be able to "somehow publish" that extra space, and allocate it perhaps as follows:
I'm not proposing that the parameters here are necessarily "religious doctrine;" the point is that it is important to distribute some backups (analagous to RAID) such that if a drive goes bad, the rest of the system doesn't have to suffer.
In Cramer's series on TCP/IP, I seem to recall an analysis done of the use of carrier pigeons to carry "information traffic" between an observatory in the mountains and a more normally "connected" site, and it didn't prove out as badly as one might expect. In the days when data-oriented communications infrastructure was a rarity, and cell phones out of "Dick Tracy," there were some creative answers.
I remember hearing the possibly-apocryphal tale that New Zealand's Usenet news feed was, for a time, fed via tapes that were flown in from Australia on a weekly basis.
Long and short is that I would be reluctant to underestimate the ingenuity of those that would do peculiar things with bandwidth in New Zealand...
This results since the BSDs did not start with an attempt at interoperability with the MS-DOS partitioning scheme.
Aside from partitioning, the install scheme has seemed to have less differences between it and (say) Slackware's install scheme than there is between the triad of (Debian, Slackware, Red Hat).
I expect that there will be some phone lines and cable modems "burning" through tonight; if I were interested in doing a 3.3 install, I'd probably order a CD today, and let the bandwidth come via the mail system...