I made a living for a couple years writing p-system code (my employer lost lots of money on it though).
UCSD p-System is exactly analogous to Java in the portability sense. We shipped a single binary to customers on p-System machines of several architecture and it ran. We did have some headaches with physical disk formats though.
There was definitely random file I/O. The DBMS we wrote wouldn't work without it. And while it didn't have graphics it had direct screen addressing; I think there was a gotoxy(x,y) in the run time library.
By the way, I did this work in 1983 and 1984, so it's not surprising that there was no graphics. Graphics systems were expensive and incompatible those days. On the hardware we worked on (8088s mostly) p-System was slow enough without a big fat graphics virtualization library.
BTW, as far as I know, p-System had the first real dynamic linking capability.
Steve Westly, vice president of marketing and business development, said Friday afternoon that the database damage was traced to a failure in software developed by Sun Microsystems Inc. (Nasdaq:SUNW)
"We know it is a problem caused by the Sun software," Westly said. "We have their full support, going to the top of Sun, they are committed to solving this problem."
Of course you can do a search on eBay now, it's back up. And are you seriously saying the web server can cause the back-end database to crash? Explain this please.
>>given my experiences with NT Server, I think it would be insane to put an NT server under those types of load conditions. Any of y'all out there running Linux with the types of loads eBay has been experiencing?
There's a long list of sites on the web at least as big as eBay running NT (Dell, Barnes&Noble, 1800flowers, ESPN, etc.), and they don't have eBay's persistant reliability problems. I suspect eBay programmers are at fault.
What's the biggest Linux site on the net you can think of? Dejanews? Hardly a bastion of reliability, and neither is/.
Have you ever actually written Perl code on Win32, or Perl anywhere for that matter? Perl on all platforms is filled with opportunities to write non-portable code. Go to CPAN and you're immediately faced with module names like Mac/MacConversions Mac/MacFileSpecUnixish Mac/MacOSASimple Mail/MailCclient RADIUS/RADIUS RADIUS/RADIUSUserFileX11/XformsPerl X11/XFvwm X11/XMotifb X11/XProtocol X11/XWcl VMS/VMSLock_ VMS/VMSMonitor_ VMS/VMSPriv_ Tk/TkTreeGraph Tk/TkWaitBox Tk/vstadaf Tk/xdbfdump OS2/OSAttrib OS2/OSExtAttr_ OS2/OSFTP_, not to mention Emacs/EmacsLisp
Making modules to take advantage of platform-specific features is not only old news on Perl, it's one of the main points of the language. It's the whole idea.
Maybe you've never written a Windows program before, but Windows programmers are used to the idea that some of their programs will only work on Windows, and are willing to trade that off for optimal utilization of features on Windows, which is the most popular platform in the world. It's a rational decision and they don't do it unwittingly.
>>Meaning code that was designed to be portable won't be.
How could this be possible in Perl? Either it's interpreted, and therefore it's exactly as portable as it's designed to be, or it's compiled and completely unportable. Your argument makes no sense.
Check out the copyright to \winnt\resource kit\Perl\Perl.exe:
Copyright 1987-1994, Larry Wall Win32 port Copyright (c) 1995 Microsoft Corporation. All rights reserved. Developed by hip communications inc., http://info.hip.com/info/
Perl for Win32 Build 107 Built Apr 29 1996@22:56:57
Hip Communications is now Activestate (although they seem to have sold the hip.com domain to someone else).
So the problem is not smart people like you, it's all those stupid people out there. All those novices buying computers at CompUSA and then unwittingly writing Windows Perl scripts. Sounds real plausible to me.
Like you said, ActiveState was founded to make Perl specifically for Win32. Some of their original funding (as Hip Computing I think) came from Microsoft so that they would have a Perl to ship with NT Server.
In case nobody here knows, a version of their Perl has always shipped with the NT Resource Kit.
>>WinPerl will not be totally compatible with our current incarnations of Perl, and that will be the problem.
Where did you get this idea? All the FAQ and press release say is that there will be access to Win32-specific features, and there have always been such extensions in ActiveState Perl. You can write portable perl and it will work in ActiveState just like on any other platform, or you can write Win32-specific code and it will work only on Win32. You can do the same thing on UNIX; don't tell me you've never seen a Perl script that would only work on UNIX, cause there are plenty of them. It's as easy as `/usr/bin/whatever`
I've written a lot of ActiveState Perl, some of it portable, some Win32-specific. It's impossible to use the type of features they are talking about accidentally. You always have to use some Win32:: module. What could more explicit than that?
I've written lots of ActiveState Perl and there are modules for registry access, for NT security management, not to mention plenty of famous 3rd-party modules, like Win32::ODBC.
It's just like the Win32-specific Java stuff in Microsoft's Java. Nobody can use it accidentally, but if you want to write a Win32-speicific program it's there for you to do (just like you can write UNIX-specific Perl programs just by calling native code).
The same hardware was used on all products, and the total working set size is 30-something MB. I'm pretty sure it's 512MB RAM in each system. Anything will cache all of it.
>>The other interesting point is the fact that ZD came up with the IIS benchmarks specifically to show how good IIS is. Such things as fitting the test harness in the cache, and only doing ISAPI dll's for dynamic content (vs CGI on other servers).
You obviously made this up. The benchmarks are completely portable, consisting of files on the server and clients making requests of those files. There is no code.
All deoends on how you define "traffic". Commerce sites do a lot more complex work than the average search engine.
In any event, www.microsoft.com and www.msn.com handle more traffic than any search engine, except Yahoo I suppose. And the work they do is far more complex than Yahoo, which largely serves static pages.
Actually, Hotmail is still on Apache/FreeBSD, but your basic point is correct. Numerous very large and reliable sites run on NT/IIS (see list below). Try to find a large site on the net running Linux; there aren't a whole lot. DejaNews is the biggest I can think of, and it's notoriously slow and unreliable.
NT Sites: www.microsoft.com www.dell.com www.gateway.com www.ebay.com www.onsale.com www.buy.com www.disney.com www.compaq.com www.nasdaq.com www.nfl.com www.espn.com www.exxon.com www.ml.com (Merril Lynch) www.shopping.com www.forbes.com www.intel.com and, of course, www.drudgereport.com, which actually appears to be running on Windows 2000/IIS5.
In fact, if you look at commerce sites on the web, IIS is by far the most popular server.
The only evidence that Microsoft lobbied for this is Baratz's assertion. You can go and read the ISO e-mail discussions yourself (be patient, slow server in Denmark); The Microsoft people basically kept their mouths shut and now everyone on the list is pissed at Sun.
Baratz needed a scapegoat. Who else would he blame?
The discussions of the Java Standards Group (JTC 1 SC22) can be found at ftp://dkuug.dk/JTC1/SC22/JSG/. Looks like anyone can join the mailing list, and anyone can read themail. ftp://dkuug.dk/JTC1/SC22/JSG/926 and up are the messages since Sun formally chickened out of submitting, and the reaction on the list is consistant: what the hell is Sun talking about? There's also general dismissal of Sun's assertions that Microsoft did any lobbying at all on this issue.
You can also see the members of the list at ftp://dkuug.dk/JTC1/SC22/JSG/list.
Slashdot Mirror
I made a living for a couple years writing p-system code (my employer lost lots of money on it though).
UCSD p-System is exactly analogous to Java in the portability sense. We shipped a single binary to customers on p-System machines of several architecture and it ran. We did have some headaches with physical disk formats though.
There was definitely random file I/O. The DBMS we wrote wouldn't work without it. And while it didn't have graphics it had direct screen addressing; I think there was a gotoxy(x,y) in the run time library.
By the way, I did this work in 1983 and 1984, so it's not surprising that there was no graphics. Graphics systems were expensive and incompatible those days. On the hardware we worked on (8088s mostly) p-System was slow enough without a big fat graphics virtualization library.
BTW, as far as I know, p-System had the first real dynamic linking capability.
More details from the ZDNN story:
Steve Westly, vice president of marketing and business development, said Friday afternoon that the database damage was traced to a failure in software developed by Sun Microsystems Inc. (Nasdaq:SUNW)
"We know it is a problem caused by the Sun software," Westly said. "We have their full support, going to the top of Sun, they are committed to solving this problem."
Of course you can do a search on eBay now, it's back up. And are you seriously saying the web server can cause the back-end database to crash? Explain this please.
CNet implies that it's Sun, but doesn't come out and say it.
By the way, their IIS is version 3, which very few people are still running. Hard to see why they stick with it.
>>given my experiences with NT Server, I think it would be insane to put an NT server under those types of load conditions.
/.
Any of y'all out there running Linux with the types of loads eBay has been experiencing?
There's a long list of sites on the web at least as big as eBay running NT (Dell, Barnes&Noble, 1800flowers, ESPN, etc.), and they don't have eBay's persistant reliability problems. I suspect eBay programmers are at fault.
What's the biggest Linux site on the net you can think of? Dejanews? Hardly a bastion of reliability, and neither is
No, they did dynamic page tests too. See http://www.zdnet.com/pcmag/stories/reviews/0,6755, 402311-2,00.html
There's a review of web server platforms in the same issue that disagrees about how wonderful Linux is.
Have you ever actually written Perl code on Win32, or Perl anywhere for that matter? Perl on all platforms is filled with opportunities to write non-portable code. Go to CPAN and you're immediately faced with module names like Mac/MacConversions Mac/MacFileSpecUnixish Mac/MacOSASimple Mail/MailCclient RADIUS/RADIUS RADIUS/RADIUSUserFileX11/XformsPerl X11/XFvwm X11/XMotifb X11/XProtocol X11/XWcl VMS/VMSLock_ VMS/VMSMonitor_ VMS/VMSPriv_ Tk/TkTreeGraph Tk/TkWaitBox Tk/vstadaf Tk/xdbfdump OS2/OSAttrib OS2/OSExtAttr_ OS2/OSFTP_, not to mention Emacs/EmacsLisp
Making modules to take advantage of platform-specific features is not only old news on Perl, it's one of the main points of the language. It's the whole idea.
Maybe you've never written a Windows program before, but Windows programmers are used to the idea that some of their programs will only work on Windows, and are willing to trade that off for optimal utilization of features on Windows, which is the most popular platform in the world. It's a rational decision and they don't do it unwittingly.
LJS
>>Meaning code that was designed to be portable won't be.
How could this be possible in Perl? Either it's interpreted, and therefore it's exactly as portable as it's designed to be, or it's compiled and completely unportable. Your argument makes no sense.
LJS
Check out the copyright to \winnt\resource kit\Perl\Perl.exe:
Copyright 1987-1994, Larry Wall
Win32 port Copyright (c) 1995 Microsoft Corporation. All rights reserved.
Developed by hip communications inc., http://info.hip.com/info/
Perl for Win32 Build 107
Built Apr 29 1996@22:56:57
Hip Communications is now Activestate (although they seem to have sold the hip.com domain to someone else).
LJS
So the problem is not smart people like you, it's all those stupid people out there. All those novices buying computers at CompUSA and then unwittingly writing Windows Perl scripts. Sounds real plausible to me.
LJS
Like you said, ActiveState was founded to make Perl specifically for Win32. Some of their original funding (as Hip Computing I think) came from Microsoft so that they would have a Perl to ship with NT Server.
In case nobody here knows, a version of their Perl has always shipped with the NT Resource Kit.
LJS
>>WinPerl will not be totally compatible with our current incarnations of Perl, and that will be the problem.
Where did you get this idea? All the FAQ and press release say is that there will be access to Win32-specific features, and there have always been such extensions in ActiveState Perl. You can write portable perl and it will work in ActiveState just like on any other platform, or you can write Win32-specific code and it will work only on Win32. You can do the same thing on UNIX; don't tell me you've never seen a Perl script that would only work on UNIX, cause there are plenty of them. It's as easy as `/usr/bin/whatever`
I've written a lot of ActiveState Perl, some of it portable, some Win32-specific. It's impossible to use the type of features they are talking about accidentally. You always have to use some Win32:: module. What could more explicit than that?
LJS
I've written lots of ActiveState Perl and there are modules for registry access, for NT security management, not to mention plenty of famous 3rd-party modules, like Win32::ODBC.
It's just like the Win32-specific Java stuff in Microsoft's Java. Nobody can use it accidentally, but if you want to write a Win32-speicific program it's there for you to do (just like you can write UNIX-specific Perl programs just by calling native code).
The same hardware was used on all products, and the total working set size is 30-something MB. I'm pretty sure it's 512MB RAM in each system. Anything will cache all of it.
LJS
>>Microsofts website and now zdnet, dell, nasdaq clearly show that NT is one of the most scalable os's ever thaks to i/o async.
Basically, I agree, except that very little at ZDNet runs on NT. Only a few outsourced things like the auctions.
>>The other interesting point is the fact that ZD came up with the IIS benchmarks specifically to show how good IIS is. Such things as fitting the test harness in the cache, and only doing ISAPI dll's for dynamic content (vs CGI on other servers).
You obviously made this up. The benchmarks are completely portable, consisting of files on the server and clients making requests of those files. There is no code.
LJS
All deoends on how you define "traffic". Commerce sites do a lot more complex work than the average search engine.
In any event, www.microsoft.com and www.msn.com handle more traffic than any search engine, except Yahoo I suppose. And the work they do is far more complex than Yahoo, which largely serves static pages.
LJS
Actually, Hotmail is still on Apache/FreeBSD, but your basic point is correct. Numerous very large and reliable sites run on NT/IIS (see list below). Try to find a large site on the net running Linux; there aren't a whole lot. DejaNews is the biggest I can think of, and it's notoriously slow and unreliable.
NT Sites:
www.microsoft.com
www.dell.com
www.gateway.com
www.ebay.com
www.onsale.com
www.buy.com
www.disney.com
www.compaq.com
www.nasdaq.com
www.nfl.com
www.espn.com
www.exxon.com
www.ml.com (Merril Lynch)
www.shopping.com
www.forbes.com
www.intel.com
and, of course, www.drudgereport.com, which actually appears to be running on Windows 2000/IIS5.
In fact, if you look at commerce sites on the web, IIS is by far the most popular server.
LJS
The only evidence that Microsoft lobbied for this is Baratz's assertion. You can go and read the ISO e-mail discussions yourself (be patient, slow server in Denmark); The Microsoft people basically kept their mouths shut and now everyone on the list is pissed at Sun.
Baratz needed a scapegoat. Who else would he blame?
LJS
The discussions of the Java Standards Group (JTC 1 SC22) can be found at ftp://dkuug.dk/JTC1/SC22/JSG/. Looks like anyone can join the mailing list, and anyone can read themail. ftp://dkuug.dk/JTC1/SC22/JSG/926 and up are the messages since Sun formally chickened out of submitting, and the reaction on the list is consistant: what the hell is Sun talking about? There's also general dismissal of Sun's assertions that Microsoft did any lobbying at all on this issue.
You can also see the members of the list at ftp://dkuug.dk/JTC1/SC22/JSG/list.