There are many possible perpectives from which to view this.
"Naive" home users that aren't quite sure what a distribution is are the group that people tend to think of first.
"Corporate" users that are trying to build centralized systems are probably the second group people think of.
Developers/experienced Linux folk are usually not the ones thought of, except from the perspective of being curmudgeons that say, ``Here's a nickel - buy yourself a real OS.''
Everyone else will probably take the "Naive home user" perspective; I'll take the "experienced developer" perspective just to provide more perspective.
I find it greatly interesting that these Debian-based distributions are now attaining wide-spread acceptance. And I suggest that the perspective I'm taking is relevant to this.
Debian has had the merit, over the RPM-based systems, of providing a full-fledged tool set directed at integrating together a distribution. It's not just the dpkg package manager; Debian's tool set sweeps much wider, including:
dselect, a package selector that knows how to look up packages from a multiplicity of locations, and do something about making sure that a suitable set of packages (Plural!) are selected in order to satisfy dependancies.
Yes, it's pretty klunky, and something newer and prettier would be nice. That's part of what Stormix provides...
apt-get, which manages multiplexing of where packages come from.
dpkg-create and various related tools.
These are the components that are even more important than the previous ones.
The many RPM-based distributions suffer, and suffer badly, from the fact that RPM itself can only go so far in validating that packages are well-constructed.
Distribution makers like RHAT, SUSE, Caldera, and TurboLinux should have some significant automated tools to help them maintain correctness, although that is not known for sure, and I am skeptical that this is actually the case.
And that is of critical value when you're trying to avoid the "Oh, it's a.0 release from Red Hat, so watch out for big problems! " situation. That has been a significant problem for Red Hat; I'm quite sure that the presence of things like lintian, debhelper, and others has helped Corel and Stormix substantially, much as it helps maintainers of "plain Debian" packages.
They're only "Leaders" insofar as they're contributing code that is getting widely used.
That could ultimately be the case, but the assertion that they can thus "take a leadership role" is pretty funny. In the free software community, you can't take anything; you can only be a leader by giving away more than anybody else. I suspect they'd find that a mite challenging; it seems to me that IBM's AlphaWorks program is a stronger contender for the status...
The thing that is particularly exciting about InterBase, setting it apart from any of the already-libre options for Linux, is the fact that InterBase was designed as an embedded RDBMS. In the "open source" context, the opening of the code ought to allow the system to be deconstructed into a set of libraries to separate data store from SQL interpreter (to name the most obvious bits) as well as, hopefully, lock manager and transaction manager and probably some other "useful bits." That is very important in that:
There are lots of applications that could use an embedded data store. They may not need SQL very badly; if "OpenInterBase" allows dropping off unneeded bits, this can turn into a very low overhead scheme.
As an embedded DBMS, InterBase has the two important properties of
Not requiring much, if any DBA work.
This is a pretty major issue at present with other DBMSes like MySQL and PostgreSQL.
Putting the database in a few files that should be user-controllable
... Which should make it easier for naive users to install and backup their data...
It takes some doing to get DBMSes up and running and configured to be usable; InterBase should "lower the bar" on this, which is a very good thing.
Borland didn't actually own much of the software that they used to sell; they were essentially reselling software produced by other companies.
One of the more notable examples of this is Turbo Prolog, which is effectively still being sold by its original producers. Take a look on Google for "Visual Prolog."
I certainly agree with your comments about "No New License, Please!"
RISC OS was an OS developed for the Acorn platform. This was a British phenomenon; I believe that these machines were StrongARM-based, which is where the RISC part comes in.
Acorn is no longer in operation, and so a whole lot of RISC OS folk have started looking at Linux/X as their future platform.
This is a pretty good thing; they may have some useful UI ideas, as well as useful code that might be ported.
Is it be better to have 64 serial lines that, with a bit of buffering, can handle a diverse set of concurrent communications?
Or is it better to have those lines used to create a single channel that can "burst mode" impressively, but which is hard to keep busy?
Parallel is great for integrated buses, where you're going to try to have a bunch of fast devices share those "64" lines.
But, if you can get some really fast serial connections that only use a wire or two apiece, this can simplify the individual circuits.
And as the serial connections operate in an asynchronous manner, "bursting" goes away, and the system is liable to cope more gracefully with diverse kinds of "traffic."
Would I rather have:
A 64 bit SUPER-SCSI channel that can burst data across at 64GB/s, at those few moments when I'm trying to do so, and which more typically only handles 8GB/s because there's not a disk drive that can keep up.
32 independent channels providing 1GB bandwidth apiece, from which I can get a sustained load of 24 GB/s?
I think I'd rather have the latter, even though it has lower "burst speed."
People talk about "replacements" to X all the time. It is fairly typical for such discussions to represent illiterate ravings of those that understand neither X nor the systems they think are candidates to replace X.
Berlin can't be a replacement for X; it's not a hardware-oriented system.
Only idiots compare Berlin to X, as the systems have very little functionality in common. X knows how to talk to hardware, whereas Berlin doesn't. Berlin needs to have some combination of GGI and OpenGL.
It would be vastly more sensible to compare Berlin to GTK, Qt, or FLTK, as that is where there might be properties in common.
A replacement for X needs to have some vaguely similar degree of portability.
It needs to run on many kinds of systems.
GGI would be the most likely candidate for this; it's not there yet.
A replacement for X needs to provide vaguely similar levels of network interoperability.
Yes, there are users that only want to run applications on one host's console. And that's why X provides things like the SHM extension so that if everything's local, performance can be made better.
But those that focus on Console! Console! Console! are ignoring that they're not the only users, they're restricting flexibility, and, more importantly, they're ignoring that network support is getting more important all the time. You see, there's this newfangled "Internet" thing...
"GnotX" won't represent a realistic alternative unless it is network-aware.
And then there's the application problem.
If the new system doesn't permit running the applications that we already have, then this means discarding all of the X-based software that people have been finding useful over the last dozen years.
Notably, no more KDE, no more GNOME, no more StarOffice, no more WordPerfect, no more ApplixWare, no more Netscape.
Even if there was a way that "GnotX" made a GTK, and thereby GNOME, port easy, this would definitely be injurious to vendors of X software like ApplixWare and WordPerfect (that have some Motif involvement, and thus mandate having a real good X emulation).
"Legacy" vendors won't see this as a move to cooperate with, and like it or not, that's a factor having significance.
Then there's the BIG problem.
People propose things as replacements for X that weren't truly designed as such, or that, worse still, aren't really designed at all.
The original incarnation of "Berlin" amounted to this; they flung epithets at X, claiming it was obsolete, and that they'd do K001 x86 assembly hacking to produce something that would just destroy X.
This was quite silly; they never had a clear design, only a set of claims that amounted to "Because We're Cool Hackers, We'll Outdo X." That may represent intent; that does not represent design.
In some senses it's not that impressive to get an interview with Maddog. After all, Slashdot is a major site visited by Linux folk, and Maddog is "major Linux folk." That's a "natural" interview.
An interview with Woz is "more impressive" in that it's something that you might not have expected. There's not as much reason for him to want to be associated with the denizens of Slashdot.
The fact that Davilean actually entered the language as a word for stupendously massive mistake is pretty cool; the idea of someone's name being put in the dictionary as synonymous with such has been popular, but I wasn't aware it had happened.
It goes to prove Mitch Radcliffe's contention that:
Computers let you make more mistakes faster than any other invention in human history, with the possible exception of handguns and tequila.
The point I was trying to make was that the "Tier 1" DBMS vendors are unlikely to be seriously injured by InterBase becoming "free."
Those that want 24x7 support contracts and the likes for big SMP boxes with big RAID arrays aren't going to be much more attracted to InterBase because it becomes free than they were before when it wasn't.
In contrast, those that were price-sensitive, and went with SOLID/ Altera/... may seriously consider trying out Interbase as an even less expensive alternative that doesn't tie them to proprietary licensing.
The company most likely to lose from this is SOLID. They got pretty seriously "flamed" a while back due to a change in licensing strategy; they used to sell individual licenses for around $200-$300, but have moved to selling groups of licenses so that the minimum price granularity is rather higher, more like $10K.
That is a market rather more vulnerable to Interbase's "scorched earth" strategy...
Certainly licensing is important; I just don't think it's worth discussing in too much detail until further details come out.
Lots of paradoxical effects are possible; the fact that PostgreSQL uses a BSD-like license means that it may be easier to do code integration between it and Interbase, as compared to GPLed MySQL, where the somewhat "infectious" nature of the license may discourage attempts to integrate code.
I certainly agree that YAPOPL (Yet Another Pseudo-Open Proprietary License) would discourage development efforts, but suggest that the relative merits/implications of GPL versus BSDL are quite nonintuitive and nonobvious.
Prolog Development Center (PDC) was founded in 1984 with the development of a Prolog compiler - later to be known as Turbo Prolog, PDC Prolog and now Visual Prolog as its main activity. Since then PDC has established itself as a world leader in the development of Prolog and related products.
Today, PDC consists of an R&D and a consultancy division. The R&D Division is concerned with the development of the Visual Prolog compiler together with new methodologies and development tools.
Borland might be an evidence against the common contention that "Microsoft is the company that never produces anything, but merely buys out products from other companies that are creative," as many of Borland's products were not natively produced, but rather resold on behalf of other componies.
By the way, that was Ashton Tate that used to own the dBase trademark...
As for integration with DBM variants, I see little importance to that. InterBase is a relational database (or at least, as relational as they come), as opposed to merely being a data store. The value would be in sharing code between InterBase and PostgreSQL or MySQL, or maybe using InterBase as a "data store" for persistent data in KDE or GNOME.
Russia used this militarily to destroy both French and German armies; they performed strategic retreats when "outgunned," destroying crops and other infrastructure so that when the Russian winter set in, opponents were overextended, and despite "winning the battle," wound up losing the war.
This obviously came at the cost of considerable Russian destruction, and with Inprise, the cost is that of not getting revenues from license sales, whilst the immediate benefit is that this may injure sales of competing DB vendors.
The open question is of how this affects already-free DBs like MySQL and PostgreSQL.
Effects on them are severalfold, and some are dependent on what license Inprise comes up with:
Regardless of the license, it should be useful to have source code access as this can allow folks to see an implementation of transaction locking, stored procedures, SQL-CLI, ODBC, as well as the data storage mechanis, which may be quite useful when they try to add such functionality to other DBMS systems even if there is no reuse of code.
If the license is sufficiently compatible, it may prove possible to integrate code one way or another either into "OpenInterBase" or into one of the other DBMSes.
Note that the folks likely to get particularly injured by this are the second/third tier companies selling licenses to things like:
Altera
SOLID SQL Server
OpenIngres
Mimer
Faircom
Raima
Yard
Empress
whilst people will still likely be prepared to "pay the bucks" to move up to "Tier 1" DBMSes like Sybase/Oracle/Informix/DB2
As with Bruce Schneider's recent presentations in various fora on "Attack Trees," a vulnerability such as "rewriting microcode" needs to be put into proper focus within the context of the natures of plausible attacks, and the relative costs thereof.
This is a game, in that attacker and defender both can construct decision trees for analysis, and treat this as a minimax problem in order to establish the most fruitful attacks and defenses.
I suppose it's difficult to be certain without running through the minimax problem, but I don't think that "vulnerability to rewriting microcode" will rank terribly high on the list.
After all, it's likely that reprogramming microcode represents something that you'd have to be in supervisor mode to do, e.g. having your code running in Ring 0.
The thing is, once the attacker's code is there in Ring 0, they've already won.
Being in Ring 0 (or an equivalent thereof) means that your process can do practically anything.
I think that's enough of an analytical result right there to establish that a "microcode attack" isn't going to be terribly feasible, as it's an attack that implies that security has already been fairly irretrievably breached.
Consider making this concrete on Linux.
If IA-64 allows user mode ( e.g. "Ring higher than 0") code to hit on the microcode engine that controls what happens in supervisor mode, THIS IS INDEED A SPECTACULAR BREACH. I can't believe that Intel could possibly be that stupid. IA-32 may be a very ugly hacked up design for many reasons; it is not a stupid design in that way.
If, on the other hand, only code in "Ring 0," e.g. kernel code, can modify microcode, then this is no worse an issue than the issues we already have with the need to trust and secure the code that runs in the kernel.
Michael Chaney was helpful in a place where throwing insults might have been easier.
The assistance was actually helpful, with no attempt to (say) change ownership of the domain name or other "giving with one hand, whilst injuring with the other."
This was a pretty "purely giving" thing, in stark contrast with Microsoft's usual greed.
It's quite entertaining that this represents an opportunity for some "Linux folk" to usefully debug a Microsoft "bug."
Michael Chaney was helpful in a place where throwing insults might have been easier.
The assistance was actually helpful, with no attempt to (say) change ownership of the domain name or other "giving with one hand, whilst injuring with the other."
This was a pretty "purely giving" thing, in stark contrast with Microsoft's usual greed.
... If the box is sitting in a concrete bunker, with no wires heading to the outside world, and armed Rangers around the base, this issue isn't that much of an issue.
I really don't think this is a significant matter for machines that are either:
Not required to be particularly secure, or
Are housed in rather secure environments.
It's fair to say that AMD might provide "better bang for the buck;" the insecurity of microcode is, however, something that organizations have been coping with since microcode computers were invented, which likely dates back to the '60s.
As for "You'd never know it," a secure US Army site is likely one of the places to which Intel would be willing to release secrets as to protocols necessary to validate that the microcode hasn't been tampered with, no?
The vaguely anticapitalist crusade is about the only faintly new comment, and only insofar as that's a three word way of nicely describing the ambiguity of the relationship between "free software" and "business."
Boy, this is liable turn into an illuminating thread... NOT.
What "the world needs" is for there to be some automated tools to help search for configuration problems of this sort.
Something like cfengine would be usable to this end; make install should generate a cfengine script that validates the system configuration, with the option of either warning of problems or of fixing them.
If not cfengine, then something else may be usable.
The critical point here is for the tool used to not merely be "a shell script," as those may get diverse in style to the point of unreadability. The validation needs to be in more of a descriptive style so that it doesn't get unreadable.
In order for there to be a Standard User Interface For Linux, there needs to be a formal standard established so that there exists a "de jure" Standard User Interface.
Consider for a moment that people keep finding it necessary to create new UIs; this is evidence that the elements needed to establish such a standard have not "settled down" yet.
If there is a 64 bit AMD CPU, called the K8, why isn't it listed on the AMD website as a product that they sell?
Reality is that There is no such product. "K8" has not been announced. Do a search at the AMD website and you will not find it.
AMD has announced something codenamed "Sledgehammer" but that was announced as a FUTURE PRODUCT.
And as far as the Athlon/Alpha motherboard interoperability, I'll believe it when I see it.
Alpha Interesting if It Gets Marketed
on
News on Pentium IV
·
· Score: 2
They have to have both product and marketing in order to, in your words,
own the 64 bit arena
I'm not convinced that this is likely; Digital has long had some pretty good products, but have lately had an inability to sell their way out of a wet paper bag.
The recently announced Compaq/Samsung venture to put effort back into Alpha may be helpful, if they actually provide powerful product for decent value. It's not clear that they're likely to out-market Intel, which is a critical issue.
This connects doubly to AMD:
AMD doesn't yet have a 64 bit CPU, and while there has been talk, there is little evidence to indicate what it would really be.
I suspect their choice needs to be between third-sourcing Alphas or creating an "IA-64 clone."
The former merely makes them a "me too" vendor; the latter runs the risk of running afoul of Intel patents and/or other "design license" restrictions.
I am at a loss to decide which outcome is more likely.
The connections between Athlon and Alpha seem to be rather more tenuous than "Slashdot Discussions" try to suggest.
The common thing is the memory access protocol, which implies very little about there being any other interoperability between Athlon and Alpha.
The inflationary effect depends on just which of the money supply variables is the true determinant of inflation.
If it be "M0" (which is essentially "Hard Cash"), then there will be an inflationary effect directly correlated with the amount of cash that the US Treasury issues.
I agree that this probably isn't the right measure, as there's reasonably more to money supply than this.
If it be "M1" (which adds in bank deposits), then you'd expect there to be no net effect, because all people do is to pull out deposits and turn them into cash, right?
This is closer to the truth than claims about M0.
But. I prefer another scenario...
The "hard cash" money supply increase comes at the "cost" of people diminishing both:
Amounts on deposit (e.g. - amounts that would be considered to be in M1, M2, and possibly some of the more abtruse money supply measures) with the result that from an inflationary point of view, they are "a wash."
There will also be...
Amounts pulled out of long term savings, whether by cashing in investments or by choosing not to invest.
These amounts unambiguously increase the money supply regardless of which variation you prefer...
Slashdot Mirror
Consider, just for starters: The main character of the story is named Jim Hacker.
- "Naive" home users that aren't quite sure what a distribution is are the group that people tend to think of first.
- "Corporate" users that are trying to build centralized systems are probably the second group people think of.
- Developers/experienced Linux folk are usually not the ones thought of, except from the perspective of being curmudgeons that say, ``Here's a nickel - buy yourself a real OS.''
Everyone else will probably take the "Naive home user" perspective; I'll take the "experienced developer" perspective just to provide more perspective.I find it greatly interesting that these Debian-based distributions are now attaining wide-spread acceptance. And I suggest that the perspective I'm taking is relevant to this.
Debian has had the merit, over the RPM-based systems, of providing a full-fledged tool set directed at integrating together a distribution. It's not just the dpkg package manager; Debian's tool set sweeps much wider, including:
Yes, it's pretty klunky, and something newer and prettier would be nice. That's part of what Stormix provides...
These are the components that are even more important than the previous ones.
The many RPM-based distributions suffer, and suffer badly, from the fact that RPM itself can only go so far in validating that packages are well-constructed.
Distribution makers like RHAT, SUSE, Caldera, and TurboLinux should have some significant automated tools to help them maintain correctness, although that is not known for sure, and I am skeptical that this is actually the case.
The Debian Maintainer Tools provides considerable assistance to the developer doing package maintenance work. As do the Debian Developers Manuals.
And that is of critical value when you're trying to avoid the "Oh, it's a .0 release from Red Hat, so watch out for big problems! " situation. That has been a significant problem for Red Hat; I'm quite sure that the presence of things like lintian, debhelper, and others has helped Corel and Stormix substantially, much as it helps maintainers of "plain Debian" packages.
Both implement databases via one or a very few files.
I seriously doubt that the formats of the files are simple; the intent surely sounds the same.
That could ultimately be the case, but the assertion that they can thus "take a leadership role" is pretty funny. In the free software community, you can't take anything; you can only be a leader by giving away more than anybody else. I suspect they'd find that a mite challenging; it seems to me that IBM's AlphaWorks program is a stronger contender for the status...
The thing that is particularly exciting about InterBase, setting it apart from any of the already-libre options for Linux, is the fact that InterBase was designed as an embedded RDBMS. In the "open source" context, the opening of the code ought to allow the system to be deconstructed into a set of libraries to separate data store from SQL interpreter (to name the most obvious bits) as well as, hopefully, lock manager and transaction manager and probably some other "useful bits." That is very important in that:
- Not requiring much, if any DBA work.
- Putting the database in a few files that should be user-controllable
... Which should make it easier for naive users to install and backup their data ...
It takes some doing to get DBMSes up and running and configured to be usable; InterBase should "lower the bar" on this, which is a very good thing.This is a pretty major issue at present with other DBMSes like MySQL and PostgreSQL.
One of the more notable examples of this is Turbo Prolog, which is effectively still being sold by its original producers. Take a look on Google for "Visual Prolog."
I certainly agree with your comments about "No New License, Please!"
RISC OS was an OS developed for the Acorn platform. This was a British phenomenon; I believe that these machines were StrongARM-based, which is where the RISC part comes in.
Acorn is no longer in operation, and so a whole lot of RISC OS folk have started looking at Linux/X as their future platform.
This is a pretty good thing; they may have some useful UI ideas, as well as useful code that might be ported.
That could be compared to HTTP, where there are an extremely diverse set of web servers, resulting from its relative simplicity.
As for the size of X, I understand that the port to the Itsy weighed in at about 300K. The things in X that are bloated are things like:
- Font cacheing and the simple fact that scaled fonts eat RAM
- Cacheing of hidden objects/windows
which represent things that would cause similar "bloat" in any alternative system.Parallel is great for integrated buses, where you're going to try to have a bunch of fast devices share those "64" lines.
But, if you can get some really fast serial connections that only use a wire or two apiece, this can simplify the individual circuits.
And as the serial connections operate in an asynchronous manner, "bursting" goes away, and the system is liable to cope more gracefully with diverse kinds of "traffic."
Would I rather have:
- A 64 bit SUPER-SCSI channel that can burst data across at 64GB/s, at those few moments when I'm trying to do so, and which more typically only handles 8GB/s because there's not a disk drive that can keep up.
- 32 independent channels providing 1GB bandwidth apiece, from which I can get a sustained load of 24 GB/s?
I think I'd rather have the latter, even though it has lower "burst speed."Only idiots compare Berlin to X, as the systems have very little functionality in common. X knows how to talk to hardware, whereas Berlin doesn't. Berlin needs to have some combination of GGI and OpenGL.
It would be vastly more sensible to compare Berlin to GTK, Qt, or FLTK, as that is where there might be properties in common.
It needs to run on many kinds of systems.
GGI would be the most likely candidate for this; it's not there yet.
Yes, there are users that only want to run applications on one host's console. And that's why X provides things like the SHM extension so that if everything's local, performance can be made better.
But those that focus on Console! Console! Console! are ignoring that they're not the only users, they're restricting flexibility, and, more importantly, they're ignoring that network support is getting more important all the time. You see, there's this newfangled "Internet" thing...
"GnotX" won't represent a realistic alternative unless it is network-aware.
If the new system doesn't permit running the applications that we already have, then this means discarding all of the X-based software that people have been finding useful over the last dozen years.
Notably, no more KDE, no more GNOME, no more StarOffice, no more WordPerfect, no more ApplixWare, no more Netscape.
Even if there was a way that "GnotX" made a GTK, and thereby GNOME, port easy, this would definitely be injurious to vendors of X software like ApplixWare and WordPerfect (that have some Motif involvement, and thus mandate having a real good X emulation).
"Legacy" vendors won't see this as a move to cooperate with, and like it or not, that's a factor having significance.
People propose things as replacements for X that weren't truly designed as such, or that, worse still, aren't really designed at all.
The original incarnation of "Berlin" amounted to this; they flung epithets at X, claiming it was obsolete, and that they'd do K001 x86 assembly hacking to produce something that would just destroy X.
This was quite silly; they never had a clear design, only a set of claims that amounted to "Because We're Cool Hackers, We'll Outdo X." That may represent intent; that does not represent design.
An interview with Woz is "more impressive" in that it's something that you might not have expected. There's not as much reason for him to want to be associated with the denizens of Slashdot.
It goes to prove Mitch Radcliffe's contention that:
Those that want 24x7 support contracts and the likes for big SMP boxes with big RAID arrays aren't going to be much more attracted to InterBase because it becomes free than they were before when it wasn't.
In contrast, those that were price-sensitive, and went with SOLID/ Altera/ ... may seriously consider trying out Interbase as an even less expensive alternative that doesn't tie them to proprietary licensing.
The company most likely to lose from this is SOLID. They got pretty seriously "flamed" a while back due to a change in licensing strategy; they used to sell individual licenses for around $200-$300, but have moved to selling groups of licenses so that the minimum price granularity is rather higher, more like $10K.
That is a market rather more vulnerable to Interbase's "scorched earth" strategy...
Lots of paradoxical effects are possible; the fact that PostgreSQL uses a BSD-like license means that it may be easier to do code integration between it and Interbase, as compared to GPLed MySQL, where the somewhat "infectious" nature of the license may discourage attempts to integrate code.
I certainly agree that YAPOPL (Yet Another Pseudo-Open Proprietary License) would discourage development efforts, but suggest that the relative merits/implications of GPL versus BSDL are quite nonintuitive and nonobvious.
According to the company history:
Borland might be an evidence against the common contention that "Microsoft is the company that never produces anything, but merely buys out products from other companies that are creative," as many of Borland's products were not natively produced, but rather resold on behalf of other componies.
By the way, that was Ashton Tate that used to own the dBase trademark...
As for integration with DBM variants, I see little importance to that. InterBase is a relational database (or at least, as relational as they come), as opposed to merely being a data store. The value would be in sharing code between InterBase and PostgreSQL or MySQL, or maybe using InterBase as a "data store" for persistent data in KDE or GNOME.
Russia used this militarily to destroy both French and German armies; they performed strategic retreats when "outgunned," destroying crops and other infrastructure so that when the Russian winter set in, opponents were overextended, and despite "winning the battle," wound up losing the war.
This obviously came at the cost of considerable Russian destruction, and with Inprise, the cost is that of not getting revenues from license sales, whilst the immediate benefit is that this may injure sales of competing DB vendors.
The open question is of how this affects already-free DBs like MySQL and PostgreSQL.
Effects on them are severalfold, and some are dependent on what license Inprise comes up with:
- Regardless of the license, it should be useful to have source code access as this can allow folks to see an implementation of transaction locking, stored procedures, SQL-CLI, ODBC, as well as the data storage mechanis, which may be quite useful when they try to add such functionality to other DBMS systems even if there is no reuse of code.
- If the license is sufficiently compatible, it may prove possible to integrate code one way or another either into "OpenInterBase" or into one of the other DBMSes.
Note that the folks likely to get particularly injured by this are the second/third tier companies selling licenses to things like:- Altera
- SOLID SQL Server
- OpenIngres
- Mimer
- Faircom
- Raima
- Yard
- Empress
whilst people will still likely be prepared to "pay the bucks" to move up to "Tier 1" DBMSes like Sybase/Oracle/Informix/DB2This is a game, in that attacker and defender both can construct decision trees for analysis, and treat this as a minimax problem in order to establish the most fruitful attacks and defenses.
I suppose it's difficult to be certain without running through the minimax problem, but I don't think that "vulnerability to rewriting microcode" will rank terribly high on the list.
After all, it's likely that reprogramming microcode represents something that you'd have to be in supervisor mode to do, e.g. having your code running in Ring 0.
The thing is, once the attacker's code is there in Ring 0, they've already won.
Being in Ring 0 (or an equivalent thereof) means that your process can do practically anything.
I think that's enough of an analytical result right there to establish that a "microcode attack" isn't going to be terribly feasible, as it's an attack that implies that security has already been fairly irretrievably breached.
Consider making this concrete on Linux.
If IA-64 allows user mode ( e.g. "Ring higher than 0") code to hit on the microcode engine that controls what happens in supervisor mode, THIS IS INDEED A SPECTACULAR BREACH. I can't believe that Intel could possibly be that stupid. IA-32 may be a very ugly hacked up design for many reasons; it is not a stupid design in that way.
If, on the other hand, only code in "Ring 0," e.g. kernel code, can modify microcode, then this is no worse an issue than the issues we already have with the need to trust and secure the code that runs in the kernel.
I really don't think this is a significant matter for machines that are either:
- Not required to be particularly secure, or
- Are housed in rather secure environments.
It's fair to say that AMD might provide "better bang for the buck;" the insecurity of microcode is, however, something that organizations have been coping with since microcode computers were invented, which likely dates back to the '60s.As for "You'd never know it," a secure US Army site is likely one of the places to which Intel would be willing to release secrets as to protocols necessary to validate that the microcode hasn't been tampered with, no?
Boy, this is liable turn into an illuminating thread... NOT.
Something like cfengine would be usable to this end; make install should generate a cfengine script that validates the system configuration, with the option of either warning of problems or of fixing them.
If not cfengine, then something else may be usable.
The critical point here is for the tool used to not merely be "a shell script," as those may get diverse in style to the point of unreadability. The validation needs to be in more of a descriptive style so that it doesn't get unreadable.
Consider for a moment that people keep finding it necessary to create new UIs; this is evidence that the elements needed to establish such a standard have not "settled down" yet.
If there is a 64 bit AMD CPU, called the K8, why isn't it listed on the AMD website as a product that they sell?
Reality is that There is no such product. "K8" has not been announced. Do a search at the AMD website and you will not find it.
AMD has announced something codenamed "Sledgehammer" but that was announced as a FUTURE PRODUCT.
And as far as the Athlon/Alpha motherboard interoperability, I'll believe it when I see it.
I'm not convinced that this is likely; Digital has long had some pretty good products, but have lately had an inability to sell their way out of a wet paper bag.
The recently announced Compaq/Samsung venture to put effort back into Alpha may be helpful, if they actually provide powerful product for decent value. It's not clear that they're likely to out-market Intel, which is a critical issue.
This connects doubly to AMD:
I suspect their choice needs to be between third-sourcing Alphas or creating an "IA-64 clone."
The former merely makes them a "me too" vendor; the latter runs the risk of running afoul of Intel patents and/or other "design license" restrictions.
I am at a loss to decide which outcome is more likely.
The common thing is the memory access protocol, which implies very little about there being any other interoperability between Athlon and Alpha.
I agree that this probably isn't the right measure, as there's reasonably more to money supply than this.
This is closer to the truth than claims about M0.
But. I prefer another scenario...
There will also be...
These amounts unambiguously increase the money supply regardless of which variation you prefer...