You're comparing apples to pears. Java wasn't GPL'd back then. Sun has their own license, which I haven't read yet. Where can I find details about the case?
And what would prevent anyone from shipping extension libraries to Java? Companies are doing that all the freaking motherforking time when distributing their Java applications (often including the full JRE or even JDK).
I guess, unless there's a precedent, we don't know for sure how such a case would be handled. Namely, in the real world it doesn't just depend on the text, but also on its interpretation by lawyers and judges.
Seeing how ambiguous the GPL is, I might not use the GPL again for further works of mine (or wait for a GPL version which is crystal clear), and I won't recommend using it to anyone.
Also, I wonder what the use of GNU/Linux is when companies can't even distribute closed-source code for it without getting criticized. This doesn't help GNU/Linux become an industry standard; in fact, it will return it to an ever smaller getting niche when corporate benefits of it turn out be zero.
Let's say, company XYZ publishes a kick-ass (but properietary) database system for GNU/Linux named FGH. Everyone from the GNU/Linux world goes "Waaa! FGH isn't open-source! It's not LEGAL! It's DOOMED!" then company XYZ will get the impression that marketing or developing the product FGH for GNU/Linux was a mistake, and promptly withdraw it.
This would go on for all eternity until no more software is written for GNU/Linux.
(It is already not very programmer friendly, I must say!)
BTW, here's a quote from GPL V2 (which covers the Linux kernel):
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
The NVIDIA kernel driver module is an isolated component developed entirely by NVIDIA, and hence not covered by the GPL.
Q.E.D.
I'm no lawyer, but that's at least what I would say.
Just from reading the GPL, I can tell that the NVIDIA driver is obviously not a derivative work of the Linux kernel. A derivative work requires that you take the source code of the kernel and modify it, which the NVIDIA driver obviously doesn't.
You might argue that a module is an extension of the kernel. Merely extending the kernel is no modification if a plug-in interface exists (so that the original source is not modified). No matter if done at source level or loadable module level. If you don't modify a single byte of the source code, it's not a modification.
A kernel module is an application program that is loaded by the kernel (a kernel-level application), and hence, the kernel isn't touched in any way whatsoever, by the kernel module. If that's the intention, to make code that runs in the kernel subject to the GPL, then the GPL is utterly ill-defined for that purpose.
I've been writing free software since the 1980ies, even before the GNU project existed, and hence I've been dealing with licenses for many years now. I created my own licenses, which were derivative of popular licenses that existed back then, which were similar to the BSD license.
If that NVIDIA case ever goes to court, you will see for yourselves that the claim that a kernel module comprises a derivative work of the kernel is utterly unfounded.
(BTW, I bet that NVIDIA's lawyers have already sorted the whole thing out before they published their first Linux driver.)
It's funny seeing GNU/Linux people spreading FUD, I always thought that was a Microsoft priviledge.:-D
WTF are you talking about? I just looked at the Linux kernel license, and it's GPL. The GPL covers the kernel source itself, not third-party kernel modules. This means, that if you were to write a driver for Linux that is not included in the kernel source, your driver would not be part of the kernel, but would be your own work that you could put under the helm of an arbitrary license. This is exactly what NVIDIA is doing.
NVIDIA just wants to protect its right to conceal its chip architecture from its competitors. After all, NVIDIA DOES provide drivers for Linux, Solaris and FreeBSD. And if they were to pull them, users could still migrate to different hardware.
(And besides, which 3D accelerated graphics adapter would you suggest that has a GPL-ed driver?)
A broader base of drivers that can (and will) be shipped with GNU/Linux distributions only helps to enlarge the user base.
Nobody wants to use Windows. Me neither. But I definitely wouldn't run Linux if I couldn't make use of my hardware. So, NVIDIA's driver is the ONLY reason I'm using Linux. I have an NVIDIA card. I have no interest in using Linux with the non-3D open-source NVIDIA driver that comes with X.org (that'd be like using standard VGA in the year 2006). And I'm sure many people feel this way about the issue.
I feel the same way about Windows and Linux. I like the user interface and the programming APIs of Windows, but the OS itself just isn't well done. GNU/Linux based systems, on the other hand, have a (moderately) great kernel, but finding a distro that works is very difficult.
I started out using UNIX-based systems only, at home, in October 2004, so it's already been two years for me. I tried SuSE, Solaris, Slackware, FreeBSD, Debian and Ubuntu, and so far, I can say that Ubuntu is the one that I liked most. However, GNOME in Ubuntu 6.10 is broken for me, I cannot burn CD's via Nautilus, for instance -- on Debian (3.1r3 stable), that worked! But there's still K3b, so that was no problem. But on every single Linux distribution that I encountered, something just didn't work (and often also couldn't be made to work).
What I really like about Ubuntu (6.10) is, that it comes with the latest and greatest software packages, like GCC 4.1, GNOME 2.16, and so on.
Before that journey to find the right distro, I was using SuSE, and was becoming increasingly bothered by it. SuSE seems to never test their packages, so plenty of those don't work. I cancelled my subscription after 10.1, because it had so many flaws, when I tried it.
What I dislike about Slackware is, that many of the packages aren't dependency-checked properly. It's easy to break your system with just one install.
FreeBSD slowly disintegrated as I was using it, still don't know why. Probably also a dependency checking problem; the more software you installed, the more things became broken. But the whole kernel stuff in FreeBSD is just nice; to load a kernel module, all you have to do is to change a single config file. You don't have to recompile the kernel.
Solaris is a great OS, but is apparently not intended for the desktop (for example, I couldn't get my USB scanner to work with it). Also, administration significantly differs from Linux or BSD systems. Perhaps I'll try that again sometime.
So, the bottom line, from my point of view is, that Ubuntu is the best GNU/Linux distro I've seen so far, and I hope it'll stay on my machine long enough that I don't have to buy Windows Vista or XP.
As far as program development is concerned, I'm dissatisfied with the whole configure-script mess. It is far too complicated to learn in a reasonable amount of time, and so I won't develop native apps for GNU/Linux (and no, none of the IDE's worked for me, I tried all of them; every single one was unable to handle the configure stuff properly). Plus, if you don't have a package maintainer for every distro, you cannot distribute your app (because doing it yourself is virtually impossible due to the insane complexity). I decided to develop exclusively on Java in my sparetime. Not only the libraries are standardized and powerful, the development tools just work and are very powerful, but also I can distribute my apps in a single jar file.
Microsoft gives its resellers major rebates on Windows licenses. I've seen it myself once, a friend of mine was a Microsoft reseller, and he got genuine Windows (95 or NT) OEM licenses for $5 each!!
Preinstalling Linux usually is more difficult for vendors who are used to preinstalling Windows. Pricing is also often a result of expected sales. I.e. a reseller might offer Linux PCs at a higher price than Windows PCs, simply because they don't expect to sell as much Linux PCs as Windows PCs.
That Windows would behave weird on particular vendor's machines has more to do with the vendor being unable to install it properly, I think. I used to read a German computer magazine called "c't" (Magazine for Computer Technology) and they never once found a computer on which Windows was installed properly. I think this speaks volumes, especially when you think about big companies like Dell, Acer, HP, and so on that sell Windows PCs.
Installing Windows can require some expertise, especially when it comes to installing only the latest drivers, making sure the system configuration is consistent and robust, and the BIOS settings are correct, the mainboard and peripheral flash BIOSes (if applicable) are patched to the latest versions, installing all Windows updates, and antivirus protection that isn't a resource hog, etc.
Installing Linux is far easier, but also takes some expertise. And usually, when you build a computer you would have to fully check the setup and make sure that everything works.
Until such a installation tasks and installation verification tasks are automated, it is unlikely that PC resellers can make PCs that give the user consistent, fully working systems. IMO.
Yeah, indeed. Java runs much better nowadays. Partially, it's because of the JVM's HotSpot engine, partially it's because the computers nowadays have much higher performance.
Java's VM isn't ideal, by far (nor is MS's CLR), but the computers nowadays are so fast, that you barely notice you're running a Java application.
I'm using the Netbeans IDE myself currently, and I'm pleased with that IDE.:-)
I've given up to try programming in C++ on Linux. The whole automake / configure script stuff is far too complicated for the little spare time that I have.
As long as space technology is as expensive as it is, that might be, to some extent. As long as we still need rocket power to get into space, it'll always be an expensive endeavor.
However, we'll always need space research for satellites, etc., at least in the foreseeable future.
What you're not saying is that all of the above applies only to OS/2 version 1.3 and below.
OS/2 2.11, Warp 3 and Warp 4 not only had a great GUI that was far beyond that of Windows in terms of functionality (like the CORBA compatible component-based Workplace Shell that was truly object-oriented and fully integrated into the user experience), but also that they fully supported 80386 and above microprocessors. The second-to-last version of IBM Visual Age for C++ (V3.5) optimized well even for Pentium II and III processors. Also, these versions of OS/2 had an integrated emulation for MS-DOS and Windows 3.1 which contradicts your opinion that they did not support the V86 modes well.
Re:Yes, Re:The entire book is about Microsoft?
on
In Search of Stupidity
·
· Score: 2, Insightful
The book isn't that far off from reality. I've seen it all happening myself, watching the computer industry since the early 1980ies.
And you cannot blame it on the users, per se, either.
OS/2 was a failure only because IBM canned it too early -- in 1996, just when the market for OS/2 was finally gaining momentum. And nowadays, if OS/2 still existed, it would be the ideal choice for many users who wanted to escape Windows Vista. Also, banks and insurances would still be using OS/2 (being traditional IBM customers).
Apple and Commodore refused to license their OSes to third parties, which was a grave mistake.
There were plenty of companies who wanted to build Amiga clones, Amiga laptops and notebooks, and so on, but Commodore declined, for instance. Amigas were used by many people just to run MacOS emulators, because the Amiga handled a greater range of peripherals than MacOS did, and was only half as expensive.
The Mac's demise started already in the 80ies, when its pricing policy made it unavailable for the general public. This policy extended far into the 90ies, and MacOS simply was too expensive to be a choice for anyone with a small budget.
This is why Microsoft won against IBM, Apple and Commodore: Windows was comparably cheap, offered more functionality and was easy to develop for.
But Microsoft now makes the same mistakes as once Apple and Commodore: They resort to restrictive licensing, and high pricing, and thus making Windows unavailable for the general masses; at least to the people who do not want to use a pirated product.
I migrated to Linux myself because Windows and associated software simply has become too expensive to afford.
And speaking as a developer, I think that Java currently seems to be the best development platform, because it's platform neutral, and the tools and libraries have great functionality and are well documented.
No, you're wrong. In fact, these 3D projection monitors already exist and have already been sold for a couple of years.
In top middle of the panel (or at the edges) there is an eye motion sensor that tracks the viewer's eye movements and then adjust the view on the screen accordingly.
For example: Light turns green, I have the right of way, but cannot legally enter the intersection unless it is safe to do so. So, do I have right of way, or not? If I was in a country that had an iron-clad right of way rule, does that mean I should just enter the intersection assuming there will be no one else there?
In Germany, if you have a green light, it means, you can enter the intersection, unless there are obvious obstacles, like a traffic jam. If you noticed nothing unusual when entering the intersection, and another driver who had a red light crashed his car into yours, it was his fault and his insurance has to take the responsibility.
Another example from traffic school: A and B approach the stop sign at the same time, but B is on the right, so B has right of way. B waves A through. The instructor said technically B could be arrested for impersonating an officer since they are directing traffic, and A can still be ticketed for not obeying the rules. How would it work otherwise?
In Germany, there are no intersections having stop signs like this. If person A encounters a stop or yield sign at an intersection, person B will not have a stop or yield sign, so person A will have to wait until person B has passed the intersection.
If there is an intersection with no signs, person A has to yield to person B. If B waves A through, it's not a problem, however. Waving someone thru is explicitly allowed.
The first rule of the German driving rules is "cautiousness and mutual considerateness." Hence, common sense is the most important rule.
The Atari 400 and 800 models (not Atari 800 XL!!) were released way before the C-64, but after the Apple II.
IIRC, Apple II came in 1977 to 1978, Atari 400 and 800 came in 1980 to 1981, and C-64 came in 1982 to 1983.
The Atari 400 was a cheaper model of the Atari 800. The 800 had a real keyboard and 48 K of memory, while the Atari 400 had a flat sensor keyboard and 16 K of memory. Hence, because of the memory size, they were more expensive than the VIC-20.
When the C-64 came, it was more than twice as expensive as the VIC-20 at first.
Hence, here in Germany at least, the Atari 800 and C-64 were seen more as business computers, not home computers.
The Apple II was far beyond in terms of pricing, it was by far the most expensive 8-bit computer, being over twice as expensive than the C-64.
The Apple II was far better than any of the others in terms of expandability. It had a built-in bus system that permitted users to plug in adapter cards, much like the IBM PC years later. So, you cannot really compare the Apple II to the Atari 800 and C-64, IMO.
The Atari 800 and VIC-20, C-64 had module connectors. Usually, you plugged in a module that led to an external expansion box, in which you were able to plug in more modules. Peripherals like disk drives and printers could be connected. I can't remember the buses of the Atari, but the VIC-20 and C-64 had -- like the bigger models -- connectors for IEC bus (serial on the VIC-20 and C-64, parallel on the PET), which permitted connecting disk drives, printers, and other devices. The cassette drive wasn't connected to the IEC bus.
In 1982/1983, the prices were about those: ZX-81: $250, VIC-20: $400, Atari 800: > $500, TI99: > $500, C-64: $750, Apple II: $1500 (all of them naked, without peripherals!). That was a lot of money, even the ZX-81 and VIC-20 seemed expensive.
If you add the prices for peripherals and expansions, you'll see that the Commdore parts were much cheaper than those of their competitors. And that's why Commodore sold more. Disk drives were the most expensive parts, all of them had their own CPUs and were often just as expensive as the computers themselves: Disk drive for Atari 800: $500, for VIC-20/C-64: $400, for Apple II: $750-$1000. (well, IIRC)
Damn! Already in '83?? I had a friend in school whose father had a TI994A. It was a marvellous machine, but wayyy too expensive (at least here in Germany). Here, it was the most expensive home computer. We never saw the big price decline, at least I can't remember it. I really liked the TI99 BASIC interpreter. The only bad thing I remember is that my friend's dad complained often that the machine was getting too hot. But my VIC-20 also was very hot (I had one of those with integrated power supply!), so that wouldn't have bothered me.
There were computer magazines for the TI994A which had plenty of programs in it. I think there wasn't much need to buy software, at least here. People bought these computers for programming and typing up programs, but perhaps that was only my view as a kid back then!;-)
I'll tell you something: After Commodore was dead, I bought my first PC. And from then on, I worked with MS-DOS, OS/2 2.x, 3.x, 4.x, Windows 3.1, 95, 98, NT 4, 2000, XP, and AIX (on RS/6000), Solaris (on UltraSPARC), SuSE Linux, Slackware Linux, FreeBSD, and now Debian Linux.
And guess what, at least in the home use arena (thus, excluding Solaris and AIX and the now-dead OS/2), Debian Linux is the first OS that I found that was stable enough for my tastes (after AmigaOS). Windows 98, XP, SuSE Linux, Slackware Linux and FreeBSD all self-destructed before me. I hope that Debian Linux -- stable version -- will live up to its promise. Because I need an OS at home that I can develop for.
And that's why I still have hopes to find another OS someday that can live up to the stability and reliability of AmigaOS. I want to do everything with it. If I find a solution that works, I'll use it.
My Amiga 3000 ran 9 years without error before self-destructing. It's in a computer museum now somewhere -- repaired.
Show me any PC OS that can do that, and I'll use it happily.
If I find a modern day (Amiga?) system someday that does everything I want, I might use only that until it breaks for good. I'm patient, like those other thousands of users who want the same thing.
Nowhere in the BCPL language specification it is written that the stack has to grow forward in memory -- this was just a characteristic of the INTCODE runtime system that was used to port Tripos to the Amiga. Once I wrote a code generator for cross-assembling INTCODE to the 68030 processor in two weeks, and if I had wanted, I could've changed the stack behavior.
That BCPL is word-addressed was not a real problem IMO. Richards later published a byte-addressed backend called CIntcode (C INTCODE). So that wasn't a matter of the language, either (although the original BCPL spec recommended word-addressing, because the machines it ran on at that time were word-addressed).
Even with word-addressing and forward-growing stack, the BCPL implementation on the Amiga wasn't all that bad. I developed for AmigaOS since version 1.1, and I noticed no difference in speed when switching to 2.0. The first thing I noticed in 2.0 was that the ReadArgs() routine was broken, which made me re-implement it to avoid calling the function re-implemented in C. Of course that was fixed in later versions, but the behavior wasn't the same.
The Global Vector was not meant as a library interface, it was simply a linking facility, for the BCPL compiler concept doesn't have a linker. That's why you can just concat INTCODE files into one file, because the Global Vector provides the "linking" mechanism.
If I could afford it, I would develop a fork of AmigaOS starting out from version 1.3. I was deeply dissatisfied with some things in 2.x and upwards.
Of course, many people would disagree with me, but honestly, AmigaOS lost some of its attractiveness to me with the advent of 2.x.
Like, for instance, the "3D look," that ate up most of the Workbench palette (if running in the default 4-color mode), and other things that I mentioned already.
Had I been a Commodore employee, I would've brought up many objections to the development of the later OS releases!;-)
My Amiga never crashed (unless, perhaps, when I ran one of my own programs!;-) ). Perhaps you should've used different software packages. I used only software that didn't crash the machine.
Lisa and Macintosh didn't have preemptive multitasking. MacOS didn't have preemptive multitasking until OS X. AmigaOS was the first personal computer operating system to have preemptive multitasking.
As for GUI systems, before Lisa, there were a number of projects developed at the Xerox research center at Palo Alto. The first (largely text-based) GUI system with mouse was developed in the early 1960ies (!!) (Google for it, there are some interesting videos; however, I can't recall the name of the project right now.)
The Atari ST was the first GUI system that was available to the masses, followed by the Amiga 1000. Macintoshs were more than twice as expensive, and unaffordable to average households!
Later it was claimed that the Amiga GUI was a Mac rip-off, but that's not true: The Amiga team started out in 1979, which was the year when the XC68000 processor came to market.
And the Atari ST was a project started by Jack Tramiel to quickly bring an Amiga-like computer to the market before Commodore did.
I recall that in 1983 and 1984, there were already rumors about a super-PC coming to market, made by Commodore, although the rumors were highly exaggerated. A friend in school told me about this, and said it would have 8-channel sound, millions of colors, etc.;-) -- so the Amiga wasn't a surprise to me when it finally came.
I wonder why Dr Martin Richards from Cambridge UK was never credited for writing Tripos that was simply taken by Tim King of MetaComCo (IIRC) and turned into the dos library. When I learnt BCPL and the design of the BCPL compiler, it was clear to me that Richards' code was very clean and logical. I cannot understand how Tripos would be different in terms of implementation quality. There was only one bug in the OCODE generator that prevented generation of the 2^31 value in OCODE (and yup, I provided a fix to Mr Richards, but that was long after Commodore was gone). Granted, BCPL code seemed to be hard to debug, but in fact it wasn't much more difficult than debugging a C program.
I think Tripos made the Amiga a desktop computer in the first place, because it provided all the functionality of file handlers, filing systems etc.
The Global Vector was an interesting aspect of that BCPL implementation. Instead of rewriting all the BCPL code in C, more documentation would've been sufficient.
I know there were some people who criticized the performance aspects of Tripos. But performance was never really an issue. The dos library wasn't much faster after the rewrite in C, and FFS wasn't much faster than OFS; FFS lacked some fundamental redundancy that made OFS safe.
The exec library was prepared for virtual memory management (see MEMF_PUBLIC flag), and it could've been implemented. I still remember Dale Luck's comment that was printed in the German "68000er" magazine, that said something to the effect of "UNIX tries to accommodate for bad software by providing good hardware (an MMU)". The sentiment was "good software doesn't need virtual memory management". This is true to some extent, but the advantage of a VMM system could've proven useful for systems with low memory. At the cost of speed, but at the gain of usability.
This is why Windows was such a success: You could run applications despite having low memory.
I think that VMM could've been implemented in the exec library without compromising speed: Namely providing virtual memory only to applications that didn't set the MEMF_PUBLIC or MEMF_CHIP flags (CHIP memory could've been paged also, or even remapped into CHIP memory only when necessary).
Like, where? You didn't mention anywhere in your article that "A600" was the working title for the "A1200".
To you last comment: The problem was, that the Amiga community was so fixated on Motorola CPUs that the only thing they accepted besides M68K was PowerPC-based systems. I still remember the "CPU wars" in the Amiga community.
You know, it's just the sheer sadness that drives people to still support Amiga. Fact is, that, conceptually speaking, the AmigaOS was far ahead of its time, and still is. The concept was and is very simple: A micro kernel, a multilayered driver system (resources, devices, and optionally, file handlers), and a real multitasking. I'm not saying this because I'm a fanboy, I'm saying this because I witnessed the advantages first hand, and still witness them. I still use an Amiga 600 for making music! Why? Because it's technically impossible to create music software for Windows or Linux that keeps the pace no matter what you're doing with the computer. On the Amiga, I can easily run my music, and do something else at the same time, without worrying about timing problems. And that's the problem: Timing. The AmigaOS was and is the only one that provides exact and predictable timing for all aspects of the operating system. Windows can't do it, by far, not even with DirectX, and Linux can't do it either, because neither is a real time OS, however AmigaOS is.
I gladly accept the design flaws in AmigaOS 2.x and 3.x, or even 4.x if it provides me with the flexibility that I need. Perhaps I might even check out MorphOS, or any other of these efforts. Recently, I ran AROS off a live CD on my present main computer, which is a 2.4 GHz Pentium 4 machine with 2 GB of RAM. Even Amiga Emulators like UAE still provide some advantages over their host OS. And that is something, that only AmigaOS can do.
Amiga Inc. is currently working on AmigaOS 5 (AmigaOS 4 was implemented by Hyperion Entertainment), and AmigaOS 5 will be multiplatform. I don't know how they'll solve the kernel issue, perhaps they'll take a Linux or BSD kernel, or write their own; or run it on top of the other systems, who knows. All I care about is, that *I* as a user, or developer, do not have to care about timing issues. If it works, I'll be all over it.:-)
I almost purchased an AmigaONE with AmigaOS 4, but unfortunately I was unemployed at the time and could not afford it. As it happened, a couple of months later, Eyetech (UK) stopped manufacturing the AmigaONE mainboards, and Hyperion halted development of AmigaOS 4 until a new hardware manufacturer has been found. However, that AmigaONE solution was very expensive; I hope they'll manage to reduce prices. I'm also unsure about the performance implications of AmigaOS 4. I hope it'll be as smooth as the old OSes. And if that shouldn't work out, perhaps AmigaOS 5 will be the cure, who knows.
And other projects like AROS and MorphOS look also promising.
To me, the loss of Amiga stifled my creativity. The Amiga was intended as a computer for creative people, and that's what it was. With its loss, an important tool went out the window.
The current operating systems, like Linux and Windows, can only partially compensate for that. And developers for these platforms have not the slightest clue about what creative people need. C*base for making music? Thanks, but no thanks.
Of course not. The 6502 was quite a basic micro processor, even by the standards of that time. It worked, but it was difficult to write any meaningful code for it, i.e. if you wanted to keep a little bit of sanity for yourself!;-)
I never programmed the 6800, but once I wrote an emulator for the 6809, and I liked the design much better than that of the 6502.
The most comfortable to program was perhaps the 68000, closely followed by the Z80. The Z80 had 22 registers in total (2 x 11 registers). Now, eat that, 8080!!;-)
I learnt 8086 assembly in the early 90ies when I was faced with MS-DOS for the first time! Yuck!!
Nowadays, Pentium 4 processors are quite nice as well, especially with all the MMX, SSE and SSE2 instructions and the additional registers. Unfortunately, no compiler is using these for regular code generation. It would make code much faster, methinks. I wonder how fast my 2 GHz processor would be if the instruction set was actually used, eh! (I had indeed some suprises when writing assembly code for Pentium II and upwards processors; I never thought that C could be so SLOW.)
I have an Amiga 600 sitting right next to me on my desk, and I can tell you it doesn't have the AGA chipset, only ECS. The Amiga 1200 was the Amiga 600 follow-up that contained the AGA chipset.
I remember there was much discussion back then about why Commodore didn't sell computers with the AGA (also called AA) chipset. Because it was finished, but no computers were being built with it. Now we know why.
There was also a follow-up to AGA, called "AAA", which never saw the light of market.
The main problem for the Amiga was the lopsidedness of application availability. Business folk could never warm themselves to it, because there were only few applications in that arena. And so the PC became "industry standard" (which only means wide adoption by businessfolk, and not by other industries).
Of course there were databases (Superbase), spreadsheets etc. - I think the biggest problem was printing support. It was a real pain to use word processors like Final Writer, which were really good on-screen, but had trouble printing (if you didn't have a PostScript printer, which were obscenely expensive back then). Due to memory restrictions for the printer.device, printing often consisted of printing out small stripes that became a whole page if you waited long enough. Windows did never have that problem, because GDI has vector graphics support. I was really disappointed at the shortcomings of the Amiga "printer.device". Commercially available printing tools tried to alleviate that situation, but in essence, you were shelling out money after money to rev up the Amiga performance for such tasks. (Like, buying RAM instead of using a virtual memory mechanism; hard disk space was much cheaper than RAM, even back then)
Slashdot Mirror
You're comparing apples to pears. Java wasn't GPL'd back then. Sun has their own license, which I haven't read yet. Where can I find details about the case?
And what would prevent anyone from shipping extension libraries to Java? Companies are doing that all the freaking motherforking time when distributing their Java applications (often including the full JRE or even JDK).
I guess, unless there's a precedent, we don't know for sure how such a case would be handled. Namely, in the real world it doesn't just depend on the text, but also on its interpretation by lawyers and judges.
Seeing how ambiguous the GPL is, I might not use the GPL again for further works of mine (or wait for a GPL version which is crystal clear), and I won't recommend using it to anyone.
Also, I wonder what the use of GNU/Linux is when companies can't even distribute closed-source code for it without getting criticized. This doesn't help GNU/Linux become an industry standard; in fact, it will return it to an ever smaller getting niche when corporate benefits of it turn out be zero.
Let's say, company XYZ publishes a kick-ass (but properietary) database system for GNU/Linux named FGH. Everyone from the GNU/Linux world goes "Waaa! FGH isn't open-source! It's not LEGAL! It's DOOMED!" then company XYZ will get the impression that marketing or developing the product FGH for GNU/Linux was a mistake, and promptly withdraw it.
This would go on for all eternity until no more software is written for GNU/Linux.
(It is already not very programmer friendly, I must say!)
Just from reading the GPL, I can tell that the NVIDIA driver is obviously not a derivative work of the Linux kernel. A derivative work requires that you take the source code of the kernel and modify it, which the NVIDIA driver obviously doesn't.
:-D
You might argue that a module is an extension of the kernel. Merely extending the kernel is no modification if a plug-in interface exists (so that the original source is not modified). No matter if done at source level or loadable module level. If you don't modify a single byte of the source code, it's not a modification.
A kernel module is an application program that is loaded by the kernel (a kernel-level application), and hence, the kernel isn't touched in any way whatsoever, by the kernel module. If that's the intention, to make code that runs in the kernel subject to the GPL, then the GPL is utterly ill-defined for that purpose.
I've been writing free software since the 1980ies, even before the GNU project existed, and hence I've been dealing with licenses for many years now. I created my own licenses, which were derivative of popular licenses that existed back then, which were similar to the BSD license.
If that NVIDIA case ever goes to court, you will see for yourselves that the claim that a kernel module comprises a derivative work of the kernel is utterly unfounded.
(BTW, I bet that NVIDIA's lawyers have already sorted the whole thing out before they published their first Linux driver.)
It's funny seeing GNU/Linux people spreading FUD, I always thought that was a Microsoft priviledge.
WTF are you talking about? I just looked at the Linux kernel license, and it's GPL. The GPL covers the kernel source itself, not third-party kernel modules. This means, that if you were to write a driver for Linux that is not included in the kernel source, your driver would not be part of the kernel, but would be your own work that you could put under the helm of an arbitrary license. This is exactly what NVIDIA is doing.
NVIDIA just wants to protect its right to conceal its chip architecture from its competitors. After all, NVIDIA DOES provide drivers for Linux, Solaris and FreeBSD. And if they were to pull them, users could still migrate to different hardware.
(And besides, which 3D accelerated graphics adapter would you suggest that has a GPL-ed driver?)
A broader base of drivers that can (and will) be shipped with GNU/Linux distributions only helps to enlarge the user base.
Nobody wants to use Windows. Me neither. But I definitely wouldn't run Linux if I couldn't make use of my hardware. So, NVIDIA's driver is the ONLY reason I'm using Linux. I have an NVIDIA card. I have no interest in using Linux with the non-3D open-source NVIDIA driver that comes with X.org (that'd be like using standard VGA in the year 2006). And I'm sure many people feel this way about the issue.
I feel the same way about Windows and Linux. I like the user interface and the programming APIs of Windows, but the OS itself just isn't well done. GNU/Linux based systems, on the other hand, have a (moderately) great kernel, but finding a distro that works is very difficult.
I started out using UNIX-based systems only, at home, in October 2004, so it's already been two years for me. I tried SuSE, Solaris, Slackware, FreeBSD, Debian and Ubuntu, and so far, I can say that Ubuntu is the one that I liked most. However, GNOME in Ubuntu 6.10 is broken for me, I cannot burn CD's via Nautilus, for instance -- on Debian (3.1r3 stable), that worked! But there's still K3b, so that was no problem. But on every single Linux distribution that I encountered, something just didn't work (and often also couldn't be made to work).
What I really like about Ubuntu (6.10) is, that it comes with the latest and greatest software packages, like GCC 4.1, GNOME 2.16, and so on.
Before that journey to find the right distro, I was using SuSE, and was becoming increasingly bothered by it. SuSE seems to never test their packages, so plenty of those don't work. I cancelled my subscription after 10.1, because it had so many flaws, when I tried it.
What I dislike about Slackware is, that many of the packages aren't dependency-checked properly. It's easy to break your system with just one install.
FreeBSD slowly disintegrated as I was using it, still don't know why. Probably also a dependency checking problem; the more software you installed, the more things became broken. But the whole kernel stuff in FreeBSD is just nice; to load a kernel module, all you have to do is to change a single config file. You don't have to recompile the kernel.
Solaris is a great OS, but is apparently not intended for the desktop (for example, I couldn't get my USB scanner to work with it). Also, administration significantly differs from Linux or BSD systems. Perhaps I'll try that again sometime.
So, the bottom line, from my point of view is, that Ubuntu is the best GNU/Linux distro I've seen so far, and I hope it'll stay on my machine long enough that I don't have to buy Windows Vista or XP.
As far as program development is concerned, I'm dissatisfied with the whole configure-script mess. It is far too complicated to learn in a reasonable amount of time, and so I won't develop native apps for GNU/Linux (and no, none of the IDE's worked for me, I tried all of them; every single one was unable to handle the configure stuff properly). Plus, if you don't have a package maintainer for every distro, you cannot distribute your app (because doing it yourself is virtually impossible due to the insane complexity). I decided to develop exclusively on Java in my sparetime. Not only the libraries are standardized and powerful, the development tools just work and are very powerful, but also I can distribute my apps in a single jar file.
Microsoft gives its resellers major rebates on Windows licenses. I've seen it myself once, a friend of mine was a Microsoft reseller, and he got genuine Windows (95 or NT) OEM licenses for $5 each!! Preinstalling Linux usually is more difficult for vendors who are used to preinstalling Windows. Pricing is also often a result of expected sales. I.e. a reseller might offer Linux PCs at a higher price than Windows PCs, simply because they don't expect to sell as much Linux PCs as Windows PCs. That Windows would behave weird on particular vendor's machines has more to do with the vendor being unable to install it properly, I think. I used to read a German computer magazine called "c't" (Magazine for Computer Technology) and they never once found a computer on which Windows was installed properly. I think this speaks volumes, especially when you think about big companies like Dell, Acer, HP, and so on that sell Windows PCs. Installing Windows can require some expertise, especially when it comes to installing only the latest drivers, making sure the system configuration is consistent and robust, and the BIOS settings are correct, the mainboard and peripheral flash BIOSes (if applicable) are patched to the latest versions, installing all Windows updates, and antivirus protection that isn't a resource hog, etc. Installing Linux is far easier, but also takes some expertise. And usually, when you build a computer you would have to fully check the setup and make sure that everything works. Until such a installation tasks and installation verification tasks are automated, it is unlikely that PC resellers can make PCs that give the user consistent, fully working systems. IMO.
Yeah, indeed. Java runs much better nowadays. Partially, it's because of the JVM's HotSpot engine, partially it's because the computers nowadays have much higher performance.
:-)
Java's VM isn't ideal, by far (nor is MS's CLR), but the computers nowadays are so fast, that you barely notice you're running a Java application.
I'm using the Netbeans IDE myself currently, and I'm pleased with that IDE.
I've given up to try programming in C++ on Linux. The whole automake / configure script stuff is far too complicated for the little spare time that I have.
As long as space technology is as expensive as it is, that might be, to some extent. As long as we still need rocket power to get into space, it'll always be an expensive endeavor.
However, we'll always need space research for satellites, etc., at least in the foreseeable future.
What you're not saying is that all of the above applies only to OS/2 version 1.3 and below. OS/2 2.11, Warp 3 and Warp 4 not only had a great GUI that was far beyond that of Windows in terms of functionality (like the CORBA compatible component-based Workplace Shell that was truly object-oriented and fully integrated into the user experience), but also that they fully supported 80386 and above microprocessors. The second-to-last version of IBM Visual Age for C++ (V3.5) optimized well even for Pentium II and III processors. Also, these versions of OS/2 had an integrated emulation for MS-DOS and Windows 3.1 which contradicts your opinion that they did not support the V86 modes well.
The book isn't that far off from reality. I've seen it all happening myself, watching the computer industry since the early 1980ies.
And you cannot blame it on the users, per se, either.
OS/2 was a failure only because IBM canned it too early -- in 1996, just when the market for OS/2 was finally gaining momentum. And nowadays, if OS/2 still existed, it would be the ideal choice for many users who wanted to escape Windows Vista. Also, banks and insurances would still be using OS/2 (being traditional IBM customers).
Apple and Commodore refused to license their OSes to third parties, which was a grave mistake.
There were plenty of companies who wanted to build Amiga clones, Amiga laptops and notebooks, and so on, but Commodore declined, for instance. Amigas were used by many people just to run MacOS emulators, because the Amiga handled a greater range of peripherals than MacOS did, and was only half as expensive.
The Mac's demise started already in the 80ies, when its pricing policy made it unavailable for the general public. This policy extended far into the 90ies, and MacOS simply was too expensive to be a choice for anyone with a small budget.
This is why Microsoft won against IBM, Apple and Commodore: Windows was comparably cheap, offered more functionality and was easy to develop for.
But Microsoft now makes the same mistakes as once Apple and Commodore: They resort to restrictive licensing, and high pricing, and thus making Windows unavailable for the general masses; at least to the people who do not want to use a pirated product.
I migrated to Linux myself because Windows and associated software simply has become too expensive to afford.
And speaking as a developer, I think that Java currently seems to be the best development platform, because it's platform neutral, and the tools and libraries have great functionality and are well documented.
No, you're wrong. In fact, these 3D projection monitors already exist and have already been sold for a couple of years.
In top middle of the panel (or at the edges) there is an eye motion sensor that tracks the viewer's eye movements and then adjust the view on the screen accordingly.
For instance, have a look at This product from Philips.
But there are also 3D projection systems that use drops of vapor that are illuminated via laser: Wired Article
Google is your friend!
Strange, the black people that I knew were all rich. But I'm living in Germany.
In Germany, if you have a green light, it means, you can enter the intersection, unless there are obvious obstacles, like a traffic jam. If you noticed nothing unusual when entering the intersection, and another driver who had a red light crashed his car into yours, it was his fault and his insurance has to take the responsibility.
In Germany, there are no intersections having stop signs like this. If person A encounters a stop or yield sign at an intersection, person B will not have a stop or yield sign, so person A will have to wait until person B has passed the intersection.
If there is an intersection with no signs, person A has to yield to person B. If B waves A through, it's not a problem, however. Waving someone thru is explicitly allowed.
The first rule of the German driving rules is "cautiousness and mutual considerateness."
Hence, common sense is the most important rule.
The Atari 400 and 800 models (not Atari 800 XL!!) were released way before the C-64, but after the Apple II.
IIRC, Apple II came in 1977 to 1978, Atari 400 and 800 came in 1980 to 1981, and C-64 came in 1982 to 1983.
The Atari 400 was a cheaper model of the Atari 800. The 800 had a real keyboard and 48 K of memory, while the Atari 400 had a flat sensor keyboard and 16 K of memory. Hence, because of the memory size, they were more expensive than the VIC-20.
When the C-64 came, it was more than twice as expensive as the VIC-20 at first.
Hence, here in Germany at least, the Atari 800 and C-64 were seen more as business computers, not home computers.
The Apple II was far beyond in terms of pricing, it was by far the most expensive 8-bit computer, being over twice as expensive than the C-64.
The Apple II was far better than any of the others in terms of expandability. It had a built-in bus system that permitted users to plug in adapter cards, much like the IBM PC years later. So, you cannot really compare the Apple II to the Atari 800 and C-64, IMO.
The Atari 800 and VIC-20, C-64 had module connectors. Usually, you plugged in a module that led to an external expansion box, in which you were able to plug in more modules. Peripherals like disk drives and printers could be connected. I can't remember the buses of the Atari, but the VIC-20 and C-64 had -- like the bigger models -- connectors for IEC bus (serial on the VIC-20 and C-64, parallel on the PET), which permitted connecting disk drives, printers, and other devices. The cassette drive wasn't connected to the IEC bus.
In 1982/1983, the prices were about those: ZX-81: $250, VIC-20: $400, Atari 800: > $500, TI99: > $500, C-64: $750, Apple II: $1500 (all of them naked, without peripherals!). That was a lot of money, even the ZX-81 and VIC-20 seemed expensive.
If you add the prices for peripherals and expansions, you'll see that the Commdore parts were much cheaper than those of their competitors. And that's why Commodore sold more. Disk drives were the most expensive parts, all of them had their own CPUs and were often just as expensive as the computers themselves: Disk drive for Atari 800: $500, for VIC-20/C-64: $400, for Apple II: $750-$1000. (well, IIRC)
Damn! Already in '83?? I had a friend in school whose father had a TI994A. It was a marvellous machine, but wayyy too expensive (at least here in Germany). Here, it was the most expensive home computer. We never saw the big price decline, at least I can't remember it. I really liked the TI99 BASIC interpreter. The only bad thing I remember is that my friend's dad complained often that the machine was getting too hot. But my VIC-20 also was very hot (I had one of those with integrated power supply!), so that wouldn't have bothered me. There were computer magazines for the TI994A which had plenty of programs in it. I think there wasn't much need to buy software, at least here. People bought these computers for programming and typing up programs, but perhaps that was only my view as a kid back then! ;-)
No, it was widespread! ;-)
;-) )
(hardly did the thing justice, tho; I wished I could've afforded one back in the day; I only had a measly VIC-20!
I'll tell you something: After Commodore was dead, I bought my first PC. And from then on, I worked with MS-DOS, OS/2 2.x, 3.x, 4.x, Windows 3.1, 95, 98, NT 4, 2000, XP, and AIX (on RS/6000), Solaris (on UltraSPARC), SuSE Linux, Slackware Linux, FreeBSD, and now Debian Linux. And guess what, at least in the home use arena (thus, excluding Solaris and AIX and the now-dead OS/2), Debian Linux is the first OS that I found that was stable enough for my tastes (after AmigaOS). Windows 98, XP, SuSE Linux, Slackware Linux and FreeBSD all self-destructed before me. I hope that Debian Linux -- stable version -- will live up to its promise. Because I need an OS at home that I can develop for. And that's why I still have hopes to find another OS someday that can live up to the stability and reliability of AmigaOS. I want to do everything with it. If I find a solution that works, I'll use it. My Amiga 3000 ran 9 years without error before self-destructing. It's in a computer museum now somewhere -- repaired. Show me any PC OS that can do that, and I'll use it happily. If I find a modern day (Amiga?) system someday that does everything I want, I might use only that until it breaks for good. I'm patient, like those other thousands of users who want the same thing.
FWIW, I still disagree.
;-)
Nowhere in the BCPL language specification it is written that the stack has to grow forward in memory -- this was just a characteristic of the INTCODE runtime system that was used to port Tripos to the Amiga. Once I wrote a code generator for cross-assembling INTCODE to the 68030 processor in two weeks, and if I had wanted, I could've changed the stack behavior.
That BCPL is word-addressed was not a real problem IMO. Richards later published a byte-addressed backend called CIntcode (C INTCODE). So that wasn't a matter of the language, either (although the original BCPL spec recommended word-addressing, because the machines it ran on at that time were word-addressed).
Even with word-addressing and forward-growing stack, the BCPL implementation on the Amiga wasn't all that bad. I developed for AmigaOS since version 1.1, and I noticed no difference in speed when switching to 2.0. The first thing I noticed in 2.0 was that the ReadArgs() routine was broken, which made me re-implement it to avoid calling the function re-implemented in C. Of course that was fixed in later versions, but the behavior wasn't the same.
The Global Vector was not meant as a library interface, it was simply a linking facility, for the BCPL compiler concept doesn't have a linker. That's why you can just concat INTCODE files into one file, because the Global Vector provides the "linking" mechanism.
If I could afford it, I would develop a fork of AmigaOS starting out from version 1.3. I was deeply dissatisfied with some things in 2.x and upwards.
Of course, many people would disagree with me, but honestly, AmigaOS lost some of its attractiveness to me with the advent of 2.x.
Like, for instance, the "3D look," that ate up most of the Workbench palette (if running in the default 4-color mode), and other things that I mentioned already.
Had I been a Commodore employee, I would've brought up many objections to the development of the later OS releases!
My Amiga never crashed (unless, perhaps, when I ran one of my own programs! ;-) ). Perhaps you should've used different software packages. I used only software that didn't crash the machine.
Lisa and Macintosh didn't have preemptive multitasking. MacOS didn't have preemptive multitasking until OS X. AmigaOS was the first personal computer operating system to have preemptive multitasking. As for GUI systems, before Lisa, there were a number of projects developed at the Xerox research center at Palo Alto. The first (largely text-based) GUI system with mouse was developed in the early 1960ies (!!) (Google for it, there are some interesting videos; however, I can't recall the name of the project right now.) The Atari ST was the first GUI system that was available to the masses, followed by the Amiga 1000. Macintoshs were more than twice as expensive, and unaffordable to average households! Later it was claimed that the Amiga GUI was a Mac rip-off, but that's not true: The Amiga team started out in 1979, which was the year when the XC68000 processor came to market. And the Atari ST was a project started by Jack Tramiel to quickly bring an Amiga-like computer to the market before Commodore did. I recall that in 1983 and 1984, there were already rumors about a super-PC coming to market, made by Commodore, although the rumors were highly exaggerated. A friend in school told me about this, and said it would have 8-channel sound, millions of colors, etc. ;-) -- so the Amiga wasn't a surprise to me when it finally came.
I wonder why Dr Martin Richards from Cambridge UK was never credited for writing Tripos that was simply taken by Tim King of MetaComCo (IIRC) and turned into the dos library. When I learnt BCPL and the design of the BCPL compiler, it was clear to me that Richards' code was very clean and logical. I cannot understand how Tripos would be different in terms of implementation quality. There was only one bug in the OCODE generator that prevented generation of the 2^31 value in OCODE (and yup, I provided a fix to Mr Richards, but that was long after Commodore was gone). Granted, BCPL code seemed to be hard to debug, but in fact it wasn't much more difficult than debugging a C program. I think Tripos made the Amiga a desktop computer in the first place, because it provided all the functionality of file handlers, filing systems etc. The Global Vector was an interesting aspect of that BCPL implementation. Instead of rewriting all the BCPL code in C, more documentation would've been sufficient. I know there were some people who criticized the performance aspects of Tripos. But performance was never really an issue. The dos library wasn't much faster after the rewrite in C, and FFS wasn't much faster than OFS; FFS lacked some fundamental redundancy that made OFS safe. The exec library was prepared for virtual memory management (see MEMF_PUBLIC flag), and it could've been implemented. I still remember Dale Luck's comment that was printed in the German "68000er" magazine, that said something to the effect of "UNIX tries to accommodate for bad software by providing good hardware (an MMU)". The sentiment was "good software doesn't need virtual memory management". This is true to some extent, but the advantage of a VMM system could've proven useful for systems with low memory. At the cost of speed, but at the gain of usability. This is why Windows was such a success: You could run applications despite having low memory. I think that VMM could've been implemented in the exec library without compromising speed: Namely providing virtual memory only to applications that didn't set the MEMF_PUBLIC or MEMF_CHIP flags (CHIP memory could've been paged also, or even remapped into CHIP memory only when necessary).
Like, where? You didn't mention anywhere in your article that "A600" was the working title for the "A1200".
To you last comment: The problem was, that the Amiga community was so fixated on Motorola CPUs that the only thing they accepted besides M68K was PowerPC-based systems. I still remember the "CPU wars" in the Amiga community.
You know, it's just the sheer sadness that drives people to still support Amiga. Fact is, that, conceptually speaking, the AmigaOS was far ahead of its time, and still is. The concept was and is very simple: A micro kernel, a multilayered driver system (resources, devices, and optionally, file handlers), and a real multitasking. I'm not saying this because I'm a fanboy, I'm saying this because I witnessed the advantages first hand, and still witness them. I still use an Amiga 600 for making music! Why? Because it's technically impossible to create music software for Windows or Linux that keeps the pace no matter what you're doing with the computer. On the Amiga, I can easily run my music, and do something else at the same time, without worrying about timing problems. And that's the problem: Timing. The AmigaOS was and is the only one that provides exact and predictable timing for all aspects of the operating system. Windows can't do it, by far, not even with DirectX, and Linux can't do it either, because neither is a real time OS, however AmigaOS is.
:-)
I gladly accept the design flaws in AmigaOS 2.x and 3.x, or even 4.x if it provides me with the flexibility that I need. Perhaps I might even check out MorphOS, or any other of these efforts. Recently, I ran AROS off a live CD on my present main computer, which is a 2.4 GHz Pentium 4 machine with 2 GB of RAM. Even Amiga Emulators like UAE still provide some advantages over their host OS. And that is something, that only AmigaOS can do.
Amiga Inc. is currently working on AmigaOS 5 (AmigaOS 4 was implemented by Hyperion Entertainment), and AmigaOS 5 will be multiplatform. I don't know how they'll solve the kernel issue, perhaps they'll take a Linux or BSD kernel, or write their own; or run it on top of the other systems, who knows. All I care about is, that *I* as a user, or developer, do not have to care about timing issues. If it works, I'll be all over it.
I almost purchased an AmigaONE with AmigaOS 4, but unfortunately I was unemployed at the time and could not afford it. As it happened, a couple of months later, Eyetech (UK) stopped manufacturing the AmigaONE mainboards, and Hyperion halted development of AmigaOS 4 until a new hardware manufacturer has been found. However, that AmigaONE solution was very expensive; I hope they'll manage to reduce prices. I'm also unsure about the performance implications of AmigaOS 4. I hope it'll be as smooth as the old OSes. And if that shouldn't work out, perhaps AmigaOS 5 will be the cure, who knows.
And other projects like AROS and MorphOS look also promising.
To me, the loss of Amiga stifled my creativity. The Amiga was intended as a computer for creative people, and that's what it was. With its loss, an important tool went out the window.
The current operating systems, like Linux and Windows, can only partially compensate for that. And developers for these platforms have not the slightest clue about what creative people need. C*base for making music? Thanks, but no thanks.
Of course not. The 6502 was quite a basic micro processor, even by the standards of that time. It worked, but it was difficult to write any meaningful code for it, i.e. if you wanted to keep a little bit of sanity for yourself! ;-)
I never programmed the 6800, but once I wrote an emulator for the 6809, and I liked the design much better than that of the 6502.
The most comfortable to program was perhaps the 68000, closely followed by the Z80. The Z80 had 22 registers in total (2 x 11 registers). Now, eat that, 8080!! ;-)
I learnt 8086 assembly in the early 90ies when I was faced with MS-DOS for the first time! Yuck!!
Nowadays, Pentium 4 processors are quite nice as well, especially with all the MMX, SSE and SSE2 instructions and the additional registers. Unfortunately, no compiler is using these for regular code generation. It would make code much faster, methinks. I wonder how fast my 2 GHz processor would be if the instruction set was actually used, eh! (I had indeed some suprises when writing assembly code for Pentium II and upwards processors; I never thought that C could be so SLOW.)
I have an Amiga 600 sitting right next to me on my desk, and I can tell you it doesn't have the AGA chipset, only ECS. The Amiga 1200 was the Amiga 600 follow-up that contained the AGA chipset. I remember there was much discussion back then about why Commodore didn't sell computers with the AGA (also called AA) chipset. Because it was finished, but no computers were being built with it. Now we know why. There was also a follow-up to AGA, called "AAA", which never saw the light of market. The main problem for the Amiga was the lopsidedness of application availability. Business folk could never warm themselves to it, because there were only few applications in that arena. And so the PC became "industry standard" (which only means wide adoption by businessfolk, and not by other industries). Of course there were databases (Superbase), spreadsheets etc. - I think the biggest problem was printing support. It was a real pain to use word processors like Final Writer, which were really good on-screen, but had trouble printing (if you didn't have a PostScript printer, which were obscenely expensive back then). Due to memory restrictions for the printer.device, printing often consisted of printing out small stripes that became a whole page if you waited long enough. Windows did never have that problem, because GDI has vector graphics support. I was really disappointed at the shortcomings of the Amiga "printer.device". Commercially available printing tools tried to alleviate that situation, but in essence, you were shelling out money after money to rev up the Amiga performance for such tasks. (Like, buying RAM instead of using a virtual memory mechanism; hard disk space was much cheaper than RAM, even back then)