Slashdot Mirror

Well, OSX (at least 10.5 and 10.6) is certified Unix 03.

And z/OS is certified Unix 95 but it's a layer atop an OS whose native API isn't UN*X, so "it's certifioed Unix 03" isn't a sufficient refutation. ("There is no "native API" atop which Mac OS X's UNIX API is implemented" is a sufficient refutation.)

Well, OSX (at least 10.5 and 10.6) is certified Unix 03.

And z/OS is certified Unix 95 but it's a layer atop an OS whose native API isn't UN*X, so "it's certifioed Unix 03" isn't a sufficient refutation. ("There is no "native API" atop which Mac OS X's UNIX API is implemented" is a sufficient refutation.)

Well, OSX (at least 10.5 and 10.6) is certified Unix 03. It's unclear about Lion and whether Apple intends to have it certified or not.

Come on dude, we're talking about server systems here, not desktop unix which isn't exactly a "consumer" product.

Not even if somewhere around 10% of desktops and laptops are running Un*x? Heck, some of them are even running trademarked UNIX.

Come on dude, we're talking about server systems here, not desktop unix which isn't exactly a "consumer" product.

Not even if somewhere around 10% of desktops and laptops are running Un*x? Heck, some of them are even running trademarked UNIX.

No, actually Unix certification only applies to OsX 10.5 (leopard) and OsX 10.6 (snow leopard). The certification applies to each version of an operating system. http://www.opengroup.org/csq/public/search.mhtml?t=&w=apple&sort=bycomponent&display=short&pid=2958 So you cannot call OsX 10.7 (Lion ) Unix. At least not yet.

The Single UNIX Specification and POSIX require vi to exist. You may find stuff breaks in interesting ways if it doesn't...

I originally meant to say that a lot of this stuff comes from POSIX, so it's not just GNU.

Here is the description of the POSIX getdate() function:
http://pubs.opengroup.org/onlinepubs/007904875/functions/getdate.html

I was a bit too quick to assume that the date format in the POSIX touch was based on the POSIX getdate() function, which isn't true.

The GNU touch does use a getdate() function that is similar in complexity. This function is then implemented using a YACC grammar, adding to the bloat.

If someone cared, it would be easy to write a much smaller 'touch' program, without all these fancy options. Of course, nobody cares.

It does in newer versions:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/touch.html

No, touch doesn't supports that.

Don't act as if GNU bloatware is Unix. It's not, as the name implies.

According to the Open Group which owns the UNIX trademark and conduct certification, OS X 10.5 on Intel and OS X 10.6 are certified UNIX. OS X is also POSIX compliant.

Yes, I'm quite aware of that; perhaps I should've said "regardless of whether you're supposed to call it UNIX" rather than trying too hard to parallel the "even the ones I'm not supposed to call UNIX" of the person to whom I was responding.

"What's under the hood" is still UNIX (in the "even if you're not supposed to call it UNIX"

According to the Open Group which owns the UNIX trademark and conduct certification, OS X 10.5 on Intel and OS X 10.6 are certified UNIX. OS X is also POSIX compliant.

My point was simply that you cannot rely on undefined or implementation-defined behavior across implementations. Moreover, part of the purpose of a standard is to provide a centralized delineation of exactly what is defined behavior, what is implementation-defined behavior (including the set of possible implementation choices), and what is undefined behavior; this is far preferable to only having a collection of a myriad of proprietary documentation (most of which is often incomplete).

Now, help me understand your scenario.

Try this on solaris and then try it on hp-ux:

shm_open("/shm-test", O_RDWR, 0600);

It will work on solaris and fail on hp-ux because the underlying mechanism for tracking the shm namespace is undefined by posix, so different vendors have implemented it in "innovative" ways. Posix is riddled with shit like that.

Am I to assume that the shared memory object named "/shm-test" already exists? If it does not, then I would expect a failure with errno set to ENOENT, as per the POSIX:2008 (IEEE Std 1003.1-2008 Base Definitions, Issue 7) documentation.

What are you experiencing that is particularly annoying?

Even worse, it's _Bool with one underscore and uppercase B. If you #include<stdbool.h> you get a #define bool _Bool which you can undefine if you really need the bool name for your own code.

See: stdbool.h

In UNIX-land, no it isn't.

Sorry, but shipping code beats standards based theory, and pretty much every *nix vendor ships dc with the OS.

Oracle (nee Sun) Solaris, IBM AIX, HP HP/UX, SGI IRIX, Apple MacOS X, SCO Openserver, SuSE Enterprise Linux (dc listed on bc page), FreeBSD, OpenBSD ...

You also appear to missed a few things about the Open Group Base Specifications Issue 7 / IEEE Std 1003.1-2008 standard - it is in essence a floor, not a ceiling - vendors can ship more tools if they care to. Also, the discussion on bc notes that some implementations of bc are built on top of dc, and that is OK, as long as the behavior of bc is correct.

It is worth noting that dc was one of the earliest programs to run in Unix, making it in while Unix was still written in assembly language. If for some reason it was to be not only omitted, but actually excluded by the standard, it would still be found in the vast majority of shipping systems for years to come until said vendor decided to migrate their Unix system to the current standard, a process that often takes years.

So yes, for the vast majority of people using Unix, an RPN calculator is often only as far away as a shell prompt.

In UNIX-land, no it isn't.

Actually, the two most popular Unix variants -- OS X 10.5 and 10.6 -- are officially Unix.

There's nothing more obscure sounding than dumping the standard GNOME desktop and X along with it.

It's so obscure that even Apple did it when it made Mac OS X. It's a certified UNIX desktop system doesn't come with GNOME.

Plan for things to fail, and when they do, you won't be in such a panic.

As for:

on all likely relevant platforms, processes hold resources, not threads. So killing a thread doesn't do anything to help with resource management and/or reclamation.

The open group disagrees

The pthread_detach() function shall indicate to the implementation that storage for the thread thread can be reclaimed when that thread terminates. If thread has not terminated, pthread_detach() shall not cause it to terminate. The effect of multiple pthread_detach() calls on the same target thread is unspecified.

So does the Comp Sci department at Temple U pthread_detatch

You can mark for deletion and reclaim the storage and other resources associated with a thread (of course, after it has terminated executing) with the command:

#include

int pthread_detach(pthread_t thread);

This command will not terminate a thread that is executing, only indicating that we want to reclaim automatically its storage when it terminates execution. Other ways of reclaiming the resources of a thread are:

• If the thread was created with attribute set to PTHREAD_CREATE_DETACHED, or
• If this thread is waited for with a pthread_join call.

So does the Lawrence Livermore National Laboratory pthread_exit() is the way to claim thread-local data.

Regardless of the method of thread termination, any cancellation
cleanup handlers that have been pushed and not yet popped are executed,
and the destructors for any existing thread-specific data are executed.

Normally, you also write clean-up routines for closing file handles, freeing up any manualy malloc'd memory and returning it to the arena, etc.

And Apple here

Because POSIX creates threads as joinable by default, this example changes the thread’s attributes to create a detached thread. Marking the thread as detached gives the system a chance to reclaim the resources for that thread immediately when it exits.

and even the Aussies at Cardiff U agree pthread_destroy() that you can free up all memory allocated, so as long as you clean up the stuff YOU allocated, and allow the library to free up the stuff allocated at thread creation and initialization.

So, what relevant platforms don't support pthreads?

iOS is not a Unix. The only Apple operating systems that are certified Unix are Leopard and Snow Leopard, both on Intel-based Macintosh computers.

As has probably been pointed out elsewhere in this thread, Unix is a trademark of The Open Group and the list of current products that are granted the use of it are here.

It's a rather sad little list actually.

Wow, you get the award for the most ignorant post I've ever seen from someone with such a low UID.

It's certainly not a "Unix".

You're right, It's not a Unix. It's a certified UNIX, since May 18, 2007.

The shiny GUI apps are very not-Unix and have a sort of Apple NIH syndrome

Uh, you know that Apple ships X11 for OS X, right?
You know you can run OS X without the shiny GUI, or if you're really hard core, compile Darwin from source to do so, right?
You know there's plenty of more UNIX-y stuff available from MacPorts and Fink, right?

~Philly

REAL Unix

You mean like OS X? Linux and BSD are not real UNIX according to the controllers of the trademark.

http://www.opengroup.org/openbrand/register/xy.htm

MacOS is actually based on the mach kernel, and not UNIX. /pedantic

That's not pedantic, that's confused. Linux might be (pedantically) a specific kernel, but UNIX isn't. Unix is a set of higher level standards, and OSX conforms, and is officially registered as a version of UNIX.

http://www.opengroup.org/openbrand/register/apple.htm

Unlike Linux, there is no way that OSX is not UNIX, including by what kernel it uses.

Big brother Apple has decreed that mac users aren't smart enough to make their own decisions on installing updated versions java.

I think maybe paranoid rather than pedantic describes you better. This move simply puts OSX in the same position as Windows. The user can install whatever version of Java he wants. But at some point in the future, there won't be one installed as part of of the OS.

iOS is not a registered UNIX product

(unlike Mac OS X 10.5 and 10.6).

OS X is still UNIX.

So is iOS.

iOS is "unix". OS X is UNIX.

No, they sell it as a certified Unix system, not Unix-like.

If you want case sensitivity for some of your applications, then create a separate partition for that purpose. Things that need one or the other can be stored in the appropriate location.

That's the first thing I did. After noticing that their "copied" text was mostly #defines and enums, I went looking at the matching part of the POSIX standard and the SUS. Lo and behold! Almost everything is part of one of the UNIX standards and simply cannot be changed. Every implementation would look the same.

FYI, you can search the SUS V2 here.

they are very much Windows and C++ only in conception and design which makes it baffling that they could ever enter the C standard library.

Can you explain what you feel to be "Windows-only" about their design?

What's the security reasoning behind the likes of strlen_s()?

strlen_s is solely useful for buffers which aren't guaranteed to be null-terminated. The name itself is a misnomer, there's nothing particularly safe about it, and its semantics don't align with those of other *_s functions. The proper name for it would be strnlen, as it works with the same kind of strings that strncpy is designed to work.

And guess what? There is a POSIX (!) standard function called strnlen with precisely those semantics.

There is also a function called strnlen_s in TR 24731-1. It's identical in semantics to POSIX-standard strnlen, except that strnlen_s will also check the string pointer for NULL, and return 0 in that case.

VC++ supports both of those. Furthermore, VC++ will not give an "unsafe function" warning if you use plain strlen (unlike with strcpy).

The only case usage I can think for the whole family of functions is *ignoring* memory corruption and buffer overflows in C++ code.

It's interesting that you speak of ignoring issues, when it's actually something that strcpy_s is least likely to let you do, compared to strlcpy. Here's why: if the destination buffer is overflown, strlcpy silently truncates. To handle everything right, you also need to check the return value and compare to actual buffer size to see whether truncation has occurred. When this is ignored - and ignoring error codes and other return values that have to be validated is an extremely common bad programming practice - you get code that doesn't crash, but doesn't quite do what it is told, either. Imagine if "rm" would silently truncate, and "rm -rf /foo/bar/baz" would get the path truncated to "/foo/baz", and not check for it! (Yeah, I'm stretching it in this example, but there have been real and very serious exploits with the same underlying problem.)

strcpy_s, in contrast, will invoke the constraint violation handler, for which the default will typically noisily abort the process, and you can explicitly request it to always do so in a portable way. The idea is that, if things go wrong, it's better for the offending code to die there and now, then to continue working with potentially corrupted data, trying to make sense out of it - as in my "rm" example above.

Note that you can also set an empty violation handler, which will allow the function to return successfully even on overflow, but even then it will set the destination buffer to an empty string - which is likely to be safer than a truncated original value.

The disadvantage of strcpy_s is that it doesn't return the actual length of string, so there's no way to efficiently do the same "guess buffer size, attempt copy, check, allocate larger buffer if needed" procedure with it as you can with strlcpy. So, when strlcpy is used correctly, it's the most efficient of the bunch. With strcpy_s, you have to first do strlen first yourself to determine the correct size, so you end up double-scanning the string; the check in strcpy_s itself serves only as a final sanity check to catch incorrect buffer size.

(As a side note - personally, I do consider the absence of actual size indication a major flaw in the design of strcpy_s.)

But I think the difference is mainly due to different approaches to design. For strlcpy, the approach seemingly was: "we want a tool that can be used safely when properly understood, and is also as efficient as possible". With strcpy_s, the design is more about "we want a tool that lets us take an existing codebase with strcpy & strncpy calls, and easily refactor it so that any incorrect use of those would not

iOS actually use XNU operating system.

iOS uses the XNU kernel.

XNU operating system is build by Mach 3.0 microkernel,

Well, not all that "micro", really - very large amounts of "kernel" functionality run in kernel mode rather than in userland servers (there are some userland servers that the kernel talks to, but the vast majority of the stuff that runs in kernel mode in UN*Xes with a "monolithic" kernel also run in kernel mode in Darwin (and in Windows NT, speaking of another OS people sometimes say has a "microkernel").

You can get XNU operating system in Darwin package, what actually is XNU + Darwin development tools.

Actually, Darwin is XNU + a pile of kexts (the same thing that's called, for example, "loadable kernel modules" in Linux) plus a bunch of user-mode libraries (starting with libSystem, for which read "libc" in most other UN*Xes) plus a bunch of user-mode programs, including but far from limited to the command-line development tools (Darwin doesn't include Xcode in its entirety).

XNU = Operating system with Mach 3.0 microkernel

No, that's Darwin.

Mac OS X = Apples software system with lots of open source software (CUPS, Apache etc) and XNU operating system running all that.

That's Darwin (which includes CUPS and Apache; see, for example, the list of components in Darwin) plus a bunch of non-open-source software (some kexts, Carbon, Cocoa, some other libraries, Finder, iTunes, etc.). Oh, and, at least according to The Open Group, it's a UNIX.

iOS = Apples software system to mobile devies with XNU operating system running all.

That's (a subset of) Darwin ported to ARM, plus a bunch of non--open-source software (Springboard, Mobile This That And The Other Thing, etc.).

I didn't know about $@ and that is a good one to know. (Is that POSIX standard, or a GNU extension?)

It is indeed part of POSIX; see XCU 2.5.2 for a complete list of such variables.

I'm still fuzzy on what NoSQL is supposed to be and what it is supposed to bring to the table.

From what I've understood, it's basically a common banner for various different databases that all share the common property of not being relational databases and not providing ACID guarantees.

If so, it seems to me that the whole NoSQL vs. RDMBS debate is about a false dichotomy. There are some applications where a relational database is the right tool for the job, and there are some where a relational database is not the right tool for the job. In some of those latter cases, one of the NoSQL databases may be the right thing.

This is nothing new. Non-relational databases have been used on Unix for a long time, and are even a standard part of POSIX (see for example the manpage for dbm_open). It's also long been known that, for example, Berkeley DB can be a lot faster than an RDBMS - as long as your application doesn't make use of all the features an RDBMS provides. Lots of programs even don't use one of these database systems, but invent their own, custom format. Git is a very successful example of this.

To me, it seems that what we are seeing here is loads of people who had learned to use relational databases for all their storage needs discovering that there are other ways to store data, and that one of those methods may work better than an RDMBS for a particular application. Well, yes. Does that surprise anyone? It sure doesn't surprise me. Does it mean that RDMBSes are now useless? Not at all. Does it mean you should use a non-relational storage system where this makes more sense? Of course! Now, can we please get back to work? I don't see the point of having a holy war over whether RDBMS or NoSQL is better, when common sense says that they both have their uses.

You mean this one?

http://www.opengroup.org/onlinepubs/9699919799/utilities/man.html

De-perimeterization (perimeter erosion) Explained

Distributed Firewalls

Just to nitpick, MacOS X is a certified UNIX.

http://www.opengroup.org/certification/unix-home.html

So "certified Unix" means that a developer can expect that the system calls are the same, more or less. Great. It's not like Linux doesn't try to be POSIX compliant. Further, "certified Unix" doesn't mean a whole hell of a lot when a great majority of the software developed for Unix targets Linux first, others second. Lastly, while this doesn't fall under the "certified" issue (technically) Apple completely butchered the filesystem. Trying to find something in /etc? Good luck, it's probably in /Library in a different place with a different name than on EVERY OTHER UNIX.

Why doesn't cp -r copy symlinks?

The -r flag to cp is implementation specific and obsolete in POSIX:2004 and no longer in in POSIX:2008.

Why is there no sensible top, or killall?

Neither are part of POSIX.

What's up with the completely nonstandard switches to ps?

Like what? I think it's the other way around, and BSD and GNU ps often support nonstandard behavior.

Maybe OpenSolaris is better, but that'd only be because it has a GNU userland by default (or at least I guess so, no experience with it here).

It doesn't. BSD and OS X usually have BSD derived tools too, although with more nonstandard extensions.

Why doesn't cp -r copy symlinks?

The -r flag to cp is implementation specific and obsolete in POSIX:2004 and no longer in in POSIX:2008.

Why is there no sensible top, or killall?

Neither are part of POSIX.

What's up with the completely nonstandard switches to ps?

Like what? I think it's the other way around, and BSD and GNU ps often support nonstandard behavior.

Maybe OpenSolaris is better, but that'd only be because it has a GNU userland by default (or at least I guess so, no experience with it here).

It doesn't. BSD and OS X usually have BSD derived tools too, although with more nonstandard extensions.

Why doesn't cp -r copy symlinks?

The -r flag to cp is implementation specific and obsolete in POSIX:2004 and no longer in in POSIX:2008.

Why is there no sensible top, or killall?

Neither are part of POSIX.

What's up with the completely nonstandard switches to ps?

Like what? I think it's the other way around, and BSD and GNU ps often support nonstandard behavior.

Maybe OpenSolaris is better, but that'd only be because it has a GNU userland by default (or at least I guess so, no experience with it here).

It doesn't. BSD and OS X usually have BSD derived tools too, although with more nonstandard extensions.

You do realize that ActiveX is an industry standard, supported by the Open Group (you now, the same people that standardized X Windows).

http://www.opengroup.org/pubs/catalog/ax01.htm

The problem with Keychain is that, by default, you don't actually need the master password to use the passwords it holds. It's deceptive, because if you use Keychain.app to access the passwords, you need to enter your master password. But if you use another application to access the Keychain, you don't need the master password.

Well, it's actually a little better than it seems. Not every application automatically gains access to every password. The application that you used to create the password automatically gets access to the password - after all if you used the application to enter a password then it follows that you trust the application with your password. If another application wants to use that password a dialog comes up which gives you information about the action and which asks you if you want the application to permanently have access to the password, just this once, or deny access. You can change these settings in Keychain Access.app

So the passwords are still pretty secure, if you trust the applications that use them. Of course if you don't trust the applications then it doesn't matter how you enter the password into them!

Interestingly enough, Keychain is based on open source and open standards and Apple contributes to the project. It'd be pretty easy to integrate Keychain with other applications that follow the CDSA:
Common Data Security Architecture (CDSA)
Apple: Open Source - Security

Actually, Snow Leopard is certified as well. You need to click on the link for the company, Apple, and it will show all their certified products. Here's the link

Anyone still using 10.4 (i.e., Tiger) who wants certified Unix (for whatever reason) can upgrade to either of the two leopards. Tiger is two OS revs and 4 years old at this point. Having said this, Mac OS X has been Unix compatible from the very start, with a bsd subsystem available from the very first developer previews.

You speak of Mac OSX as if it's not a fully-certified Unix. It is: http://opengroup.org/openbrand/register/brand3555.htm

Well, if Snow Leopard is certified, the Open Group should update their website, cause it's not on there.

Snow Leopard Server (a true, if highly GUI-fied, UNIX server)

That's not true. The UNIX trademark is handled by the Open Group. Only if they say it's UNIX, it's UNIX. Mac OS X 10.5 Leopard (for Intel) is UNIX. Mac OS X 10.6 Snow Leopard is not. The Server version also doesn't have a certification.

Sure, it's Unix-like. It might even comply with the Single Unix Specification. But it's not a true UNIX until the Open Group says it is.

The only devs that Macs are good for are Mac devs.

You do realize that OS X is a certified Unix? That means that OS X shares an enormous commonality/overlap with the entire *nix software developing world including AIX, HPUX, Solaris, BSD and Linux. In fact OS X ships with a huge amount of OSS software pre-installed along with Apple's own proprietary stuff and optional developer packages that include a lot more OSS stuff. Apple also contributes to the OSS movement. Macs are also quite popular for all kinds of platform independent and web development. Apple deserves criticism like any other soulless megacorp and their computers aren't the best development machines ever conceived by the mind of man but Macs are useful for a lot more than just Mac development.

there is a finite time before changed data are permanently stored even on this new SSD menory. Furthermore that time can be quite large depending on the OS and file system design.

If you flush and sync the file in the thread that writes the file, you can be sure that "[t]he fsync() function does not return until the system has completed [writing data] or until an error is detected." By "that time", do you refer to the time that the program blocks on fsync()?

You can -- but that loses you all the advantages that a cache gives you. If you're going to flush/sync after every write, you might as well not have a write cache at all.

there is a finite time before changed data are permanently stored even on this new SSD menory. Furthermore that time can be quite large depending on the OS and file system design.

If you flush and sync the file in the thread that writes the file, you can be sure that "[t]he fsync() function does not return until the system has completed [writing data] or until an error is detected." By "that time", do you refer to the time that the program blocks on fsync()?

It matters because as long as GNU/Linux isn't standardised, and can subtly change behaviour between releases, you don't have a stable platform to target. If you're developing against the UNIX 03 specification, you know that your application will behave as expected on any of these systems. Stability and standardisation means a lot when supportability is a major consideration.

I've done X over a 28.8k modem. It was ugly.

Moving to 128kbps ISDN made things hugely better. Using SSH compression was better still. And differential X was fairly usable with lots of X11 software at the time.

But in reading this announcement, I can't help but think: Isn't this the same as Broadway? It seems that it was released along with X11R6.3, which Wikipedia says went public on December 23, 1996. Wikipedia's article on XFree86 also implies that it should've been in the hands of Linux users sometime on or before March 8, 2000, when the 4.0 release of XFree86 went public, which was supposed to support X11R6.4.

But: Nobody, as far as I can tell, ever used the silly thing, despite all of the flowery claims about how cool it'd be to run X over teh Intarwebs, having finally solved the latency and bandwidth problems by introducing a standard made to deal with them from the outset.

So, here we are in 2009, about 12 years hence: Can anyone explain to me why this "new" NX Server concept should be any more successful than Broadway? Is it just because we're a decade ahead, now? (Or is that a decade behind?)

In other words, your conjecture is wrong.

That wasn't conjecture. This is my experience of making hard drive sleeping when I work under Linux.

Also, it doesn't matter what mode is used to open a swap file - its syncing is regulated by :help 'swapsync' option. It is set to 'fsync' by default on *nix systems, meaning that fsync() would be called when something new is written to swap file.

You should have applied some really disrupting tuning to your I/O subsystem - for it to delay write out of synced data. This breaks all application's expectations regarding file I/O integrity. A trouble in making.