Slashdot Mirror

Software standards such as Apache or Linux

Linux is not a "standard." POSIX is a standard, which Unixes (Linux too) follow.

The article incorrectly states that PAM (Pluggable Authentication Modules) came out of Project Athena.

However, it was actually invented by Sun, and was eventually adopted as RFC 86.0 by the Open Software Foundation in 1995.

Check out the Jericho Forum - a group of major companies who also recognise that the role of the network perimeter firewall is becoming less relevant and an obstacle to business demands:

The Jericho Forum is an international forum of IT customer and vendor organisations who recognize that over the next few years, as technology and business continue to align closer to an open, Internet-driven world, the current security mechanisms that protect business information will not match the increasing demands for protection of business transactions and data in the future. Existing perimeters are full of holes. The 'walls' are crumbling. Managing the problems using today's security solutions is increasingly expensive and time-consuming.

A new approach is needed, to move from the traditional network perimeter down to the individual networked servers and devices - and ultimately to the level of the data being sent over the networks. The Jericho Forum aims to drive and influence development of security solutions, based on open standards, that will meet future business needs for secure interoperation of information systems to support collaboration and commerce over open networks, within and between organisations, based on a security architecture and design approach which the Forum calls de-perimeterisation.

Next major meeting is in Sydney on September 8th - join in the debate!

Sure, OpenOffice is great, but commercial enterprises will stick with commercial solutions for which there is support.

I don't exactly get what you mean by support. My impression from the people and businesses I know personally is that Microsoft Office format is a big success not because of "support", but because there's a wealth of products built around it by third parties.
These 3rd-party products are crucial for the enterprise, stuff like Eletronic Content Management, being able to create document workflow and revision systems, and groupware. All this stuff integrates seamlessly with the Windows desktop and the Windows office applications. In any enterprise with a huge amount of paper and workflow, document management systems are a necessity. This is point OpenOffice proponents frequently forget: office applications are not about just the single desktop user but they are also about integrating seamlessly in an eco-system of content management software provided by theird-parties and accessing legacy documents. For instance, in my country, Brazil, legislation demmands that certain financial documents be stored for a period that outruns any document format you might have seen. This means people have to migrate very old sofware document records.
This is an area ISV working on open-source platforms could explore, an unexplored niche market. AFAIK, not even COLD solutions exists and COLD goes way back decades (ever since computers started processing bills.) And there are no equivalents of proprietary software in the open-source market (this shows you that open source developers are sometimes out of touch with their would-be customer base). People are developing groupware, but there are no ECM (Enterprise Content Management) solutions. Groupware, ERM, and ECM are the bulk of enterprise software.
If only the open-source community would take something like OpenOffice, or further develop AbiWord (which has nice plug-in functionalities), and integrate these with Mono, you would have made a serious dent in the Windows dominance. I mean, who wouldn't want to avoid expensive per-seat Microsoft licenses, plus per-seat ECM licenses? And software houses that provide ECM solution (e.g., the market leader OnBase) work with year-round support and customization, and we know this is a way of doing business that is viable for open-source (of course, they have per-seat licenses).
BTW, I really mean Mono, and not Java. Java is not an alternative on the long term, not only because of the Java's proprietary nature, but because Mono is gearing itself towards Windows-*Nix interoperability, to the point where software build with Windows.Forms will work on Mono. Additionally, having to depend on Sun's finances is a a suicidal investment of resources.
But open-source has major hurdles: it nees to standardize on OpenGroup and LSB That is to say, the Free Standards Group has to advanced by libre *Nix distros and vendors, so that software developers have an easier time with all the distros. De Icaza wrote something about this in this essay. Linux distros need to be reliable in terms of time frame for releases (which the commercial ones are), too.
My feeling is that Microsoft has foreseen a trend going against its closed-source format (OASIS, the Massachusetts imbroglio) and anticipated any possible open-source incursion in the field of content management. If these formats are truly opened, they've raised the bar for the arguments of any future switching to FOSS platforms+OO.org solutions (because, right now, as I've argued, there are no FOSS replacements for content management for the enterprise AFAIK, and there's a huge amo

The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes. The nature of the transfer is implementation-defined.

If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell the user what can be expected from the system. It is explicitly intended that a null implementation is permitted. This could be valid in the case where the system cannot assure non-volatile storage under any circumstances or when the system is highly fault-tolerant and the functionality is not required. In the middle ground between these extremes, fsync() might or might not actually cause data to be written where it is safe from a power failure.

The most common data model in C for 64 bit programming is LP64. In this model, longs and pointers are 64 bits while ints are still 32.

In Java longs are already 64 bits which basically makes Java code 64 bit ready. If there is going to be any troubles, it will be with sloppy C code that assumes sizeof(int) == sizeof(long).

Even worth learning ADL (:-))

--dave

There are many ways to skin the cat.

The reason Microsoft chose LLP64 to ensure transparent portability between 32 and 64 bit compiles of Win32 apps. That was the most important consideration in their mind. I wouldn't call Microsoft's choice "stupid", but practical. There are very few applications for a 64 bit integer - it would just be wasted space most often, and it complicates portability between 32 and 64 bit compiles.

The reasons the Unix crowd went LP64 (sizeof(long) == 8) is they felt LLP64 requires extensive modifications to existing specifications to support those places which should naturally become 64-bit wide. In other words, they wanted APIs to natuarally grow to 64 bit.

All Microsoft APIs, and most third party APIs already use "Windows" types (BYTE, WORD, DWORD, QUADWORD, LPDWORD, etc) that are a fixed size. This is partly due to the fact that these DLLs are linked from many languages (VB, Pascal, C). They are not very C centric. Also, we are not used to recompiling everything to use a library: we likely don't have the source. We have to link carefully. Ints and longs won't do.

I do think Microsoft's choice (LLP64) fails to follow the spirit of Stroustrup's C++ standard that: "Plain ints have the natural size suggested by the architecture of the execution enviorment."

I personally have found myself avoid long in the last 5 years. After living through the 16 to 32 bit migration, I favor int32, int64, size_t, wchar_t, etc. You just can't count on the sizeof(long). I still use int, but just for counting and indexing within functions and methods, when I know my application won't come close to needing even 16 bits. If I need more than that, I use size_t.

Well, if you need an int of a particular size, you need to typedef yourself a compiler/platform specific one anyway; this has always been that way.

int{N}_t uint{N}_t
int_least{N}_t uint_least{N}_t
int_fast{N}_t uint_fast{N}_t
intptr_t uintptr_t
intmax_t uintmax_t
INT{N}_MIN INT{N}_MAX UINT{N}_MAX
INT_LEAST{N}_MIN INT_LEAST{N}_MAX
UINT_LEAST{N}_MAX
INT_FAST{N}_MIN INT_FAST{N}_MAX UINT_FAST{N}_MAX
INTPTR_MIN INTPTR_MAX UINTPTR_MAX
INTMAX_MIN INTMAX_MAX UINTMAX_MAX
PTRDIFF_MIN PTRDIFF_MAX
SIG_ATOMIC_MIN SIG_ATOMIC_MAX
SIZE_MAX WCHAR_MIN WCHAR_MAX WINT_MIN WINT_MAX
INT{N}_C(value) UINT{N}_C(value)
INTMAX_C(value) UINTMAX_C(value)

As somebody else noted, c99 also supports long long. Of course older compilers don't have stdint.h. I don't think Microsoft C does either, although I don't have the latest version.

Go check for yourself.

Most of registered ones are RH and Novell/SUSE, with a few others like Mandrake, SGI and Sun JDS.

See it is just the reverse of your hypothesis. It is only the commercial interests that are interested. That and you need to support the Red Hat way of file system and init and RPM.

The minors only get to play if they pony up some bucks (negligible for a Corp but significant for a non-profit volunteer org) and change things so they are done the RH way. It involves significant changes for any non-RPM based distro to get certified.

The ones that don't still use the LSB and FSH (File System Hierarchy) test suites, like Debian does.

So, exactly what distributions are we complaining about? Seems like the LSB and the FSH standard are seeing pretty widespread adoption to me!

I didn't find this info on the Open Group's website...

Have a look here: http://www.opengroup.org/lsb/cert/docs/LSB_Fee_Sch edule.html

If its LSB version X runtime environment Y compliant, it will run on any distro that is LSB version X runtime environment Y compliant.

X being the version (currently 2.0) and Y being the architecture (like IA32/X86)

Here is the LSB 2.0 Runtime Environment IA32 standard: http://www.opengroup.org/lsb/cert/docs/PS_2.0/LSB_ Runtime_Environment_IA32_20_PS.html

ActiveX has been steered by The Open Group since Microsoft handed over control in 1996. See the COMsource page for details of the COM/DCOM implementation for UNIX, etc.

> something that isn't a standard, will never be a standard and would be completely undesirable as a standard

I don't really want to get into this argument, but ActiveX is actually a documented standard.

Furthermore, COM/ActiveX is a core Windows OS technology which makes it a lot more "standard" than Mozilla plugins or XPI (aka Mozilla's clone of ActiveX).

You missed copying the first sentence of that paragraph: "Some say that Windows NTFS does not really offer a journaled file system." Nice FUD there.

That might be trying to say that NTFS doesn't journal file data, which is the case for almost all journaling file systems (or alternatives such as FreeBSD's Soft Updates). Those that do have that feature never enable it by default: the cost is simply too great.

File system integrity (i.e. metadata) is the job of the OS and the filesystem. Data integrity is the job of the application (until it has told the OS to commit the data to the disk, i.e. fsync in POSIX or FlushFileBuffers in Win32). The OS can't attempt to do that on a general level without greatly inhibiting performance for everything. That said, it would be very useful to have a journaling API available that applications could use.

http://www.microsoft.com/windowsserver2003/communi ty/centers/fileservices/fileservices_faq.mspx

More realistically Linux is the kernel which is in the more technical sense the OS (OS is the software layer which manages the software, this line is not easy to draw in every OS, but with linux it is pretty clear).

An operating system is more than a kernel. Take a look at the Single Unix Specification and see what sort of things an operating system specification deals with.

If we consider terms like "Unix" and "POSIX" to be terms relating to operating systems (and we do), then the GNU system must also be considered an operating system.

GNU makes some nifty software that happens to be in the list of applications that Redhat distributes along with the Linux OS.

Incorrect. In 1984 - long before Linux was a gleam in Linus's eye - the GNU project set out to write a complete Unix-like free software system.

By the early 90s, every piece of this operating system was in place except the kernel. People started droping Linux into the center of the system and bam!, GNU/Linux

Also, we are somewhat cautious about what happened with Unix - it splintered into eight applications -- until McNealy (Scott McNealy, chief executive of Sun) finally announced he won the battle and had the one surviving Unix out there.

Interesting that EDS shares SUN's view of what Unix versions are available. Imagine how surprised HP, IBM, and even SCO will be to learn that SUN has the one surviving Unix, considering:

The OS registered as compliant with the UNIX 03 specification is: AIX

Other "surviving" Unixes that are registered by the Open Group include, well, look for yourself... http://www.opengroup.org/openbrand/register/catalo g.htm

It bugs the heck out of me also. Fiddling with crazy and inconsistant directory structures gets in the way of doing the real work.

Debian follows the LSB pretty well. RedHat Enterprise also seems to do ok.

I think most of the modern major distros use the FHS. At least, they are certified by the LSB, but I don't know if that means they strictly follow the LSB.

In my experience, most of the modern distros follow the LSB pretty well. Most of the confusion with the directory structure has to do with old distros, legacy products, and third party products who won't comply the LSB.

true, but i can't imagine that they couldn't do it with an int[] or something like it: hell, even c has int rand(void) which could fill an array and i imagine is in the c libs used by apple. not that i'd know how to do it in c though.

Woops, forgot to post my source for the code:
http://www.opengroup.org/onlinepubs/009695399/func tions/rand.html

Microsoft's file sharing uses NETBIOS for naming, etc, but there are other elements to it, too. Microsoft published a draft to the IETF for CIFS (formerly SMB). It's only a subset of the functionality that Windows actually supports, and it was chock full of errors and omissions. There were also several books written about SMB. The earliest I can find is Protocols for X/Open PC Interworking: SMB, Version 2, published October 1992. The first version may have been published more than two years earlier, in January 1990, but I'm having difficulty finding that information. The Samba site says that the first version, developed in 1992, was based on reverse engineering the wire protocol of the MS-DOS SMB client. The later versions may have made use of this other documentation.

IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.

Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).

One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.

Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX . Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.

The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.

Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.

When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.

If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.

Repost

IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.

Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).

One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.

Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX . Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard basealso offer a cross vendor foundation.

The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.

Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.

When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.

If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.

Repost

Not a bug a feature... to generate message Ids that are traceable back to originating machine...

Not a feature an idea that perhaps seemed OK at the time... to generate unique message IDs based on an existing type of unique identifier that happened, in the original format defined for it, to use an IEEE 802 MAC address, presumably because those are intended to be unique to a piece of hardware, so the rest of the UUID merely has to be a value that will never be used again on a system where that MAC address is used to generate UUIDs.

The current Internet-Draft for a URN namespace for UUIDs mentions another scheme to generate UUIDs in that format that don't use a hardware MAC address but that won't collide with UUIDs generated from MAC addresses for hardware (by turning on the bit that would be the multicast bit in an 802 MAC address).

IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.

Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).

One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.

Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.

The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.

Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.

When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.

If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.

IMO the latter vendor dependent death march is the the major outside factors for the failure of large software projects. In most cases, in house development teams just cannot keep up with the vendor brand-new-innovative-reason-to-upgrade "features" of each release.

Larger in-house projects take around one to three years to mature, and need around a seven year window to recover the ROI. Porting existing software to the vendors new system often takes more effort than the development of the original software ( pity the Visual Basic coders who have to upgrade millions of lines of VB to VB.NET ).

One solution to the Vendor Dependent Death March is to build upon stable vendor independent foundations, augmented with open sourced software.

Over the two decades one api set has remained relatively constistantly implemented by all OS vendors : POSIX. Linux and all of the Unix based systems implement native APIs that follow the POSIX standard closely, and some offer fully compliant libraries as an add on. The Linux standard base also offer a cross vendor foundation.

The above solid foundation can be safely augmented using open source licensed software, by being rebuilt in house so that it runs from subdirectories of the project ( /opt/[organization]/[project]/[package] ). The distribution/OS Vendor can then ship conflicting versions of dependent packages without it breaking the project code. The in house developers can then test and port to the new version at their leisure.

Vendor dependent user interface systems are fickle and often are the braking point for many failed in house projects. The solution is to build client/server code that uses a standard browser interface or use a standard GUI networked interface that has remained backwardly compatable to application written back in 1986: The X[11] Protocol. You can have a X based application running on a server sitting behind an internal firewall and it will run productively for over a decade. Every OS platform has multiple vendors who supply X11 client side servers, this is one interface that is futureproof.

When interfacing with any changeable or vendor specific system , build a connecting system that runs as standalone binary ( or plugin DDL ) that sits between the project code and the application/library. Future developers can quickly hack the independent module without touching the base project source code. This strategy has saved my sanity a number of times.

If at all possible ( subject to NDAs ) develop as much of the code as possible as an open source project. Even if only a couple of other individuals or organizations end up deploying software from the same base, it will give your developer and managers feedback from outside developers who often more free of the inside office politics to give a more honest opinion on the quality of the source code.

If they give you a skills test, they'll often ask you about the most cryptic-looking functions that are necessary in programming like htonl(), strtoul(), atoi(), and the like. Also make sure you understand how (void *) works and how to pass pointers to functions. People love this crap. Unless they're more into software engineers than programmers. Then you better pull out your C++ books and remember how all of the variations on virtual methods work.

If they give you a skills test, they'll often ask you about the most cryptic-looking functions that are necessary in programming like htonl(), strtoul(), atoi(), and the like. Also make sure you understand how (void *) works and how to pass pointers to functions. People love this crap. Unless they're more into software engineers than programmers. Then you better pull out your C++ books and remember how all of the variations on virtual methods work.

If they give you a skills test, they'll often ask you about the most cryptic-looking functions that are necessary in programming like htonl(), strtoul(), atoi(), and the like. Also make sure you understand how (void *) works and how to pass pointers to functions. People love this crap. Unless they're more into software engineers than programmers. Then you better pull out your C++ books and remember how all of the variations on virtual methods work.

This touches on it. I used to have some proof of concept code that did this but I cannot find it :(

Basically do a regular old DCE-RPC call to a DCOM server and just do not use any of the DCE provided security or directory calls and it will work. (at least it did in the NT 4.0 days, I'm not 100% sure about today)

Finkployd

DCE did a "proper" job by using the available fields of kerberos for the correct - documented - purpose.

the use of CDS being largely irrelevant was recognised by TOG in 1999: you need to pay IBM stacks of $$$ to get the code _but_ it was recognised: OpenGroup link here. fortunately, someone has created a set of free software plugins - nss and pam etc. already

AFS, OpenAFS, DFS - it's a long long story for another day, methinks :)

It's already been done! Also see this for details of TOG meetings etc.

Distributed COM.

Something that's been puzzling me since I first heard about an open source Solaris is to what degree it will be actual "UNIX", in the OpenGroup sense of the word. How much SVR4 code was ripped out and replaced, and are these replacements going to break compliance with the UNIX 98 certification? Will they hinder compliance with the UNIX 03 standard? Will Sun even pursue certification after the source is opened?

It's not that I'm incredibly worried, I've just always affixed Solaris as "Sun Solaris UNIX" when speaking about it, to denote compliance and compatibility in the commercial UNIX community.

BSD is UNIX. Not only that, it's one of the first UNIX certified operating systems.

I don't see BSD mentioned anywhere on the list of certified products - do you have any information on some older version of the standard, e.g. UNIX 95, for which "BSD" is certified?

I can't tell you a great deal about the early days of UNIX, but University of California at Berkeley's computer science department did a lot of work with Bell Labs to create the original UNIX.

That's not exactly how "the early days of UNIX" went. The original UNIX came from Bell Labs; people at a number of universities, research institutions, etc. had their own sets of improvements to UNIX that they distributed to other licensees. The Berkeley Software Distribution was one of them; the Fourth Berkeley Software Distribution was arguably one of the most important, if not the most important, of those, and with 4.2BSD the Berkeley contribution was arguably as important as the contemporary AT&T contributions.

But the "original UNIX" wasn't a joint effort of AT&T and UCB, although just about any modern UNIX has a significant number of BSD contributions (sockets, symlinks, etc.), whether the code came from Berkeley or was a reimplementation of stuff from Berkeley.

UNIX is a certification and registered trademark, not a single operating system.

Yes, that's what it is now, at least at the legal level, as per The Open Group's What is UNIX ®. Sometimes "UN*X" is used to refer not only to those OSes certified as "UNIX®", but to those OSes that haven't gone through the registration procedure but that are generally thought of as enough like other OSes considered "UNIX" to be worthy of the name. (I'd definitely put the major Linux distribution into the "UN*X" category, along with {Free,Net,Open,Dragonfly}BSD and OS X.)

by double-edged:
I wonder if the author left out some "secret methods" he used in the field

yes. fgrep

Okay...I'm not completely up in the inner workings of GRID computing, but is the premise the same as those used in the past for other distributed environments such as DCE (Distributed Computing Environment ) or CORBA (Common Object Request Broker Architecture)?

My experience with DCE at least was that it was a distributed environment that took a lot of coordination between systems, which unfortunately was not done very well in the environment I'm familiar with. As a result of this it did not prove robust enough for the systems it was used for. It had some possibilities, but if not done properly, can be a major confusing thing to deal with.

With CORBA, as I understand it (I've never directly worked with CORBA), it is suppose to represent similar services in a more Object Oriented way and easier to program with. Not an expert, but I believe this is ingrained into Java world along with other RMI type interfaces or peer to peer intefaces (like JXTA).

With these types of services, both DCE and CORBA offer distributed network services such as directory services, distributed file systems, and security services on hetrogenious environements. The interfaces are defined (see IDL) and compiled in to stubs for client/server services to develope and use on any compatible platform.

How is GRID different from these methods?

Eh? Who defines this stuff. BSDI? SCO? Novell? One of the perennial curses of what constitutes UNIX was the bitching betweeen the big guys.

Nowadays everybody can take part in the process of making the next revision of POSIX, see http://www.opengroup.org/austin/ for more details. From my own experience I can say that getting bugfixes in the standard isn't really that hard.

While coding in C, I mostly use http://www.opengroup.org/bookstore/catalog/t912.ht m.

I recommend browsing http://www.opengroup.org/ and http://www.unix.org/ because -- after registration -- documentation of incredibly high quality can be read online and legally downloaded for personal use. DO READ THE TERMS OF USAGE FIRST, as this is only my own personal interpretation of the conditions.

Following this link, in section "Technical Standards", you can find many documents of the Single Unix Specifications v1 (Unix95, issue 4 v2), v2 (Unix98, issue 5) and v3 (Unix03, issue 6): http://www.opengroup.org/bookstore/catalog/un.htm

Sorry for my weak English. I tried to avoid deep-linking into any of the mentioned sites.

I hope my wording and use of trademarks was compatible to what's written in http://www.opengroup.org/legal.htm, if not, my failure to do so happened against my intent.

While coding in C, I mostly use http://www.opengroup.org/bookstore/catalog/t912.ht m.

I recommend browsing http://www.opengroup.org/ and http://www.unix.org/ because -- after registration -- documentation of incredibly high quality can be read online and legally downloaded for personal use. DO READ THE TERMS OF USAGE FIRST, as this is only my own personal interpretation of the conditions.

Following this link, in section "Technical Standards", you can find many documents of the Single Unix Specifications v1 (Unix95, issue 4 v2), v2 (Unix98, issue 5) and v3 (Unix03, issue 6): http://www.opengroup.org/bookstore/catalog/un.htm

Sorry for my weak English. I tried to avoid deep-linking into any of the mentioned sites.

I hope my wording and use of trademarks was compatible to what's written in http://www.opengroup.org/legal.htm, if not, my failure to do so happened against my intent.

While coding in C, I mostly use http://www.opengroup.org/bookstore/catalog/t912.ht m.

I recommend browsing http://www.opengroup.org/ and http://www.unix.org/ because -- after registration -- documentation of incredibly high quality can be read online and legally downloaded for personal use. DO READ THE TERMS OF USAGE FIRST, as this is only my own personal interpretation of the conditions.

Following this link, in section "Technical Standards", you can find many documents of the Single Unix Specifications v1 (Unix95, issue 4 v2), v2 (Unix98, issue 5) and v3 (Unix03, issue 6): http://www.opengroup.org/bookstore/catalog/un.htm

Sorry for my weak English. I tried to avoid deep-linking into any of the mentioned sites.

I hope my wording and use of trademarks was compatible to what's written in http://www.opengroup.org/legal.htm, if not, my failure to do so happened against my intent.

While coding in C, I mostly use http://www.opengroup.org/bookstore/catalog/t912.ht m.

I recommend browsing http://www.opengroup.org/ and http://www.unix.org/ because -- after registration -- documentation of incredibly high quality can be read online and legally downloaded for personal use. DO READ THE TERMS OF USAGE FIRST, as this is only my own personal interpretation of the conditions.

Following this link, in section "Technical Standards", you can find many documents of the Single Unix Specifications v1 (Unix95, issue 4 v2), v2 (Unix98, issue 5) and v3 (Unix03, issue 6): http://www.opengroup.org/bookstore/catalog/un.htm

Sorry for my weak English. I tried to avoid deep-linking into any of the mentioned sites.

I hope my wording and use of trademarks was compatible to what's written in http://www.opengroup.org/legal.htm, if not, my failure to do so happened against my intent.

While coding in C, I mostly use http://www.opengroup.org/bookstore/catalog/t912.ht m.

I recommend browsing http://www.opengroup.org/ and http://www.unix.org/ because -- after registration -- documentation of incredibly high quality can be read online and legally downloaded for personal use. DO READ THE TERMS OF USAGE FIRST, as this is only my own personal interpretation of the conditions.

Following this link, in section "Technical Standards", you can find many documents of the Single Unix Specifications v1 (Unix95, issue 4 v2), v2 (Unix98, issue 5) and v3 (Unix03, issue 6): http://www.opengroup.org/bookstore/catalog/un.htm

Sorry for my weak English. I tried to avoid deep-linking into any of the mentioned sites.

I hope my wording and use of trademarks was compatible to what's written in http://www.opengroup.org/legal.htm, if not, my failure to do so happened against my intent.

UNIX® 03 is POSIX. It is a "common update to IEEE Std 1003.1,1996 Edition, IEEE Std 1003.2, 1992 Edition, their ISO/IEC counterparts and the previous version of the Single UNIX Specification".

In the case of uname, compare the UNIX and the IBM definitions. They look the same. In practise, the two ways it conforms to POSIX.1 yet differs from Solaris are the -m flag and the -r flag. With -m, AIX prints a hexadecimal number indicating the precise machine model rather than just the architecture (however this has become less useful on new IBM pSeries systems as "many new machines share a common machine ID of 4C"). This information can be augmented with the output of uname -M. With -r, I think only the major and minor version numbers are printed (it doesn't mention the point release since any point release should be compatible with other releases in that series). More precise information can be determined by running oslevel.

I agree it would be nicer if uname -m gave a human-readable architecture description as many other UNIX systems do, but POSIX doesn't require it be human readable or have a 1:1 mapping to CPU architecture.

Care to provide a link? I can't find anything about Apple on opengroup.org's list of Registered Products by Company.

I wondered too... It took a fair bit of poking around on the Open Group's site to find this:
http://www.opengroup.org/openbrand/Brandfees.htm

It seems that "Linux" cannot get certified... or at least, not easily.

The tests themself are mostly available free - but the certification costs around $4000 + percentage of revenue.

Now I don't know about Linus himself, but there are a fair few companies (Redhat, SuSE, Debian) who would have to each shell out to sizeable chunks to be certified... Seems like a bit much to me...

A less fiddly way to get the bitmaps is with pdfimages, which comes with xpdf. Yes it's an arcane etc. command-line program; you'll live. And don't get too excited about the legal implications, either, because the bitmaps are very low resolution (maybe 200 ppi).

Dude, go to the certified distributions list url major linux distros including Red Hat, Mandrake, and Suse are in there!!

Please check facts before posting. Too bad you got modded up.

If you use [Gentoo|Peanut|Arch|Scooby-Doo] Linux at home, then this stuff doesn't have much to do with you.