In the deep dark mists of the past, the phone companies doubtless worried of the same issue of saturation. After all, they had sold a whopping pile of phones (well, more like "rented a whopping pile," but close enough...), and virtually every home had one.
But not to worry... They had not accounted for the fact that you might want to have more than one telephone. Personally, I have two telephones in my apartment, and connect to my ISP and to TiVo service using the one line as well. Add to that the "mobile telephony" equipment...
The parallels to computing should be blatantly obvious; families already have the issue of family members "disputing" over who gets to use the computer.
In the long run, it would make a whopping lot of sense for there to be a whole "horde" of computers in a home, between:
One used for "communications control."
Whether firewall or "Internet Services Server," this option seems eminently likely.
What The World Really Needs is a $250 firewall box that runs Linux, and integrates in a cable modem and an Ethernet hub. No screen, by default; perhaps not even a hard drive.
One for each adult, potentially allowing them to VPN out to get at systems and applications at work.
If there are the Standard 2.2 kids, there might be 2 computers in the "kids' zone" so they may simultaneously work on homework, and/or play games with one another.
There might be something integrated into the "Audio/Visual Systems," whether as a controller for DVD 'stuff,' MP3 'stuff,' or other such.
There might be value in having a computer with touch-sensitive LCD that attaches to the fridge to allow entering appointment/schedule information.
In the bedroom, there might be a computer to run the "feelies." (Shades of Huxley, anyone?:-))
In the basement, the HVAC controller might get integrated into the "home network."
To be sure, not all of these are practical applications at present, but the fact that it's easy to come up with additional such uses is pretty suggestive that those that think the markets are "saturated" probably haven't thought hard enough.
Let's consider another comparison: others have asked ``how many women are on the core team?''.
The answer, both before and after, is ``none''. This isn't discrimination: we currently have no female committers, so it's just not possible. For whatever reason, hacking remains a very predominantly male business.
Obviously it makes sense to select the "politicians" from the group of people that are interested in participating in the project. If no women were interested in participating, it is unsurprising that none were available for selection.
The problem, if it be considered such, does not lie in the selection of the FreeBSD core team, but rather way back when people decide what sorts of things they want to get involved with. Where there weren't any women that put FreeBSD on their lists.
The Big Problem with most of the would-be solutions (note: I use CFS, and find it quite satisfactory for my purposes, despite the weaknesses) is that you get to choose between only two options:
You can either "mount" the resultant FS publicly, so that anyone on your system can see it, or
Each and every program that wants to go after encrypted data needs to individually explicitly include cryptographic support to read keys and access/update encrypted data.
Neither of these are terribly satisfactory. The first approach leaves a lot of stuff visible in plaintext form, whilst the latter pushes a substantial burden for encryption support into each and every program.
As is nicely outlined here , the Plan 9 operating system provides the ability to do this Another Way, using the concept of namespaces. The basic idea is that the "file tree" is no longer a global thing, but is, instead, localized to processes.
In effect, I might, from my shell, run the command:
mount -t crypto/home/cbbrowne/encrypted-stuff/mounts/plaintext
This results in the encrypted stuff in my home area getting attached to the file tree under /mounts/plaintext
The two clever things about this are that:
/mounts/plaintext is visible to the shell that invoked the mount, as well as to its children.
/mounts/plaintext is not visible to any other processes.
When Mozilla got released, way back when, it was ridiculously useless on day 1 due to it depending on a whole bunch of development tools that weren't available as free software ( e.g. - stuff from RSA, Motif, Orbix, I think some Rogue Wave libs).
I expect that "Open Office" isn't quite so challenging, but I sure it does depend on some stuff. Does it need Lesstif? How about other such stuff?
When Cryptography Becomes a Political Attack...
on
SDMI Cracked Too Soon
·
· Score: 2
I agree with you that from the perspective of trying to preserve the ability to demolish SDMI's ciphers at a later time, it may have been foolish to break the codes now. Eric Raymond wrote a pretty entertaining letter on the matter commending the idea of luring the RIAA into a false sense of security, so that they would invest some real money in SDMI, foolishly getting NO security out of the deal, vulnerable to be badly scarred by the later serious attacks.
On the other hand, the Salon article seems to indicate that the consortium that created SDMI is politically fragile. Which suggests a different set of outcomes:
An attack on the ciphers now whilst they are politically vulnerable to attack might knock the whole consortium down.
Which leaves nobody there to agree on a "SDMI Mark II".
Not attacking the ciphers now allows the consortium to gather political stability, which leads to financial stability.
Given financial stability, they might attain the funding to mount a legislative response to a later cipher attack.
In effect, the hackers might attack now, while SDMI is weak, and destabilize it from a political perspective.
It is possible that the scenarios I suggest are not representative, but if they are, which seems possible, this certainly paints a rather different picture.
I'll be quite happy to not bother drooling about this for another six months while AMD shakes out any bugs in implementations of mobos, memory interfaces, and distribution. And they should be "less than spectacularly expensive" by that point too...
Yes, indeed, the notion that corporations "pay taxes" is a fiction. If they don't either "charge it back" to their customers, or pass it on to their owners, then the tax essentially demolishes their ability to be profitable on behalf of the owners, making them unviable. (I've actually prepared corporate income tax returns, so I quite know that this needs to be couched in all sorts of "legal ums and ahs" in order to be treated as true...)
On The Other Hand. Corporate "taxation," such as it is, exists for two reasons:
Because mindless voters will vote for this sort of thing, and
Because there are some Tax Games that could be played by keeping monies inside the company, potentially avoiding indefinitely taxation of the income-making activities.
By providing something that pretends to tax the corporation, and which potentially hits up the individual for two tax bills rather than one, this forces the individual to make the company disburse incomes sooner.
The essence of it is that there are people that have vigorously strong positions on some peculiar issues and that there is little point to trying to debate the issues even if you think you have a rational position and can debate rationally.
There are enough people who have strongly irrational positions, whether due to mental instability (suggested in the essay, and likely, in my view, for "crackpot" theories) or (I would add) due to having strong emotional feelings surrounding the issue, and likely to be true for situations such as the Abortion debate, matters in the Middle East, and anything relating to Nazi Germany.
In effect, this provides a corollary to Godwin's Law that topics involving large numbers of deaths and/or outright wars evoke such strong emotion that many find it hard to detach themselves from the issue so as to discuss the issue rationally.
And if the matter is "insane" to begin with (e.g. - as with most "conspiracy theories"), there is no "rational" side to start with...
You can be aggressive in trying to personally attack or annoy the telemarketers; the problem with that is that:
While it may feel cathartic to harass the person calling you, you're merely annoying someone low on the food chain.
This is a bottom end job, taken by people that have had few better opportunities. They make no decisions, and annoying one of them merely annoys one of them.
You can make one other person's day worse by hurling abuse their way, but this will have no effect on how often you get called. There are thousands of them, and they don't all talk to one another.
Did I mention already that abusing them does nothing to get you off the lists?
I instead suggest looking to JunkBusters.com.
These are the same people that produce the beloved Junkbuster "web proxy" that can block cookies and evil ad banners for you.
They suggest sending your info to the Direct Marketing Association indicating you don't want calls from member companies. I remain skeptical of this...
I still get an irritating number of calls from the companies I already do business with, mostly the credit card cretins; the LD Provider calls significantly diminished when I started at least partially following the "JunkBuster Script."
(Horrors! That sounds terrifyingly close to "chain letter" systems!)
... Which is actually of some actual importance in light of the fact that one of its release criteria is that of having
a stable ABI.
This is quite a significant issue, as libraries compiled with one release of G++ by one person may not work with another release of G++ by someone else.
This appears to be the root of the problems I had running Opera; it would generally run OK until I actually tried to load in a web page, at which point it would discover it had just tried to violate a segment. That was with the statically-linked version; a dynamically-linked version will be at even greater risk of ABI violations...
There's a guy in Scandanavia this week that has found an old Honeywell DPS-6 that is trying to figure out if there is any hope of refurbishing it to run Multics. It's a forlorn hope; he might conceivably get it to run GCOS, with a little luck, and perhaps some help from Thinkage.
Is this of any practical value? Well, a DPS-6 is likely about as powerful as an 80386, and it won't likely fit in your closet, so it's fair to say that it's not a terribly practical proposal.
Likewise, an iPaq has a pretty small screen, small memory, small secondary storage, and no keyboard, thus meaning that it's not a vastly practical computing platform on which to run Debian.
However. Consider two things:
With constantly improving hardware, the models out next year might have 64MB of RAM, and we might be able to get cheap 256MB CF cards.
Which means that while it's not spectacularly useful now, if some people scramble to work on it now, they may start having useful software and configuration tools (and boot tools, and...) by the time the hardware is ready to be really useful.
If it is never of practical value, it can still be a cool hack.
Nobody is going to power up a DPS-6 because they want to run payroll on it, or write TECO macros to calculate Pi because that's a particularly efficient way to do it; they'll do it because they can.
I think that in another year, there may well be enough hardware on PDAs to usefully run Linux. More power to those experimenting with it now that will make it deployable by then.
Interesting thoughts; I could believe that this simultaneously represents a shot over the bows both of Oracle, with which SAP long has had something of a love/hate relationship, and of Microsoft, where the "love-in" has mostly appeared "soured" by virtue of the Linux-related SAP initiatives.
It was pretty likely that many of the companies spending lots on Adabas-D were running R/3 on top of it, in which case it makes sense for the DB to jump over to SAP as it is effectively being used as an "embedded" database, not as a fullscale product in its own right. For SAP to "own" it means that they can have more control over integration between R/3 and SAP-DB, which is useful. And if SAP owns it, then all the money for licensing flows to SAP.
With the somewhat limited use of SAP DB (compared to Oracle, DB/2, Informix,...), and the difficulty of pushing into a pretty saturated market, it makes as much sense as anything for SAP AG to not worry about getting any licensing revenue from SAP DB, and just give it away. If it gives the vicarious thrill of injuring Oracle a little bit, and injuring Microsoft a little bit, that may be a nice bonus.:-)
SAP DB was previously known as Adabas-D, which, in the venerable past, was one of the original databases on which R/3 ran.
In the even more ancient past (which is really quite some time ago; possibly before some readers were born!), the mainframe-based R/2 system was able to use Adabas on mainframes.
If SAP DB is GPLed (or LGPLed), this is a very interesting thing, probably moreso than the "freeing" of Interbase, as Adabas-D was more like a "scaled down mainframe system" than like a "scaled up PC system."
Another interesting property of Adabas-D that
is hopefully inherited by "Free-SAP-DB" is that it provides an Oracle SQL compatibility mode that tries hard to provide equivalent functionality to Oracle... Probably useful for porting Oracle apps over to it...
Grgory Benford and David Brin wrote a book entitled Heart of the Comet where a mission to land on Halley's Comet gets vigorously affected by nothing less than a space-borne purple "fungus."
In the novel, it turns out to be a potent force for both danger and salvation.
If the Gentle Scientists can't beat the fungus, it may be a neat move to try to find ways to make it outright useful.
This provides Microsoft with some influence over what happens next with WP, which has got to be of some value to them.
The second most important thing about this is that Microsoft gets to control the "bouncing" of Borland Paradox, which appears to be the nearest thing that there is on Linux to a competitor to MS Access.
There are all sorts of other opportunities for "paranoid delusion," notably that this might diminish the ability of Corel to continue to support WINE efforts as a technology that was independent of Microsoft.
Which is distressing if you were planning to put your millions of dollars worth of development effort into cloning Win32 software over to Linux via libWINE, but that sounds rather paranoid-delusional. There are probably as many millions going into that as went into cloning Win16 software over to unix via Willows TWIN...
I think I'll go with "Control over WP's Next Disposition" as the most likely value of this to MSFT...
No, that is not a limitation imposed by the filesystem, so they can't.
As far as I can tell, all of these filesystems allow files vastly bigger than 2GB, but the interface between VFS and LIBC still nicely enforces the 2GB limit for most purposes.
This is the wrong thread on which to try to find resolution to that issue; take it up with the folks that defined ISO and ANSI C...
As has been observed by others, a lot of the machines particularly in the raQ line are using the IA-32 architecture, on which one might consider running, oh, say, Solaris-x86.
It is also important to look forward, not just back, from whence comes thoughts of both IA-64 and SPARC.
One of the significant things Cobalt had was designs for compact-and-hopefully-usable cases and support software; that sort of thing ought to work perfectly well if Sun contributed SPARC motherboards and CPUs to the mix, with compatible form factors. At which point running Solaris-for-SPARC makes perfect sense.
And in looking ahead, the present MIPS chips aren't likely to be viable to the business purpose five years from now, at which point IA-64 might be more likely to be of importance.
The importance of MIPS in all of this is incredibly low, and steadily falling...
The fastest machine on report appears to be a 144-way SMP PentiumII system (if I'm reading that right):
Parnass2 144x PII/400 Myrinet 57684.96
And I'm quite aware that BogoMIPS are an even more Meaningless Indicator of Processing Speed than the indicators that people try to take seriously... It is of practical value, but only in predicting the performance of timing loops...
If the system gets wedged up with a whole lot of #ifdefs, that makes it more and more difficult to maintain. LOTS of them can make software impossible to maintain.
I wouldn't be shocked if the stretching of boundaries that comes from:
"Big Iron" changes, as well as
Embedded System changes
winds up turning into there being some clear demands for forking.
The fundamental problem with a fork comes in the code that you'd ideally like to be able to share between the systems. Device drivers float particularly to mind.
After a 2-way fork, it becomes necessary to port device drivers to both forks, which adds further work.
And if a given driver is only ported to one fork, and not the other, can it correctly be said that
Due to them being largely meaningless, I tend to ignore them any time other than the first time I boot a given system; is 1489 fairly high? Or not?
I would find it unremarkable if there was some Intel chip that had an outrageously higher BogoMIPS rating that would disappear from the "running" as soon as you tossed POVRay onto it...
On the one hand, it tends to be easier to reimplement something that someone else figured out, which means that Intel/AMD/... ought to be able to replicate many of the Transmeta features more quickly since they can avoid some of the learning curve.
On the other hand, Intel/AMD didn't hire the Rather Bright group of engineers of whom Linus Torvalds is merely one in a cast of dozens.
On the gripping hand, Transmeta has obtained patents on many of the more interesting technologies that they developed in the process, thus meaning that Intel/AMD would need to work around them, which I expect is an underlying assumption in the assertion that it would take some years to replicate it all...
I haven't seen any aggrevious "marketing spiels" on the X newsgroups lately; the clueless PR guy got "stomped on" pretty good the last time, and it looks as if they may have gotten the clue that it's wiser to say nothing at all rather than to pull the You're having problems? Dump XFree86 and buy our product! thing with all the attendant bad publicity.
My usual reaction to thoughts of buying Accelerated X is to suggest, as a thought, that the gentle reader consider:
Spending the $200 on a card that is supported by XFree86 ;
Spending $100 on a supported card, and donate $100 to XFree86.
The one situation where Xi's products really might commend themselves are where you want to use a really high end 3D graphics card in conjunction with a heavily tuned OpenGL implementation.
The other arguable situation where one might need Xi is when you get yourself into the unfortunate condition of having bought a laptop for which XFree86 does not support the video chipset.
Although I think I'd rather do business with MetroLink, personally...
You make a bunch of good comments; I guess it stands as a pretty big unknown now as to how difficult it is to create your own bootable CD as an alternative to the built-in one.
As for the "lack of storage," I don't see that as a huge problem:
If your plan is to use your own customized flash card, you're going down a road towards substantial configuration complexity whereby you'll have to get quite intimate with how it works...
The other major way to use it is to mount writable storage from somewhere else, say via NFS, in which case what bits of storage sit locally are quite irrelevant.
I prefer the latter option, personally; combine having writable storage elsewhere with a customized CD and this might work pretty well. All it is forcibly missing is the space for extra NIC.
With a lot of games, there are several components that are not all of equal "creativity."
I'll suggest the thought that gaming "engines" represent something that could indeed come together via some sort of "Open Source" scheme, whilst other parts of a game, such as the setting of "physics parameters," creation of "artsy stuff" like pictures, and the construction of what relationships are used in the game represent something "less open."
For instance, someone might create a really cool Quake level, with customized graphical images, as well as parameters and maze layout being set up to be somehow "particularly fun to play." If someone messes with it, it becomes somehow less satisfactory, much as James Joyce's "The Dubliners" would likely suffer if you or I were to "tweak" it as we wish.
With Quake, the "engine" somewhat corresponds to the way books have pages, and standard sorts of formatting, and familiar fonts. That can reasonably be quite open. In contrast, a well-put-together Quake level, or other game scenario, is somewhat like a novel. It loses some of its "artistic integrity" if you mess with it.
Some "game scenarios" might be pretty robust, and even designed for you to fiddle with. Others may be very fragile, where any change will work ill.
The crucial thing about free software in this context is that in order for it to work for games, which are of arguably "frivolous" value, someone has to be willing to sponsor/commission their creation beforehand. "Open source" has been particularly successful with tools that were of demonstrable utility to their makers. If working on cfengine provides you utility, then it is clearly worthwhile, even if you subsequently give away the results.
With games, the utility is less demonstrable, and it may be necessary to have a "rich patron" willing to pay for production beforehand, with no expectation of future returns.
A few people wanting to fool around with flight simulation can find "fooling around with flight simulation" of sufficient utility to justify producing a flight sim; that's not quite the same thing as producing a line of "cool video games."
Slashdot Mirror
But not to worry... They had not accounted for the fact that you might want to have more than one telephone. Personally, I have two telephones in my apartment, and connect to my ISP and to TiVo service using the one line as well. Add to that the "mobile telephony" equipment...
The parallels to computing should be blatantly obvious; families already have the issue of family members "disputing" over who gets to use the computer.
In the long run, it would make a whopping lot of sense for there to be a whole "horde" of computers in a home, between:
Whether firewall or "Internet Services Server," this option seems eminently likely.
What The World Really Needs is a $250 firewall box that runs Linux, and integrates in a cable modem and an Ethernet hub. No screen, by default; perhaps not even a hard drive.
To be sure, not all of these are practical applications at present, but the fact that it's easy to come up with additional such uses is pretty suggestive that those that think the markets are "saturated" probably haven't thought hard enough.
Obviously it makes sense to select the "politicians" from the group of people that are interested in participating in the project. If no women were interested in participating, it is unsurprising that none were available for selection.
The problem, if it be considered such, does not lie in the selection of the FreeBSD core team, but rather way back when people decide what sorts of things they want to get involved with. Where there weren't any women that put FreeBSD on their lists.
- You can either "mount" the resultant FS publicly, so that anyone on your system can see it, or
- Each and every program that wants to go after encrypted data needs to individually explicitly include cryptographic support to read keys and access/update encrypted data.
Neither of these are terribly satisfactory. The first approach leaves a lot of stuff visible in plaintext form, whilst the latter pushes a substantial burden for encryption support into each and every program.As is nicely outlined here , the Plan 9 operating system provides the ability to do this Another Way, using the concept of namespaces. The basic idea is that the "file tree" is no longer a global thing, but is, instead, localized to processes.
In effect, I might, from my shell, run the command:
mount -t crypto /home/cbbrowne/encrypted-stuff /mounts/plaintext
This results in the encrypted stuff in my home area getting attached to the file tree under /mounts/plaintext
The two clever things about this are that:
Entertainingly, perhaps not even to root.
Why should this be considered relevant to Linux? Because there has been considerable discussion of namespaces in relation to the Linux kernel. It won't be in 2.4, but it's the sort of thing Alex Viro is liable to consider experimenting with in 2.5 or some such version.
I expect that "Open Office" isn't quite so challenging, but I sure it does depend on some stuff. Does it need Lesstif? How about other such stuff?
On the other hand, the Salon article seems to indicate that the consortium that created SDMI is politically fragile. Which suggests a different set of outcomes:
Which leaves nobody there to agree on a "SDMI Mark II".
Given financial stability, they might attain the funding to mount a legislative response to a later cipher attack.
In effect, the hackers might attack now, while SDMI is weak, and destabilize it from a political perspective.
It is possible that the scenarios I suggest are not representative, but if they are, which seems possible, this certainly paints a rather different picture.
I'll be quite happy to not bother drooling about this for another six months while AMD shakes out any bugs in implementations of mobos, memory interfaces, and distribution. And they should be "less than spectacularly expensive" by that point too...
Yes, indeed, the notion that corporations "pay taxes" is a fiction. If they don't either "charge it back" to their customers, or pass it on to their owners, then the tax essentially demolishes their ability to be profitable on behalf of the owners, making them unviable. (I've actually prepared corporate income tax returns, so I quite know that this needs to be couched in all sorts of "legal ums and ahs" in order to be treated as true...)
On The Other Hand. Corporate "taxation," such as it is, exists for two reasons:
By providing something that pretends to tax the corporation, and which potentially hits up the individual for two tax bills rather than one, this forces the individual to make the company disburse incomes sooner.
The essence of it is that there are people that have vigorously strong positions on some peculiar issues and that there is little point to trying to debate the issues even if you think you have a rational position and can debate rationally.
There are enough people who have strongly irrational positions, whether due to mental instability (suggested in the essay, and likely, in my view, for "crackpot" theories) or (I would add) due to having strong emotional feelings surrounding the issue, and likely to be true for situations such as the Abortion debate, matters in the Middle East, and anything relating to Nazi Germany.
In effect, this provides a corollary to Godwin's Law that topics involving large numbers of deaths and/or outright wars evoke such strong emotion that many find it hard to detach themselves from the issue so as to discuss the issue rationally.
And if the matter is "insane" to begin with (e.g. - as with most "conspiracy theories"), there is no "rational" side to start with...
The Apple SMP systems seem fairly nice, but rather expensive.
It's not a realistic alternative unless I can specify the specs rather than living with whatever AAPL tells me I can buy.
I've idly watched the OpenPPC project; apparently the direct offspring, Pop Computers, found that they had severe procurement problems.
This does not a viable market make.
You can be aggressive in trying to personally attack or annoy the telemarketers; the problem with that is that:
This is a bottom end job, taken by people that have had few better opportunities. They make no decisions, and annoying one of them merely annoys one of them.
I instead suggest looking to JunkBusters.com. These are the same people that produce the beloved Junkbuster "web proxy" that can block cookies and evil ad banners for you.
Notably see JUNKBUSTERS Telemarketing Headlines, subtitled How to reduce the number of junk phone calls you get.
I use this regularly, and it did the trick with MCI.
I still get an irritating number of calls from the companies I already do business with, mostly the credit card cretins; the LD Provider calls significantly diminished when I started at least partially following the "JunkBuster Script."
(Horrors! That sounds terrifyingly close to "chain letter" systems!)
This is quite a significant issue, as libraries compiled with one release of G++ by one person may not work with another release of G++ by someone else.
This appears to be the root of the problems I had running Opera; it would generally run OK until I actually tried to load in a web page, at which point it would discover it had just tried to violate a segment. That was with the statically-linked version; a dynamically-linked version will be at even greater risk of ABI violations...
Is this of any practical value? Well, a DPS-6 is likely about as powerful as an 80386, and it won't likely fit in your closet, so it's fair to say that it's not a terribly practical proposal.
Likewise, an iPaq has a pretty small screen, small memory, small secondary storage, and no keyboard, thus meaning that it's not a vastly practical computing platform on which to run Debian.
However. Consider two things:
Which means that while it's not spectacularly useful now, if some people scramble to work on it now, they may start having useful software and configuration tools (and boot tools, and...) by the time the hardware is ready to be really useful.
Nobody is going to power up a DPS-6 because they want to run payroll on it, or write TECO macros to calculate Pi because that's a particularly efficient way to do it; they'll do it because they can.
I think that in another year, there may well be enough hardware on PDAs to usefully run Linux. More power to those experimenting with it now that will make it deployable by then.
It was pretty likely that many of the companies spending lots on Adabas-D were running R/3 on top of it, in which case it makes sense for the DB to jump over to SAP as it is effectively being used as an "embedded" database, not as a fullscale product in its own right. For SAP to "own" it means that they can have more control over integration between R/3 and SAP-DB, which is useful. And if SAP owns it, then all the money for licensing flows to SAP.
With the somewhat limited use of SAP DB (compared to Oracle, DB/2, Informix, ...), and the difficulty of pushing into a pretty saturated market, it makes as much sense as anything for SAP AG to not worry about getting any licensing revenue from SAP DB, and just give it away. If it gives the vicarious thrill of injuring Oracle a little bit, and injuring Microsoft a little bit, that may be a nice bonus. :-)
In the even more ancient past (which is really quite some time ago; possibly before some readers were born!), the mainframe-based R/2 system was able to use Adabas on mainframes.
If SAP DB is GPLed (or LGPLed), this is a very interesting thing, probably moreso than the "freeing" of Interbase, as Adabas-D was more like a "scaled down mainframe system" than like a "scaled up PC system."
Another interesting property of Adabas-D that is hopefully inherited by "Free-SAP-DB" is that it provides an Oracle SQL compatibility mode that tries hard to provide equivalent functionality to Oracle... Probably useful for porting Oracle apps over to it...
In the novel, it turns out to be a potent force for both danger and salvation.
If the Gentle Scientists can't beat the fungus, it may be a neat move to try to find ways to make it outright useful.
The second most important thing about this is that Microsoft gets to control the "bouncing" of Borland Paradox, which appears to be the nearest thing that there is on Linux to a competitor to MS Access.
There are all sorts of other opportunities for "paranoid delusion," notably that this might diminish the ability of Corel to continue to support WINE efforts as a technology that was independent of Microsoft.
Which is distressing if you were planning to put your millions of dollars worth of development effort into cloning Win32 software over to Linux via libWINE, but that sounds rather paranoid-delusional. There are probably as many millions going into that as went into cloning Win16 software over to unix via Willows TWIN...
I think I'll go with "Control over WP's Next Disposition" as the most likely value of this to MSFT...
As far as I can tell, all of these filesystems allow files vastly bigger than 2GB, but the interface between VFS and LIBC still nicely enforces the 2GB limit for most purposes.
This is the wrong thread on which to try to find resolution to that issue; take it up with the folks that defined ISO and ANSI C...
It is also important to look forward, not just back, from whence comes thoughts of both IA-64 and SPARC.
One of the significant things Cobalt had was designs for compact-and-hopefully-usable cases and support software; that sort of thing ought to work perfectly well if Sun contributed SPARC motherboards and CPUs to the mix, with compatible form factors. At which point running Solaris-for-SPARC makes perfect sense.
And in looking ahead, the present MIPS chips aren't likely to be viable to the business purpose five years from now, at which point IA-64 might be more likely to be of importance.
The importance of MIPS in all of this is incredibly low, and steadily falling...
And I'm quite aware that BogoMIPS are an even more Meaningless Indicator of Processing Speed than the indicators that people try to take seriously... It is of practical value, but only in predicting the performance of timing loops...
I wouldn't be shocked if the stretching of boundaries that comes from:
- "Big Iron" changes, as well as
- Embedded System changes
winds up turning into there being some clear demands for forking.The fundamental problem with a fork comes in the code that you'd ideally like to be able to share between the systems. Device drivers float particularly to mind.
After a 2-way fork, it becomes necessary to port device drivers to both forks, which adds further work.
And if a given driver is only ported to one fork, and not the other, can it correctly be said that
or do we need to be forever vague about that?I would find it unremarkable if there was some Intel chip that had an outrageously higher BogoMIPS rating that would disappear from the "running" as soon as you tossed POVRay onto it...
On the other hand, Intel/AMD didn't hire the Rather Bright group of engineers of whom Linus Torvalds is merely one in a cast of dozens.
On the gripping hand, Transmeta has obtained patents on many of the more interesting technologies that they developed in the process, thus meaning that Intel/AMD would need to work around them, which I expect is an underlying assumption in the assertion that it would take some years to replicate it all...
My usual reaction to thoughts of buying Accelerated X is to suggest, as a thought, that the gentle reader consider:
The one situation where Xi's products really might commend themselves are where you want to use a really high end 3D graphics card in conjunction with a heavily tuned OpenGL implementation.
The other arguable situation where one might need Xi is when you get yourself into the unfortunate condition of having bought a laptop for which XFree86 does not support the video chipset.
Although I think I'd rather do business with MetroLink, personally...
As for the "lack of storage," I don't see that as a huge problem:
- If your plan is to use your own customized flash card, you're going down a road towards substantial configuration complexity whereby you'll have to get quite intimate with how it works...
- The other major way to use it is to mount writable storage from somewhere else, say via NFS, in which case what bits of storage sit locally are quite irrelevant.
I prefer the latter option, personally; combine having writable storage elsewhere with a customized CD and this might work pretty well. All it is forcibly missing is the space for extra NIC.I'll suggest the thought that gaming "engines" represent something that could indeed come together via some sort of "Open Source" scheme, whilst other parts of a game, such as the setting of "physics parameters," creation of "artsy stuff" like pictures, and the construction of what relationships are used in the game represent something "less open."
For instance, someone might create a really cool Quake level, with customized graphical images, as well as parameters and maze layout being set up to be somehow "particularly fun to play." If someone messes with it, it becomes somehow less satisfactory, much as James Joyce's "The Dubliners" would likely suffer if you or I were to "tweak" it as we wish.
With Quake, the "engine" somewhat corresponds to the way books have pages, and standard sorts of formatting, and familiar fonts. That can reasonably be quite open. In contrast, a well-put-together Quake level, or other game scenario, is somewhat like a novel. It loses some of its "artistic integrity" if you mess with it.
Some "game scenarios" might be pretty robust, and even designed for you to fiddle with. Others may be very fragile, where any change will work ill.
The crucial thing about free software in this context is that in order for it to work for games, which are of arguably "frivolous" value, someone has to be willing to sponsor/commission their creation beforehand. "Open source" has been particularly successful with tools that were of demonstrable utility to their makers. If working on cfengine provides you utility, then it is clearly worthwhile, even if you subsequently give away the results.
With games, the utility is less demonstrable, and it may be necessary to have a "rich patron" willing to pay for production beforehand, with no expectation of future returns.
A few people wanting to fool around with flight simulation can find "fooling around with flight simulation" of sufficient utility to justify producing a flight sim; that's not quite the same thing as producing a line of "cool video games."