Slashdot Mirror

Bryan Cantrill, one of the DTrace developers wrote this blog entry as a general introduction to the source code layout and also to DTrace. This post by Adam Leventhal goes into some more detail.

82678 lines of C were made public. No registration, no click through license before download. The OpenSolaris FAQ is pretty good btw, and there's also a roadmap page.

According to this blog (the entry dated 15:43), those in the pilot program (more than 100 developers out side of Sun) have today gotten access to the entire Solaris source base, and have already built their own version - screen shot.

Bryan Cantrill, one of the DTrace developers wrote this blog entry as a general introduction to the source code layout and also to DTrace. This post by Adam Leventhal goes into some more detail.

82678 lines of C were made public. No registration, no click through license before download. The OpenSolaris FAQ is pretty good btw, and there's also a roadmap page.

According to this blog (the entry dated 15:43), those in the pilot program (more than 100 developers out side of Sun) have today gotten access to the entire Solaris source base, and have already built their own version - screen shot.

For those of you wanting to delve in the source for DTrace, check Bryan's blog.
He's on of the two key devs that brought DTrace to reality, and gives some good insight into the code. You can almost see him blushing like a proud new dad in his blog as well. :)

A. DTrace is a new facility in the Solaris Operating System that adds dynamic instrumentation and tracing to the kernel and can be used on production systems. It's a power tool that can be used by both the entry-level and experienced system administrators to diagnose and resolve problems in hours or minutes that might have previously taken days.

A. Faster resolution of performance problems for system administrators
Quicker time to market and higher quality product for developers
Greater utilization of existing system resources for IT managers

A. Comprehensive coverage: over 30,000 instrumentation points in even the smallest system; integrated access to both application and kernel data
Always available: built-in with no need to reboot or otherwise reconfigure system, disable or alter applications, or disable user/client access
Safe: cannot panic system and has no impact on the system when not being used
Enable only the trace points you need
Analyzes data in real time on production systems
Extensible as new analysis routines can be built for re-use using the D programming language

A. When not in use, DTrace has no impact on system performance or other behavior. When being used, DTrace overhead is dependent on the number of probe points being observed.

A. DTrace is the only dynamic tracing tool available that eliminates the need for collecting and processing event data. With DTrace a system administrator can query the system experiencing the problem in real time, while in production, and get accurate and precise information regarding the source of the problem. No log files are generated, and there is no data to analyze. This reduces the time it takes to identify and resolve problems by orders of magnitude! Literally from days to minutes.

Containers are based on software. They offer logical separation with the same OS in each Container. Containers offer enormous scalabilty: while there is no hard coded limit, upto 4000 per OS image are available and is beyond normal requirements today.

A. You can leverage scripts developed by others (such as those available on the Sun BigAdmin portal). However, it is not difficult to learn D which is very similar to the ANSI C programming language with a special set of functions and variables to make tracing easy.

I'm not sure, but I feel this (http://www.sun.com/software/looking_glass/) may be what you are talking about. I actually got a compile working (despite my hatred of Java.) It does appear to be kind of sluggish but the idea of it is quite nice. I wasn't able to get it to load anything but from the demos of seen (taken with a grain of salt) it is an idea whose time came a couple of years ago but was never implemented. To anyone who has a spare *n?x machine and a bit of curiosity; I suggest you throw it on there and browse around. I haven't taken a look for 2 months so it's likely polished enough to have a lot of the kinks I didn't like worked out. Just bare in mind it is pre-alpha iirc.

I have a friend who works for Sun Microsystems, and he tells me they're working on a 3D version of JDS (don't get me wrong, a desktop system is the LAST thing I'd want to see Java used for, but that's not the point). Among other things, you can rotate a window, say, 80 degrees and stick it in a corner. It's then still recognizable, but it doesn't take up much space. You can also turn things around and write notes on the back. This is a REAL use of 3D in a graphical shell. Now, if only somebody would take their idea and implement it in C++ (or some other language with a goal other than portability).

You're talking about Project Looking Glass, which is still in alpha, but will eventually bring a true 3d interface to the Linux desktop. It truly looks like a revolutionary interface, and you can see a video demo of Satan himself (Jonathan Schwartz) ;-P demoing it here.

Some developers are already beginning to contribute to the project, which is open sourced. You can find more details and even download a developer preview of the release at this website.

I downloaded the developer preview and briefly got it up and running on my system. I'm running Suse 9.2, and it requires an ATI or Nvidia 3d card with DRI support enabled in your X config.

I have a friend who works for Sun Microsystems, and he tells me they're working on a 3D version of JDS (don't get me wrong, a desktop system is the LAST thing I'd want to see Java used for, but that's not the point). Among other things, you can rotate a window, say, 80 degrees and stick it in a corner. It's then still recognizable, but it doesn't take up much space. You can also turn things around and write notes on the back. This is a REAL use of 3D in a graphical shell. Now, if only somebody would take their idea and implement it in C++ (or some other language with a goal other than portability).

You're talking about Project Looking Glass, which is still in alpha, but will eventually bring a true 3d interface to the Linux desktop. It truly looks like a revolutionary interface, and you can see a video demo of Satan himself (Jonathan Schwartz) ;-P demoing it here.

Some developers are already beginning to contribute to the project, which is open sourced. You can find more details and even download a developer preview of the release at this website.

I downloaded the developer preview and briefly got it up and running on my system. I'm running Suse 9.2, and it requires an ATI or Nvidia 3d card with DRI support enabled in your X config.

You are I are both busy people though, so if you know how a Sun v40z is better, prey tell!

Go look at page 7 and 9 of this PDF about the v40z and v20z architecture. The diagram is basically the same as for HP's Opteron servers, or any Opteron server worth talking about. Compare to page 25 and 26 of this Intel board layout. Note that Intel's 800MHz FSB moves about 6.4GB/sec. (And remember that a 400Mhz 128-bit path moves as much data as a 64-bit 800Mhz path, hence the need to compare in terms of GB/sec, not Mhz) Ignore the "Service Processor" and all the lines from it on the Sun diagrams.

Intel's Front Side Bus architecture has a single 800MHz (6.4GB/sec) point where all access to I/O and RAM goes through that single 800MHz point. This effectively serializes your CPUs (they can only all be doing something simultaneously when one of them is working out of cache; otherwise they have to wait for the 800Mhz FSB to be available) That FSB ties to a controller that has some I/O hanging off of it (PCI/E), RAM and an I/O controller. Then, the slowest I/O is off of an I/O controller off of that one.

Then compare to the architecture of a v20z. Each CPU has its own bank of RAM with a 5.3GB/sec bus to it. Then there's a 6.4GB/sec connection between the two CPUs. So, typically, your CPUs can work on totally independent tasks without needing to share the FSB just to get to their RAM. When one CPU needs access to RAM on the other, it does tie up the RAM access for both CPUs, but with a proper process scheduler and most tasks that's avoidable, besides, all that's done is reduce you to the temporary equivalent of a 5.3GB/sec FSB. Then, on the V20z, I/O is on a 6.4GB/sec path to an I/O controller, and from there it all looks pretty similar to the Intel I/O arrangement, with slower I/O off of that, etc.

Add a couple of CPUs and things look even worse for Intel and better for Opteron. Intel just sticks all the CPUs on the same FSB. Opterons each get their own bank of RAM, and I/O access is now split between two of the CPUs (the other two have direct access to each other and one of the CPUs with I/O on it.) Absolute worst case for a 4-way opteron (when your process scheduler fails or your particular task makes life hard on the process schedule) is that the I/O for 3 CPUs is tied up when something is accessed. This is still better than on an Intel board where the best case is I/O for all CPUs being tied up any time one CPU accesses I/O or RAM.

(In other words, give me NUMA over a FSB any day of the week)

Besides, Opteron systems are getting pretty commodity (at least, compared to Xeons). Shouldn't be any driver support issues; they're actually using some pretty similar chipsets for everything (LSI RAID, Broadcom or Intel NIC, etc.) as what Dell has. Price quotes we've been getting back from Sun are reasonably comptetive with Dell Xeon quotes for similarly configured servers (though, given the NUMA architecture and strong 64-bit CPUs, it'd be fairer to compare to IBM PowerPC based servers) Last I checked, IBM's Opteron offerings were a little lacking in the "enterprise" features we wanted (redundant power, specifically), but HP had very similar offerings to Sun's (same basic mobo layout, different specific offerings.) and there's a lot of "Whitebox" vendors with similar offerings, as well. To be fair, though, I work for an educational institution and Sun's got some pretty aggressive discounts available for us, especially on certain packages.

Do be careful when looking into Opteron servers from the smaller vendors. Once you get into 2 or more CPUs, some motherboard manufacturers cut corners by sticking all the RAM onto one bank tied to one CPU, which eliminates all the cool NUMA advantages. Dell doesn't offer any AMD CPUs primarily because they have a deal with Intel that gets them bett

java is open source for years now, and java5 got a pretty neat license, too.

http://java.sun.com/j2se/jrl_download.html

You clearly have no clue what ZFS is about. Stop spouting made-up crap. ZFS is about data integrity, simple administration and huge capacity. Searching??? Where the hell did you get that from? All you have to do is read what Sun actually says about it. Go search Blogs.sun.com and read what actual ZFS engineers have to say.

I stand corrected:
http://www.sun.com/software/linux/compatibility/lx run/

Yes. Johnathon's "open letter" is one of the silliest, snarkiest, stupidest things I've seen in some time.

Oh, Johnathon, you're so clever with your "open letter" on your blog. Gimme a break. Your company is not doing well and hasn't been since the easy pickings of the dot-com years when everyone did well. You've been one of the sick men of the IT world for years. You finally managed to eke out a tiny profit, but your revenue continues to slide. Analysts are not impressed and while you were busy getting in your competitors' faces and thumping your chest, your stock dropped some more...I mean, I'm reading his blog and looking at SUNW's chart and thinking "are we reading the same Q4 release?" Maybe if you spent some time running it instead of talking shit to your competitors you'd have some ground to stand on.

Why hasn't IBM ported its products to Solaris 10? Perhaps because it isn't released yet. Perhaps because there's no demand. We run IBM tools (Tivoli, MQ, etc.) on Sun boxes and there is every reason to believe that they'll port their tools once they perceive a market. Hey, Johnathon, does N1 support anything other than Sun's blades yet? You lock-in dogs!

Johnathon Schwartz is acting like an overpaid NBA player whose game isn't all that good. If Wilt Chamberlain talks trash, it's one thing, but if it's some second-rate bencher who has no game, it just looks sad. Tell you what, Johnathon - how about not dissing IBM or HP until Sun's back on top?

Yes. Johnathon's "open letter" is one of the silliest, snarkiest, stupidest things I've seen in some time.

Oh, Johnathon, you're so clever with your "open letter" on your blog. Gimme a break. Your company is not doing well and hasn't been since the easy pickings of the dot-com years when everyone did well. You've been one of the sick men of the IT world for years. You finally managed to eke out a tiny profit, but your revenue continues to slide. Analysts are not impressed and while you were busy getting in your competitors' faces and thumping your chest, your stock dropped some more...I mean, I'm reading his blog and looking at SUNW's chart and thinking "are we reading the same Q4 release?" Maybe if you spent some time running it instead of talking shit to your competitors you'd have some ground to stand on.

Why hasn't IBM ported its products to Solaris 10? Perhaps because it isn't released yet. Perhaps because there's no demand. We run IBM tools (Tivoli, MQ, etc.) on Sun boxes and there is every reason to believe that they'll port their tools once they perceive a market. Hey, Johnathon, does N1 support anything other than Sun's blades yet? You lock-in dogs!

Johnathon Schwartz is acting like an overpaid NBA player whose game isn't all that good. If Wilt Chamberlain talks trash, it's one thing, but if it's some second-rate bencher who has no game, it just looks sad. Tell you what, Johnathon - how about not dissing IBM or HP until Sun's back on top?

DTrace is a Solaris Kernel tool. It debugs problems in the Solaris Kernel, and strangely enough the Solaris Kernel only works on Solaris - what would be the point of putting it into linux?

According to the ZFS Q&A on http://www.sun.com/emrkt/campaign_docs/icee_0703/t ranscript-SEE-091504.pdf they are already investigating porting zfs to linux.

Other sun stuff like Java, Star/Openoffice, Netbeans/SunOne Studio, iPlanet etc... are available for a multitude of other OS's.

here you can see who is who in Sun.

Now there is only office for 300 dollars, and you get MS(doesn't)works free w/ a new pc

Unfortunately, you are badly uninformed.

But hey, why let facts stop some good FUD?

At least I know i wasn't the only one who thought it was sun and not sol

Free Solaris 10 for x86 download

• 128-bit filesystem (zettabyte?)
• Automagic volume management
• Rock-stable NFS implementation

Well, for starters, check out the OpenSolaris Community Manager's Blog and Technorati's OpenSolaris "tag" (category) site...

There is a recent article that talks about how researchers are given time to work on side projects, so long as they publish results. Of course, there's a big difference between 'researchers' and grunt coders with deadlines.

Umm, here's the UltraSparc page which states that USIV scales to ~1000 CPUs. I think the number is actually 1024, but hey close enough, huh. If there was a market, they could probably extend that out to a multiple with some specialized hardware, but who cares! This is all like measuring cock sizes.
USIV specs

And yes I am an employee of Sun. I am not a marketing drone though. If you have any doubt about that, read my past posts. There are a few since I've been here since around the beginning.

Next, tnamed is still active on Solaris 9. From the same box:

# grep tnamed /etc/inetd.conf name dgram udp wait root /usr/sbin/in.tnamed in.tnamed

Finally, as another poster pointed out, Sun's got a great tool in JASS, a vendor-supplied tool. And we all owe a debt to Titan, the first majorly popular Sun hardening program. YASSPis also out there for Sun.

Ok, from this little statement it is obvious that you missed the major feature behind the new 'greenline' code in Solaris 10. (I know, this is slashdot...)

In short, generates a vectored graph of services. This gives the system a list of services and their dependencies. The old init.d/rc.X only provides a linear `these scripts must run in this order` relationship.

This has several advantages that immediately come to mind:

1. The system can start faster since it can now run several init scripts at once. No longer does one have to wait for nfs to start before starting the web server (assuming one uses the all too common setup where nfs is rc3.d/S15nfs and the web server is rc3.d/S99apache)
2. Since the system tracks dependencies, it can restart dependant services as needed (and not touch services that are not impacted)
3. You can disable things and patches will no longer re-enable them. Under solaris 9, a common way to disable something was to rename the SXXbla file by putting a `.` or `_` in front of it. This works great unless they release a patch to that file and the new (patched) file gets dumped out there in the rc directory.
4. During a jumpstart (kickstart for you RedHat folks), you can drop in your own site.xml file and instantly customize a ton of thigns that used to require editing dozens of files.
5. It is now easy to drop in a service monitoring facility (like sun's SMF) that monitors key services and restarts both them and their dependent services.

By the way, the file that it uses is xml, not binary.

And it is also not a 'file that changes'. The actual config file is static (unless you make a change). The only thing that may change is the order that two nondependent services start in relationship to each other. And that is the point, they are not dependent and thus you should not care if apache starts before sshd. In fact, this is a very good thing as you probably dont want a problem in the apache rc file to cause sshd to never start (guess how many times i've seen rc3.d/S99apache and rc3.d/S99sshd on a single system... guess which one runs first under init.d... yup.... apache.)

For more details, you can check out the blogs of Stephen Hahn, Bill Moffitt, or Tobin Coziahr.

Ok, from this little statement it is obvious that you missed the major feature behind the new 'greenline' code in Solaris 10. (I know, this is slashdot...)

In short, generates a vectored graph of services. This gives the system a list of services and their dependencies. The old init.d/rc.X only provides a linear `these scripts must run in this order` relationship.

This has several advantages that immediately come to mind:

1. The system can start faster since it can now run several init scripts at once. No longer does one have to wait for nfs to start before starting the web server (assuming one uses the all too common setup where nfs is rc3.d/S15nfs and the web server is rc3.d/S99apache)
2. Since the system tracks dependencies, it can restart dependant services as needed (and not touch services that are not impacted)
3. You can disable things and patches will no longer re-enable them. Under solaris 9, a common way to disable something was to rename the SXXbla file by putting a `.` or `_` in front of it. This works great unless they release a patch to that file and the new (patched) file gets dumped out there in the rc directory.
4. During a jumpstart (kickstart for you RedHat folks), you can drop in your own site.xml file and instantly customize a ton of thigns that used to require editing dozens of files.
5. It is now easy to drop in a service monitoring facility (like sun's SMF) that monitors key services and restarts both them and their dependent services.

By the way, the file that it uses is xml, not binary.

And it is also not a 'file that changes'. The actual config file is static (unless you make a change). The only thing that may change is the order that two nondependent services start in relationship to each other. And that is the point, they are not dependent and thus you should not care if apache starts before sshd. In fact, this is a very good thing as you probably dont want a problem in the apache rc file to cause sshd to never start (guess how many times i've seen rc3.d/S99apache and rc3.d/S99sshd on a single system... guess which one runs first under init.d... yup.... apache.)

For more details, you can check out the blogs of Stephen Hahn, Bill Moffitt, or Tobin Coziahr.

Ok, from this little statement it is obvious that you missed the major feature behind the new 'greenline' code in Solaris 10. (I know, this is slashdot...)

In short, generates a vectored graph of services. This gives the system a list of services and their dependencies. The old init.d/rc.X only provides a linear `these scripts must run in this order` relationship.

This has several advantages that immediately come to mind:

1. The system can start faster since it can now run several init scripts at once. No longer does one have to wait for nfs to start before starting the web server (assuming one uses the all too common setup where nfs is rc3.d/S15nfs and the web server is rc3.d/S99apache)
2. Since the system tracks dependencies, it can restart dependant services as needed (and not touch services that are not impacted)
3. You can disable things and patches will no longer re-enable them. Under solaris 9, a common way to disable something was to rename the SXXbla file by putting a `.` or `_` in front of it. This works great unless they release a patch to that file and the new (patched) file gets dumped out there in the rc directory.
4. During a jumpstart (kickstart for you RedHat folks), you can drop in your own site.xml file and instantly customize a ton of thigns that used to require editing dozens of files.
5. It is now easy to drop in a service monitoring facility (like sun's SMF) that monitors key services and restarts both them and their dependent services.

By the way, the file that it uses is xml, not binary.

And it is also not a 'file that changes'. The actual config file is static (unless you make a change). The only thing that may change is the order that two nondependent services start in relationship to each other. And that is the point, they are not dependent and thus you should not care if apache starts before sshd. In fact, this is a very good thing as you probably dont want a problem in the apache rc file to cause sshd to never start (guess how many times i've seen rc3.d/S99apache and rc3.d/S99sshd on a single system... guess which one runs first under init.d... yup.... apache.)

For more details, you can check out the blogs of Stephen Hahn, Bill Moffitt, or Tobin Coziahr.

First, the biggest single system Linux box is 512 CPUs (although I think NASA has 2048 CPUs in a BX2 machine, which has an expanded cache coherency domain to 1024 or 2048 CPUs, I'm not sure if they've actually hooked them up yet).

Still, that literally blows Sun's biggest machine out of the water. Especially in absolute performance, when you consider a new 9MB cache I2 is probably a clear twice the speed of the fastest of sun's sparcs.

Second, Sun's machines are NUMA as well. That's right, they have Non Uniform Memory Access. See here. They have a 4 tiered access hierarcy on memory. Either way, SGI's NUMAlink interconnect is far better than Sun's old crossbar switch dinosaur. See here. The Altix has 4 times the top-of-the-line Sun's memory bandwidth per CPU. That is SGI's old interconnect too, mind you.

Most phone manufacturers have custom SDKs (including emulators), usually freely available, that support either their own language or Java. Search the manufacturers site, these are usually well hidden inside the business section.

Siemens has a good toolkit:
http://developers.sun.com/prodtech/javatools/jssta ndard/reference/techart/siemens.html
https://communication-market.siemens.de/portal/mai n.aspx?LangID=0&MainMenuID=2&LeftID=2&pid=1&cid=0& tid=3000&xid=0

http://tuxmobil.org/phones_linux.html Has alot of info/links on Cell Phones and programming for them

I am a cellphone application developer, specializing in Qualcomm's BREW. It's true that getting you application onto an actual handset is quite an ordeal. You have to be authenticated, then send any handsets to Qualcomm, to become "test-enabled", that will allow you to cable-load applications to the phone.

But what about java enabled devices? I haven't actually done any developement in that area, but it would be wise to see if the same restrictions apply. You can probably find information from Sun, I believe most devices use J2ME (http://java.sun.com/j2me/). I know that most of Sprint's handsets are Java-enabled. Also, distributing your applications is MUCH easier for java handsets, as opposed to BREW's distrobution system (it's called a "walled-garden"), completely controlled by the carriers. Whereas with java you can distribute via WAP pushes, and links.

Every Java applet should be able to be easily assigned a set of permissions.

Every Java applet should be able to be easily assigned a set of permissions.

Every Java applet should be able to be easily assigned a set of permissions.

Every Java applet should be able to be easily assigned a set of permissions.

And then they all get eaten by this thing. End splash screen: Sun Microsystems.

by making sure that the 3D hardware is continually tied up running the particle engine floating around the talking paper clip or Enlightenment logo or whatever.

I realy REALLY highly doubt that a logo or annoying paperclip, regardless of how 3d it's rendered is going to tie up the graphics card.

I do however, agree with the bulk of what you're stating. I think that would be great if the OS COULD utilize the graphics card to do more, whether it be off-loading things currently done by the CPU or enhancing the user experience by doing things that weren't possible on a lower end graphics card.

However, like all of the "look enhancing" features of windows, I would greatly appreciate the ability to turn it off and run on crappy Intel Extreme Graphics should I need to.

That is, of course, unless Microsoft is moving towards something like Sun's experimental Project Looking Glass 3D Desktop. Were that the case, then I would probably be accepting of a higher end graphics card requirement as I would, in fact, be working more efficiently, rather than just oogling how pretty the menus look.

by making sure that the 3D hardware is continually tied up running the particle engine floating around the talking paper clip or Enlightenment logo or whatever.

I realy REALLY highly doubt that a logo or annoying paperclip, regardless of how 3d it's rendered is going to tie up the graphics card.

I do however, agree with the bulk of what you're stating. I think that would be great if the OS COULD utilize the graphics card to do more, whether it be off-loading things currently done by the CPU or enhancing the user experience by doing things that weren't possible on a lower end graphics card.

However, like all of the "look enhancing" features of windows, I would greatly appreciate the ability to turn it off and run on crappy Intel Extreme Graphics should I need to.

That is, of course, unless Microsoft is moving towards something like Sun's experimental Project Looking Glass 3D Desktop. Were that the case, then I would probably be accepting of a higher end graphics card requirement as I would, in fact, be working more efficiently, rather than just oogling how pretty the menus look.

SVG support.

I have to second this. Just this week, I came across a financial site that used SVG for some of its graphs. Adobe's program isn't available for my platform, and native support in Mozilla/Firefox would be excellent.

disable flash

Per-site profiles for Flash, Java, etc., like we already have for cookies and images would be perfect. Disabling plugins selectively could improve security for everyone and make life livable for those with older computers.

Improve the download manager.

For anything important, like an CD-R ISO, I use Sun Download Manager. It's written in Java, and it works very well.

Remember what tabs I was reading

What about NSFW (not safe for work) sites? Remembering tabs should be configurable.

Do a thorough security audit.

This would be worth the future PR alone. Perhaps they should enlist some of the BSD crew for the auditing.

Emacs

Emacs is already way more powerful than Mozilla. I replied to your post, and, now, I know you were just trolling. Thanks for wasting my time! ;)

I only WISH a Unix/Linux vendor had the support MS does for thier legacy products!

Here is Sun's Solaris lifecycle. In fact, it looks like the latest patch cluster for Solaris 2.5.1 came out in September. Solaris 2.5.1 first shipped in 1996.

Sales:

Sun delivers a new release of the Solaris Operating System approximately every 24-36 months. Roughly four times a year, updates that incorporate a set of tested, integrated patches along with new Solaris features and support for new hardware are released.

At a minimum, there are two major releases of the Solaris Operating System available for purchase. After a new release is delivered, Sun announces the end of sales life for the 2nd prior release of the product and customers are given 90 days to place final orders. Final shipments are made for 90 days beyond the final order date.

The support contract for products that have reached the end of their sales life can be extended by five further years through the Solaris Vintage Support Model.

Support:

The Solaris Vintage Support model allows customers to extend contractual support for the Solaris Operating System (SPARC and x86) for five years from the Last Ship date as follows: The level of support during the first two years from the Last Ship date will provide contract customers full remedial support excepting requests for enhancements and cosmetic bugs. Patches will be created as needed and distributed through the SunSolve program. This provides no material reduction in the level of support. However, patches will not be rolled up into quarterly updates. In years three through five from the Last Ship date, contract customers will continue to receive telephone support and to have access to existing patches on the SunSolve site. No patches will be issued for new bugs. Five years from the Last Ship date and beyond, customers may contact Sun Enterprise Services for a custom quote for support services.

Sales:

Sun delivers a new release of the Solaris Operating System approximately every 24-36 months. Roughly four times a year, updates that incorporate a set of tested, integrated patches along with new Solaris features and support for new hardware are released.

At a minimum, there are two major releases of the Solaris Operating System available for purchase. After a new release is delivered, Sun announces the end of sales life for the 2nd prior release of the product and customers are given 90 days to place final orders. Final shipments are made for 90 days beyond the final order date.

The support contract for products that have reached the end of their sales life can be extended by five further years through the Solaris Vintage Support Model.

Support:

The Solaris Vintage Support model allows customers to extend contractual support for the Solaris Operating System (SPARC and x86) for five years from the Last Ship date as follows: The level of support during the first two years from the Last Ship date will provide contract customers full remedial support excepting requests for enhancements and cosmetic bugs. Patches will be created as needed and distributed through the SunSolve program. This provides no material reduction in the level of support. However, patches will not be rolled up into quarterly updates. In years three through five from the Last Ship date, contract customers will continue to receive telephone support and to have access to existing patches on the SunSolve site. No patches will be issued for new bugs. Five years from the Last Ship date and beyond, customers may contact Sun Enterprise Services for a custom quote for support services.

Sun produces patches in support for Solaris two years after the last ship date, and ends support five years after the last ship date. That has them creating patches for Solaris 7 until next August and phase 2 support for Solaris 2.5.1 ending next September.

Although most /. readers probably won't care, dual core CPU's are already on the market in the form of the UltraSPARC IV CPU from Sun Microsystems. Sun also happen to be sporting the most ambitious multi-core project going in the form of Niagara, which although initially an 8-core system has apparently been seen running Solaris 9 with 32 independent CPU cores.

In addition to this, the POWER 5 CPU is also available with multiple cores, fully supporting Linux.

Also of note is that the Opteron dual-core CPU's from AMD are apparently going to be pin-compatible with the current Opteron processors (by current,I mean, the latest socket 939 (I think) systems, not the original Opteron 2xx or whatever).

This is really of most use for the data center right now, but as more applications wrap their heads around paralelizing themselves, multi-core CPU's on the desktop will become more popular.

That said, developers really have no excuses for not having blazing fast "dual-core aware" apps... a multi-processor system purchased today provides about as much performance as a dual core system... so it's not like a wild new technology where application developers have to wait for SDK's or test hardware. Multiple cores, HyperThreading CPU's or multiple physical processors are all just additional CPU's from the operating systems perspective, and are developed for using the same tried and true thread libraries (pthreads, etc).

Multi-thread those apps people! There are so many instances, especially when writing GUI apps, where an extra thread or two thrown in the right direction can really improve the user experience.

Of course, a big problem is just how developers learn to program. Everyone learns their "Hello World!", then goes from there... but this is all very linear in approach. Finding good programmers who can think of an application in terms of what many parallel threads should (or shouldn't) be doing isn't easy... but I digress.

The buzz word of 2005 is "dual core". It just stands to reason that Gpu's go down this same road. You can find "dual core" concepts in the gamming console, server, desktop and gamming pc, and now video cards. One person gets a good idea and everyone jumps on board. If you want to see multi-core taken to the extreme, Check out Suns 32 way server on a chip. http://blogs.sun.com/roller/page/jonathan/20040910

.
> Time is money.

Yup. And when you purchase a $30,000 vendor solution, your risk drops to near zero. When you build it yourself, you assume all the risk. What risk you say? Risk of costing you WAY MORE time than you expected to make it work.

Six months ago I and a few engineers were chomping at the bit to build a $3000 highly-available NFS server solution - two Athlon 2500 linux boxes each with 5 200GB HDDs running RAID-5 and Gig-E, dual mirrored boot drives. That's 1200 - 1600 GB of storage for $3000, instead of spending

I mean, everyone's doing it right, so it can't be hard to get working nicely? And it's TONS cheaper than a pair of similarly sized commercial rack-mount $15,000 to $60,000 systems.

Well guess how much support you get from some dumbass consumer grade SATA RAID-5 card vendors when the cards (both of them in both systems) act flakey as hell and repeatedly "drop" a drive or two every week only to rebuild them without complaint?

Jack shit.

Not only that, but our linux sysadmin took months learning every feature of the cards and setting up the array and setting up the HA-NFS solution. Don't get me wrong, a large part of the reason it took months was because building and tearing down terrabyte arrays is slow as molasses (we're talking about a full day just to rebuild one "dropped" 200 GB drive), but MOSTLY because our sysadmins were already overworked and just didn't have the time for it.

Oh, guess what? You discover that your RAID Card vendor's support for all the different variants of linux? DOES NOT INCLUDE the ability to rebuild drives while the OS is running and the array is in degraded mode. If a drive drops out your only option is to boot into the BIOS and wait 12 hours for it to rebuild a drive. It was only 6 months AFTER we bought the raid cards that they shipped an upgraded SUSE driver.

So, here's what we learned:

1) If you don't have a low-pay sysadmin with tons of spare time to work out bugs and hassle the vendors for support/replacements, you increase your risk.

2) If your company hasn't built this exact same solution once before using the exact bits of hardware and software that you intend to use, expect tons of unexpected hickup, which increases your risk yet again.

If you have the worst bits of both 1 and 2, you could luck out and be fine, or you could get seriously fucked when your boss asks you 4 months latter where the fuck the HA-NAS solution is.

.
> Time is money.

Yup. And when you purchase a $30,000 vendor solution, your risk drops to near zero. When you build it yourself, you assume all the risk. What risk you say? Risk of costing you WAY MORE time than you expected to make it work.

Six months ago I and a few engineers were chomping at the bit to build a $3000 highly-available NFS server solution - two Athlon 2500 linux boxes each with 5 200GB HDDs running RAID-5 and Gig-E, dual mirrored boot drives. That's 1200 - 1600 GB of storage for $3000, instead of spending

I mean, everyone's doing it right, so it can't be hard to get working nicely? And it's TONS cheaper than a pair of similarly sized commercial rack-mount $15,000 to $60,000 systems.

Well guess how much support you get from some dumbass consumer grade SATA RAID-5 card vendors when the cards (both of them in both systems) act flakey as hell and repeatedly "drop" a drive or two every week only to rebuild them without complaint?

Jack shit.

Not only that, but our linux sysadmin took months learning every feature of the cards and setting up the array and setting up the HA-NFS solution. Don't get me wrong, a large part of the reason it took months was because building and tearing down terrabyte arrays is slow as molasses (we're talking about a full day just to rebuild one "dropped" 200 GB drive), but MOSTLY because our sysadmins were already overworked and just didn't have the time for it.

Oh, guess what? You discover that your RAID Card vendor's support for all the different variants of linux? DOES NOT INCLUDE the ability to rebuild drives while the OS is running and the array is in degraded mode. If a drive drops out your only option is to boot into the BIOS and wait 12 hours for it to rebuild a drive. It was only 6 months AFTER we bought the raid cards that they shipped an upgraded SUSE driver.

So, here's what we learned:

1) If you don't have a low-pay sysadmin with tons of spare time to work out bugs and hassle the vendors for support/replacements, you increase your risk.

2) If your company hasn't built this exact same solution once before using the exact bits of hardware and software that you intend to use, expect tons of unexpected hickup, which increases your risk yet again.

If you have the worst bits of both 1 and 2, you could luck out and be fine, or you could get seriously fucked when your boss asks you 4 months latter where the fuck the HA-NAS solution is.

Okay, I'll bite... here are the details regarding termination of the license to use the Sun Java Development Kit 5.0.

Pay close attention to this part...

7. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. Upon Termination, you must destroy all copies of Software.

...which means that you're license to use the JDK can only be terminated in one of two scenarios:

1. You are involved in (or likely to be involved in) an intellectual property lawsuit that exposes Sun or yourself to liability (you can terminate the license yourself).
2. You break one of the other preconditions of the license. If you look through the rest of the license, this involves things like violating export restrictions, warranting the use of the application in nuclear facilities, and attempting to modify the code (a la Microsoft), redistributing it as if it were your own, and other behaviors that require you to essentially step on Sun's intellectual property to trigger the revocation of your right to use the JDK.

I always thought that NAT and bastille would be enough. I never considered the risk of this sort. Worse yet, it seems that the reported exploit isn't the only locally exploitable flaw

What's an admin to do?

from the without-users-this-wouldn't-be-a-problem dept.

*Shudders*

Then, methinks: "I'll just apply a patch..."

It turns out that patches do NOT always fix the problem.

What's an admin to do?

Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.

I was able to extract the encryption classes I needed. See my tech tip Data Encryption for J2ME Profiles for details.

how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog

This depends on the device, but in general with MIDP 2.0 you can use the permissions mechanism to basically have the user prompted only once instead of each time. See Understanding MIDP 2.0's Security Architecture.

Is there any J2ME forum you could recommend, by the way?

The hardcore J2ME types hang around on the KVM-INTEREST list run by Sun. See J2ME Mailing Lists.

Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.

I was able to extract the encryption classes I needed. See my tech tip Data Encryption for J2ME Profiles for details.

how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog

This depends on the device, but in general with MIDP 2.0 you can use the permissions mechanism to basically have the user prompted only once instead of each time. See Understanding MIDP 2.0's Security Architecture.

Is there any J2ME forum you could recommend, by the way?

The hardcore J2ME types hang around on the KVM-INTEREST list run by Sun. See J2ME Mailing Lists.

J2ME adoption has been tremendous. Go read Java Turns 5!. This means there is an opportunity out there to make some dough by creating J2ME-based solutions. Up to you if you want to take advantage of this opportunity...

ceo
www.j2medeveloper.com