>
OS/2 could run a real DOS kernel via a Virtual Machine Boot, but a typical VDM used an emulated DOS interface, not a real one.
> It would probably take a certain level of cooperation from the kernel folks, though, at least if one wanted low-level access to stuff like sound hardware.
Isn't Plex86 or VMWare what you want?
Anyway, for me this is historical. The only thing I am lacking from the proprietary world is a little bit of polish and a Flash Player. Everything else I can have in my GNU iBook...
In free software POSIX systems, Wine and DOSEMU are separate projects, contained far away from the basic system. And POSIX evolved along years, with a nice design that took security, performance, resources consumption, extensibility, network and multiuser capabilities into account. Not only the MS Win, IBM OS/2 and MS-DOS family of systems, being derived from CP/M, never saw such thoroughout engineering, growing slowly by accretion, it made things worse by backwards compatibility with software that simply had contradictory goals.
The fact remains that backwards compatibility kept IBM OS/2 a proprietary, limited system, and delayed its stability by many years. Yes, later versions of IBM OS/2 are much more stable than MS WNT. But they are neither as stable, nor as capable, as GNU/Linux and BSD. And they are not open systems.
>
Neither Linux nor the *BSD family was as useful on x86 hardware at that point in time.
Agreed, but you talked about today as well.
>
providing a level of functionality that Linux still can't realistically provide even with DOSEMU, Wine
First, IBM has the PC-DOS and MS W16 source code. Second, GNU/Linux is intended to be POSIX, not MS-W32 compatible. Third, GNU/Linux made the option for robustness; backwards compatibility with MS-DOS and MS-Win has seriously damaged IBM OS/2 and MS-WNT.
>
Usually this internal RISC form is more like and "expanded form" and it is used also by RISC: it isn't truly an instruction set as its intructions has no real length..
Your point being?...
>
It would be interesting to compare the power consumption of Pentium-M vs PPC, it is not obvious at all that the PPC would win: Intel has one of the best process here.
Again, you are talking about something that has nothing to do with architecture, but with economies of scale both in production and design. If Intel didn't got an unfair advantage RISC would be even better than Intel is today. If Intel was RISC, it could do better. Ceteris paribus.
>
rumors of IBM cutting deals with Apple to ship OS X on their servers
And quite wild rumours at that. Who would want Mac OS X in the server, apart from Apple shops? Ridiculous. IBM could ship either AIX, GNU/Linux or NetBSD in the same hardware with better performance and less resources consumption easily.
For some of us it is too. Intel is one of the legs of the Wintel duopoly; just as MS in the software side, it has been keeping the technological progress at a check by mass producing inferior products that waste resources. And the predominance of a single, outdated hardware architecture helps reinforce the "no one was ever fired for buying Microsoft" myth, as well as simple buyer inertia.
While I agree the software side is more important, it would be nice to be a sane, RISC architecture compete with Intel for volume.
>
Sun is way the heck ahead in the 64 bit computer game
Way ahead of whom? IBM has long had its own 64 bits CPU, the POWER4, and a version of AIX to go along with it. Too bad SGI went from its 64 bits MIPS, and HP from its 64 bits PA-RISC and Alpha (the first one, from Digital), to Intel.
And way ahead by which measurement? IBM and Sun may be full 64 bits now, but it could be the unfortunate case that x86-64 and IPF would soon have higher volumes than POWER and UltraSPARC combined, just by virtue of the Intel x86 inertia on MS Windows, plus the combination of low-volume RISC strategies and the reluctance of free software users to go 64 bits now.
>
in my case the fields aren't fixed size, not all the records have the same fields
The physical fields were fixed size, but you just made them as big as necessary... and you can do pretty much the same with field delimiters. Different tuple types are so simple too.
>
So I can send it down the wire, not knowing what language, OS, or whatever the other end is using
You specify an encoding, and agree on the schema. That's all that XML ends up doing for data exchange, anyway, but verbosely.
>
it's main competitor in that arena is the ini file, XMLs expressive power wins hands down
Not at all. You have all kinds of simple dbs, from GNU dbm to PostgreSQL; and I find/etc simple commented name/value pars much more useful than XML configuration files.
>
I can tell people "send in some XML that looks like this example, and you'll get some back that looks like this example" and they say "OK"
I did the same think with simple, fixed-size fields sequential files.
>
relational model is great for data storage, but I can't say it's great for data interchange, because I don't even have a clear idea what that would mean.
OK, let's step back and think; we're messing here.
Obviously the relational model is for data storage, not interchange.
And that you are restricting XML to interchange is a good thing in itself, as far as it goes.
My grip is that a simple COBOL file copy conveys as much information about data as a XML schema, and is much simpler and more efficient. Having a public relational (or SQL) schema, and then sequential file definitions for data exchange, would be richer than XML, much more efficient, and more natural for dealing with data as data, as opposed to as documents.
That said, XML does impose some structure... still it's not worth the price in going back to a hierarchical mindset and in waste.
>
you want us all to use the same database schema definition system, because then we can create a data exchange format that's more consise than XML, and get everyone to standardise on that. Sounds great. Let me know when everyone agrees and you've got it running.
The point is exactly that people don't know data enough. I want people to be educated; I can't bring this change about by myself. In this domain (sensors) I have no interest.
>
I'd rather have 1 pretty good thing than a huge number of better ones.
If all you have is a hammer, anything looks like a nail.
>
I don't think you appreciate the wide usefulness of XML.
I do. I just think XML carried us from the 50s to the 60s, that is from sheer incompatibility to hierarchical systems. We still have to arrive to the 70s, that was when the relational model was established.
Now for text markup it is lovely, I use it very much.
>
HTML is XML, so it obviously is working for the majority of data transfers
HTML is not data transfer, but presentation. XML is not a data format, but text markup. Different tools for different jobs.
>
why would anyone give direct access to a DB
That is not what I called for. What I said is that instead of defining a hierarchical, verbose data format, we should have database schemas, possibly ANSI SQL ones if we can't get our act together around a really relational model. Then one can define data exchange formats that will be much faster, logical, than XML-derived ones, and require far less machine processing and programming.
Perhaps you will need some background. I would recomment DBDebunk.
>
once we do get a truly reliable open source rdbms, and people are convinced of it's worth, the pain involved in a once only migration process will be mitigated by the long term cost savings
Agreed, but there are some points:
SQL does not an RDBMS make; we are still waiting for a relational, free software offering, today the only one is proprietary, Alphora Dataphor;
Reliability is not the only need. Other is for ANSI SQL conformance. Many people will be wary for exchanging a not-quite-SQL DBMS for another only slightly more SQL compliant, and will prefer to migrate to something standards compliant so they could go IBM DB2 or SAPdb or FireBird or whatever should PostgreSQL show cracks later;
All this will be a process. If it happens at all, no one will be able to say, 'This is the year of the LAN^H^H^Hfree software DBMS'.
What I want is a relational or SQL schema. Then a much slimmer data transfer format would be possible.
Sure enough I can get XML data and input into a more useful SQL or relational database. But why go thru a verbose, hierarchical format, I can't see enough reason.
No I am not. Look for me in Usenet and mailing lists. Just like Churchill, or was it Roosevelt? -- 'Stalin and Hitler are two bastards. We support the weaker one to destroy the stronger, and then finish with the remaining one.' Too bad the bastards got together in the Ribbentrop-Molotov treaty.
In other words, I would rather an Apple than an Intel because they are more elegant technically as esthetically, so I will use it if I can't find a RISC from a saner company; if they go for AMD, I will try harder to find another RISC such as a second-hand workstation, AmigaOne or ARM; or go with AMD, VIA if RISCs become unavailable. If Apple went with AMD for example, I would have no incentive to buy it over a silent PC with GNU/Linux or without an OS, but would still consider it less evil than a PC with MS WXP preinstalled.
It is all about continuums of technical and moral factors.
>
from time to time they convert old ACS customers data from Oracle SQL to ANSI without too much trouble.
You have to consider two factors:
One, PostgreSQL is not ANSI SQL, but a compromise between ANSI and Oracle SQL. For example, it has add-ons for CONNECT BY and PL/SQL. So it is an easier migration target than ANSI SQL.
Two, ACS, being WWW and TCL based, is string oriented. Thus data types and the such are much less of an issue.
In general business applications such migration would be much harder.
One country alone doesn't keep an architecture afloat.
>
Amiga was very much alive at the time too.. atari yeah, they were on their way out.. with their last ditch effort the jaguar, also based on an m68k chip..
Sun and DEC, not sure about sgi and hp tho... both dropped m68k because motorola told them it was nearing its end of life
Which timeframe are you thinking about? Seems to be you are uninformed about how old MIPS, SPARC, PA-RISC are, and for how long have Amiga and Atari been in trouble. About DEC it is clear, not only they already had their CISC processor, the VAX, so they were not M68K user, and they had a NIH syndrome not to mention the Alpha being so much better design.
>
they tried ppc, which was motorola`s official migration path, but chose to develop their own next generation processors instead.
Ops! Not! The PPC is a derivation of POWER, sponsored by Apple, IBM and Motorola. Even Apple wanted to use the Alpha, but was turned down by DEC's VMS über alles attitude. When the PowerPC was conceived, POWER was already in full competition with the early generations of SPARC, PA-RISC, MIPS, Alpha.
>
i would wager that more m68k chips were being sold than x86 ones.
Yes, just as there may be more PowerPCs being sold today as embedded chips, not for computers.
If you want to prove your point, you will have to give references, dates and numbers, not wild suspicions.
>
the RISC crowd was primarily right, they were just targeting the wrong area
What do you mean? That they should've focused on the internals and left the CISC ISAs alone? This would've been prohibitively expensive. Only Intel's wages of monopoly and scale made it possible, and this benefited no one but Intel not even its customers, which were given the option of avoiding better systems.
>
There is no such thing as being internally RISC: RISC is about a style of Instruction Set (Reduced Instruction Set Cpu).
Yes, it exists. You translate external CISC into internal RISC, and thus are able to use all the tricks in the RISC book plus lots of chip real state, energy consumption and heat, less speed. Still better than pure CISC.
>
if you look at all the other CPU except the 80x86, they are all RISC CPUs, or VLIW.
Wrong. Ever heard about ColdFire, AKA M68K?
>
The fact that 80x86 is CISC is irrelevant
Not for me. I actually enjoy having a fanless, energy-efficient iBook that runs quite fast for its clock, and not helping to hold the whole CPU field back for backwards compatibility I don't need.
>
80x86 has won by being 1) cheap
Cheap to buy, but expensive to design, manufacture, and costly to the environment.
>
being able to run the cheapest OS (Microsoft OSs)
Slashdot Mirror
Isn't Plex86 or VMWare what you want?
Anyway, for me this is historical. The only thing I am lacking from the proprietary world is a little bit of polish and a Flash Player. Everything else I can have in my GNU iBook...
Better yet, defects. Simpler, more direct, more descriptive, easier to translate.
Not only that, it also translates and consolidates worldwide info. I can't find weather forecasts for Brasil and Confoederation Helvetica at NOAA.
In one word, complexity.
In free software POSIX systems, Wine and DOSEMU are separate projects, contained far away from the basic system. And POSIX evolved along years, with a nice design that took security, performance, resources consumption, extensibility, network and multiuser capabilities into account. Not only the MS Win, IBM OS/2 and MS-DOS family of systems, being derived from CP/M, never saw such thoroughout engineering, growing slowly by accretion, it made things worse by backwards compatibility with software that simply had contradictory goals.
The fact remains that backwards compatibility kept IBM OS/2 a proprietary, limited system, and delayed its stability by many years. Yes, later versions of IBM OS/2 are much more stable than MS WNT. But they are neither as stable, nor as capable, as GNU/Linux and BSD. And they are not open systems.
Agreed, but you talked about today as well.
First, IBM has the PC-DOS and MS W16 source code. Second, GNU/Linux is intended to be POSIX, not MS-W32 compatible. Third, GNU/Linux made the option for robustness; backwards compatibility with MS-DOS and MS-Win has seriously damaged IBM OS/2 and MS-WNT.
And how is this different from GNU/Linux or *BSD?
Your point being?...
Again, you are talking about something that has nothing to do with architecture, but with economies of scale both in production and design. If Intel didn't got an unfair advantage RISC would be even better than Intel is today. If Intel was RISC, it could do better. Ceteris paribus.
References?
And quite wild rumours at that. Who would want Mac OS X in the server, apart from Apple shops? Ridiculous. IBM could ship either AIX, GNU/Linux or NetBSD in the same hardware with better performance and less resources consumption easily.
For some of us it is too. Intel is one of the legs of the Wintel duopoly; just as MS in the software side, it has been keeping the technological progress at a check by mass producing inferior products that waste resources. And the predominance of a single, outdated hardware architecture helps reinforce the "no one was ever fired for buying Microsoft" myth, as well as simple buyer inertia.
While I agree the software side is more important, it would be nice to be a sane, RISC architecture compete with Intel for volume.
Way ahead of whom? IBM has long had its own 64 bits CPU, the POWER4, and a version of AIX to go along with it. Too bad SGI went from its 64 bits MIPS, and HP from its 64 bits PA-RISC and Alpha (the first one, from Digital), to Intel.
And way ahead by which measurement? IBM and Sun may be full 64 bits now, but it could be the unfortunate case that x86-64 and IPF would soon have higher volumes than POWER and UltraSPARC combined, just by virtue of the Intel x86 inertia on MS Windows, plus the combination of low-volume RISC strategies and the reluctance of free software users to go 64 bits now.
The physical fields were fixed size, but you just made them as big as necessary... and you can do pretty much the same with field delimiters. Different tuple types are so simple too.
You specify an encoding, and agree on the schema. That's all that XML ends up doing for data exchange, anyway, but verbosely.
Not at all. You have all kinds of simple dbs, from GNU dbm to PostgreSQL; and I find /etc simple commented name/value pars much more useful than XML configuration files.
It doesn need to be all in one table...
I did the same think with simple, fixed-size fields sequential files.
OK, let's step back and think; we're messing here.
Obviously the relational model is for data storage, not interchange.
And that you are restricting XML to interchange is a good thing in itself, as far as it goes.
My grip is that a simple COBOL file copy conveys as much information about data as a XML schema, and is much simpler and more efficient. Having a public relational (or SQL) schema, and then sequential file definitions for data exchange, would be richer than XML, much more efficient, and more natural for dealing with data as data, as opposed to as documents.
That said, XML does impose some structure... still it's not worth the price in going back to a hierarchical mindset and in waste.
The point is exactly that people don't know data enough. I want people to be educated; I can't bring this change about by myself. In this domain (sensors) I have no interest.
If all you have is a hammer, anything looks like a nail.
I do. I just think XML carried us from the 50s to the 60s, that is from sheer incompatibility to hierarchical systems. We still have to arrive to the 70s, that was when the relational model was established.
Now for text markup it is lovely, I use it very much.
Thank you! That was nice. I hope someday someone writes this history in full. Today's world is lacking memory...
HTML is not data transfer, but presentation. XML is not a data format, but text markup. Different tools for different jobs.
That is not what I called for. What I said is that instead of defining a hierarchical, verbose data format, we should have database schemas, possibly ANSI SQL ones if we can't get our act together around a really relational model. Then one can define data exchange formats that will be much faster, logical, than XML-derived ones, and require far less machine processing and programming.
Perhaps you will need some background. I would recomment DBDebunk.
Agreed, but there are some points:
SQL does not an RDBMS make; we are still waiting for a relational, free software offering, today the only one is proprietary, Alphora Dataphor;
Reliability is not the only need. Other is for ANSI SQL conformance. Many people will be wary for exchanging a not-quite-SQL DBMS for another only slightly more SQL compliant, and will prefer to migrate to something standards compliant so they could go IBM DB2 or SAPdb or FireBird or whatever should PostgreSQL show cracks later;
All this will be a process. If it happens at all, no one will be able to say, 'This is the year of the LAN^H^H^Hfree software DBMS'.
Nice irony...
Why XML with all its verboseness and hierarchy?
What I want is a relational or SQL schema. Then a much slimmer data transfer format would be possible.
Sure enough I can get XML data and input into a more useful SQL or relational database. But why go thru a verbose, hierarchical format, I can't see enough reason.
No I am not. Look for me in Usenet and mailing lists. Just like Churchill, or was it Roosevelt? -- 'Stalin and Hitler are two bastards. We support the weaker one to destroy the stronger, and then finish with the remaining one.' Too bad the bastards got together in the Ribbentrop-Molotov treaty.
In other words, I would rather an Apple than an Intel because they are more elegant technically as esthetically, so I will use it if I can't find a RISC from a saner company; if they go for AMD, I will try harder to find another RISC such as a second-hand workstation, AmigaOne or ARM; or go with AMD, VIA if RISCs become unavailable. If Apple went with AMD for example, I would have no incentive to buy it over a silent PC with GNU/Linux or without an OS, but would still consider it less evil than a PC with MS WXP preinstalled.
It is all about continuums of technical and moral factors.
You have to consider two factors:
One, PostgreSQL is not ANSI SQL, but a compromise between ANSI and Oracle SQL. For example, it has add-ons for CONNECT BY and PL/SQL. So it is an easier migration target than ANSI SQL.
Two, ACS, being WWW and TCL based, is string oriented. Thus data types and the such are much less of an issue.
In general business applications such migration would be much harder.
One country alone doesn't keep an architecture afloat.
Which timeframe are you thinking about? Seems to be you are uninformed about how old MIPS, SPARC, PA-RISC are, and for how long have Amiga and Atari been in trouble. About DEC it is clear, not only they already had their CISC processor, the VAX, so they were not M68K user, and they had a NIH syndrome not to mention the Alpha being so much better design.
Ops! Not! The PPC is a derivation of POWER, sponsored by Apple, IBM and Motorola. Even Apple wanted to use the Alpha, but was turned down by DEC's VMS über alles attitude. When the PowerPC was conceived, POWER was already in full competition with the early generations of SPARC, PA-RISC, MIPS, Alpha.
Yes, just as there may be more PowerPCs being sold today as embedded chips, not for computers.
If you want to prove your point, you will have to give references, dates and numbers, not wild suspicions.
What do you mean? That they should've focused on the internals and left the CISC ISAs alone? This would've been prohibitively expensive. Only Intel's wages of monopoly and scale made it possible, and this benefited no one but Intel not even its customers, which were given the option of avoiding better systems.
Yes, it exists. You translate external CISC into internal RISC, and thus are able to use all the tricks in the RISC book plus lots of chip real state, energy consumption and heat, less speed. Still better than pure CISC.
Wrong. Ever heard about ColdFire, AKA M68K?
Not for me. I actually enjoy having a fanless, energy-efficient iBook that runs quite fast for its clock, and not helping to hold the whole CPU field back for backwards compatibility I don't need.
Cheap to buy, but expensive to design, manufacture, and costly to the environment.
So is now MS giving away its source code?