Slashdot Mirror

I'm sure the commons-collection is a nice implementation, but for those who haven't heard, Java 1.5 (currently in beta) contains most of the features you've named. Some are simply new classes in the collections framework, others are language extensions (i.e. generics for type-safe collections).

Also, some of the features you named are already in java 1.4, such as identity maps, reference maps that allow garbage collection, adapters for converting collections to/from enumerations and arrays.

I'm sure the commons-collection is a nice implementation, but for those who haven't heard, Java 1.5 (currently in beta) contains most of the features you've named. Some are simply new classes in the collections framework, others are language extensions (i.e. generics for type-safe collections).

Also, some of the features you named are already in java 1.4, such as identity maps, reference maps that allow garbage collection, adapters for converting collections to/from enumerations and arrays.

Look this patch for Solaris from Sun:
ROC timezone should be avoided for political reasons

Sun do, they just suck at advertising it.

http://wwws.sun.com/software/product_categories/em ail_calendar_collaboration.html

They also have plugins for outlook and evolution to give full functionality. The web stuff works quite well anyway, and a new integrated version of the webside for mail and calendar will be coming soon.

Ah, OK, so it's not the JVM that's the issue with backwards compatability, but the lack of the appropriate library support. Interesting. I gather then that a 1.4 JVM would actually work just fine provided the 1.5 libraries were in its classpath.

I can't seem to find anything about this mysterious method "toInt()" in the 1.5 api specs, but I understand the issue now. Thanks.

Uhhh...wrong. Java has had support for domain name resolution (and reverse DNS lookup) since its inception! Sure it doesn't have ability to do fancier stuff like dynamic DNS updates in its main classes, but neither do any other mainstream languages. Languages such as C++ don't even have support for Sockets in their "main classes", so this is a rather weak criticism even if it were remotely true.

2. Java network interface support is not platform independent. As a result any application that needs to bind to a specific interface on a multihomed machine needs to have external config or to be platform dependant which largely defeats the idea of using java in first place.

Wrong again! It's trivial to iterate over the set of network interfaces on a machine and bind to a specific one. One of my apps uses this functionality, and it works perfectly on multiple platforms (including linux, mac, pc, aix, ...)

Try again cluesink...

Uhhh...wrong. Java has had support for domain name resolution (and reverse DNS lookup) since its inception! Sure it doesn't have ability to do fancier stuff like dynamic DNS updates in its main classes, but neither do any other mainstream languages. Languages such as C++ don't even have support for Sockets in their "main classes", so this is a rather weak criticism even if it were remotely true.

2. Java network interface support is not platform independent. As a result any application that needs to bind to a specific interface on a multihomed machine needs to have external config or to be platform dependant which largely defeats the idea of using java in first place.

Wrong again! It's trivial to iterate over the set of network interfaces on a machine and bind to a specific one. One of my apps uses this functionality, and it works perfectly on multiple platforms (including linux, mac, pc, aix, ...)

Try again cluesink...

What happens to your precious C and assembly when you compile and assemble them? They get converted into machine code for whatever processor you are running it on.

JVM stands for Java Virtual Machine.
It is called that because it interprets the Java bytecodes as if they were machine instructions, and executes them as if they were running on a "Java Machine".
The JVM is just an emulator for a standard "Java Machine". At the time Java was designed, there was no real machine that could execute Java bytecodes.

The specialized Java processors use Java bytecodes as their instruction set (to an extent, they leave out a few bytecodes and usually add I/O instructions). This is what I mean by mostly implemented in hardware. They still need a low-level operating system to handle linking and garbage collection, but this is usually already burned into the ROM (along with a few specialized classes to handle I/O and such), so the developer doesn't need to worry about it.

If you're still unclear how this is possible, feel free to read the JVM specification:
http://java.sun.com/docs/books/vmspec/2nd-edition/ html/Instructions2.doc.html
It doesn't specifically say that this can/should/has be/be/been done, but you can look at the instruction set and see if you think it could reasonably be implemented in hardware.

Agreed this is indeed a problem, JVMs can be quite memory hungry. However there are several ways to address this. First of all, it's possible to have a single application server instance host multiple web applications. In fact, this is half the point of having an application server in the first place! Sure there's extra effort involved in getting the security and other configuration right, but it will save you gobs and gobs of memory.

Additionally, Sun will be providing new functionality in J2SE 1.6 (6.0?), due out in beta this year, to allow JVM resources to be shared across separate instances of the JVM.

Take a look at http://research.sun.com/projects/barcelona/papers/ oopsla00.pdf to see how Sun plan on addressing this.

Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2)

Oh, what BS. Like that is the only thing that has changed .Java has become big enough to come in three different version, enterprise, standard and micro edition. The micro edition is extremely common in mobile phones, enterprise very common in banking etc.

Some of the new things in Java 1.3:
Java Naming and Directory Interface (JNDI), 20% faster RMI serialization, improvements in AWT/Swing/JavaSound, security enhancements, HotSpot optimization of client and server VMs.

In Java 1.4:
Secure Sockets and HTTPS, IPv6, cryptography extensions, LinkedHashMap, NIO (FileChannel, Non blocking IO), builtin regexp and logging (though there are even better open source libraries for those), assertions, XML processing, hardware acceleration of Java2D, image I/O framework, java Web start, Unicode 3.0 Support, Currency class, Accessibility improvements, Math improvments, Itanium support

In Java 1.5:
Generics, enhanced for Loop (for each), autoboxing/unboxing, typesafe enums, varargs, metadata annotations, class data sharing (improved VM startup time), launching apps under inetd in unix/linux, loads of security enhancements, Unicode 4 support, hyperbolic transcendental functions (sinh, cosh, tanh), cube root, base 10 logarithm, AMD Opteron support....

Sun is not letting MS win without a fight.

Although things are far from the halcyon days of dot-com yesteryear

A sure fire test of whether someone is a globalist toady is when they compare present conditions to the peak of the dotcom craze rather than to the recessionary periods of the early 80's or early 90's.

It's sort of like if you dared take so much as a 30% pay raise at any time during the period from 1998 through 2000, you are fair chicken meat for the carnal desires of a pod of AIDS neuropathic Scott McNealy clones and their puppet masters.

Define "get things done". I need one reference: the API. I can usually find what I want in there by working out what I would have called it and looking there. If there's a similar reference on Perl, I'd like to know the URL: I use the O'Reilly book, but when I run into problems I generally have to ask a Perl guru what I need to look up in the index.

Re Java being "mysterious" (?!). You're reading the wrong books. Not that you need a book at all. All you need is:
The Java Language specification
and if you are interested in more depth, The VM spec
The specified behavior for synchronization, the memory model & threading are all there in fairly simple terms.

Re Java being "mysterious" (?!). You're reading the wrong books. Not that you need a book at all. All you need is:
The Java Language specification
and if you are interested in more depth, The VM spec
The specified behavior for synchronization, the memory model & threading are all there in fairly simple terms.

Java has a standard class for seing file permissions. I'm not sure what that whole thing about writing a C routine was about... was this several years ago?

I'm not sure why you would complain about the XMl choices. You have a lot of options but since when is that bad? If you need to keep it simple there is JDOM. What are you doing for XML work in Python that's so much easier to use?

The other poster already made the point of how extensive the Java API's are - currently the most comprehensive standard library around for any language.

for( SomeType s : collection )
doSomething( s );

I think something along those lines is already possible in Java :)

Over at my library, we use Sun's SunRays. They make for a OK solution. At first, I was quite excited about it, but the school's IT department implemented them poorly. The biggest detail in this regard is their choice to use CDE for the desktop environment, rather than using fvwm95 or even KDE and GNOME. We used CDE for a couple of years, and then ITSS finally got around to installing KDE and making it the default option for the new incoming students.

Under CDE, the students hated them. And a lot still do, with that reputation becoming entrenched. And with the switch to KDE, the reasons the students hated them changed, although there were still a lot of negative feelings toward them. CDE is ... CDE, and very unfamiliar to your average users of Windows and Mac OS. But there weren't problems with speed. But when they put KDE 2.x on there (not sure if they are running 3 now) people knew how to use it for the most part, but things got incredibly slow. KDE is slow, CDE was pretty fast. On top of that, KDE has had a lot of flaky little features, the most common is not being able to log-out of the session, but there's a lot of parts of KDE that seem to crash randomly. That confuses students and patrons. These people aren't Linux users at home- when the logout button doesn't work in KDE, they don't know enough to log-in to the SunRay next to them and kill the Xsession. But then again, they shouldn't have to.

Considering that, it's not surprising to find that the relatively small number of real PCs are always in use, people checking to see if there's a PC open before resorting to a SunRay.

The price... it really isn't all that good. The models we use, The SunRay 1g, costs $360 now from Sun. Not horrible, but then you also have to consider the very big and expensive SunRay servers in that. When we got them, they cost a whopping $699. This was 4 years ago, but even back then you could get a low-end PC for that. That didn't include the 18" LCD displays either, but that's the same on any computer. Though, back then, the prices on the LCDs were very good- when this was all happening, I remember hearing that some school (in Michigan?) was buying a bunch of SunRays from Sun just to get the huge discount on the LCD displays, which they were using with their "real" PCs. The SunRay's lived in a closet somewhere in their original shipping boxes.

I recall reading a very interesting thread on the Java forums. There are very few female programmer's in the industry and there are even fewer women working as sysadmins.
Hwre is the thread
From research conducted it was proved that generally speaking, the female mind is "weak" in certain areas of the brain which are used for programming logic and deduction. In my opinion, not having women in the IT field is kinda a good thing. Helps us with are geek status n all, ya know :D

Sun Rays are dead silent (no moving parts), very low power (20W) which also saves you on air-con, last forever, require no maintenance on the client side, are very secure (air traffic control for Air Force One is run off a network of Sun Rays) and easy to setup.

Version 3.0 of the server software also runs on Linux. V3 is also bandwidth efficient enough that you can deploy over broadband or a group over 10Mb Ethernet.

As for how much they cost, on modern hardware the main thing to bear in mind is the amount of main memory you have. Sun have a sizing guide to help. For lightweight usage, eg a library, they suggest you can run 40 clients off a server with 4GB of main memory.

So 40x Sun Ray 1g = $359 * 40 = $14.4K (re-use monitors from your existing systems). On server side, a Sun Fire v20z with 2x Opteron 250s and 4GB of memory is $7k, though you could get a model with slower CPUs and pay for more memory. As a library, you should be able to get an educational discount too.

Sun Rays are dead silent (no moving parts), very low power (20W) which also saves you on air-con, last forever, require no maintenance on the client side, are very secure (air traffic control for Air Force One is run off a network of Sun Rays) and easy to setup.

Version 3.0 of the server software also runs on Linux. V3 is also bandwidth efficient enough that you can deploy over broadband or a group over 10Mb Ethernet.

As for how much they cost, on modern hardware the main thing to bear in mind is the amount of main memory you have. Sun have a sizing guide to help. For lightweight usage, eg a library, they suggest you can run 40 clients off a server with 4GB of main memory.

So 40x Sun Ray 1g = $359 * 40 = $14.4K (re-use monitors from your existing systems). On server side, a Sun Fire v20z with 2x Opteron 250s and 4GB of memory is $7k, though you could get a model with slower CPUs and pay for more memory. As a library, you should be able to get an educational discount too.

Sun Rays are dead silent (no moving parts), very low power (20W) which also saves you on air-con, last forever, require no maintenance on the client side, are very secure (air traffic control for Air Force One is run off a network of Sun Rays) and easy to setup.

Version 3.0 of the server software also runs on Linux. V3 is also bandwidth efficient enough that you can deploy over broadband or a group over 10Mb Ethernet.

As for how much they cost, on modern hardware the main thing to bear in mind is the amount of main memory you have. Sun have a sizing guide to help. For lightweight usage, eg a library, they suggest you can run 40 clients off a server with 4GB of main memory.

So 40x Sun Ray 1g = $359 * 40 = $14.4K (re-use monitors from your existing systems). On server side, a Sun Fire v20z with 2x Opteron 250s and 4GB of memory is $7k, though you could get a model with slower CPUs and pay for more memory. As a library, you should be able to get an educational discount too.

ObDisclaimer: I work for the Linux Server Group at Sun.

I have also worked rather intimately with a few thin client technologies over the years, including SunRay, X Terminals (NCD, e.g.), and WinTerminals with WinFrame (NT 3.5) or MetaFrame (NT4/2k). I run a few SunRay servers today, and have run a 75-user cluster of Win/MetaFrame machines in the past. All of these solutions have their plusses (in fact, terminal services is the one Windows technology I like)...

There are, however, bits of your specific set of issues that point me at the SunRay for you:

1. Bandwidth to the clients are not an issue, so no need for the bandwidth saving that ICA gives you (ICA is really quite good over dial-up, e.g.), so that leaves:
2. Windows compatibility. Since you don't seem to care about running Windows apps, all solutions are on more-or-less even footing.

If you've got some coin and are willing to spend a little on systems, I'd recommend the SunRay because:

1. Sessions tied to smart cards. Folks can log in, and wander anywhere in the library with their session tied to (e.g.) their library card. For folks doing combination book/internet research, this is awesome. Folks that haven't tried yet are really missing out.
2. Soon, you won't be tied to Solaris/SPARC anymore. Sun has announced a port of the SunRay software to Linux, so you may well be able to reuse your existing server hardware. In fact, the beta is available for download here.

It never ceases to amaze me how many PC techs I know complain about crawling under desks or removing 25 lbs of personal effects to fetch a system so they can swap a dead drive or similar. When I tell them that thin client technology can guarantee them never having to crawl under a desk again (barring wiring or serious catastrophe), they definitely stop worrying about nonexistant 3D performance. Thin-client is an awesome way to go--you might not spend that much less on the machines, but maintenance and client upgrade costs go to zero.

The downside is no Windows (excepting via e.g. VMWare, Wine, etc.). OTOH, even on Windows Terminal Services you have programs that aren't really written to be run by multiple users on the same machine (even Office gave us fits at times with entries in HKLM instead of HKCU). It's gotten better over the years, though...

Short version: Even if you don't go SunRay, save yourself a lot of headache and go with a thin client.

Note that the Sun Ray Server Software 3.0 Beta is also supported on Linux.

Sun's SunRays always seemed fairly interesting. And I've seen them used by a crew who run the dataroom for a national security conference (with glowing praise).

As a matter of fact, you CAN look at the code for Java. Have you ever? I'm a java developer and I sure haven't. As a matter of fact, I don't give a flying fuck how they implemented java.util.LinkedList. Java's free anyways, and Solaris is too for 1 processor (and I think they have a right to sell it for server use, they built it). Why do you zealots whine so much about 'open source' if you can do everything you'd want with it anyways, and will probably never look at the code.

blog entry.

It's Deja Vu all over again.

Solaris 2.5.1 had a "PowerPC edition"

http://docs.sun.com/db/doc/802-4127

This was back in the day when you could also get NeXTSTEP for Motorola 68K, Intel x86, SPARC, and HPPA.

Ugh, why would you want to?

Now, Solaris on an XServe... That makes sense... Server class hardware that doesn't suck, yet doesn't cost an arm and a leg, running perhaps the best multiprocessor Unix ever... Mmmmm.

The ironic thing in my view is that this is sort of what CHiRP was supposed to be - a happy universe where you could buy an RS6000 and run MacOS on it, or a Mac and run Solaris on it, or whatever. But then His Steveness decided that the clones had to go...

Ugh, why would you want to?

Now, Solaris on an XServe... That makes sense... Server class hardware that doesn't suck, yet doesn't cost an arm and a leg, running perhaps the best multiprocessor Unix ever... Mmmmm.

The ironic thing in my view is that this is sort of what CHiRP was supposed to be - a happy universe where you could buy an RS6000 and run MacOS on it, or a Mac and run Solaris on it, or whatever. But then His Steveness decided that the clones had to go...

Please define exactly what your definition of "open source" is. As the blog indicated, open source potentially has a different meaning for people. If by open source you mean that you want access to Solaris, check out Solaris Source (although this really just states: "Source code for the Solaris Operating System is available for qualified educational institutions and partners; please contact your Sun sales team for details"). I don't know what disclosure agreements are necessary for the access, but a determined individual should be able to get access.

Please define exactly what your definition of "open source" is. As the blog indicated, open source potentially has a different meaning for people. If by open source you mean that you want access to Solaris, check out Solaris Source (although this really just states: "Source code for the Solaris Operating System is available for qualified educational institutions and partners; please contact your Sun sales team for details"). I don't know what disclosure agreements are necessary for the access, but a determined individual should be able to get access.

1) He's not CTO. He's COO and President. Greg Papadopoulos is CTO.
2) This is not some official PR vaporware announcement. It's some entry in his blog.
3) If anything, for things like this, I trust the execs that can read C code over the ones that can read a balance and income statement. Nothing worse than management who thinks "Things will just work" and underestimate the technical resources and time required to accomplish tasks.

Just a second! Sun's been telling me to use Java because it's secure!. Certainly, we all know from reading /. that only Microsoft is vulnerable to these 'trojan horse' attacks because their software is poorly written!

Are you telling me that Java is poorly written? Or is there really no defense against tricking users into loading and running programs (as most Windows "viruses" of the past year or so have spread).

If that's true, then phones shouldn't be able to run software at all!

I know the expense account system is a Java web app.

Also, in Java 1.0.2 there was a "private protected" keyword that corresponded to C++-style protected variable access. However, apparently that was a "bug", and was quickly removed, over the protests of the userbase.

P.S. sorry I didn't reply in this thread earlier to clarify things, guys, I guess I didn't think anyone would be interested. :)

Argh. This is inaccurate.
Here's a link:
http://java.sun.com/docs/books/jls/second_edition/ html/names.doc.html#104285

In a nutshell (and paraphrasing)

public members have global visibility.
private members are visible solely within the top-level class that declares them
default-access members have package visibility
protected members have package visibility AND are visible to subclasses.

Then I have some dork telling me about their "Open Firmware". Open, my ass. If it was Open, I could build my own.

You can. Open Firmware is an open standard set up by Sun (IEEE 1257). Have a nice crow.

I notice that their "affiliates" buy up loads of domains as they expire and turn them into farms directing traffic to sites to install CoolWeb or lesser relatives.

Is that the same sort of thing as JavaDoc?

class foo.Wonk
--> protected int fld
--> protected void mth()

class foo.WonkPrime extends foo.Wonk
--> void doThis(foo.WonkPrime sameInput, foo.Wonk superInput)

class bar.WonkPrime extends foo.Wonk
--> void doThat(bar.WonkPrime sameInput, foo.Wonk superInput)

2 AMD Opteron 200 series processors. (up to 2.4 ghz.)

4 PCI-X busses.

Up to 16GB PC3200 memory with 12.8GB/sec. total memory bandwidth!

Holy schnikes Batman! Sun's new workstation just ate my dual G5 for lunch.

For an example of true 3D chip stacking, see Infineon's SOLID technology. Infineon announced that in 2002. Intel and Sharp have also played around with similar approaches.

The Infineon approach is interesting because it puts a layer of copper between the chips. Getting heat out of the middle of the stack is a major problem with all stacking schemes. Infineon claims to address this, but it's not clear how well. You're probably not going to stack up a pile of 50 watt CPUs with this technology. RAM, maybe. Low-duty-cycle flash memory, no problem. Music players are the obvious application.

Not much seems to have come from that technology since the 2002 announcement. So far, none of these stacking schemes have been useful. They're smaller, but not cheaper.

As I recall, it used to be possible to turn off runtime bounds checking. I also think that most people would do this once the code is debugged. Did this feature get disabled recently?

The language is defined so that this is impossible. See here. If you were to disable bounds checking, then you would be violating the language spec, and therefore it would not be Java. It would be the same if you wrote a JVM that ran bytecode but never checked array accesses. This sort of stuff may be useful for debugging or academic purposes, but it's not something one can do without redefining what it means to be Java.

Here is some technical background on the subject:

Abstract

This paper reports results from wireless chip to chip communication experiments. Sixteen bit words pass from one chip to another in parallel without detectable error at 1.35 billion data items per second for a total data rate of 21.6 Gigabits per second. The experiment transmits pseudo random patterns between chips built in 350nm CMOS technology. Chips touch face-to-face to communicate. The same pseudo random data pattern is loaded onto both chips so that the receiving chip can check the accuracy of every bit communicated. Each communication channel consumes a static power of 3.6 milliWatts, and a dynamic power of 3.9 picoJoules per bit communicated. The channels lie on 50 micron centers. Because the capacitive communication works through covering oxide, ESD protection is unnecessary. Vernier position measuring circuits built into the chips indicate the relative position of transmitting and receiving arrays to assist mechanical alignment. The test chip includes a Vernier circuit that provides inter-chip position measurements with a resolution of 1.4 microns.

Background

On-chip performance has been increasing much more rapidly than off-chip communication bandwidth because both on-chip transistor density and clock frequency are increasing faster than off-chip input/output (I/O) density and frequency [2]. This difference occurs because off-chip bonding and wiring are about two orders of magnitude larger than on-chip wiring. On-chip wiring pitch is on the order of 1 micron, while off-chip wiring and ball-bond pitches are on the order of 100 microns. The performance gap between on-chip and off-chip bandwidth makes off-chip bandwidth a performance bottleneck.
Fig. 1 shows a comparison of the density of I/O pads for proximity communication versus area ball bonding [2]. Because proximity communication structures use the lithographic pitch of on-chip wires, proximity communication can achieve a density about 60 times greater than area ball bonds.

Proximity Communication

Proximity communication is based on the observation that faster, lower-cost communication is possible over shorter distances. We name this communication method "Proximity" because chips are placed in a face-to-face arrangement with the transmitter and receiver circuits aligned with only microns of distance between them.
Fig. 2 illustrates two chips positioned for proximity communication. Because the transmitter and receiver are close to each other and communicate by capacitive coupling rather than through large off-chip wires, the transmitter and receiver circuits are small. Moreover, the transmitter and receiver pads are protected from exposure to electrostatic discharge (ESD) events by the top layer dielectric and passivation. Thus the transmitter and receiver omit ESD protection, further reducing the parasitic capacitance and power consumption.
We chose to couple the transmitter pads directly to the receiver pads [1][5], in contrast to [3][4] in which the transmitter couples to a multi-chip module (MCM) substrate trace which couples in turn to a receiver pad. Coupling the transmitter pad directly to the receiver pad provides a stronger signal, improving signal integrity and reducing power.

Alignment

Alignment is a critical issue. Misalignment reduces received signal strength by reducing coupling area and increasing distance. Cross-talk also increases with misalignment because the voltage swings on adjacent transmitter and receiver pads couple into the receiver pad. In order to couple the transmitter and receiver pads best, the pads must be placed in correct alignment. Fig. 3 shows the six alignment dimensions, three translational and three rotational.
We use an on-chip Vernier measurement system to measure the relative positions of two chips in the x, y, and dimensions. Verniers are common in mechanical systems, and a micro electro-mechanical system (MEMS) Vernier strain gauge has demonstrated a resolution of 10 nm [6].

Have fun...

As pointed out by jdb2 here

Probably best to go read Sun's paper on the topic.

I understand that there are many programs out there that use ./configure make make install. But the LSB has already proposed a standardized package managment system to be used across distributions.
This way the instalation of a program will be the same as windows: a double click of the rpm file.

However, after installation I believe that there are some issues about how the program should be made available to the user. This is an area that needs more standarization.
Some add a directory to the GNOME/KDE menu.
Other programs programs install a program to a directory in $PATH. Others don't make any chances and force the user to find the program and make changes accordingly.

In order to help linux make it to the desktop market, package management should eliminate the problem of. "Ok, the program is installed, what do I do next? How do I use it?" A possible extention is to enforce an additional "user discovery" such as a standardized start menu, a "most recently installed programs" directory, a unread README files, etc. etc.

http://zdnet.com.com/2100-1104_2-5188012.html I googled for "Sun microsoft patents". First hit.

Perhaps you should read the URLs you google? Nothing in there says anything about Sun suing Microsoft over Java patents.

You might also consider reading this.

Don't chastise people for spreading Microsoft .NET FUD from your high horse while you go about spreading Java FUD.

Why do so many people around here seem to think that Java is more free than .Net? This is far from true.

Java is just as patent-encumbered as .Net is. Hell, Sun sued *Microsoft* over some Java patents shortly ago. Who is to say they wouldn't do the same to gcj if it served their interests?

In fact, it is argueable that it is moreso since a single, commercial body controls it (Sub) whereas with .Net at least you have a standards body (ECMA) who has ratified the spec, which means that an independant implementation of the spec API (Mono) is less likely to have problems than an independant implimentation of the Java API.

The reality is that everyone is against .Net soley because it is made by MS. Yay for groupthink!.

Regarding pmap, I meant something comparable to Solaris pmap, not the limited Linux pmap. On Solaris, pmap can display unresolved dynamic links, hardware page sizes, swap information, etc. And on Solaris 10, pmap will explicitely label the stack, can work on a core file,

Regarding ppgsz, I know that x86 chips do support multiple page sizes - Linux 2.6 includes so-called "hugetlbfs" support, but this works by allocating a fixed number of 2 MB pages. You can't set the page size on a per-process level, like you can on Solaris. Without the ability to do this, oprofile's TLB output isn't so useful. See this article on Sun Blueprints for how Solaris handles it.

Regarding pmap, I meant something comparable to Solaris pmap, not the limited Linux pmap. On Solaris, pmap can display unresolved dynamic links, hardware page sizes, swap information, etc. And on Solaris 10, pmap will explicitely label the stack, can work on a core file,

Regarding ppgsz, I know that x86 chips do support multiple page sizes - Linux 2.6 includes so-called "hugetlbfs" support, but this works by allocating a fixed number of 2 MB pages. You can't set the page size on a per-process level, like you can on Solaris. Without the ability to do this, oprofile's TLB output isn't so useful. See this article on Sun Blueprints for how Solaris handles it.