get CPU info, RAM info

[Arne Vajhøj]

On 4/12/2010 4:54 AM, Roedy Green wrote:
The OS-specific parts of the JRE [1] are, of course, precisely
stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Roedy, you should get out more. ;-)

The C and POSIX standards define a lot. And most platforms are
either compliant or close.

Perhaps this has changed since I worried about this stuff, but at one time
"POSIX compliant" meant "A simple-minded test suite could be made to compile
and run", not that you'd actually use the POSIX interfaces for anything that
mattered.

POSIX is pretty thin in many contexts. Way smaller than the
Java library.

It is not sufficient to create portable applications in general.

But for the topics mentioned "File i/o, networking" I think it
will do very well.

Arne

 

[Eric Sosman]

On 12-04-2010 08:44, Eric Sosman wrote:
On 4/12/2010 4:54 AM, Roedy Green wrote:
The OS-specific parts of the JRE [1] are, of course, precisely
stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Roedy, you should get out more. ;-)

The C and POSIX standards define a lot. And most platforms are
either compliant or close.

Perhaps this has changed since I worried about this stuff, but at one
time
"POSIX compliant" meant "A simple-minded test suite could be made to
compile
and run", not that you'd actually use the POSIX interfaces for
anything that
mattered.

POSIX is pretty thin in many contexts. Way smaller than the
Java library.

It is not sufficient to create portable applications in general.

But for the topics mentioned "File i/o, networking" I think it
will do very well.

It seems to me that "{Java,POSIX} can do {files,nets} on all
systems" is being mis-read as "{Java,POSIX} can do all kinds of
{files,nets}." My point -- and it's not new, nor complicated --
is that the former is achieved by making the latter untrue. Again,
two of my counter-examples: Where are the {Java,POSIX} interfaces
for {resource forks,DECnet}?

The response "Who needs 'em?" may cover a lot of cases, but
it surely does not cover all.

 

[Roedy Green]

Roedy, you should get out more. ;-)

They all have tree structured directories. They all treat files as
blobs of bytes, randomly accessible. They all support a basic set of
attributes.

Windows has its drive letters. There is the complication of symbolic
links.

In the olden days the OS handled various types of keyed lookup, with
quite eccentric interfaces. There were many kinds of databases besides
SQL.

 

[Martin Gregorie]

They all have tree structured directories. They all treat files as
blobs of bytes, randomly accessible. They all support a basic set of
attributes.

Sorry, but that's not altogether true. Off the top of my head I know
three systems (IBM mainframes and i series [i.e. AS/400], Guardian non-
stop) that don't use hierarchic file systems. All three use the older
named extent/file/subfile model where there is no hierarchic concept at
either extent or file level (both are flat lists) and where all the
subfiles in a file not only form a flat list but also hold the same type
of data, defined by a file-level descriptor.

Windows has its drive letters. There is the complication of symbolic
links.

OS-9 and VMS also have separate trees on each disk, unlike Unices, but
only the Unices support symbolic links or multiple hard links per file.

In the olden days the OS handled various types of keyed lookup, with
quite eccentric interfaces.

Thats still alive and well - i series buries that in the OS, connected to
the file via the descriptor.

 

[Mike Schilling]

They all have tree structured directories. They all treat files as
blobs of bytes, randomly accessible. They all support a basic set of
attributes.

Sorry, but that's not altogether true. Off the top of my head I know
three systems (IBM mainframes and i series [i.e. AS/400], Guardian
non- stop) that don't use hierarchic file systems. All three use the
older named extent/file/subfile model where there is no hierarchic
concept at either extent or file level (both are flat lists) and
where all the subfiles in a file not only form a flat list but also
hold the same type of data, defined by a file-level descriptor.

Windows has its drive letters. There is the complication of symbolic
links.

OS-9 and VMS also have separate trees on each disk, unlike Unices, but
only the Unices support symbolic links or multiple hard links per
file.

VMS also supports files that appear in multiple directories, or at least did
back when I last used it.

Thats still alive and well - i series buries that in the OS,
connected to the file via the descriptor.

VMS also supports files that are not simply lists of bytes, including both
the simple case of sequential files with defined record lengths and the more
complex one of indexed files. In neither of these does seeking to an
arbitrary byte offset make sense.

 

[Martin Gregorie]

They all have tree structured directories. They all treat files as
blobs of bytes, randomly accessible. They all support a basic set of
attributes.

Sorry, but that's not altogether true. Off the top of my head I know
three systems (IBM mainframes and i series [i.e. AS/400], Guardian non-
stop) that don't use hierarchic file systems. All three use the older
named extent/file/subfile model where there is no hierarchic concept at
either extent or file level (both are flat lists) and where all the
subfiles in a file not only form a flat list but also hold the same
type of data, defined by a file-level descriptor.

Windows has its drive letters. There is the complication of symbolic
links.

OS-9 and VMS also have separate trees on each disk, unlike Unices, but
only the Unices support symbolic links or multiple hard links per file.

VMS also supports files that appear in multiple directories, or at least
did back when I last used it.

Thats still alive and well - i series buries that in the OS, connected
to the file via the descriptor.

VMS also supports files that are not simply lists of bytes, including
both the simple case of sequential files with defined record lengths and
the more complex one of indexed files. In neither of these does seeking
to an arbitrary byte offset make sense.

Yeah, I forgot to comment on that the ability to seek to a byte offset.
The i series source text files hold 80 byte fixed length records though
they aren't indexed. Same probably applies to Z series though not to
Guardian. However, all three systems support ISAM (indexed sequential)
files as natively supported types. They are a natural fit with a number
of languages, notably COBOL, RPG and PL/1.

 

[Arne Vajhøj]

They all have tree structured directories. They all treat files as
blobs of bytes, randomly accessible. They all support a basic set of
attributes.

Sorry, but that's not altogether true. Off the top of my head I know
three systems (IBM mainframes and i series [i.e. AS/400], Guardian
non- stop) that don't use hierarchic file systems. All three use the
older named extent/file/subfile model where there is no hierarchic
concept at either extent or file level (both are flat lists) and
where all the subfiles in a file not only form a flat list but also
hold the same type of data, defined by a file-level descriptor.

Windows has its drive letters. There is the complication of symbolic
links.

OS-9 and VMS also have separate trees on each disk, unlike Unices, but
only the Unices support symbolic links or multiple hard links per
file.

VMS also supports files that appear in multiple directories, or at least did
back when I last used it.

It still does.

But it is not used much.

VMS also supports files that are not simply lists of bytes, including both
the simple case of sequential files with defined record lengths and the more
complex one of indexed files. In neither of these does seeking to an
arbitrary byte offset make sense.

Instead it is possible to seek by RFA, which is similar to how
fgetpos/fsetpos work unlike ftell/fseek.

Arne

 

[Eric Sosman]

[...]
VMS also supports files that are not simply lists of bytes, including both
the simple case of sequential files with defined record lengths and the more
complex one of indexed files. In neither of these does seeking to an
arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed. Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

Next time someone asks "How can I delete some data in the
middle of a big file?" and you answer "Copy the whole file but
omit the doomed data," consider that VMS' Random and Indexed
organizations support delete-in-the-middle directly (for suitable
notions of "middle"). I mention this for the benefit of anyone
who might think it "eccentric" to want to avoid copying and re-
copying an enormous file just to erase a little data.

 

[Mike Schilling]

[...]
VMS also supports files that are not simply lists of bytes,
including both the simple case of sequential files with defined
record lengths and the more complex one of indexed files. In
neither of these does seeking to an arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed. Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

And really, only sequential with stream/LF recordtype works well. You can
read variable-length records, but AFAIK you can't write them. (Making each
"write" call create a new record would be alien to the spirit of the
OutputStream interface, in which the only different between writing an array
of bytes and writing the contents of the array one by one is (possibly)
efficiency.)

 

[Eric Sosman]

[...]
VMS also supports files that are not simply lists of bytes,
including both the simple case of sequential files with defined
record lengths and the more complex one of indexed files. In
neither of these does seeking to an arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed. Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

And really, only sequential with stream/LF recordtype works well.

As I recall, we got a pretty good match for C's notions of
file I/O by using StreamLF for "text" files and Undef for "binary"
files.

And really, only sequential with stream/LF recordtype works well. You can
read variable-length records, but AFAIK you can't write them. (Making each
"write" call create a new record would be alien to the spirit of the
OutputStream interface, in which the only different between writing an array
of bytes and writing the contents of the array one by one is (possibly)
efficiency.)

Right. And if VAR records are hard for Java to manage, VFC
records are *utterly* outside the model. This is the sort of
capability loss I had in mind when I wrote that Java's I/O is a
"least common denominator:" Many systems can support Java's
simplistic notions of I/O, but many systems also support I/O
flavors Java just won't grok. The unending compromise: power
versus portability.

 

[Arne Vajhøj]

[...]
VMS also supports files that are not simply lists of bytes, including
both
the simple case of sequential files with defined record lengths and
the more
complex one of indexed files. In neither of these does seeking to an
arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed.

No - it is: sequential, relative and indexed.

Random access (as opposed to sequential access) is
possible to all file organizations.

> Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

As the only language (of those that I know) on VMS then
C IO only has full support for sequential files. Of course
access to the other organizations are possible using
VMS specific libraries.

And yes Java inherited that - and using the VMS libraries
requires use of JNI (I have a nice lib for indexed
files if anyone is interested).

Next time someone asks "How can I delete some data in the
middle of a big file?" and you answer "Copy the whole file but
omit the doomed data," consider that VMS' Random and Indexed
organizations support delete-in-the-middle directly (for suitable
notions of "middle"). I mention this for the benefit of anyone
who might think it "eccentric" to want to avoid copying and re-
copying an enormous file just to erase a little data.

Indexed is really a little database in itself.

I believe that some IBM OS'es have similar functionality.

Arne

 

[Arne Vajhøj]

Typo - the word "Java" accidentally pasted randomly into that phrase.

That typo made it on topic ...



Arne

 

[Lew]

That typo made it on topic ...

Cute, but I thought it was the comment, "I see that there is a robust hard
real-time Java (pre-5) implementation for QNX.
"<http://www.aicas.com/qnx>"
that made it on topic.

 

[Martin Gregorie]

It is: sequential, relative and indexed.

Random access (as opposed to sequential access) is possible to all file
organizations.

Indexed is really a little database in itself.

I believe that some IBM OS'es have similar functionality.

I think all mainframes from that period had more or less the same
capabilities for accessing records in a disk file. I used ICL kit (first
1900 series and then 2900 series). These offered the following access
methods:

sequential - variable length records, prefixed with a length word
stored in arrival sequence.
self-indexed - fixed length records, retrieved by record number
indexed - fixed length records, retrieved by a key field, stored
in key sequence and accessed via a distributed index
random - fixed length records, retrieved by a key field,
stored via a hash of the key

All four organisations could be read sequentially.

In that era files tended to occupy fixed places on a disk: the 1900's
basic file allocation amounted to partitioning the disk and treating each
partition, which was named for access, as a file. Source and executables
were kept in 'subfiles' - variable sized chunks of a file. Only the
George 3 OS had the sort of hierarchic filing system that we now expect.

 

[Eric Sosman]

No - it is: sequential, relative and indexed.

Thanks for the correction. (As I said, my VMS work was
long ago, and my gray cells suffer a few parity errors.)

 

[Mike Schilling]

Thanks for the correction. (As I said, my VMS work was
long ago, and my gray cells suffer a few parity errors.)

A VAX would have corrected those, or at least detected them.

 

[Stanimir Stamenkov]

Thu, 15 Apr 2010 21:28:43 +0000 (UTC), /Martin Gregorie/:

only the Unices support symbolic links or multiple hard links per file.

Windows with NTFS supports file hard links and directory symbolic
links since Windows 2000:

http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil_hardlink.mspx
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

AFAIK Windows 7 supports file symbolic links, also.

 

[Arne Vajhøj]

I think all mainframes from that period had more or less the same
capabilities for accessing records in a disk file. I used ICL kit (first
1900 series and then 2900 series). These offered the following access
methods:

sequential - variable length records, prefixed with a length word
stored in arrival sequence.
self-indexed - fixed length records, retrieved by record number
indexed - fixed length records, retrieved by a key field, stored
in key sequence and accessed via a distributed index
random - fixed length records, retrieved by a key field,
stored via a hash of the key

All four organisations could be read sequentially.

And there were often pretty good language support for
those accesc methods in Cobol, Fortran, Pascal etc..

Arne

 

[Arne Vajhøj]

Arne Vajhøj wrote:
On 12-04-2010 08:44, Eric Sosman wrote:
On 4/12/2010 4:54 AM, Roedy Green wrote:
The OS-specific parts of the JRE [1] are, of course, precisely
stuff that's
been tweaked to work on all supported platforms.

File i/o, networking etc are basically the same on all platforms.

Roedy, you should get out more. ;-)

The C and POSIX standards define a lot. And most platforms are
either compliant or close.

Perhaps this has changed since I worried about this stuff, but at one
time
"POSIX compliant" meant "A simple-minded test suite could be made to
compile
and run", not that you'd actually use the POSIX interfaces for
anything that
mattered.

POSIX is pretty thin in many contexts. Way smaller than the
Java library.

It is not sufficient to create portable applications in general.

But for the topics mentioned "File i/o, networking" I think it
will do very well.

It seems to me that "{Java,POSIX} can do {files,nets} on all
systems" is being mis-read as "{Java,POSIX} can do all kinds of
{files,nets}." My point -- and it's not new, nor complicated --
is that the former is achieved by making the latter untrue. Again,
two of my counter-examples: Where are the {Java,POSIX} interfaces
for {resource forks,DECnet}?

The response "Who needs 'em?" may cover a lot of cases, but
it surely does not cover all.

There are certainly a lot of IO and network stuff not
covered by POSIX.

But Roedy started the "standard in C" subthread by
referring to "File i/o, networking" in a reply to where
Mike were referring to "The OS-specific parts of the JRE".

Because the JRE does not support DECnet and resource forks,
then those does not counter a claim that the IO and network
in Java should be reasonable POSIX standard.

(my guess is that there are a few pronlems anyway - there
usually are when porting C)

Arne

 

[Arne Vajhøj]

On 4/15/2010 5:35 PM, Mike Schilling wrote:
[...]
VMS also supports files that are not simply lists of bytes,
including both the simple case of sequential files with defined
record lengths and the more complex one of indexed files. In
neither of these does seeking to an arbitrary byte offset make sense.

Long ago when I worked with VMS, it supported three "file
organizations:" Sequential, Random, and Indexed. Of these, only
Sequential fit into the I/O model (or straitjacket) adopted by C
and later by Java.

And really, only sequential with stream/LF recordtype works well.

As I recall, we got a pretty good match for C's notions of
file I/O by using StreamLF for "text" files and Undef for "binary"
files.

Those are the logical choices. But the VMS traditional way is to
use fixed 512 for binary.

Right. And if VAR records are hard for Java to manage, VFC
records are *utterly* outside the model.
Indeed.

This is the sort of
capability loss I had in mind when I wrote that Java's I/O is a
"least common denominator:" Many systems can support Java's
simplistic notions of I/O, but many systems also support I/O
flavors Java just won't grok.

True.

But when Java or at least Java EE came to existance, then databases
had already replaced "more flat" files as the primary data storage.

There were simply not a big need.

The unending compromise: power
versus portability.

So true.

Arne