I think Corel is making a big mistake here. The Linux comunity is in the process of attempting to build distribution standards so commercial developers won't have to tailor applications to multiple distributions. Adding yet another distribution from Corel won't help matters, and it's pretty obvious that Corel plans to use this offering to cross market it's office products with its new distribution. What does the Linux community get out of this?
Where does that leave Red Hat, Debian, Suse, and Caldera users? I think Corel should continue porting their product line over to Linux and tailor a known distribution (like the Mandrake project tailors RedHat) so we won't have to deal with even more market segmentation.
Corel is doing great with their support of Wine. Instead of focusing on something which will (hopefully) fail, why not continue focusing effort on Wine (and porting their commercial products) where they will do the most good?
Can someone give me more information or point me to all currently available information on porting Windows apps to Linux?
(Yes, I'm a Windows vendor looking to port to Linux, one of 1000's more to come, I am sure).
Thanks for any help. It looks like a daunting task. Microsoft has us really tied into their MFC, but I think it's worth doing.
[speaking as an occasional wine user, not a developer]
Check out www.winehq.com for the primary wine homepage and comp.emulators.ms-windows.wine for the primary newsgroup. You may find wine is 'good enough' already for a porting project, but it's nowhere near a functional Win32 runtime library. What that means is that you may be able to tailor your codebase to the API already available on wine to get a working product now; of course, maybe not. The wine folks would prefer you fix problems with the wine API instead of retrofitting your application codebase to work with wine. I'd say you should fiddle with wine a bit, decide if it's the proper porting tool for you, and if so let your software engineers decide what parts of your codebase should be mangled to work with wine and what parts should be fixed within wine itself.
And, as I'm sure the wine developers would say, please pass those patches and bug reports back to the wine community!
and run directly on Linux. It outputs OpenGL and takes about any data type you want to input. Yes it's expensive... that's because it's commercial software.
You are seriously lame (Was Re: You people need..)
on
Microsoft-Compaq-BeOS
·
· Score: 1
Sheesh!
I wonder when MS magically disappears at some point in the near future (hmm, maybe by an alien ship kept at Roswell to be used by the DoJ) and any memory of MS is wiped from the member's of society by satellites orbiting the Earth, what company are you paranoids going to go after next?
How the fuck do you relate Microsoft antitrust court documents with aliens and roswell? Talk about needing prozac, get a grip and write something comparing two related things next time.
Worse yet, the crunchy-granola crowd would hi-jack the open-source movement and turn it into the free-software movement. That's fine and dandy for dusty academics living on NSF grants, but Ayn Rand would never approve of such munificence. If the open-source movement is to prove itself, it will need to produce a commercially viable product.
Does this guy have a clue about the timeline for the creation of the term 'Open Source' vs. 'Free Software'? Obviously not.
Declaring the K Desktop Environment (KDE) apostate because it contains some proprietary code from a Norwegian company is beyond belief. For a dynamic market to grow up around an open-source software product, the open-source movement will have to be unencumbered from all of the left-of-Leningrad socio-economic claptrap.
Believe it dude. Read the GPL and consider the potential (ill)legality of including QT in something released under said licensing terms... Concern over KDE's inclusion of QT was real considering their use of the GPL. If they had chosen a BSD or MIT license that wouldn't have been an issue... but they didn't. This is not about granola crunchy leftist pinko commie 'guild of computer programmers' out to kill the commercial White Knight of technological distribution to the masses and their standardized easy to use GUI (never mind the irony of calling MS a 'White Knight' or considering the terrible effect allowing a monopoly to control the entire software industry, as is obviously MS's intent, would have on our economy as a whole). It's an arcane legal Intellectual Property rights issue meant to maintain the validity of copylefting as a technique. That means protecting the authors code from unscrupulous corporate players who have in the past stolen and copywrited others' work given out to the public domain. All the Open Source licenses exist in order to protect authors' ownership rights (and to a lessor extent protect the authors from implied warrenty issues).
As for the pinko commie trite - since when has sharing for a common collective good among individual citizens for a nonpolitical goal ever been a communist activity? By this line of logic any community service or charitable donation, church activity or otherwise, would be considered communist. Of course, I think you really mean it's communist once it affects your business's bottom line, which has nothing to do with communist politics and everything to do with your corporate marketing spin.
Also: as for Ayn Rand and her extreme philosophy of egoism as the center of creativity: she can blow me.
Well, after this I don't think you guys should claim impartial editorial content. ^o While I realize Sengen didn't write this, he certainly published it.
" A little detective work revealed that, as is usually the case when you encounter something shoddy in the vicinity of a computer, Microsoft incompetence and gratuitous incompatibility were to blame. "
True or not I think this may be pushing an anti MS viewpoint too far. Nor that I support MS. Yeah, I mostly agree with the DOJ view and consider MS has legally stepped over the line. But a news portal ought to be a little more careful about presenting fair and consistent views from the editorial staff, and they ought to be as impartial as possible. This was nowhere near that goal.
I think you'll find that while the FP performance on an Alpha is exceptional the I/O subsystem is really not much better than a PC until you buy a high end system. This means that if you're running CPU intensive applications which require little I/O throughput to disk or network subsystems the Alpha is a good choice. But if you're looking for heavy transaction processing, like with a huge database connected to a web server, a Sun E4000 or E3500 is going to provide significantly better performance (even single CPU).
The Alpha may have been the first 64 bit CPU to come to market, but given similar L2 cache sizes and reasonably modern hardware, it's not really that much better than an UltraSPARC or high end PowerPC based AS/400 system for serious number crunching. And the IBM AS/400 and Sun E3500/4000/10000 systems just eat it's lunch for raw I/O.
If hardware encryption becomes the standard this will kill off any Open Source encryption momentum. You'll note that the Wassenaar agreement specifically doesn't address Open Source. see: www.gnupg.org. So if everyone gets hooked on hardware encryption it's one step closer on the slippery slope to 'clipper' type key escroe our friends at the NSA have been pushing all decade.
I won't be buying into that garbage, nor would I trust Intel or any other huge corporation with my privacy.
Here are some URLs to FAQs which contain specific information on OpenVMS, the VAX and Alpha AXP architecture line, and finally the older PDP-11 line and it's Operating systems RSTS-E, RSX, and RT-11. A Vax-11/750 might disapoint you for sheer computing power compared with todays processors - it's not much faster than a 16mhz 386, but it had a great backplane, powerful peripherals, it could handle huge memory spaces (up to 4MB of RAM in 1977!), and could support 50 (or so) simultaneous users.
VMS Specific FAQs: http://www.cis.ohio-state.edu/hypertext/faq/bngu senet/comp/os/vms/top.html
The PDP-11 was the first low cost 'desk-side' computer available. Introduced in 1970 with a wire wrapped backplane, 8K words of CORE (that's 16K bytes of wire mesh RAM hand weaved for those who don't know), and a CPU made of discrete components, by 1974 a PDP-11/03 could be had for something like 50K which contained 64K of RAM, a VT-52 video terminal, RX01 8" Floppy drives, and RK05 or RL02 removeable pack disk drives (between 2.5MB to 5MB per pack). These machines usually ran RT-11, a Real Time operating system very similar to DOS (except done properly). By Real Time, what they mean is that it's not much more than a program loader - applications get Real Time access to the CPU. These machines were usually bought by scientists for cheap automated data collection or by factories for automated assembly on a production line.
The PDP-11 could also be used for larger multiuser systems, supporting up to 22 bits of address space with an MMU (some backplanes only supported up to 18 bits). Accessing memory beyond 64K thus meant setting offset page registers to move around. In those days memory management meant finding ways to move around a larger address space than directly addressable by the CPU. Today 32 bit CPU's address 4GB while 64 bits work out to 4TB of address lines. Now memory management refers to using virtual memory to readdress linear physical RAM to various address ranges doled out by the OS kernel and 'owned' by individual processes.
In the larger configuration the PDP-11 made for an excellent multiuser system. An 11/44 or 11/34 with 768K of RAM migh run RSTS/E - a multitasking, multiuser Operating System which used BASIC as it's primary interface (I'm certain this is why BASIC in ROM because popular in late 70's micros like the TRS-80, Apple II and Commodore PET 2000 computers). RSX provided a similar interface to RT-11 (as a program loader) but was a multiuser OS. A machine like this could easily handle 16 - 20 simultaneous users while providing a large array of tools, compilers, and I/O devices.
Of course, there was also UNIX available. Check out the UNIX Preservation Society and download a PDP-11 emulator along with a copy of V7 UNIX! You can even buy a source license to V7 UNIX for $100 bucks from SCO! And this is REALLY important because SCO has recognized the historical value of ancient UNIX sources and acted in time preserve history. Compaq should do the same! Time is running out!
COMPAQ, please give out source and binary licenses for ancient operating systems like RT-11, RSTS/E and RSX if only because some people still use these systems and cannot purchase support or maintanance from Digital any longer!
And if you open up OpenVMS by giving away source you stand a good chance at revitalizing the VMS community and reducing your overall support costs for an OS you obviously plan on mkaing obsolete. There are plenty of free UNIX systems now available, we could all use a free alternative operating environment and VMS is certainly a credible alternative to UNIX. If you free the source, hackers will come to fix it up and port it to new platforms - and you won't have to spend a dime.
PDP-11 FAQs:
http://www.village.org/pdp-11/faq.htm
Sunsite PDP-11 support page: http://metalab.unc.edu/pub/academic/computer-sci ence/history/pdp-11/
Great photographs of old systems! http://www.telnet.hu/hamster/pdp-11/
PDP-11 on UNIX preservation society http://minnie.cs.adfa.oz.au/PUPS/
Obviously YMMV, but I had a great experience with the company. They took a tremendous amount of hassling from me getting quote after quote, were always courteous, and handled a special case order where my company needed RedHat 4.2 instead of RH-5.2. And since the box was SMP they even compiled a kernel to support the hardware and provided instructions for getting it up. I really can't give them higher marks!
And to pay them back we ordered only one machine VA and chose a (brain dead) local vendor for about 50 other machines. ARRRGH! Of course the local guy is cheaper (this choice is not management's fault or only concern however, I'm well to blame because of time pressures during the qote exchange phase), but I payed for that by having to give these locals plenty of tech support. I spent a good while explaining to them why a glibc X server won't run on RedHat 4.2 and why rpm --nodeps isn't always the right solution to a dependency problem for example. Feh.
VAResearch was a breath of fresh air and I hope to buy from them again.
Since Compaq seems intent on letting VMS die, I think it would be a shame (especially for those who still use VMS) to let the codebase die.
COMPAQ, this move would give you great PR within the Open Source community and would cost you little. In fact, while you're at it why not free up RT-11, RSTS/E, and RSX? Who uses that stuff anymore but dedicated hobbyists?
Think about their historical value.
J. Maynard Gelinas
MIPS hardware is great, IRIX blows chunks
on
SGI's Visual PC
·
· Score: 1
IMHO, The move to an x86/NT scheme already showed that they aren't too bright. I'm part of a minority who happened to like their mips-based machines...
I can't tell you how many times I've pulled my hair out because if inconsistencies between SGI NFS implementations and the rest of the world. Even IRIX 6.x has problems exporting NFS v.3 to Solaris 2.6... and this is *after* dealing with its horrible 64bit NFS bugs (-32bitclients anyone?). Sure, IRIX scales wonderfully as an SMP kernel, but the userspace tools and many basic UNIX services have been broken for too long. Solaris is just as good a server and it *doesn't* have these problems.
Of course, suggesting that Linux can solve their IRIX problems on commodity Intel hardware only shows that you've never dealth with a serious server. When MIPS Linux or UltraLinux supports 64 CPUs with good threading and apps to make use of this then it may compete with IRIX and Solaris.
As for SGI's last ditch effort with an NT desktop, I don't think this is going to generate significant revenue for SGI because their technology will simply be cloned by the major video card makers within 6 months to a year after release. They don't stand a chance.
The MIPS hardware line is *excellent*... Irix needs some tweeks to make it useful in heterogeneous environments and SGI should fix these obnoxious problems instead of pointing fingers at Sun (and Sun should do the same!) SGI seems destined to throw away their best technology for a forray into the commodity PC world. Good Luck. They'll need it.
AC Writes: E is good for impressing your buddies whom use Windows, but pretty poor for doing anything reasonably productive. Sure, it looks nice, but it's simply not as useful as WindowManager.
I recently installed the new DR15 available with gnome-0.99.0 and I have to agree with this sentiment. It *looks* nice, but it's unstable and tended to crash regularly. But I'm NOT complaining! This a a DR snapshot and as such we should expect that it's basically unusable for production work. Hell, gnome is basically still unusable in production - but it sure does look nice too!
I suspect WindowMaker will gain gnome compliance before E hits 1.0 (or becomes as usable as WindowMaker is at 0.20.x)... In that case I'd say to Rasterman 'don't push yourself to release something broken just so RedHat uses E instead of WindowMaker when they release RH-6.0... spend time and make it right.' Of course I don't say this to disparage either Rasterman or E, just to point out that meeting this deadline is probably less important than finishing up E's featureset and ironing out the bugs before going 1.0.
RH-6.0 is going to be an important release for the US Linux community because it will probably be tested out in the major corporations for ease of use and ease of administration issues. While RH5.2 is at the cutting edge as far as library support goes, its current AnotherLevel window manager configuration is badly broken, and FVWM95 is getting old.
I'm pleased to see them incorporating KDE in the next RH developer release. This way RedHat is covering their butts in case gnome isn't ready for RH-6.0. KDE is something just about every PHB can understand... this is *important* for Linux to become accepted as a small departmental server like NT. Given Caldera's target market they were right to include KDE with COL 1.3, QT issues aside.
Next thing: Linuxconf samba configuration module.... along with including (hopefully) samba-2.0...
Slashdot Mirror
I think Corel is making a big mistake here. The Linux comunity is in the process of attempting to build distribution standards so commercial developers won't have to tailor applications to multiple distributions. Adding yet another distribution from Corel won't help matters, and it's pretty obvious that Corel plans to use this offering to cross market it's office products with its new distribution. What does the Linux community get out of this?
Where does that leave Red Hat, Debian, Suse, and Caldera users? I think Corel should continue porting their product line over to Linux and tailor a known distribution (like the Mandrake project tailors RedHat) so we won't have to deal with even more market segmentation.
Corel is doing great with their support of Wine. Instead of focusing on something which will (hopefully) fail, why not continue focusing effort on Wine (and porting their commercial products) where they will do the most good?
Can someone give me more information or point me to all currently available information on porting Windows apps to Linux?
(Yes, I'm a Windows vendor looking to port to Linux, one of 1000's more to come, I am sure).
Thanks for any help. It looks like a daunting task. Microsoft has us really tied into their MFC, but I think it's worth doing.
[speaking as an occasional wine user, not a developer]
Check out www.winehq.com for the primary wine homepage and comp.emulators.ms-windows.wine for the primary newsgroup. You may find wine is 'good enough' already for a porting project, but it's nowhere near a functional Win32 runtime library. What that means is that you may be able to tailor your codebase to the API already available on wine to get a working product now; of course, maybe not. The wine folks would prefer you fix problems with the wine API instead of retrofitting your application codebase to work with wine. I'd say you should fiddle with wine a bit, decide if it's the proper porting tool for you, and if so let your software engineers decide what parts of your codebase should be mangled to work with wine and what parts should be fixed within wine itself.
And, as I'm sure the wine developers would say, please pass those patches and bug reports back to the wine community!
This app has been available for Linux for awhile directly from Advanced Visual Systems. It has a freshmeat entry at:
0 9/25/906704695.html
http://ny.us.mirrors.freshmeat.net/appindex/1998/
and run directly on Linux. It outputs OpenGL and takes about any data type you want to input. Yes it's expensive... that's because it's commercial software.
Sheesh!
I wonder when MS magically disappears at some point in the near future (hmm, maybe by an alien ship kept at Roswell to be used by the DoJ) and any memory of MS is wiped from the member's of society by satellites orbiting the Earth, what company are you paranoids going to go after next?
How the fuck do you relate Microsoft antitrust court documents with aliens and roswell? Talk about needing prozac, get a grip and write something comparing two related things next time.
Worse yet, the crunchy-granola crowd would hi-jack the open-source movement and turn it into the free-software movement. That's fine and dandy for dusty academics living on NSF grants, but Ayn Rand would never approve of such munificence. If the open-source movement is to prove itself, it will need to produce a commercially viable product.
Does this guy have a clue about the timeline for the creation of the term 'Open Source' vs. 'Free Software'? Obviously not.
Declaring the K Desktop Environment (KDE) apostate because it contains some proprietary code from a Norwegian company is beyond belief. For a dynamic market to grow up around an open-source software product, the open-source movement will have to be unencumbered from all of the left-of-Leningrad socio-economic claptrap.
Believe it dude. Read the GPL and consider the potential (ill)legality of including QT in something released under said licensing terms... Concern over KDE's inclusion of QT was real considering their use of the GPL. If they had chosen a BSD or MIT license that wouldn't have been an issue... but they didn't. This is not about granola crunchy leftist pinko commie 'guild of computer programmers' out to kill the commercial White Knight of technological distribution to the masses and their standardized easy to use GUI (never mind the irony of calling MS a 'White Knight' or considering the terrible effect allowing a monopoly to control the entire software industry, as is obviously MS's intent, would have on our economy as a whole). It's an arcane legal Intellectual Property rights issue meant to maintain the validity of copylefting as a technique. That means protecting the authors code from unscrupulous corporate players who have in the past stolen and copywrited others' work given out to the public domain. All the Open Source licenses exist in order to protect authors' ownership rights (and to a lessor extent protect the authors from implied warrenty issues).
As for the pinko commie trite - since when has sharing for a common collective good among individual citizens for a nonpolitical goal ever been a communist activity? By this line of logic any community service or charitable donation, church activity or otherwise, would be considered communist. Of course, I think you really mean it's communist once it affects your business's bottom line, which has nothing to do with communist politics and everything to do with your corporate marketing spin.
Also: as for Ayn Rand and her extreme philosophy of egoism as the center of creativity: she can blow me.
Well, after this I don't think you guys should claim impartial editorial content. ^o While I realize Sengen didn't write this, he certainly published it.
" A little detective work revealed that, as is usually the case when you encounter something shoddy in the vicinity of a computer, Microsoft incompetence and gratuitous incompatibility were to blame. "
True or not I think this may be pushing an anti MS viewpoint too far. Nor that I support MS. Yeah, I mostly agree with the DOJ view and consider MS has legally stepped over the line. But a news portal ought to be a little more careful about presenting fair and consistent views from the editorial staff, and they ought to be as impartial as possible. This was nowhere near that goal.
I think you'll find that while the FP performance on an Alpha is exceptional the I/O subsystem is really not much better than a PC until you buy a high end system. This means that if you're running CPU intensive applications which require little I/O throughput to disk or network subsystems the Alpha is a good choice. But if you're looking for heavy transaction processing, like with a huge database connected to a web server, a Sun E4000 or E3500 is going to provide significantly better performance (even single CPU).
The Alpha may have been the first 64 bit CPU to come to market, but given similar L2 cache sizes and reasonably modern hardware, it's not really that much better than an UltraSPARC or high end PowerPC based AS/400 system for serious number crunching. And the IBM AS/400 and Sun E3500/4000/10000 systems just eat it's lunch for raw I/O.
If hardware encryption becomes the standard this will kill off any Open Source encryption momentum. You'll note that the Wassenaar agreement specifically doesn't address Open Source. see:
www.gnupg.org. So if everyone gets hooked on hardware encryption it's one step closer on the slippery slope to 'clipper' type key escroe our friends at the NSA have been pushing all decade.
I won't be buying into that garbage, nor would I trust Intel or any other huge corporation with my privacy.
Here are some URLs to FAQs which contain specific information on OpenVMS, the VAX and Alpha AXP architecture line, and finally the older PDP-11 line and it's Operating systems RSTS-E, RSX, and RT-11. A Vax-11/750 might disapoint you for sheer computing power compared with todays processors - it's not much faster than a 16mhz 386, but it had a great backplane, powerful peripherals, it could handle huge memory spaces (up to 4MB of RAM in 1977!), and could support 50 (or so) simultaneous users.
u senet/comp/os/vms/top.html
5 6/faq1.htm
i ence/history/pdp-11/
VMS Specific FAQs:
http://www.cis.ohio-state.edu/hypertext/faq/bng
http://www.montagar.com/dfwlug/openvms-faq.html
http://www.geocities.com/SiliconValley/Lakes/29
The PDP-11 was the first low cost 'desk-side' computer available. Introduced in 1970 with a wire wrapped backplane, 8K words of CORE (that's 16K bytes of wire mesh RAM hand weaved for those who don't know), and a CPU made of discrete components, by 1974 a PDP-11/03 could be had for something like 50K which contained 64K of RAM, a VT-52 video terminal, RX01 8" Floppy drives, and RK05 or RL02 removeable pack disk drives (between 2.5MB to 5MB per pack). These machines usually ran RT-11, a Real Time operating system very similar to DOS (except done properly). By Real Time, what they mean is that it's not much more than a program loader - applications get Real Time access to the CPU. These machines were usually bought by scientists for cheap automated data collection or by factories for automated assembly on a production line.
The PDP-11 could also be used for larger multiuser systems, supporting up to 22 bits of address space with an MMU (some backplanes only supported up to 18 bits). Accessing memory beyond 64K thus meant setting offset page registers to move around. In those days memory management meant finding ways to move around a larger address space than directly addressable by the CPU. Today 32 bit CPU's address 4GB while 64 bits work out to 4TB of address lines. Now memory management refers to using virtual memory to readdress linear physical RAM to various address ranges doled out by the OS kernel and 'owned' by individual processes.
In the larger configuration the PDP-11 made for an excellent multiuser system. An 11/44 or 11/34 with 768K of RAM migh run RSTS/E - a multitasking, multiuser Operating System which used BASIC as it's primary interface (I'm certain this is why BASIC in ROM because popular in late 70's micros like the TRS-80, Apple II and Commodore PET 2000 computers). RSX provided a similar interface to RT-11 (as a program loader) but was a multiuser OS. A machine like this could easily handle 16 - 20 simultaneous users while providing a large array of tools, compilers, and I/O devices.
Of course, there was also UNIX available. Check out the UNIX Preservation Society and download a PDP-11 emulator along with a copy of V7 UNIX! You can even buy a source license to V7 UNIX for $100 bucks from SCO! And this is REALLY important because SCO has recognized the historical value of ancient UNIX sources and acted in time preserve history. Compaq should do the same! Time is running out!
COMPAQ, please give out source and binary licenses for ancient operating systems like RT-11, RSTS/E and RSX if only because some people still use these systems and cannot purchase support or maintanance from Digital any longer!
And if you open up OpenVMS by giving away source you stand a good chance at revitalizing the VMS community and reducing your overall support costs for an OS you obviously plan on mkaing obsolete. There are plenty of free UNIX systems now available, we could all use a free alternative operating environment and VMS is certainly a credible alternative to UNIX. If you free the source, hackers will come to fix it up and port it to new platforms - and you won't have to spend a dime.
PDP-11 FAQs:
http://www.village.org/pdp-11/faq.htm
Sunsite PDP-11 support page:
http://metalab.unc.edu/pub/academic/computer-sc
Great photographs of old systems!
http://www.telnet.hu/hamster/pdp-11/
PDP-11 on UNIX preservation society
http://minnie.cs.adfa.oz.au/PUPS/
Obviously YMMV, but I had a great experience with the company. They took a tremendous amount of hassling from me getting quote after quote, were always courteous, and handled a special case order where my company needed RedHat 4.2 instead of RH-5.2. And since the box was SMP they even compiled a kernel to support the hardware and provided instructions for getting it up. I really can't give them higher marks!
And to pay them back we ordered only one machine VA and chose a (brain dead) local vendor for about 50 other machines. ARRRGH! Of course the local guy is cheaper (this choice is not management's fault or only concern however, I'm well to blame because of time pressures during the qote exchange phase), but I payed for that by having to give these locals plenty of tech support. I spent a good while explaining to them why a glibc X server won't run on RedHat 4.2 and why rpm --nodeps isn't always the right solution to a dependency problem for example. Feh.
VAResearch was a breath of fresh air and I hope to buy from them again.
Since Compaq seems intent on letting VMS die, I think it would be a shame (especially for those who still use VMS) to let the codebase die.
COMPAQ, this move would give you great PR within the Open Source community and would cost you little. In fact, while you're at it why not free up RT-11, RSTS/E, and RSX? Who uses that stuff anymore but dedicated hobbyists?
Think about their historical value.
J. Maynard Gelinas
IMHO, The move to an x86/NT scheme already showed that they aren't too bright. I'm part of a minority who happened to like their mips-based machines...
I can't tell you how many times I've pulled my hair out because if inconsistencies between SGI NFS implementations and the rest of the world. Even IRIX 6.x has problems exporting NFS v.3 to Solaris 2.6... and this is *after* dealing with its horrible 64bit NFS bugs (-32bitclients anyone?). Sure, IRIX scales wonderfully as an SMP kernel, but the userspace tools and many basic UNIX services have been broken for too long. Solaris is just as good a server and it *doesn't* have these problems.
Of course, suggesting that Linux can solve their IRIX problems on commodity Intel hardware only shows that you've never dealth with a serious server. When MIPS Linux or UltraLinux supports 64 CPUs with good threading and apps to make use of this then it may compete with IRIX and Solaris.
As for SGI's last ditch effort with an NT desktop, I don't think this is going to generate significant revenue for SGI because their technology will simply be cloned by the major video card makers within 6 months to a year after release. They don't stand a chance.
The MIPS hardware line is *excellent*... Irix needs some tweeks to make it useful in heterogeneous environments and SGI should fix these obnoxious problems instead of pointing fingers at Sun (and Sun should do the same!) SGI seems destined to throw away their best technology for a forray into the commodity PC world. Good Luck. They'll need it.
AC Writes:
E is good for impressing your buddies whom use Windows, but pretty poor for doing anything reasonably productive. Sure, it looks nice, but it's simply not as useful as WindowManager.
I recently installed the new DR15 available with gnome-0.99.0 and I have to agree with this sentiment. It *looks* nice, but it's unstable and tended to crash regularly. But I'm NOT complaining! This a a DR snapshot and as such we should expect that it's basically unusable for production work. Hell, gnome is basically still unusable in production - but it sure does look nice too!
I suspect WindowMaker will gain gnome compliance before E hits 1.0 (or becomes as usable as WindowMaker is at 0.20.x)... In that case I'd say to Rasterman 'don't push yourself to release something broken just so RedHat uses E instead of WindowMaker when they release RH-6.0... spend time and make it right.' Of course I don't say this to disparage either Rasterman or E, just to point out that meeting this deadline is probably less important than finishing up E's featureset and ironing out the bugs before going 1.0.
RH-6.0 is going to be an important release for the US Linux community because it will probably be tested out in the major corporations for ease of use and ease of administration issues. While RH5.2 is at the cutting edge as far as library support goes, its current AnotherLevel window manager configuration is badly broken, and FVWM95 is getting old.
I'm pleased to see them incorporating KDE in the next RH developer release. This way RedHat is covering their butts in case gnome isn't ready for RH-6.0. KDE is something just about every PHB can understand... this is *important* for Linux to become accepted as a small departmental server like NT. Given Caldera's target market they were right to include KDE with COL 1.3, QT issues aside.
Next thing: Linuxconf samba configuration module.... along with including (hopefully) samba-2.0...
rantrantrantrant
Thanks for all your hard work, Raster!