I tried your program (compiled with G++ 4.0), and it got "Bus error (core dumped)".
According to the current version of the Single UNIX Specification, the default action for SIGSEGV and SIGBUS is "abnormal termination of the process", and "The behavior of a process is undefined after it returns normally from a signal-catching function for a SIGBUS, SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(), sigqueue(), or raise()." What the behavior is if the signal-caching function terminates the thread by calling pthread_exit() isn't specified in any immediately-obvious place.
Define "Linux only". Perhaps Linux distributions are the only OSes that come bundled with GTK+ (although I think they're in the ports collections of at least some of the BSDs), but they're certainly not the only OSes on which GTK+ works. It works on, as far as I know, most if not all modern UNIX+X11 systems (including OS X+X11), and there's also a Win32 port that runs atop GDI (with some annoying bugs, but Tor Lillqvist is now working at Novell, and I suspect he was hired to, at least in part, make it work better on Windows to support Evolution on Windows). No OS X version that runs atop Quartz, though.
As I read those CAD software requirement, I bet the mean reason of no Mac OSX version is the Processor, most of them only support X86 CPU not PPC.
If so, then the question then is "why do they only support x86?" The answer could be:
"because we only support Windows, and almost all Windows machines are x86", in which case they'd have to port to OS X even with x86-based Macs;
"because we only support Windows and Linux, and almost all Windows machines and most Linux machines are x86" - see previous answer;
"because we've done a lot of work to optimize for x86", in which case the processor might make more of a difference.
(The answer might also be something else I didn't think of in the list above.)
Just wonder if X11 run in X86, will it perfectly fit and don't need to re-compile it ?
In the generic sense, X11 runs just fine on x86; most Linux and free-software BSD boxes are probably PC's, and most if not all of the ones being used as machines with a GUI are running X11.
It has to be compiled for x86, obviously, but that's done as part of the Linux distribution/free-software BSD release.
In the specific sense of X11 on OS X, you'd have to ask somebody with one of the developer transition systems, but they probably have X11, compiled for x86 (and possibly compiled for PowerPC, too, and shipped as a fat binary).
the problem with the way osx does ftp though, at least through finder, is that it mounts it as a filesystem
There are those who consider that a problem. As per the posting to which you're replying, I obviously consider that a feature.
and when the remote ftp site goes out to lunch it sometimes takes osx with it.
If a remote server hang can hang up your entire system, that's a problem with the system (or with some component of the system; if you can still do things in a Terminal window, the problem is probably at a layer above Darwin), not with the notion of an ftpfs, as there are other remote file systems in OS X - and in Linux, and various BSDs, and various other UN*Xes.
it also makes it impossible to parallelize tasks to a single remote site. the way ftpfs does it, everything gets serialized and blocks. a slow remote ftp site will make finder slow to a crawl.
Sounds like too little threading - again, a problem with OS X's implementation of the idea, not with the idea itself.
ftpfs also groks an extremely limited dialect of ftp, it gets easily confused by various ftp server software that kioslave (or mozilla, camino, etc.) doesn't have any problems with.
Again, an implementation problem, not a problem with the idea. What are some examples of FTP server software that ftpfs's client can't handle?
no, kioslave really is the best way to do it.
That assertion is not supported by anything you've said above, because that stuff just complains about a particular implementation of the notion of an FTP file system.
Of course, Mac OS X has ways of accomplishing all of the same tasks, but having gotten used to being able to get an any of this functionality so quickly and easily in KDE, I find OS X a little cumbersome to use.
And having gotten used to the notion of cding to a remotely-mounted FTP directory and grepping through files, catting them, firing them up in MicroEMACS, etc., etc., I'd probably find doing it only through KDE applications a little cumbersome to use.
Sounds like a job for userfs (and a mount_userfs command usable by ordinary users; an ordinary user would only, for example, be allowed to mount atop directories they own, as is the case in BSDs including OS X). Perhaps being able to cd to a tarball and look at individual files wouldn't be as useful as doing so over FTP, as you can fetch individual files over FTP without having to scan through a bunch of other files, but it still might be useful.
I haven't bought the replacement iBook (yet?) mainly because now I can't live without KDE's network protocol integration (sftp , webdav, smb, ftp,... everything is supported!). I can transparently access folders with the (file browser, editor, image viewer, etc. etc. ) in multiple servers, seamlessly. OS/X is seriously lacking in this area.
Yeah, it really sucks that OS X lets you transparently access folders over FTP with ls. It'd be much better if it did it with ioslaves, so only KDE applications could transparently access them.
(Yes, I know that ftpfs is read-only. Implementing it as an NFS server, so that the FTP back-end has no way of knowing when an application is finished writing to the file, makes it difficult to support read/write access. And, yes, I really have accessed an FTP server with ls, egrep, etc., and yes, it was convenient.)
And the same goes for WebDAV and SMB (although WebDAV uses a gateway VFS rather than using NFS, so it does know when a file is closed and can upload its contents if it was written to, and smbfs is implemented as a kernel-level VFS and supports reading and writing). Unfortunately, there's no sftpfs, but, if there were, that'd be a lot more UN*Xy than doing it with an ioslave.
BTW, your Linux box probably has an smbfs, too, so you can access SMB servers from the command line as well as from KDE apps. (Or does KDE do the right thing on systems with smbfs/cifsfs, and just mount the damn server and let the underlying UN*X do the work?) Somebody might have implemented ftpfs, etc. with userfs, so you might have them as well.
Better yet would be OS X itself natively supporting the most widely used network protocols. Tiger was a big dissapointment in this respect...
Which ones are missing? (Other than read/write FTP, and sftp, which are already known to be missing.)
So yeah, I think you're going to see a whole new ISA
Perhaps you will, but Intel's already got 3 ISA's they're implementing (x86^H^H^HIA-32, IA-64, and ARM with XScale - 4, if you count x86-64, and then there might be some other microcontrollers they have); they might not be interested in doing Yet Another ISA. (That's not what the new "architecture" they announced recently is; it's another internal architecture implementing the x86 and perhaps x86-64 ISA's.)
And yet, I'd not be shocked if OS X did even more than all of that, doing stuff like registering the forked application with higher-level message-passing and even application-layer stuff like Finder and Launch Services
I'd be shocked if fork() did any of that on OS X. xnu and libsystem know nothing of the Finder or Launch Services or any Carbon/Cocoa/CoreFoundation/etc.-level message passing (although they provide infrastructure that those facilities use); higher-level app framework code handles that stuff.
The bloody X clipboard is separate from GNOME's clipboard
Really? How is GNOME's clipboard implemented? Does it really have nothing to do with the ICCCM's CLIPBOARD selection?
If they've got rid of it
Given the freedesktop.org Clipboard Manager spec's references to the ICCCM, I suspect they have not gotten rid of the X clipboard in the sense of the CLIPBOARD selection.
If I can't just highlight into the PRIMARY selection and then middle-click-paste into an xterm (or my other "real" X11 applications) anymore, then Gnome is useless to me.
Viruses are not generally written in machine or machine-specific code, they do the same as most Windows software does: call APIs that have flaws in them because MS does not write them robustly enough
But how do they exploit those flaws? If a flaw is, for example, an overflow of a buffer on the stack, do they exploit it by writing some code onto the stack and then overwriting the return address on the stack, so that a return from the routine with the offending buffer jumps to the code on the stack? If so, then, even if the virus itself is written in portable code, the code it's injecting into the application is probably machine code - and probably x86 machine code.
(And, as far as I know, Windows doesn't have fat binaries, so even if the virus wasn't written in machine-specific code and doesn't inject machine-specific code, it might have been compiled into machine-specific code, if it's not some all-Visual Basic or all-JavaScript virus.)
A virus written for a Windows XP machine has at least a 90% chance of hitting a similarly protected Alpha running XP (OK, OK, let the flames begin....)
No flame, just a simple question: do you have any data to support that assertion? Are most of those viruses either written in some language that translates into machine-independent code of some sort or executed via emulation mode on non-x86 machines?
A virus written for a Windows XP machine has at least a 90% chance of hitting a similarly protected Alpha running XP (OK, OK, let the flames begin....). Does the above comment infer
imply
that when Mac OS moves to i386 it will be more suceptible?
Only by 10%, if it's truly the case that only 10% of viruses would be instruction-set-dependent; after all, why would not a virus writtten for an x86 OS X machine not have at least a 90% chance of hitting a similarly protected PowerPC machine running OS X?
This may be the case, for one or both of two reasons: 1) by then the focus will have moved from MS Windows attacks to Mac OS attacks because of market penetration
I.e., you're predicting that Apple's move to x86 will significantly increase their market share?
A part of the problem is the amount of time most Americans spend at work, and how little vacation time people get in this country. Two weeks of vacation a year isn't much, and people burn out as a result.
That sounds like a testable hypothesis; do the results of a survey such as this differ in, say, European countries where people get more vacation and don't spend as much time at work?
Try opening lots of quiet applications. I have Mail, Finder, Firefox, Terminal, Emacs, Activity monitor, Preview and Nvu.
None of these apps are doing anything special. Flash, animated GIFs and PNGs and Java are disabled in Firefox, yet my average activity level is 15-20%
So what is Activity Monitor showing as consuming that CPU time? Does the CPU time consumed by those processes add up to the activity level you're seeing?
If so, that's not the scheduler's fault; a scheduler that doesn't give some process or processes any CPU time even though those processes are runnable and there's idle time definitely could work better.:-)
Another effect is that in the situation described above (many apps open) no app can get anywhere near 100% CPU when they need it. 80% is the max, or thereabouts. Of course if you close all the idle apps then of course you can but this is not a good thing.
My definition of "idle", in this context, is "blocked 100% of the time waiting for an event". If all the apps in question (the apps that, if you close them, let your app get 100% of the CPU) are truly idle in that sense, then whatever's wasting the extra 20% of time, whether it be the scheduler or some other part of the system, is at fault.
However, if the apps in question aren't idle in that sense, even if they're supposed to be just sitting there waiting for your input, then I'd say it's the apps that are at fault; how is the scheduler to know that they're just wanking rather than performing useful work?
"...So, thread creation time is included in the fork () benchmark of Lmbench. "
Any questions?
Yes, three questions.
What work that's not done when creating a thread with pthread_create() is also included in the fork() benchmark of LMbench?
What fraction of the total work of fork() is the part of that work not also done by pthread_create()?
And, if a significant portion of the work done by fork()is not done by pthread_create() (or clone(), if MySQL is directly using clone()), how meaningful is a fork() benchmark if you're curious about pthread creation performance?
NT is a fairly unique Client/Server kernel design, meaning that it allows OSes to run on top of the NT kernel design (reducing traffic to the NT kernel)
This is, of course, completely different from the way Linux and OS X work. In those OSes, many UNIX APIs are implemented as user-land stubs that trap directly to the kernel, with the kernel calling routines to handle those traps.
on a similar OS/X desktop even though none of the apps are doing anything, the CPU meter typically hover at about 15%. This seems to be pure scheduler overhead.
Have you run top or Activity Monitor on an (otherwise) idle OS X desktop? I'm running it right now, and the main consumers of CPU time are Safari and, err, umm, top and Activity Monitor. (WindowServer pops up on occasion to draw the text and pretty pictures for Activity Monitor and for Terminal on behalf of top, and Terminal's showing up as a middleman between top and the window system. pmTool, kernel_task, and coreservicesd also consume a little bit of time.)
So, at least on my desktop, if you subtract out top (and Terminal) and Activity Monitor, as all of them would be idle if I weren't measuring (and a lot of WindowServer wouldn't be there, either), you have Safari, which is probably drawing a bunch of stupid animated-GIF ads, and some system processes.
I.e., perhaps those apps were doing something, even if it's not something useful (I certainly wouldn't, for example, describe the 50 babies wiggling around on those stupid popup mortgage ads as "useful").
One useful way to think about Mac OS X's various threading APIs is to arrange them in an layered hierarchy. For example, each MP task is layered on top of a pthread, and each pthread is layered on top of a Mach thread.
(which is presumably what you meant by "everything is a kernel thread").
However, OS X's design choice makes for more secure communication between user-space threads and the kernel, which gives an advantage in the workstation-space, since you can keep a user process from running amok in the kernel.
As opposed to Linux's design choice, where user-mode code is in userland and kernel-mode code is in the kernel, and user-mode code can't run amok in the kernel.
OS X never had userthreads. The article corrects that misconception from the previous article:
Readers pointed out that there were two errors in this sentence. The first one is that Mac OS X does use kernelthreads, and this is completely true. My confusion came from the fact that FreeBSD 4.x and older - which was part of the OS X kernel until Tiger came along -
did not implement kernelthreads; rather, only userthreads. It was one of the reasons why MySQL ran badly on FreeBSD 4.x and older. In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace.
However, this is not the case of Mac OS X. Pthreads, available to the programmer, map directly to a Mach thread, and thread handling is the very heart of the Mach kernel inside the OS X kernel.
Slashdot Mirror
According to the current version of the Single UNIX Specification, the default action for SIGSEGV and SIGBUS is "abnormal termination of the process", and "The behavior of a process is undefined after it returns normally from a signal-catching function for a SIGBUS, SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(), sigqueue(), or raise()." What the behavior is if the signal-caching function terminates the thread by calling pthread_exit() isn't specified in any immediately-obvious place.
I tried your program (compiled with G++ 4.0), and it got "Bus error (core dumped)".
Define "Linux only". Perhaps Linux distributions are the only OSes that come bundled with GTK+ (although I think they're in the ports collections of at least some of the BSDs), but they're certainly not the only OSes on which GTK+ works. It works on, as far as I know, most if not all modern UNIX+X11 systems (including OS X+X11), and there's also a Win32 port that runs atop GDI (with some annoying bugs, but Tor Lillqvist is now working at Novell, and I suspect he was hired to, at least in part, make it work better on Windows to support Evolution on Windows). No OS X version that runs atop Quartz, though.
(By "Linux only" did you mean "UNIX+X11 only"?)
If so, then the question then is "why do they only support x86?" The answer could be:
(The answer might also be something else I didn't think of in the list above.)
In the generic sense, X11 runs just fine on x86; most Linux and free-software BSD boxes are probably PC's, and most if not all of the ones being used as machines with a GUI are running X11.
It has to be compiled for x86, obviously, but that's done as part of the Linux distribution/free-software BSD release.
In the specific sense of X11 on OS X, you'd have to ask somebody with one of the developer transition systems, but they probably have X11, compiled for x86 (and possibly compiled for PowerPC, too, and shipped as a fat binary).
...or other libraries that don't ship as fat libraries in Tiger, which includes, err, umm, all the X11 libraries in /usr/X11R6/lib.
...unless you don't want to have to build 64-bit versions of the X11 libraries yourself.
Could you please cite the evidence that leads you to believe that IBM created NTFS? (And if he really meant "HPFS", the same question could be asked.)
There are those who consider that a problem. As per the posting to which you're replying, I obviously consider that a feature.
If a remote server hang can hang up your entire system, that's a problem with the system (or with some component of the system; if you can still do things in a Terminal window, the problem is probably at a layer above Darwin), not with the notion of an ftpfs, as there are other remote file systems in OS X - and in Linux, and various BSDs, and various other UN*Xes.
Sounds like too little threading - again, a problem with OS X's implementation of the idea, not with the idea itself.
Again, an implementation problem, not a problem with the idea. What are some examples of FTP server software that ftpfs's client can't handle?
That assertion is not supported by anything you've said above, because that stuff just complains about a particular implementation of the notion of an FTP file system.
And having gotten used to the notion of cding to a remotely-mounted FTP directory and grepping through files, catting them, firing them up in MicroEMACS, etc., etc., I'd probably find doing it only through KDE applications a little cumbersome to use.
Sounds like a job for userfs (and a mount_userfs command usable by ordinary users; an ordinary user would only, for example, be allowed to mount atop directories they own, as is the case in BSDs including OS X). Perhaps being able to cd to a tarball and look at individual files wouldn't be as useful as doing so over FTP, as you can fetch individual files over FTP without having to scan through a bunch of other files, but it still might be useful.
Yeah, it really sucks that OS X lets you transparently access folders over FTP with ls. It'd be much better if it did it with ioslaves, so only KDE applications could transparently access them.
(Yes, I know that ftpfs is read-only. Implementing it as an NFS server, so that the FTP back-end has no way of knowing when an application is finished writing to the file, makes it difficult to support read/write access. And, yes, I really have accessed an FTP server with ls, egrep, etc., and yes, it was convenient.)
And the same goes for WebDAV and SMB (although WebDAV uses a gateway VFS rather than using NFS, so it does know when a file is closed and can upload its contents if it was written to, and smbfs is implemented as a kernel-level VFS and supports reading and writing). Unfortunately, there's no sftpfs, but, if there were, that'd be a lot more UN*Xy than doing it with an ioslave.
BTW, your Linux box probably has an smbfs, too, so you can access SMB servers from the command line as well as from KDE apps. (Or does KDE do the right thing on systems with smbfs/cifsfs, and just mount the damn server and let the underlying UN*X do the work?) Somebody might have implemented ftpfs, etc. with userfs, so you might have them as well.
Which ones are missing? (Other than read/write FTP, and sftp, which are already known to be missing.)
Almost. It's not 5000 years old now, it's (approximately) 6000 years old now.
Perhaps you will, but Intel's already got 3 ISA's they're implementing (x86^H^H^HIA-32, IA-64, and ARM with XScale - 4, if you count x86-64, and then there might be some other microcontrollers they have); they might not be interested in doing Yet Another ISA. (That's not what the new "architecture" they announced recently is; it's another internal architecture implementing the x86 and perhaps x86-64 ISA's.)
Surely you mean "Fuck you very much, the FCC".
I'd be shocked if fork() did any of that on OS X. xnu and libsystem know nothing of the Finder or Launch Services or any Carbon/Cocoa/CoreFoundation/etc.-level message passing (although they provide infrastructure that those facilities use); higher-level app framework code handles that stuff.
...which is probably referring to the freedesktop.org Clipboard Manager spec.
Really? How is GNOME's clipboard implemented? Does it really have nothing to do with the ICCCM's CLIPBOARD selection?
Given the freedesktop.org Clipboard Manager spec's references to the ICCCM, I suspect they have not gotten rid of the X clipboard in the sense of the CLIPBOARD selection.
If selecting text doesn't set the PRIMARY selection in a GNOME application, then GNOME doesn't follow the freedesktop.org clipboard explanation.
If the middle mouse button in xterm doesn't paste the PRIMARY selection, either your xterm is broken or somebody's configured it not to do so.
But how do they exploit those flaws? If a flaw is, for example, an overflow of a buffer on the stack, do they exploit it by writing some code onto the stack and then overwriting the return address on the stack, so that a return from the routine with the offending buffer jumps to the code on the stack? If so, then, even if the virus itself is written in portable code, the code it's injecting into the application is probably machine code - and probably x86 machine code.
(And, as far as I know, Windows doesn't have fat binaries, so even if the virus wasn't written in machine-specific code and doesn't inject machine-specific code, it might have been compiled into machine-specific code, if it's not some all-Visual Basic or all-JavaScript virus.)
No flame, just a simple question: do you have any data to support that assertion? Are most of those viruses either written in some language that translates into machine-independent code of some sort or executed via emulation mode on non-x86 machines?
imply
Only by 10%, if it's truly the case that only 10% of viruses would be instruction-set-dependent; after all, why would not a virus writtten for an x86 OS X machine not have at least a 90% chance of hitting a similarly protected PowerPC machine running OS X?
I.e., you're predicting that Apple's move to x86 will significantly increase their market share?
If by "Pentium" you mean the original Pentium, prior to the Pentium Pro, could you cite a reference that supports that assertion?
That sounds like a testable hypothesis; do the results of a survey such as this differ in, say, European countries where people get more vacation and don't spend as much time at work?
So what is Activity Monitor showing as consuming that CPU time? Does the CPU time consumed by those processes add up to the activity level you're seeing?
If so, that's not the scheduler's fault; a scheduler that doesn't give some process or processes any CPU time even though those processes are runnable and there's idle time definitely could work better. :-)
My definition of "idle", in this context, is "blocked 100% of the time waiting for an event". If all the apps in question (the apps that, if you close them, let your app get 100% of the CPU) are truly idle in that sense, then whatever's wasting the extra 20% of time, whether it be the scheduler or some other part of the system, is at fault.
However, if the apps in question aren't idle in that sense, even if they're supposed to be just sitting there waiting for your input, then I'd say it's the apps that are at fault; how is the scheduler to know that they're just wanking rather than performing useful work?
Yes, three questions.
What work that's not done when creating a thread with pthread_create() is also included in the fork() benchmark of LMbench?
What fraction of the total work of fork() is the part of that work not also done by pthread_create()?
And, if a significant portion of the work done by fork()is not done by pthread_create() (or clone(), if MySQL is directly using clone()), how meaningful is a fork() benchmark if you're curious about pthread creation performance?
...by not actually sending messages to the NT kernel for a lot of APIs. Instead, many Win32 APIs call user-land stub routines that trap directly to the kernel, with the kernel calling routines to handle those traps.
This is, of course, completely different from the way Linux and OS X work. In those OSes, many UNIX APIs are implemented as user-land stubs that trap directly to the kernel, with the kernel calling routines to handle those traps.
Have you run top or Activity Monitor on an (otherwise) idle OS X desktop? I'm running it right now, and the main consumers of CPU time are Safari and, err, umm, top and Activity Monitor. (WindowServer pops up on occasion to draw the text and pretty pictures for Activity Monitor and for Terminal on behalf of top, and Terminal's showing up as a middleman between top and the window system. pmTool, kernel_task, and coreservicesd also consume a little bit of time.)
So, at least on my desktop, if you subtract out top (and Terminal) and Activity Monitor, as all of them would be idle if I weren't measuring (and a lot of WindowServer wouldn't be there, either), you have Safari, which is probably drawing a bunch of stupid animated-GIF ads, and some system processes.
I.e., perhaps those apps were doing something, even if it's not something useful (I certainly wouldn't, for example, describe the 50 babies wiggling around on those stupid popup mortgage ads as "useful").
As opposed to OS X, where every thread has a kernel thread:
(which is presumably what you meant by "everything is a kernel thread").
As opposed to Linux's design choice, where user-mode code is in userland and kernel-mode code is in the kernel, and user-mode code can't run amok in the kernel.
OS X never had userthreads. The article corrects that misconception from the previous article: