That's strange. I can ssh into all my NT machines remotely and do anything I want via a remote GUI. And it didn't cost me a cent. I don't see how that's harder than using ssh/X.
First of all, it wasn't written by Gates, it's "satire". But let's pretend it was written by Gates. Taking your points in order:
1. Gates is smart enough to know that within 3 years the OS will be irrelevant. "It's about the applications, stupid." Hence.NET; hence no mention of server-side stuff in this mail at all.
2. Basic philosophical difference in approach. There is no "right" answer.
3. BeOS does not have industry support. MacOS _does_ have Windows Media Player support.
4. Now you're just being silly. If the US economy consisted _solely_ of work on Java, then yes, you might be right. But of course it doesn't. It remains to be seen what impact C# has on Java.
I don't understand what all the fuss is about. Here's why.
1. This is not Office.
Nowhere in any of the articles so far referenced in these/. two stories (aside from the *unconfirmable* WinInsider "scoop") is Office mentioned. Internet Explorer is not part of Office.
2. Internet Explorer already runs on Unix.
It has done, on at least Solaris and HP-UX, since 1997 with IE 3.0. Mainsoft was the solution provider for that port, and ports since, too. Nowhere in any of the articles referenced in these two/. stories is there mention of ports other than Solaris and HP-UX, so far as I can see. I've not used any of the ports; I've heard good and bad things about the latest port of IE 5. It would seem that YMMV.
3. My take on this:
It seems to me that this is nothing more than Microsoft confirming to Mainsoft that they (Mainsoft) will continue to be contracted to port IE for the near future, at least. That may mean IE 5.5 ports to Solaris and HP-UX; it may even mean ports of IE 6, when that becomes available.
But *nowhere* in any of these articles, so far as I can see, is there a *mention* of porting Office, or indeed of porting *anything* to a platform other than Solaris or HP-UX.
If you want my opinion (and hey, you probably don't, but this is my post), then I think this is nothing more than a small company (Mainsoft) trumpeting its own success so it can feel like it's playing with the big boys.
Despite the fact that they were going down anyway many people will still see this as evidence the open source business model doesn't work.
But Corel doesn't really use an open source business model, do they? In fact, I'm not sure what you'd call their business model. It's neither 100% commercial (a la Microsoft or IBM), nor is it open source (their stuff tends to be free as in beer, not speech). It's not one nor the other (although to be fair, since [this is just my opinion, not flame-bait] it's not possible to make money off open source, they can't really do that).
And that, in a nutshell, sums up Corel: neither one nor the other. Corel is a confused company that seems to lack any fundamental vision, and that's why it's tanking. I hate to seem cynical, but Corel's dance with Linux is a last-ditch effort to seem relevant in a software industry in which they are no longer relevant.
Netscape isn't a COM container, and IE (on Win32) is. That's how IE is able to host your IT department's ActiveX controls, and Netscape isn't. Your IT department must have developed their application on the understanding that by requiring ActiveX it would only function under IE on Win32.
There's been an example of this in New Zealand just in the past week. An indigenous fishing company, Moana Pacific, discovered the domain moanapacific.com had been registered by a competitor.
...severely broken in terms of supporting standards...
Heh. That's pretty funny. Try to do anything vaguely complex with templates in gcc, then we'll talk.
[VC++, etc.]... are good for slapping out broken, severely buggy bloatware quickly...
Irrelevant. Bloat is about the programmer, not the tools.
For instance, I wouldn't trade gdb for the broken, crappy debugger built into VC++ any day.
Well, you're entitled to your opinion, of course. I guess I just disagree, that's all. I know that Emacs supports inline debugging from gdb, but in my opinion it's not as nice as Visual Studio's integrated debugging. And what exactly is "broken" about VC++'s debugger?
Why do you think Linux has been able to attract so many software development geeks?
Um, because both the platform and the development toos are free? (As in beer - I don't believe that the majority of Linux users really care about freedom of speech.) While very useable and powerful, these tools pale in comparison to proprietary tools available on other platforms. Their only significant advantage from a corporate perspective is price.
That's a bit unfair. The stuff that's implemented _does_ work just fine, it's just they've implemented the minimum possible to be able to claim Posix compliance - to be precise, they have implemented 1003.3.
Interix adds heaps more functionality; MS also offers a downloadable (non-free-beer) Unix Services for NT which adds various Unix-standard daemons.
I am not deploying any server that I can't administer from the comfort of an SSH connection from home.
Um, you _can_ administer NT via SSH from home. We've got several NT boxes here which we can administer via SSH (run on a Linux box, of course) using VNC. Works like a dream.
Not suggesting you deploy NT, of course, just giving an alternative point of view;)
Does the script have to use PERL? If not, you could try using MAILTO, a free 10 kb program available from winfiles.com that allows you to send SMTP mail from a commandline. You need an SMTP server available somewhere on your network. Or if Microsoft Exchange is the backend, then I have a VBScript script that can be invoked via Windows Scripting Host to send a piece of mail (plus an attachment). Email me off of the list if you want to get it: alastair@hsnz.co.nz
I wonder how the backend database is supposed to be used from within ASP under Apache. Presumably Chilisoft have implemented at least the ADO object (or an emulation of it) that can be instantiated from within an ASP page...
[goes hunting]
Ah, yes. According to http://www.chilisoft.com/chiliasp/ar chdiag.htm, they've not only implemented Active Data Objects (ADO), but also the other base objects that come with ASP on IIS (FileSystem, TextStream, etc). That's cool. And the backend db looks to be pluggable, from that diagram; Oracle, MySQL and DB2 are mentioned.
With regard to instantiating other COM objects; according to http://www.chilisoft.com/chiliasp/ aspfaq.htm#com, no, it's not possible on native UNIX (figures). But a COM to Java bridge is available, so you can instantiate Java servlets as COM objects in your ASP scripts, and DCOM is also available, so you can continue to instantiate Win32 COM objects, just off of a remote Windows NT server!
You're drastically overestimating the intelligence of VB idiots if you think they are even capable of learning a useful programming language. They're not.
Writing a large-scale, multi-tier business app in VB requires the same skills and knowledge as it does in any other language. I think you do VB developers a disservice with your comments.
... apache+php offers more or less the same solution as [insert webserver] + ASP.
The primary difference between IIS + ASP and (e.g.) Apache + ASP (via Chilisoft) is that IIS supports COM component instantiation from within ASP. This means that you can write a GUI app using Visual C++ or another dev tool and, so long as you've separated out the GUI from the implementation in your object design, you can instantiate your middle tier objects (via COM) directly from within ASP. Essentially, you can replace the Win32 GUI layer in your app with an HTML GUI layer provided by IIS without having to rewrite any of the core business logic.
For businesses with an existing OO/Win32 investment, IIS + ASP can make a lot of sense. ASP by itself, without COM, doesn't offer anything more than Apache + modperl.
VB is a simple language for high productivity development of GUI business apps.
Not strictly true; it is quite possible to develop GUI-less apps (e.g. Windows NT services) in VB.
Unfortunately, VB's sedimentary feature accumulation has destroyed its potential for soundness and beauty; the language is a mess.
Agreed. Although with VB7 it looks like the VB developers are going back to the drawing board and reworking some of the cruft in the language (e.g. exception handling).
It's a product that lets you run MS' Active Server Pages on a Linux web server.
Which by itself is not particularly useful. What makes ASP compelling is its ability to instantiate COM components. Hence you can implement your middle tier in C++ or Java, then call those components from ASP without writing extra code.
I don't see how the COM calling conventions are going to be made to work under non-MS operating systems. ASP by itself is not particularly useful.
Basically, it means that you can let your users use Frontpage without worrying about what's supported and what isn't.
Irrelevant. ASP and FrontPage are different. All the snazzy stuff in FrontPage is enabled by the FrontPage Server Extensions, which have been available for Apache for several years:)
Not necessarily. I haven't investigated the Chilisoft product in detail, but I would imagine that the COM system that makes ASP as powerful as it is is not available under non-MS operating systems. Without COM, and the ability to instantiate objects from ASP scripts, ASP is not particularly useful.
Knuth didn't create C++. And maybe he made up a large number name in order to make his talk more accessible; "aleph0" isn't exactly a term that's in common usage:)
Slashdot Mirror
The Opera browser is 100% W3C compliant
Then why is its ECMA script support so horribly broken?
That's strange. I can ssh into all my NT machines remotely and do anything I want via a remote GUI. And it didn't cost me a cent. I don't see how that's harder than using ssh/X.
First of all, it wasn't written by Gates, it's "satire". But let's pretend it was written by Gates. Taking your points in order:
.NET; hence no mention of server-side stuff in this mail at all.
1. Gates is smart enough to know that within 3 years the OS will be irrelevant. "It's about the applications, stupid." Hence
2. Basic philosophical difference in approach. There is no "right" answer.
3. BeOS does not have industry support. MacOS _does_ have Windows Media Player support.
4. Now you're just being silly. If the US economy consisted _solely_ of work on Java, then yes, you might be right. But of course it doesn't. It remains to be seen what impact C# has on Java.
Cheers,
Alastair
This would be such an inconvenience for users that MS would have to fix it!
No, this would be such an inconvenience for users that they'd either switch banks or just not use internet banking. Think about it.
The root user is a "serious problem" that people should be aware of? I take it you're joking :)
Good analogy, but it's "Ouroboros" (OO - ROB - OR - ROSS), not "Ourobos", I think. Watch more Red Dwarf :)
I don't understand what all the fuss is about. Here's why.
/. two stories (aside from the *unconfirmable* WinInsider "scoop") is Office mentioned. Internet Explorer is not part of Office.
/. stories is there mention of ports other than Solaris and HP-UX, so far as I can see. I've not used any of the ports; I've heard good and bad things about the latest port of IE 5. It would seem that YMMV.
1. This is not Office.
Nowhere in any of the articles so far referenced in these
2. Internet Explorer already runs on Unix.
It has done, on at least Solaris and HP-UX, since 1997 with IE 3.0. Mainsoft was the solution provider for that port, and ports since, too. Nowhere in any of the articles referenced in these two
3. My take on this:
It seems to me that this is nothing more than Microsoft confirming to Mainsoft that they (Mainsoft) will continue to be contracted to port IE for the near future, at least. That may mean IE 5.5 ports to Solaris and HP-UX; it may even mean ports of IE 6, when that becomes available.
But *nowhere* in any of these articles, so far as I can see, is there a *mention* of porting Office, or indeed of porting *anything* to a platform other than Solaris or HP-UX.
If you want my opinion (and hey, you probably don't, but this is my post), then I think this is nothing more than a small company (Mainsoft) trumpeting its own success so it can feel like it's playing with the big boys.
Cheers,
Alastair
Despite the fact that they were going down anyway many people will still see this as evidence the open source business model doesn't work.
But Corel doesn't really use an open source business model, do they? In fact, I'm not sure what you'd call their business model. It's neither 100% commercial (a la Microsoft or IBM), nor is it open source (their stuff tends to be free as in beer, not speech). It's not one nor the other (although to be fair, since [this is just my opinion, not flame-bait] it's not possible to make money off open source, they can't really do that).
And that, in a nutshell, sums up Corel: neither one nor the other. Corel is a confused company that seems to lack any fundamental vision, and that's why it's tanking. I hate to seem cynical, but Corel's dance with Linux is a last-ditch effort to seem relevant in a software industry in which they are no longer relevant.
Netscape isn't a COM container, and IE (on Win32) is. That's how IE is able to host your IT department's ActiveX controls, and Netscape isn't. Your IT department must have developed their application on the understanding that by requiring ActiveX it would only function under IE on Win32.
There's been an example of this in New Zealand just in the past week. An indigenous fishing company, Moana Pacific, discovered the domain moanapacific.com had been registered by a competitor.
/storydisplay.cfm?storyID=139411
http://www.nzherald.co.nz
They successfully had the domain overturned.
Wired has an article in the same vein as the CNN one:
http://www.wired.com/news/p olitics/0,1283,36899,00.html
Cheers,
Alastair
...severely broken in terms of supporting standards...
... are good for slapping out broken, severely buggy bloatware quickly...
Heh. That's pretty funny. Try to do anything vaguely complex with templates in gcc, then we'll talk.
[VC++, etc.]
Irrelevant. Bloat is about the programmer, not the tools.
For instance, I wouldn't trade gdb for the broken, crappy debugger built into VC++ any day.
Well, you're entitled to your opinion, of course. I guess I just disagree, that's all. I know that Emacs supports inline debugging from gdb, but in my opinion it's not as nice as Visual Studio's integrated debugging. And what exactly is "broken" about VC++'s debugger?
It all boils down to opinions.
Why do you think Linux has been able to attract so many software development geeks?
Um, because both the platform and the development toos are free? (As in beer - I don't believe that the majority of Linux users really care about freedom of speech.) While very useable and powerful, these tools pale in comparison to proprietary tools available on other platforms. Their only significant advantage from a corporate perspective is price.
That's a bit unfair. The stuff that's implemented _does_ work just fine, it's just they've implemented the minimum possible to be able to claim Posix compliance - to be precise, they have implemented 1003.3.
Interix adds heaps more functionality; MS also offers a downloadable (non-free-beer) Unix Services for NT which adds various Unix-standard daemons.
Sounds cool, but what if you're outside the US?
I am not deploying any server that I can't administer from the comfort of an SSH connection from home.
;)
Um, you _can_ administer NT via SSH from home. We've got several NT boxes here which we can administer via SSH (run on a Linux box, of course) using VNC. Works like a dream.
Not suggesting you deploy NT, of course, just giving an alternative point of view
Actually, it doesn't matter if you use PERL or not. Both those things I mentioned above could be invoked from a PERL script without difficulty...
Does the script have to use PERL? If not, you could try using MAILTO, a free 10 kb program available from winfiles.com that allows you to send SMTP mail from a commandline. You need an SMTP server available somewhere on your network. Or if Microsoft Exchange is the backend, then I have a VBScript script that can be invoked via Windows Scripting Host to send a piece of mail (plus an attachment). Email me off of the list if you want to get it: alastair@hsnz.co.nz
I think I've just been trolled :)
I wonder how the backend database is supposed to be used from within ASP under Apache. Presumably Chilisoft have implemented at least the ADO object (or an emulation of it) that can be instantiated from within an ASP page...
[goes hunting]
Ah, yes. According to http://www.chilisoft.com/chiliasp/ar chdiag.htm, they've not only implemented Active Data Objects (ADO), but also the other base objects that come with ASP on IIS (FileSystem, TextStream, etc). That's cool. And the backend db looks to be pluggable, from that diagram; Oracle, MySQL and DB2 are mentioned.
With regard to instantiating other COM objects; according to http://www.chilisoft.com/chiliasp/ aspfaq.htm#com, no, it's not possible on native UNIX (figures). But a COM to Java bridge is available, so you can instantiate Java servlets as COM objects in your ASP scripts, and DCOM is also available, so you can continue to instantiate Win32 COM objects, just off of a remote Windows NT server!
Very cool!
You're drastically overestimating the intelligence of VB idiots if you think they are even capable of learning a useful programming language. They're not.
Writing a large-scale, multi-tier business app in VB requires the same skills and knowledge as it does in any other language. I think you do VB developers a disservice with your comments.
... apache+php offers more or less the same solution as [insert webserver] + ASP.
The primary difference between IIS + ASP and (e.g.) Apache + ASP (via Chilisoft) is that IIS supports COM component instantiation from within ASP. This means that you can write a GUI app using Visual C++ or another dev tool and, so long as you've separated out the GUI from the implementation in your object design, you can instantiate your middle tier objects (via COM) directly from within ASP. Essentially, you can replace the Win32 GUI layer in your app with an HTML GUI layer provided by IIS without having to rewrite any of the core business logic.
For businesses with an existing OO/Win32 investment, IIS + ASP can make a lot of sense. ASP by itself, without COM, doesn't offer anything more than Apache + modperl.
VB is a simple language for high productivity development of GUI business apps.
Not strictly true; it is quite possible to develop GUI-less apps (e.g. Windows NT services) in VB.
Unfortunately, VB's sedimentary feature accumulation has destroyed its potential for soundness and beauty; the language is a mess.
Agreed. Although with VB7 it looks like the VB developers are going back to the drawing board and reworking some of the cruft in the language (e.g. exception handling).
It's a product that lets you run MS' Active Server Pages on a Linux web server.
:)
Which by itself is not particularly useful. What makes ASP compelling is its ability to instantiate COM components. Hence you can implement your middle tier in C++ or Java, then call those components from ASP without writing extra code.
I don't see how the COM calling conventions are going to be made to work under non-MS operating systems. ASP by itself is not particularly useful.
Basically, it means that you can let your users use Frontpage without worrying about what's supported and what isn't.
Irrelevant. ASP and FrontPage are different. All the snazzy stuff in FrontPage is enabled by the FrontPage Server Extensions, which have been available for Apache for several years
Not necessarily. I haven't investigated the Chilisoft product in detail, but I would imagine that the COM system that makes ASP as powerful as it is is not available under non-MS operating systems. Without COM, and the ability to instantiate objects from ASP scripts, ASP is not particularly useful.
Knuth didn't create C++. And maybe he made up a large number name in order to make his talk more accessible; "aleph0" isn't exactly a term that's in common usage :)