Slashdot Mirror

1. get apache + jserv (java.apache.org)
2. re-write your scripts as servlets
3. get the java COMM package (http://java.sun.com/products/javac omm/index.html to talk to the backend server.
4. put your data in any database you want and connect to it via jdbc. One way would be to keep the access db on an NT box and whenever you get new data connect to it via jdbc, grab the data, stick it in more robust database (also via jdbc)

1. easier to maintain and debug
2. see #1

Check out http://www.sun.com/corporateove rview/ceo/mgt_joy.html for his BIO and all his contributions to UNIX.

An even better solution is the extension of servlets called JSP -- Java Server Pages. In this case, you (like w/ an embeded scripting language like server-side javascript or w3-msql), write HTML with embedded java code, and the JSP engine translates that into a java servlet (or in gnujsp's case a "Template" instance) w/ html embeded as "out.println()" instructions.

The current standard now has support for "tag libraries" where the JSP programmer can write html/xml-like tags to support doing the "logic" of the page, then the presentation guy can use the provided tags, in combination w/ html, to do the layout and make it look nice/consistent. the presentation person doesn't need to know any java at all.

Links on jsp

• Java Server Pages at javasoft
• Jakarta -- the reference implementation

...
> Lack of firm evidence to support his position. I
> tried to read the spreadsheet, but my copy of
> Excel would not open it. Nothing else in the
> article gives me any confidence in his position.
...

If your Excel refuses to open his spread sheet
(isn't that enough proof of conspiracy? :) then
you may use StarOffice" to open it. Works fine.

"In addition, the Sun Ray 1 enterprise appliance also allows access to applications running on Microsoft NT 4.0 TSE via Citrix MetaFrame technology, other UNIX® platforms, and 3270/5250 environments."

A major point:

"Thin client" is a marketing term. It doesn't have anything to do with the 'fatness' of the computer itself. Check out this link to Sun.

The key is in the blurb:

"Are you looking for centralized administration and a rich user experience? Look no further. The "plug-and-work" enterprise appliance requires no client administration or upgrades while at the same time putting the power of the server on your desktop."

Thin clients aren't about dumb terminals; they're about terminals which remove the need for users to do any kind of administration. Notice that this has nothing to do with X windows, XML, Java. Nor does it have anything to do with CPU, etc. It doesn't matter what the box is running, as long as all the user has to do plug it into a jack and turn it on.

The OS gets tossed because it is confusing, not b/c it eats too many resources. The CPU, file system, and memory are all trivial costs. It's the service calls that are expensive.

Therefor, it isn't appropriate to discuss thin clients in terms of these non-factors (OS, windowing technology, etc.). You want a thin-client solution, pick X/Java/whatever and build something your users never have to think about.

I thought that a version of the language was complete? (completely specified that is). Do you mean you think that current implementations of the J(V)M have a long way to go before being able to be classed as 'mature'?

To answer your questions: as far as I know, there is no current publication "The Java Language Specification", which specifies the language in all its glory. There exists an OLD version (for version 1.0 of the language) and an appendix, (patching the specification to 1.1), check here. But there is nothing current, i.e. for the current versions of the language. This complicates making a JVM and writing applications - and of course makes it more difficult to decide to blame a problem on the provider of the JVM or on the application. Instead, Sun/Javasoft have specified a comprehensive testsuite, which is supposed to ensure "standard compliance" (check here). I have not tested this, thus I have no opinion on that.

That said, the JVM's still have a long way to go before being mature. In particular the JVM provided by Sun for Solaris is disappointing in speed as well as other aspects (while the JVM provided by Sun for MS Windows is suspiciously optimized....).

I thought that a version of the language was complete? (completely specified that is). Do you mean you think that current implementations of the J(V)M have a long way to go before being able to be classed as 'mature'?

To answer your questions: as far as I know, there is no current publication "The Java Language Specification", which specifies the language in all its glory. There exists an OLD version (for version 1.0 of the language) and an appendix, (patching the specification to 1.1), check here. But there is nothing current, i.e. for the current versions of the language. This complicates making a JVM and writing applications - and of course makes it more difficult to decide to blame a problem on the provider of the JVM or on the application. Instead, Sun/Javasoft have specified a comprehensive testsuite, which is supposed to ensure "standard compliance" (check here). I have not tested this, thus I have no opinion on that.

That said, the JVM's still have a long way to go before being mature. In particular the JVM provided by Sun for Solaris is disappointing in speed as well as other aspects (while the JVM provided by Sun for MS Windows is suspiciously optimized....).

Picture a world where all of your personal devices can talk to one another.

That world is here, its called Jini. http://www.sun.com/jini/
Sun has done things like make Dig. Cameras talk directly to Palm Pilots, without special software or drivers... just Jini Enabled. Saw a presentation/demo of it a few weeks ago.

Sun has been runing 64bit for over 3 years

More like one year, given that this press release has Sun announcing Solaris 7 on October 27, 1998, and given that Solaris 7 was the first fully 64-bit OS from Sun (Solaris 2.6 supports 64-bit file offsets, but that's it).

The title of the original article was a bit misleading, as "64-bit Solaris" has been running for about a year on Sun's SPARC V9 systems; however, I suspect at least some nerds consider it news that it also now boots on Raseodymium or Echnetium or Odium or whatever the hell that name was that Intel presumably spent lots of money to get somebody to come up with....

btw, these IDC general servey surveys divide into 3 groups - entry level ($1,000,000). It also splits into Unix and general server. For Sun, "entry level" equates to its E450 and below, mid-range = Ex500 range, and high-end = Starfire. Over the last year Sun has more than doubled it's shipments of Starfires! (They recently finished building a new factory for them) For almost all of Sun's products, demand is exceeding supply - Sun has nearly $1billion in unfulfilled orders at the moment! It's also continuing to grow pretty steadily at 20-25% per year, and is still getting that despite it being some time since it introduced new hardware - their nice UltraSparc-III is rather late.

The only big computer hardware company that is growing faster than Sun, is Dell. However, Sun is pure-Unix and Dell is pure-PC, while the other biggers (HP, IBM and Compaq) are all mixed...

It seems that Sun has a rather odd definition of "transparent". Take a look at Star's own small print, embedded in a bunch of 2.5 MB PDF files: http://www.sun.com/products/sta roffice/filters.html.

The point is, for an even slightly non-trivial document, there is no way you can do a Word-Star-Word conversion and end up with the same document -- which is what I need. =/

Cheers,
-j.

Ok, since everyone is talking about all the
things that could happen with the SCSL, I
thought it might be a good time to tell you
all a real problem with the current Java API
and how Sun interacts with developers.
I have been trying to get Sun to fix the
Runtime.exec() API for more than a year.
If you are a Java developer, you probally
already know what I am talking about. The
exec() method does not provide a useful
way to set env vars or to exec() a process
with a current directory other than the one
the JVM was started in.

If you are a JDC member you can read all
about it at this URL. (Sorry, if you
can not view this URL, but Sun will not
let people look at Java bug reports without
joining the JDC and agreeing to a license).


http://developer.java.sun.com/developer/bugParad e/bugs/4156278.html

I submitted this bug report on July 10, 1998
and it was not "reviewed" until June 28, 1999.
It was then shelved for another 3 months when
they decided to "fix" the problem. Now comes
the tricky part. There is no real information
about how they intend to "fix" this bug, and
the reviewer mentions that they are not even
going to fix "all" of the problems with this
API, just the current directory problem. So
I still have no real feedback and I will have
to wait until the new release of the JDK to
see how they decided to "fix" this bug. There
is something really wrong here. This
kind of crap would never happen on a real
Open Source project.

Mo DeJong

I haven't seen this said before so....

Netscape attempted an open source release. They said very clearly that they controled the code, but if they ever mishandled that responsibility the community was specifically free to fork the code. Code, not API.

But Netscape had nothing to loose. A functional equivalent of their product was being distributed free for major platforms, and the code was of such a quality and age that the developers who worked on the project started by rewriting portions of it. Also, Netscape had already been making much of it's money selling other products and support.

Sun, on the other hand, has invested a great deal in products that are largly unequaled. To truely contribute these projects to the community would be very risky. They are not interested in being relagated to merely a support company.

The community may also make them a bit nervous. This RFE requests Linux support in addition to MS Windows and Solaris. (Link is to JDC, requires free registration.) The RFE was submitted on Dec 08, 1997. Since then, it has accumulated over 400KB of supporting comments becoming the top RFE by a lead of 3729 votes (total 4476). It is still unsatisfied. Sun can't support Linux any more than it could support Mac. (Mac support [by Sun] was dropped as of Java 1.0) With an open source project, this would be no problem. The primary developer simply says, "If you want it that badly, write it." The developer can say this because if the community does write it, but the developer rejects their work, the community can fork the code. But, of course, Sun isn't open source....

sklein

Could it be that acceptance of one type of license vs. another simply boils down to readability, i.e. whether a mere mortal can quickly scan and understand it?

In this respect, the BSD and GPL licenses rule, closely followed by the Perl artistic license. All of these are clearly written with understandability in mind, not just with a lawyer's mindset.

However, the licenses that Netscape produced, and worse still what SUN published with their SCSL is so bloated and peppered with legal terms that the average developer may tire and loose momentum before he/she actually reaches the end of the document.

I know I only finished reading the SCSL because I made it a point to be able to report to users here on campus what it may mean to them.

I would think that at least in the academic sector and among the crowd of 'hobby enthusiasts', people have little patience to wade through legalese, hence there will be little participation in 'open source' projects that are marred with a long and incomprehensible license.

ESR stated that a plausible promise will motivate people to participate. This may include an interesting project, strong design and reasonably clean, understandable (and maybe even working) source. I propose that clean and strong design be also applied to the license (or simply use an established and accepted license). lest noone will bother.

After reading the MainWin overview on MainSoft's site, it is obvious that it is just another Win32 emulation layer, similar to Wine for Linux or Wabi for Solaris. Of course, they state on their page that MainWin is not an emulator. But all it does is to translate Win32 API calls to something that runs under Linux. The calls are executed in the MainWin layer (thanks to the Windows source code that they can use) or translated to Linux system calls. By the way, MainWin is already available for many UNIX systems, and they are just adding Linux to their list.

How is this different from Wine? On the negative side, it is closed source and probably quite expensive. On the positive side, the fact that they have access to the Windows source code means that they might be more compatible with all the undocumented Win32 features that are used by some MS applications.

I don't think that there is anything really exciting about this announcement. Win32 emulators have existed for quite a while on various UNIX systems, and all of them have their drawbacks. This one might be better in some areas and worse in some others, but it will never replace a native port of the applications to Linux.

If MicroSoft (not MainSoft) starts publishing press releases encouraging developers to work only on Win32 because it is portable to all environments including Linux, then we may have something to respond to. But I don't think that any serious company would stop porting their products to Linux because some small company provides a (closed and expensive) emulation layer for Win32 apps.

Huh? Java can use either native threads or green threads. It depends on your JVM (or in some cases how you start the JVM). It sounds like you haven't researched threads under Java--posting without knowing the facts can be a dangerous proposition.

For Solaris, Sun has a web page describing the threading options at http://java. sun.com/products//jdk/1.3/docs/tooldocs/solaris/th reads.html that could be helpful. I haven't looked for pages about threads on other operating systems.

I wonder if it will be Kestrel (aka JDK 1.3, see JDC's Early Access section. It might require a free registration.) which is AFAIK scheduled for delivery around January-February 2000. Well, the article did say "the latest".

I also wonder who is the first to devise the most insidious and twisted conspiracy theory full of world-eating evil out of that piece of news. :p

One of the side effects of using SCLS as the licensing terms is that people from some countries are not allowed to download the code. As you can see when you check the link above, they want to enforce their IP, thus, you don't have to wonder they don't feel like using GPL.

In other words, I don't think i18n or L10N are well-established, but that's just me.

Well, for those doing any work at all in the field, those terms are very well established. Since the project is initially to coordinate all those working in the field to be unified on Linux, it seems like a very good choice of names. See their charter for why I have that impression.

For The Java stuff, try the Java documentation itself. http://java.sun.com/products/jdk/1.1/docs/guide/in tl/index.html

THE GOOD

• LinuxCare's little bootable Linux recovery CD kicks ass. No bigger than a business card, it fits in the 3" diameter groove in CD-ROM/DVD-ROM drive trays and has the potential to save your butt when lilo eats itself. They also had some Linux stickers that now adorn the case of my 386... (Yes, it runs Linux.)
• IBM had a presence. Although certainly not the largest or flashiest booth in the show, Quake 3 on a rather large plasma display attracted lots of attention. Dual PII-400 Intellistation + Voodoo 3 3000 + large plasma display. Mmmmmm. Thanks to the guys there for letting me get some game time on that mammoth thang...
• O'Reilly also had a presence, and their trade show pricing kicks much booty. Picked up a few books for 20% off list and got a shirt to boot...
• Mad props to VA Linux Systems for not only having a cool booth and giving away lots of stuff but for supplying the machines used for public Internet access. Their Debian boxed set is pretty cool and sports Learning Debian GNU/Linux from O'Reilly. (Yes, I was one of the people who stood around in line for ten or fifteen minutes to win this...)
• Thanks to the Sun and Rave Systems folks for all the free stuff. Learn to play Quake 2 without cheating before next year's show... :-) (Now where's my complimentary Sparc 5?)

THE BAD

• None of the shirts I got fit. None. Zero. Zip. Zilch. I'm 6-foot-3-inches tall and weigh 295 pounds. Show me the big-assed shirts!
• The IBM guys told me that the Showcase had a T-1 connection to the 'Net. I couldn't verify -- the packet loss and latency was horrible on the connection. I'm hoping this is only because lots of geeks were pounding on the connection like a pack of wild monkeys...
• Food choices were few, and lines were long. Within the Galleria, your choices were Subway, some cafe whose name I don't remember, Ruby Tuesday's, and Chick-Fil-A. If you were bold, you could go to the movie theater downstairs and buy a big tub of popcorn. The group I was with walked across the street to another mall and ate at Arby's. Yum... I think.

THE UGLY

• Where the hell were the Slackware people? I wanted Slackware apparel... Hmmph.
• Linux merchandise places came out of the woodworks to hock their goods. Yay capitalism...
• Don't eat at Shoney's. Our group waited over an hour for food before giving up and leaving.

THE REST

• The andover.net/freshmeat.net/slashdot.org booth was smack dab next to the linux.com booth. Taken together, it looked like one big congregation of slackers with laptops. All things considered, however, I wouldn't have minded flopping down on the couch for a rest after walking around for a few hours...
• I will seek revenge against the guy in the Debian shirt who shot me in the arm with a Nerf dart... muahahahaha
• The Debian folks had a Sun Ultra 5 running XaoS, Netscape, and some Tetris clone in separate windows. Just for kicks, I maximized the XaoS window. Can we say slideshow?
• I had nothing interesting enough to trade with the lady at the VA Linux booth, so I didn't get one of those nifty enlightenment shirts. Dammit.
• NetBSD was there. Go figure.

Overall, it was a pretty cool show, but I wish I didn't have the 2-1/2 hour drive. It was put on very professionally and appeared to be very well organized. I was only slightly disappointed that the show wasn't any bigger... The nifty canvas bag attendees got and the included CD made up for that, though.

THE GOOD

• LinuxCare's little bootable Linux recovery CD kicks ass. No bigger than a business card, it fits in the 3" diameter groove in CD-ROM/DVD-ROM drive trays and has the potential to save your butt when lilo eats itself. They also had some Linux stickers that now adorn the case of my 386... (Yes, it runs Linux.)
• IBM had a presence. Although certainly not the largest or flashiest booth in the show, Quake 3 on a rather large plasma display attracted lots of attention. Dual PII-400 Intellistation + Voodoo 3 3000 + large plasma display. Mmmmmm. Thanks to the guys there for letting me get some game time on that mammoth thang...
• O'Reilly also had a presence, and their trade show pricing kicks much booty. Picked up a few books for 20% off list and got a shirt to boot...
• Mad props to VA Linux Systems for not only having a cool booth and giving away lots of stuff but for supplying the machines used for public Internet access. Their Debian boxed set is pretty cool and sports Learning Debian GNU/Linux from O'Reilly. (Yes, I was one of the people who stood around in line for ten or fifteen minutes to win this...)
• Thanks to the Sun and Rave Systems folks for all the free stuff. Learn to play Quake 2 without cheating before next year's show... :-) (Now where's my complimentary Sparc 5?)

THE BAD

• None of the shirts I got fit. None. Zero. Zip. Zilch. I'm 6-foot-3-inches tall and weigh 295 pounds. Show me the big-assed shirts!
• The IBM guys told me that the Showcase had a T-1 connection to the 'Net. I couldn't verify -- the packet loss and latency was horrible on the connection. I'm hoping this is only because lots of geeks were pounding on the connection like a pack of wild monkeys...
• Food choices were few, and lines were long. Within the Galleria, your choices were Subway, some cafe whose name I don't remember, Ruby Tuesday's, and Chick-Fil-A. If you were bold, you could go to the movie theater downstairs and buy a big tub of popcorn. The group I was with walked across the street to another mall and ate at Arby's. Yum... I think.

THE UGLY

• Where the hell were the Slackware people? I wanted Slackware apparel... Hmmph.
• Linux merchandise places came out of the woodworks to hock their goods. Yay capitalism...
• Don't eat at Shoney's. Our group waited over an hour for food before giving up and leaving.

THE REST

• The andover.net/freshmeat.net/slashdot.org booth was smack dab next to the linux.com booth. Taken together, it looked like one big congregation of slackers with laptops. All things considered, however, I wouldn't have minded flopping down on the couch for a rest after walking around for a few hours...
• I will seek revenge against the guy in the Debian shirt who shot me in the arm with a Nerf dart... muahahahaha
• The Debian folks had a Sun Ultra 5 running XaoS, Netscape, and some Tetris clone in separate windows. Just for kicks, I maximized the XaoS window. Can we say slideshow?
• I had nothing interesting enough to trade with the lady at the VA Linux booth, so I didn't get one of those nifty enlightenment shirts. Dammit.
• NetBSD was there. Go figure.

Overall, it was a pretty cool show, but I wish I didn't have the 2-1/2 hour drive. It was put on very professionally and appeared to be very well organized. I was only slightly disappointed that the show wasn't any bigger... The nifty canvas bag attendees got and the included CD made up for that, though.

wow.

long? yes. well tought out? yes.

I work in the guts of a distributed object infrastructure project, so this is the kind of discussion that my fellow geeks and I would spend HOURS on if management didn't walk by that offten. I think you clearly see the empty spot on the scatter diagram you drew out there, and are obviously on the right track to fill it in.

I also think you're reinventing the wheel. (don't we all at some point? ;)

What you've described is the message passing protocols that existed before IPC. This is the style of programming that was taught by having to "run" your programs by carrying a shoe box of punched cards to the window by the machine room and giving it to an operator who would run it and give you back a stack of cards. This stack of cards of course might itself be a program which could then be fed back to the operator in one or more additional shoe boxes and the cycle began again.... I still write scripts that end by enqueing several more scripts for batch processing - and I WASN'T actively part of that era of computing. This style of communications is also still the big winner in the mainframe world of Transaction Monitors, ERPs, etc . . . look at IBM's hugely successful MQ Series for example. (here is a better read for the un-initiated.)

There are several implementations of frameworks for messaging protocols out there. One of my favorites in uni was the Paralell Virtual Machine architecture. Another was the Message Passing Interface. Many forms of paralell computation use the messaging model.

Messaging is also being brought into the Java world with JMS (no, not the great maker) the Java Messaging System.

wow. This is the kind of discusion that makes me proud to login to /. why can't there be more? Why aren't there? hrmm.

Why Don't you go tell Sun that Star Portal can't work.

Because, according to this press release, StarPortal isn't the sort of "Web-based application" the original poster was citing as a reason why we should all "forget about toolkits". It says

Completing development of StarPortal, a web-based version of the office suite that combines a Java(TM)-based client with the software to enable browser access to office productivity tools.

which appear to be saying it's an application written in Java (see earlier comments in which I note that a Java-based application is just an application written for Java plus some widget set, just as a GNOME application is written in C or C++ or whatever plus GTK+ and a KDE application is written in C++ or whatever plus Qt), not a "web-based application" where you just fill in forms and hit "Submit", as the Web calendar and mail applications some people mentioned are.

Yeah, maybe it's more cross-platform than, say, a UNIX+KDE or UNIX+GNOME application is, but it's not the same sort of application as is, say, Slashdot, that being an example that one of the people to whom I replied gave.

And what about a web based mp3 player? Couldn't they store all the mp3 files on the server and stream to your local machine, saving you from having to find all the mp3s you want and archiving them yourself.

Again, that's not a "Web-based application" any more than an MP3 player that can read files somehow magically becomes "NFS-based" or "CIFS-based" by reading from a file system on a server; the application is a local application, written using some toolkit - toolkits being what the person to whom I originally replied (and who cited Slashdot as an example of "Writing for the Web") said we should "forget".

Are you trying to say that Netscape doesn't have access to your sound card?

No - but if it's playing something itself, it's not as if somebody "wrote for the Web" - they didn't write any application at all to play MP3s, they just used an application that already existed, namely Netscape or a plug-in. If you already have a canned application to perform some function, the mere fact that the canned application happens to be part of a Web browser doesn't mean that, by using that application, you've "written for the Web", it means you haven't had to write it in the first place - that certainly means you don't have to worry about toolkits, but it doesn't help you if that's something Netscape or whatever doesn't do.

Try reading Tim O'reilly's new article on MS vs. Linux.

Oh, you mean this one, which I read several days ago, where he says

Traditional software embeds small amounts of information in a lot of software; infoware embeds small amounts of software in a lot of information. The "actions" in an infoware product are generally fairly simple: make a choice, buy or sell, enter a small amount of data, and get back a customized result.

and

Information interfaces are not as efficient for tasks that you do over and over as pure software interfaces, but they are far better for tasks you do only rarely, or differently each time. In particular, they are good for interfaces in which you make choices based on information presented to you. Whether you're buying a book or CD at Amazon.com, or a stock at E*Trade, the actual purchase is a fairly trivial part of the interaction. It's the quality of the information provided to help you make a decision that forms the heart of the application you interact with.

where he pretty clearly indicates that he does not think that all traditional applications are dead and that CGI scripts will replace them, he indicates that there's a whole pile of new applications for doing new things that are best done with browsers talking to Web servers.

The problem that some people have is that, as, if I remember correctly, Abraham Maslow said, "to somebody whose only tool is a hammer, the whole world looks like a nail". Web-based applications, in the "3270 for the '90s" sense (as somebody described Web stuff several years ago), are cool - but they're not the whole world.

Try reading the original poster's article, which said

Forget toolkits. Linux-only development is a dead-end. Write for the web and maybe you'll make some bucks like CmdrTaco and Jerry Yang.

(without, it appears, bothering to ask what application the submitter of the question was trying to write).

Writing a custom GUI application to do Internet shopping, or calendar management, or library card catalog searching, might be a dumb thing to do now that we have HTTP servers and clients all over the place (although I'm not about to boldly declare that it is foolish; there may well be reasons why some particular such application makes more sense than a CGI script as a solution for some particular problem); nobody's made a convincing case that writing GUI applications in general is no longer necessary now that we have the Web.

I've heard tell about some sort of IO standard that Intel's been pushing of late that supposedly 'replaces all current bus technology'. Anybody know more about this?

I personally am looking forward to hearing more about Jini, which is Sun's initiative to do to hardware what Java is doing to software.

Basically, they move the device abstraction out of the OS driver and into the device itself. So you basically plug a Jini-enabled device into the network, and it immediately registers itself and makes its services available to other devices on the network.

No OS-specific drivers, no kludges/workarounds. Things just "work".

http:/www.sun.com/jini/

While it's not going to win any awards for bangs-for-bucks, Pixar are using a bunch of nice Sun hardware for their render-farm - 120 E4500s and 4.5 terabytes of disc storage, totaling 1680 CPUs. List price has lots of zeros.... Sun press release.

Just to set the record straight about what is reality from someone who has written an IPv6 stack. (Trumpet Winsock 5.0)

Firstly, IPv6 can actually aid your privacy in that it is now technically possible for you to *choose* your IP address provided you reset the globally unique bit, and use the duplicate address detection mechanism to make sure your traffic will work. The only time duplicates become a problem is when the same address exists in the scope of the network where it matters. i.e. your subnet for an ethernet connection, or the PPP link when you are using dialup.

It would be technically possibly for you to dynamically change the lower 64 bits of your IPv6 address during the life of your connection to the internet be that ethernet or PPP. There is one proviso in that it is not currently feasible to modify your address for active TCP/UDP connections, so you would need to close all active connections to lose all trace of your older address.

Given the active discussion that this topic has generated, I am now keen to add a feature to our stack which would build a random EIU64 address each time the interface is opened. This feature is already in place for PPP connections, and I could also add a button which would force a new address to be built on all interfaces. Of course to pick up the new address, all connections would need to be broken, but it would be a simple matter for the stack to continue using both addresses until the original address is fully deprecated. IPv6 is powerful enough to use as many addresses as you like from your internet node. That is the beauty of stateless autoconfiguration and neighbor discovery.

I suggest that slashdotters go and read the relevant RFCs *and* Internet Drafts in some detail, and they will realize how powerful IPv6 is and how it will solve many of the issues facing the immediate future of the Internet.

A good place to start is

http://playground.sun.com/pu b/ipng/html/ipng-main.html

I found Sun's page describing the Ultra5, but it still doesn't tell me much. What's it like compared to my PII/400? How good is Linux on it? Are there case and/or cpu fans? What else do I want to know? :-)
--

I just tried using their system configurator to put together a sub-$2K machine, but I wasn't able to drop the price below $2.5.

To /. their serv... um, check the prices for yourself, go here.

Although the Ultra 5's are fairly nice for Unix workstations. Not as nice as, say, the Ultra 1 or Ultra 2, since they use a cheaper processor and are IDE (vs SCSI which is fine for a workstation), but still very decent.

More specs are here and here.

jf

Although the Ultra 5's are fairly nice for Unix workstations. Not as nice as, say, the Ultra 1 or Ultra 2, since they use a cheaper processor and are IDE (vs SCSI which is fine for a workstation), but still very decent.

More specs are here and here.

jf

On top of this, due to the mission critical nature of the boxes (they are used nation wide), we have extensive change management controls. Any patch that we apply would have to have a corresponding backout procedure. It is much easier to consider a patch as one big patch than 21 individual patches. Sure, us tech people know that they are really one and the same. But try telling the change managment people that.

Speaking of enterprise environments, though, I think it would be unfair to leave out Solaris 7. It has 22 security-related patches as listed here: ftp://sunsolve6.Sun.COM/pub/patches/Solaris7.Patch Report Do you run Solaris at your site? If so, did you install all of those? Here, we've got scripts that install those patches on the Solaris boxes. Of course, change management is involved, too.

Sure, it would be nice if Red Hat paid more attention to security and quality control, but that's why I tend to stick with Debian & FreeBSD when feasible. :)

Java does throw OutOf MemoryError, which isn't quite an exception (it doesn't have to be declared) but can be treated the same way.

We've been thru the "if we politely point out the advantages of true open source, maybe they'll switch" business twice already with Java and StarOffice. If you read their page on the principles of the SCSL you'll see they know the difference quite well, and simply don't believe in the bazaar model of development. They want control over the specifications and interface, and the absolute right to prevent forking because they actually think it makes their product better.

In an abstract idealistic sense Sun may have made the world a little better by allowing people read access to their sources. However, IMO, this is outweighed by the obfuscation of the meaning of "open source" and the potential to draw developers away from really free OSes like Linux, *BSD, and Hurd.

Compromise is appropriate sometimes. Other things, like pregnancy or freedom, are more difficult to compromise on, either you are, or you aren't. I'm reminded of the 70's when long hair on males hit the mainstream and Nixon made peace signs. Co-option is the biggest threat to any popular movement.

Several months ago, having been a Java developer for some time and being interested in looking at the source code, I decided to download it from Sun ( under Sun Community Source License ).
I got a big surprise when I realized that the country where I live in, is not among authorized countries to receive source code.
I contacted Sun Legal department by mail, and they kindly explained me that the specific problem with my country was its weak copyright laws concerning software.

I just installed Solaris 7 for the intel, and had a hell of a time (as you did) finding the tools that makes linux so great. You can go to Sunfreeware.com to get loads of software for Solaris for both the intel and SPARC platforms. (Don't forget to download gnuzip first so that you can decompress the other files) You can install the packages with the ``pkgadd'' command like this ``pkgadd -d ./'' and that should prompt you to install all of the available packages in the current directory.

And, in case you noticed, the HotJava browser that is included with Solaris 7 sucks. You can go to Java.sun.com to download it, and although an intel version is not listed, you can follow the instructions for the linux version, and get it going very nicely.

I believe it to be extremely stupid, as well, for Solaris 7 to include a Glade-type GUI tool, but not to include a C compiler! I have successfully used gcc, and gmake to build a very simple test application (IE no functionality, just a GUI shell) with this tool, although I haven't tried more complicated programs.

Linux seems to fall under the same cometetition standards as the server market did for a while.

I remember a conference I went to 6 years ago called the SGI/Oracle Webmaster Survival Conference. In this conference, SGI made it well known that even though they would like to see one of their workstations on every desk top and one of there servers in everyone's server room, they knew that it wasn't possible. They knew that there would be a market split and that certain server/workstation solutions made sense in certain situations.

IBM seems to get this too. They portray that although we wouldn't really mind if you bought all this computing machinery from us, it isn't a big deal if you don't, especially if it doesn't make sense to do so. At a company I used to work for we would use IBM's high end printing solutions. Although we ran the printer with an RS/6000, we ran the rest of the network with Sun equipment. IBM would have liked to see us running the rest of the network (which was all *very* dependant upon this printer) with IBM equipment, but it wasn't necessary and they understood that the Sun/HP solution we had in place made more sense.

On the same respect, it seems as though Sun does not support this mentality. They think that every computer in your network should be a Sun computer. PC's? Forget it, replace them with XTerms. SGI's? Why do you need one of those when you could use an enterprise 10000 to do the same thing? Remember the movie Toy Story? They had to use (I forget the exact stats, but something like) 20 farms of 100 Sparc 20's to do the same thing that 2 or 3 SGI Onyx's could do. Sun doesn't seem to care if something doesn't make sense as long as it puts money in their pocket. Although I think that Sun has some great products, I think that this mentality will haunt them.

That also seems to be the same way that these companies approach Linux as mentioned before so I won't mention it again. You are right, and the evidence has been around longer than all of these companies have been embracing Linux. Articles like this are good indicators that Sun still believes that every computer in the world should and will be a Sun. Perhaps Sun is the one that needs the reality check in this article and not IBM.
---

The compatiblity with MS Office is greatly exaggerated.

My anecdotal experience with interoperability highlights some significant limitations, primarily the limitation that StarOffice is more interoperable with Office2000 than previous Office95 or Office97 releases. I took a number of spreadsheets I use frequently and was unable to import any sort of chart from Excel95 into StarOffice (including pie, bar, scatter, and line charts.)

The point of spreadsheets and manipulating data is to A) understand what's going on and to B) cleanly and simply express what's going on to someone else. Thus charting constitutes about 50% of a spreadsheet program's value, a fact not reflected by Sun's 95%+ interoperability claims. (For those interested, Sun's precise interoperability claims are documented in hundreds of pages of documentation, mostly comparing to Office2000.)

The irony is that to get interoperability with StarOffice, such as ability to import Excel charts, corporations will have to first upgrade to Office2000 and save all files in that format before moving to StarOffice!

So I wouldn't spend too much time paying attention to StarOffice; it won't be giving MS problems any time soon (unfortunately for all our pocketbooks.) For offices/homes not needing such a conversion, I imagine it'll work fine, but currently poor compatibility will prevent it from harnessing network effects and getting a positive feedback loop going as an Office replacement. It's just cheap software.

Sigh.

--LP

--

--

--

--

Try StarOffice. It has pretty good compatibility with MS Office (feature lists and comparisons are available on their web site), and it's free. "StarOffice Impress" is the included presentation program, and is very similar to PowerPoint.

We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.

You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.

On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.

PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.

One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.

My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.

Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.

If you'll be using the CGI version of PHP3, please be sure that you

• set up a chroot() running environment for your CGI (phttpd does this by default, Apache does this with a modified suexec - ask me if you need it).
• compile a version of PHP with --enable-force-cgi-redirect or you'll be opening a great security hole.

If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.

If you're interested in writing debuggers for Java then you might wanna take a look at Java Platform Debugger Architecture (JPDA). This is where JVMDI falls under as well.

JPDA provides the infrastructure needed to build end-user debugger applications. It includes Java Debug Interface (JDI) which allows you to do remote debugging, Java Debug Wire Protocol (JDWP) which defines the protocol used between the debugged process and the debugger application, and Java Virtual Machine Debugger Interface (JVMDI) which lets you hook up to the guts of JVM.

For more info, go to the JPDA Home Page.

Sun's future would have people depending on mega-ISPs (using Solaris servers, of course) that would store your files and serve your apps for you. Think WebTV with decent video.

Sun's intent is quite clear in this regard. The main point of my argument, which will be concluded in a second column appearing next week, is that neither Sun's nor Microsoft's world-view is right for everyone. Thin clients are great in some situations, horrible in others. Linux is flexible enough to serve as an excellent thin-client, fat-client, or server. Neither of the commercial approaches is best in all cases, yet neither does much to acommodate models outside of its own.

Linux is a threat to both Microsoft and Sun because it offers the flexibility to serve either model -- or some hybrid of the two -- very well. Linux isn't trying to push the user into one world-view or another of the way computing should be done.

Sun does not read those 4000+ comments telling
them what they don't want to hear.

So instead of replying to it, just add your own bug, telling them to support linux now.

http://java.sun.com/cgi-bin/bugreport.cgi

He was also responsible (in some sense) for Java. He was going to leave Sun for NeXT, and McNealy asked him to write a letter telling him what was wrong with Sun. This led to the FirstPerson "skunkworks" project that eventually spawned Java. Here's a good article about it.

This environment makes it difficult to know what is going on, as it would all run on the server.

Hmmmm . . . hack the server maybe, but there ain't much on the client to play with.

-- Reverend Vryl

--Jamin Philip Gray
jamin@DoLinux.org