your condescension and use of the word "modern enough" is getting annoying. core duo chips are less than 18 months old, so enough with the snobbery.
A PowerMac G5 with a 970FX is a more modern machine than one with the original 970, and this "New Product Focus" note seems to indicate that the 970FX was the first 970 to support changing the clock speed and voltage on the fly, so, if you want to have the OS able to adjust the processor speed (or the processor able to adjust its speed spontaneously), and you have a machine with the original 970, you'll need a more modern machine. The 970FX PowerMac G5 machines are about 34 months old....
Any filesystem which requies a disk write every few seconds on an idle system (i.e nothing is reading from or writing to the disk) is broken.
And the only reason why reading from a file system should require a write to the disk(s) it's on would be to update the last access time, so, if mount or other options are available to disable access time updates, that might help, although
some file systems might decide not to treat those updates as sufficiently important to push them to disk until the file system is unmounted or the in-memory data structure for the file needs to be recycled (so any in-memory changes have to be pushed to disk);
if you're reading from the file system, there's probably a decent chance you'll need to read from the disk in any case.
But, yes, the correct term for a file system that writes metadata to the disk every few seconds, even if there has been no file system activity since the last metadata write, isn't "advanced", it's "broken".
total bunk, that was only 3 powermac revisions ago.
OK, it's not a sufficiently modern Macintosh. The PowerMac G5 family is almost 4 years old. The 970FX supports frequency scaling (see the IBM PowerPC 970FX RISC Microprocessor User's Manual), but I can't find any user's manual for the earlier 970's, so I don't know whether they support it as well. If they don't, you're out of luck, and need to get a more modern machine.
I also don't know whether it would be possible to switch off individual processors in an MP 970 machine. Given that your machine isn't modern enough to have multiple processor cores on a single die, that's presumably what you meant by "1 core".
There was some useful info in this article about configuring your network adapter to support wake-on-lan, but what about wireless adapters? In my experience they don't seem to support WOL or any equivalent.
At least at one point, I found one 802.11 adapter or chipset that supported OnNow-style wakeup, but I don't know whether drivers supported that.
You'd have to keep the radio on, though, which means there's some power you can't save.
Is there any sort of WOL capabilities in the new 802.11n?
That's probably more of a chipset issue than a protocol/PHY issue, so I'm not sure there'd be any chanages in 802.11n - unless there's some radio-layer changes to allow the receiver to run in a low-power mode capable of receiving a wakeup indication.
Ive noticed all companies, including apple, whose products i use, are giving you only a black and white choice. you either have the computer awake or its fully asleep.
i'd like to have a low power transfer mode, where the cpu is reduced (to 1 core at say 500 mhz), the monitor is turned off, and as much memory as possible is dedicated to the apps which are doing intensive file reads/writes. this will allow the hard drives to be used less by caching the files in ram and pulsing the hard disk.
That is "awake", so it's not "asleep", "fully" or otherwise.
OS X and, I suspect, {Windows,Linux,*BSD,etc.} will at least turn the monitor off if you haven't used it for a while (and turn it back on for user input) - I remember seeing that with W2K and with the right X server on FreeBSD.
As for cranking the CPU down, as far as I know at least some OSes will crank clock speeds down under the right circumstances; dunno whether they'll power down cores or not. Whether they'll do it in the case you're referring to is another matter, though.
And as for memory use, I don't know of any OS that would target memory usage in exactly that fashion, although the behavior you describe might be a consequence of the memory use policy in some cases on some OSes. (If you're transferring stuff sequentially, I'm not sure caching the files in RAM helps, though - once a page has been read, you're probably not going to read it again in that transfer, and, once a page has been written, you're probably done with it, too; what you're probably thinking of isn't "caching" so much as it's aggressive pre-fetching, so you do a small number of big reads, and aggressive write-behind, so you do a small number of big writes.)
Let's not forget that many OS features on which the iPhone depends are practically guaranteed to make an appearance on the desktop version of OS X, whether that happens in Leopard or the next version after. Things like resolution independence, multitouch, smooth scrolling, Core Animation.
Yeah, it's not as if Core Animation was announced as a Leopard feature before the iPhone had even been announced, or something such as that....:-)
Kevents are available in OS X, but they are not widely used. The Finder still uses polling to check for updates
Not as of Tiger, on file systems that support kevents. Not all do - NFS, for example, doesn't.
and Spotlight uses the searchfs system call
Presumably you mean fsevents. searchfs can only search based on certain properties, not on, for example, the file contents, and only works on some file systems - it doesn't work on NFS, but Tiger happily indexed the stuff under my NFS home directory at work.
Files created by Perl scripts certainly don't trigger any event-monitoring mechanism.
The event-monitoring mechanism is called "EVFILT_VNODE kqueue events", and the mechanism in xnu that generates them has no idea whether the file was added to a directory by a Perl script or not. If the events are getting lost, or if the Finder isn't updating the window when they're delivered, that has nothing to do with whether the files were created by a Perl script.
Apple's experience with usability and quality can go wonders in other electronics. Now if only they'd release an RPN calculator....
Get them to support Terminal on the iPhone, and then type dc followed by "return".:-) Or, if you don't care whether it's a handheld calculator, just do that on your Mac.
AMD64? But the Core 2 Duo is an Intel chip. Or is there something I am not understanding?
You're not understanding that wild_berry meant "EM64T", err, sorry, "Intel 64" rather than "AMD64", or meant "x86-64" rather than either of them.:-)
Speaking of 64-bit x86, has anybody tested any real-world applications to see whether the extra space taken by 64-bit pointers (and longs) ever outweighs the extra registers you get in 64-bit mode?
I'm talking about something that runs transparently in hardware and stops process A accessing process Bs memory - period. So even with malicious or defective code - nothing happens.
If by "process" you mean "process" in the sense in which it's used in UN*X and Windows systems, if you think that something that "stops process A from accessing process B's memory" (which already exists with UN*X systems and NT-flavored Windows systems such as XP, as long as the processes don't explicitly share memory or use libraries that do so) will ensure that "even with malicious or defective code - nothing happens", you're mistaken. Stack-based buffer overflows are usually problems occurring entirely within a single process.
As for the vulnerability you mention, it doesn't say whether it occurs on systems with the NX/XD bit used by the OS or not; a lot of PC's out there have processors that don't support the NX/XD bit, as they have AMD processors built before AMD introduced that bit or Intel processors built before Intel adopted that bit.
The general sensation in Brazil is that we are known by our futebol, our samba and carnival, our giant man-eater screaming snake overlords (anacondas), our monkeys and our natural beauties (landscapes and women).
I might be missing something, but I've yet to see the name "Embraer" in any of these threads.
If you can bring yourself to see from other perspectives
I can. Can you?
consider what it would be like to be a program inside a computer. Your perception of the universe is one of numbers, and address space is your universe; anything beyond this is difficult to comprehend at best. How do you prove, from your perspective, that there was "The Programmer"? Which is more likely, that the bits and bytes emerged from the randomness of the system, growing more complex over time, the fittest versions surviving, the rest being discarded? Or that there is "The Programmer", who is infinitely more intelligent and beyond the comprehension of any program, and he designed and wrote everything?
Good question. What is the likelihood that "there is 'The Programmer', who is infinitely more intelligent and beyond the comprehension of any program, and he designed and wrote everything"? For that matter, what is the likelihood that there was a team of "Programmers"? Or that the programmer was more intelligent but not infinitely more intelligent? Or that there were multiplecompetingProgrammers?
But from the program's perspective, everything can be explained without "The Programmer", except for various things like "where did the system come from in the first place," of which there could be various theories (like "just happened to pop into existence one day"). There's nowhere in the system you can point at where the programmer "lives". Anything referring to "The Programmer" could be dismissed as propaganda and the desire for one program to "control" other programs. As there is no programmer, everything emerged from randomness, there is thus no "right" or "wrong" way to run, and eventually we need to figure out a way to escape the system before the universe ends. Even if "The Programmer" comes and proverbially taps on a program's shoulder, the interaction is entirely within the program's realm: the interaction can be "explained away" with entirely natural circumstances; bits and bytes are changed, what's miraculous about that? Any features of the physics of the universe or the way things work are just that: "just the way things work". Maybe there are an infinite number of other systems ("universes") that work in an infinite combination of ways, and our programs just happen to be in this one.
Now I'm not saying God is a programmer sitting at a console someplace checking us into CVS.
I'd have difficulty worshiping a god who hadn't yet switched to something such as SVN. A source code control system that doesn't understand renames? Bletch.
I'm stating this so that you can gain a bit of perspective: ask yourself what you're really after
I'm after something better than "well, you have to have faith".
and what actually comprises "proof".
Something subject to experimental test, rather than something that can always be explained away as "the ways of the Lord are mysterious", for starters.
If you haven't experienced these _yourself_, you have valid NO FRAME of REFERENCE.
If you have experienced these yourself, how do you know that a near-death experience or out-of-body experience wasn't a neurobiologically-based phenomenon, and that what you saw as a past life wasn't an construct of your imagination?
Does not the objective truth depend on the subjective experience?
What guarantees that objective truth comes from subjective experience?
(Note: if you want to be a solipsist about this, fine, but you'll have to live with some others not taking you seriously.)
but why don't the US use Pay As You Earn, like the UK do? Surely it's easier for everyone, including the taxman?
To quote the Wikipedia article on PAYE:
While not officially called "pay as you earn" the tax systems of both Canada and the USA are similar. Taxes on pay are withheld by an employer and sent directly to the government on the earner's behalf. However, due to various exemptions and deductions which exist in the tax systems of those countries, an employer can only roughly estimate an individual's total tax liability. Taxpayers are required to file an annual tax return to reconcile their total tax due. The difference will result in either a tax refund being issued or a requirement to pay additional tax.
which is pretty much what other responses said (i.e., the tax code is sufficiently complicated by various deductions and exemptions that your employer doesn't know enough to calculate your tax correctly).
When you therefore state "kernel_task is the Mach task to which all kernel threads belong"., I assume you are describing just the Mach part of the kernel.
When I say "Mach task", I'm describing the Mach part of the kernel. However, parts of the kernel, and kernel extensions, that might be considered as being in the "BSD part" of the kernel create kernel threads, which are threads in the kernel task.
The notion of a "kernel thread" isn't unique to OS X; the current Linux kernel, for example, supports it, as do current versions of Solaris, FreeBSD, and probably other UN*Xes; the NT kernel (which is the kernel of W2K, WXP, WServer2K3, WVista, etc.) might also have a similar notion (I don't have my copies of "Inside Windows {NT, 2000}" handy to check).
I assume that higher level operations that make use of system calls such as network access would not be spawned by Mach, but by userland processes.
Not all non-Mach stuff happens in userland processes - code in a kernel thread can make internal OS calls to do network access, etc..
Does this imply that Mach is in a sense a process of itself? It sounds sufficiently weird and recursive to be vaguely right; this would explain why one can see the kernel itself in a list of running processes.
No - "the kernel" and "Mach" are pieces of code; a thread isn't a piece of code, it's an entity that runs code, and a process has multiple threads associated with it. Kernel code can run in a thread that has a userland thread associated with it, or in a kernel thread, so "kernel_task" isn't the kernel, it's a collection of threads that run kernel code, but those aren't the only threads running kernel code - those threads just happen never to have run any userland code, unlike threads associated with other tasks.
The short and simple answer is: Kernel_task is the kernel.
And a more correct answer is "kernel_task is the Mach task to which all kernel threads belong".
Each user-mode process has a Mach task corresponding to it; each pthread in that task has a Mach thread corresponding to it. Those threads can be executing kernel code if they're in the middle of a system call, so not everything done by the kernel is done in a kernel_task thread.
The kernel has threads of its own, not started within a user-mode process's task; those threads run in the kernel task.
The gnu linker generally will include the entire object file if it is referenced for *any* reason, so if you have a 50k.o file in there and refer to one 100 byte function in it then your program grows by 50k.
And how is this a function of "the way libraries are stored in ELF" rather than a function of the way code is stored in an object file?
If shared libraries are designed to be ', err, umm, shared' then why not also include a lot of extra information past the 'end' so that they can be used to make static binaries that are not huge?
Why do that rather than, for example, include extra information (if needed) in object files so that you can build with a static library and extract individual functions from the object files in the static library?
The way libraries are stored in ELF makes it almost impossible to remove functions at link time that are not used; if you link to a library you may have to include the whole thing instead of only the 20% reachable from what your code uses.
Do you mean "the way shared (dynamically-linked) libraries are stored in ELF"? Static libraries are stored as archives, and if you link with a static library, you should get only the object modules reachable from what your code uses. Shared libraries were designed to be, err, umm, shared; it's not clear that it makes sense for a self-contained application package to include shared versions of libraries if only the application uses or will ever use the library.
At least with Linux (and BSD) packaging mechanisms, the impression I have is that if you want to have a shared library as a package of its own - for use by more than one application - you can do that, and declare application packages that use it as dependent on it, so that at least some installers will, when installing the application, install the packages on which it depends.
No one here on/. is going to offer any rational arguments. Instead they are going to prop up their "theory of evolution is a fact" and "religion is bad" rhetoric.
Except for the ones who will prop up their "what's written in the Bible are facts" and "evolution is bad" rhetoric.
Slashdot Mirror
A PowerMac G5 with a 970FX is a more modern machine than one with the original 970, and this "New Product Focus" note seems to indicate that the 970FX was the first 970 to support changing the clock speed and voltage on the fly, so, if you want to have the OS able to adjust the processor speed (or the processor able to adjust its speed spontaneously), and you have a machine with the original 970, you'll need a more modern machine. The 970FX PowerMac G5 machines are about 34 months old....
And the only reason why reading from a file system should require a write to the disk(s) it's on would be to update the last access time, so, if mount or other options are available to disable access time updates, that might help, although
But, yes, the correct term for a file system that writes metadata to the disk every few seconds, even if there has been no file system activity since the last metadata write, isn't "advanced", it's "broken".
OK, it's not a sufficiently modern Macintosh. The PowerMac G5 family is almost 4 years old. The 970FX supports frequency scaling (see the IBM PowerPC 970FX RISC Microprocessor User's Manual), but I can't find any user's manual for the earlier 970's, so I don't know whether they support it as well. If they don't, you're out of luck, and need to get a more modern machine.
I also don't know whether it would be possible to switch off individual processors in an MP 970 machine. Given that your machine isn't modern enough to have multiple processor cores on a single die, that's presumably what you meant by "1 core".
That's not a modern Macintosh.
I don't know which of the PPC processors used in Macs supported that sort of speed adjustment.
At least at one point, I found one 802.11 adapter or chipset that supported OnNow-style wakeup, but I don't know whether drivers supported that.
You'd have to keep the radio on, though, which means there's some power you can't save.
That's probably more of a chipset issue than a protocol/PHY issue, so I'm not sure there'd be any chanages in 802.11n - unless there's some radio-layer changes to allow the receiver to run in a low-power mode capable of receiving a wakeup indication.
That is "awake", so it's not "asleep", "fully" or otherwise.
OS X and, I suspect, {Windows,Linux,*BSD,etc.} will at least turn the monitor off if you haven't used it for a while (and turn it back on for user input) - I remember seeing that with W2K and with the right X server on FreeBSD.
As for cranking the CPU down, as far as I know at least some OSes will crank clock speeds down under the right circumstances; dunno whether they'll power down cores or not. Whether they'll do it in the case you're referring to is another matter, though.
And as for memory use, I don't know of any OS that would target memory usage in exactly that fashion, although the behavior you describe might be a consequence of the memory use policy in some cases on some OSes. (If you're transferring stuff sequentially, I'm not sure caching the files in RAM helps, though - once a page has been read, you're probably not going to read it again in that transfer, and, once a page has been written, you're probably done with it, too; what you're probably thinking of isn't "caching" so much as it's aggressive pre-fetching, so you do a small number of big reads, and aggressive write-behind, so you do a small number of big writes.)
I guess that explains the slow response I got - I mostly used Multics from an IBM 2741, so I didn't have any cards.
Yeah, it's not as if Core Animation was announced as a Leopard feature before the iPhone had even been announced, or something such as that.... :-)
The Leopard Technology Overview lists resolution independence (as well as Core Animation, of course).
Not as of Tiger, on file systems that support kevents. Not all do - NFS, for example, doesn't.
Presumably you mean fsevents. searchfs can only search based on certain properties, not on, for example, the file contents, and only works on some file systems - it doesn't work on NFS, but Tiger happily indexed the stuff under my NFS home directory at work.
The event-monitoring mechanism is called "EVFILT_VNODE kqueue events", and the mechanism in xnu that generates them has no idea whether the file was added to a directory by a Perl script or not. If the events are getting lost, or if the Finder isn't updating the window when they're delivered, that has nothing to do with whether the files were created by a Perl script.
Get them to support Terminal on the iPhone, and then type dc followed by "return". :-) Or, if you don't care whether it's a handheld calculator, just do that on your Mac.
You're not understanding that wild_berry meant "EM64T", err, sorry, "Intel 64" rather than "AMD64", or meant "x86-64" rather than either of them. :-)
Speaking of 64-bit x86, has anybody tested any real-world applications to see whether the extra space taken by 64-bit pointers (and longs) ever outweighs the extra registers you get in 64-bit mode?
If by "process" you mean "process" in the sense in which it's used in UN*X and Windows systems, if you think that something that "stops process A from accessing process B's memory" (which already exists with UN*X systems and NT-flavored Windows systems such as XP, as long as the processes don't explicitly share memory or use libraries that do so) will ensure that "even with malicious or defective code - nothing happens", you're mistaken. Stack-based buffer overflows are usually problems occurring entirely within a single process.
As for the vulnerability you mention, it doesn't say whether it occurs on systems with the NX/XD bit used by the OS or not; a lot of PC's out there have processors that don't support the NX/XD bit, as they have AMD processors built before AMD introduced that bit or Intel processors built before Intel adopted that bit.
I might be missing something, but I've yet to see the name "Embraer" in any of these threads.
I can. Can you?
Good question. What is the likelihood that "there is 'The Programmer', who is infinitely more intelligent and beyond the comprehension of any program, and he designed and wrote everything"? For that matter, what is the likelihood that there was a team of "Programmers"? Or that the programmer was more intelligent but not infinitely more intelligent? Or that there were multiple competing Programmers?
Thank you for summarizing what I, at least, see as a deep, and unfixable, problem with theism.
I'd have difficulty worshiping a god who hadn't yet switched to something such as SVN. A source code control system that doesn't understand renames? Bletch.
I'm after something better than "well, you have to have faith".
Something subject to experimental test, rather than something that can always be explained away as "the ways of the Lord are mysterious", for starters.
If you have experienced these yourself, how do you know that a near-death experience or out-of-body experience wasn't a neurobiologically-based phenomenon, and that what you saw as a past life wasn't an construct of your imagination?
What guarantees that objective truth comes from subjective experience?
(Note: if you want to be a solipsist about this, fine, but you'll have to live with some others not taking you seriously.)
Cite some.
No, not particle theory, complex analysis.
To quote the Wikipedia article on PAYE:
which is pretty much what other responses said (i.e., the tax code is sufficiently complicated by various deductions and exemptions that your employer doesn't know enough to calculate your tax correctly).
Why wouldn't it let the person to whom you're responding post one? It let you post one....
When I say "Mach task", I'm describing the Mach part of the kernel. However, parts of the kernel, and kernel extensions, that might be considered as being in the "BSD part" of the kernel create kernel threads, which are threads in the kernel task.
The notion of a "kernel thread" isn't unique to OS X; the current Linux kernel, for example, supports it, as do current versions of Solaris, FreeBSD, and probably other UN*Xes; the NT kernel (which is the kernel of W2K, WXP, WServer2K3, WVista, etc.) might also have a similar notion (I don't have my copies of "Inside Windows {NT, 2000}" handy to check).
Not all non-Mach stuff happens in userland processes - code in a kernel thread can make internal OS calls to do network access, etc..
No - "the kernel" and "Mach" are pieces of code; a thread isn't a piece of code, it's an entity that runs code, and a process has multiple threads associated with it. Kernel code can run in a thread that has a userland thread associated with it, or in a kernel thread, so "kernel_task" isn't the kernel, it's a collection of threads that run kernel code, but those aren't the only threads running kernel code - those threads just happen never to have run any userland code, unlike threads associated with other tasks.
And a more correct answer is "kernel_task is the Mach task to which all kernel threads belong".
Each user-mode process has a Mach task corresponding to it; each pthread in that task has a Mach thread corresponding to it. Those threads can be executing kernel code if they're in the middle of a system call, so not everything done by the kernel is done in a kernel_task thread.
The kernel has threads of its own, not started within a user-mode process's task; those threads run in the kernel task.
And how is this a function of "the way libraries are stored in ELF" rather than a function of the way code is stored in an object file?
Why do that rather than, for example, include extra information (if needed) in object files so that you can build with a static library and extract individual functions from the object files in the static library?
Do you mean "the way shared (dynamically-linked) libraries are stored in ELF"? Static libraries are stored as archives, and if you link with a static library, you should get only the object modules reachable from what your code uses. Shared libraries were designed to be, err, umm, shared; it's not clear that it makes sense for a self-contained application package to include shared versions of libraries if only the application uses or will ever use the library.
At least with Linux (and BSD) packaging mechanisms, the impression I have is that if you want to have a shared library as a package of its own - for use by more than one application - you can do that, and declare application packages that use it as dependent on it, so that at least some installers will, when installing the application, install the packages on which it depends.
Except for the ones who will prop up their "what's written in the Bible are facts" and "evolution is bad" rhetoric.