The conversation on this page has been archived and is no longer active.

sleep from terminal

Message #1 - Posted 2006/01/01 - johnny bobby bee

I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.

Cheers.

NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

Message #2 - Posted 2006/01/01 - Hans Aberg

Previously, johnny bobby bee wrote:

I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.

Probably not, as sleep depends on code external to the UNIX kernel.

Hans Aberg

Message #3 - Posted 2006/01/01 - ZnU

Previously, johnny bobby bee wrote:

I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.

AppleScript is your friend:

osascript -e 'tell application "Finder" to sleep'

This make not work if the user you're logged in as isn't logged into the GUI.

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #4 - Posted 2006/01/02 - Andre Berger

* johnny bobby bee (2006-01-01):

I know of an app called 'sleepnow' that does this, but is there a built-in shell command to make the computer sleep from terminal? Jag and Panther.

Darwinports has got a sleepnow package.

-Andre

Message #5 - Posted 2006/01/02 - johnny bobby bee

ZnU wrote:

AppleScript is your friend:

osascript -e 'tell application "Finder" to sleep'

Wacky applescript, it works; cheers.

NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

Message #6 - Posted 2006/01/02 - johnny bobby bee

Hans Aberg wrote:

Probably not, as sleep depends on code external to the UNIX kernel.

OS X doesn't really use a traditional UNIX kernel, does it? Panther has replaced init (and others?) with launchd. So, you'd think there could be a built-in apple command to initiate sleep. I'm no apple scripter, but as we see below it can be done with an apple script from terminal. Just thought there would be something like apm or acpid.

NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

Message #7 - Posted 2006/01/02 - Hans Aberg

Previously, johnny bobby bee wrote:

Hans Aberg wrote:

Probably not, as sleep depends on code external to the UNIX kernel.

OS X doesn't really use a traditional UNIX kernel, does it?

Sure, Mac OS X has a FreeBSD UNIX with its kernel replaced by a Mach kernel. Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics,†external faulty code that the UNIX kernel†cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).

Hans Aberg

Message #8 - Posted 2006/01/02 - Hans Aberg

Previously, johnny bobby bee wrote:

OS X doesn't really use a traditional UNIX kernel, does it? Panther has replaced init (and others?) with launchd. So, you'd think there could be a built-in apple command to initiate sleep.

Looking at 'man launchd' and 'man init', launchd is used as the root process with PID = 1, and at the end of the boot process, it launches init, which would be the normal root process under BSD. The UNIX kernel (Mach under Mac OS X), does however itself not†launch any programs or processes: only a process can†launch another process. The kernel just keeps track of these processes, scheduling them, making sure they do not do anything illegal. So all processes end up on a parent-child tree, depending how processes (parents) launch other processes (children).

Then the UNIX kernel cannot go to sleep by itself. So Apple must have installed some other code, first called at boot. Probably launchd links the UNIX kernel to this other code at boot, though I do not see exactly how. But the result is not only the ability to go to sleep, but the inability to handle certain code, kernel panics.

Hans Aberg

Message #9 - Posted 2006/01/02 - Daniel Cohen

johnny bobby bee wrote:

ZnU wrote:

AppleScript is your friend:

osascript -e 'tell application "Finder" to sleep'

Wacky applescript, it works; cheers.

Not really wacky. the 'tell ...' is just a straighforward AppleScript,

osacript is a way of running AppleScripts in the shell,

and the flag -e says that the script to run is the bit in quotes. If you had saved a script, as scriptname then

osascript fullpathtoscriptname

would run the script.

Send e-mail to the Reply-To address;
mail to the From address is never read

Message #10 - Posted 2006/01/02 - johnny bobby bee

Daniel Cohen wrote:

Not really wacky. the 'tell ...' is just a straighforward AppleScript,

and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.

NOTICE: anyone seen smoking will be assumed to be on fire and will be summarily put out.

Message #11 - Posted 2006/01/02 - L

johnny bobby bee <useraddshine_eh@yahoo.ca> wrote in news:q5iuf.20206 $km.15496@edtnps89:

Daniel Cohen wrote:

Not really wacky. the 'tell ...' is just a straighforward AppleScript,

and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.

That's Applescript's syntax:

Tell application.app
do this, that, and everything
end tell

Message #12 - Posted 2006/01/02 - ZnU

Previously, Hans Aberg wrote:

Previously, johnny bobby bee wrote:

Hans Aberg wrote:

Probably not, as sleep depends on code external to the UNIX kernel.

OS X doesn't really use a traditional UNIX kernel, does it?

Sure, Mac OS X has a FreeBSD UNIX with its kernel replaced by a Mach kernel.

Well, sort of. The OS X kernel is actually an odd combination of Mach code and kernel code borrowed from various BSD systems.

Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics,†external faulty code that the UNIX kernel†cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #13 - Posted 2006/01/03 - Hans Aberg

Previously, ZnU wrote:

Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics,†external faulty code that the UNIX kernel†cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

Sure it is relevant, whether it is in the UNIX kernel, or if it is in non-UNIX†kernel extensions, as it affects reliability, for example.

The situations seems to be like that of Tenon BSD UNIX running as a program within Mac OS 9. In that case, the†reliability and capacities of the UNIX programs are limited by Mac OS 9 reliability.

For Mac OS X, it seems that one has added a mini-OS, by which the†FreeBSD and its Mach kernel run within.

But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

The original the answer I gave, was for a UNIX shell command; I should have added that one must call something without that UNIX environment to get the effect. The answer given, using AppleScript, also gives hint that some of these things cannot be handled within the UNIX proper itself. Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.

Hans Aberg

Message #14 - Posted 2006/01/03 - Hans Aberg

Previously, ZnU wrote:

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing†happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.

Hans Aberg

Message #15 - Posted 2006/01/03 - Daniel Cohen

johnny bobby bee wrote:

Daniel Cohen wrote:

Not really wacky. the 'tell ...' is just a straighforward AppleScript,

and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.

Come to think of it, my version of the instructions was

tell "System Events" to sleep

That's a change in the way scripts work, but I'm not sure if it was introduced in Tiger or earlier.

The older version does make sense, though I see your point, given that 'sleep' is a menu item in the Finder.

Send e-mail to the Reply-To address;
mail to the From address is never read

Message #16 - Posted 2006/01/03 - Dave Seaman

On Tue, 3 Jan 2006 13:09:01 +0000, Daniel Cohen wrote:

johnny bobby bee wrote:

Daniel Cohen wrote:

Not really wacky. the 'tell ...' is just a straighforward AppleScript,

and 'tell'(ing) the 'Finder' to sleep caused the computer to sleep? that's wacky.

Come to think of it, my version of the instructions was

tell "System Events" to sleep

That's a change in the way scripts work, but I'm not sure if it was introduced in Tiger or earlier.

The older version does make sense, though I see your point, given that 'sleep' is a menu item in the Finder.

No, 'sleep' is a menu item in the Apple Menu, which is shared by all applications.

Dave Seaman
U.S. Court of Appeals to review three issues
concerning case of Mumia Abu-Jamal.
<http://www.mumia2000.org/>

Message #17 - Posted 2006/01/03 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing†happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.

Huh? *No* code executes while the computer is sleeping. The CPU isn't even powered. And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #18 - Posted 2006/01/03 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

Then stuff, like sleep and probably some drivers, that does not fit into that model is added by code external to that. This is what is causing kernel panics,†external faulty code that the UNIX kernel†cannot handle. So if one should get the UNIX kernel to handle things like sleep, it must call an external Mac OS X program that can do the job. AppleScript evidently can do it (by the other posts).

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

Sure it is relevant, whether it is in the UNIX kernel, or if it is in non-UNIX†kernel extensions, as it affects reliability, for example.

The situations seems to be like that of Tenon BSD UNIX running as a program within Mac OS 9. In that case, the†reliability and capacities of the UNIX programs are limited by Mac OS 9 reliability.

For Mac OS X, it seems that one has added a mini-OS, by which the†FreeBSD and its Mach kernel run within.

There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs *on top* of this kernel.

But just because something is in the kernel, doesn't mean there's a *nix command to access it. And just because something is outside of the kernel, doesn't mean a *nix command can't access it.

The original the answer I gave, was for a UNIX shell command; I should have added that one must call something without that UNIX environment to get the effect. The answer given, using AppleScript, also gives hint that some of these things cannot be handled within the UNIX proper itself.

There *is* nothing in OS X which occurs outside of the *nix environment.

Sure, Apple has added commands by which it seems almost anything can be run from a suitable Apple shell command, and in later Mac OS X versions, more and more it put over to the UNIX part proper.

Once again, there is no separate UNIX environment in OS X. OS X is a *nix operating system. All the Mac-like stuff runs *within* this environment.

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #19 - Posted 2006/01/04 - Hans Aberg

Previously, ZnU wrote:

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing†happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.

Huh? *No* code executes while the computer is sleeping. The CPU isn't even powered.

It sounds logical. But there has something that brings it back to life. An interrupt of some kind.

And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

It can take minutes before the kernel is loading, though.

Hans Aberg

Message #20 - Posted 2006/01/04 - Hans Aberg

Previously, ZnU wrote:

There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs *on top* of this kernel.

So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads). So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

Hans Aberg

Message #21 - Posted 2006/01/03 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run. A similar thing†happens during boot: the UNIX kernel proper is only started after awhile after the Apple extension has booted.

Huh? *No* code executes while the computer is sleeping. The CPU isn't even powered.

It sounds logical. But there has something that brings it back to life. An interrupt of some kind.

Sure, but it's not part of the operating system, or any other software. It's a hardware feature.

And the kernel is the first part of the operating system to load at boot, though some code in firmware that loads first.

It can take minutes before the kernel is loading, though.

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

momentum:/ znu$ ls -l mach_kernel
-rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #22 - Posted 2006/01/03 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

There is no separate 'UNIX kernel' component in OS X. There's just a kernel, called 'xnu', which contains Mach code, code borrowed from various BSD systems, and a bunch of code written by Apple and NeXT over the last couple of decades. Then, there are a bunch of kernel modules which extend the kernel, to add support for specific hardware, file systems, etc. Everything else, including everything that makes OS X Mac-like, runs *on top* of this kernel.

So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads).

That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.

So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

Mach *is* a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.

The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.

There's a decent high-level overview at:

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #23 - Posted 2006/01/04 - Steven Fisher

Previously, ZnU wrote:

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

momentum:/ znu$ ls -l mach_kernel
-rw-r--r-- 1 root wheel 4330232 Oct 3 23:04 mach_kernel

Yeah, this confused me for a while, too. I think he is thinking of some of the maintenance tasks early in startup.

Steven Fisher; sdfisher@spamcop.net

Message #24 - Posted 2006/01/03 - Matthew Russotto

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

Power management, including sleeping, is definitely something handled within the kernel. Whether it's actually in the base kernel code or in a kernel extension isn't really relevant; it all ends up in kernel space at run-time.

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run.

The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.

There's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one.

Message #25 - Posted 2006/01/04 - Geoff Welsh

Matthew Russotto wrote:

The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.

I am hoping at this point, one of the readers of the "sleep from..." thread can give a hint as to why a mouse would not work after sleep?

iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking. The only two things I have found that work, are a reboot or unplugging the USB connection for the mouse receiver. I also tried using the "number keys as mouse option" to force-quit finder but that didn't help. Anything I can type in Terminal to reload something? (driver, extension, kernel, something else?)
I have installed the latest Logitech driver, but this seems USB related, not internal (right?)
GW

Message #26 - Posted 2006/01/04 - Hans Aberg

Previously, ZnU wrote:

It can take minutes before the kernel is loading, though.

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.

Hans Aberg

Message #27 - Posted 2006/01/04 - Hans Aberg

Previously, ZnU wrote:

So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads).

That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.

This is just the standard description of UNIX and BSD UNIX, as in books: Bach, "The Design of the UNIX operating system" Leffler et al., "The Design and Omplementaion of the BSD UNIX OS"

So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

Mach *is* a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.

The original Mach required a lot of information being passed thorugh it, making it slow, but later versions, I am told, have been more monolithic, whatever that means.

The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.

The question is really what controls what: If it is the Mach kernel that controls the rest, or if there is a kernel extension which controls the Mach kernel.

There's a decent high-level overview at:

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

Thanks for the link. But does not seem to address the kernel structure issue.

Hans Aberg

Message #28 - Posted 2006/01/04 - Hans Aberg

Previously, Matthew Russotto wrote:

One practical situation where it does make a difference whether it is in the UNIX kernel or in some Apple extension code, is when trying to run things during sleep. Then the UNIX kernel is turned off, and so for example, 'cron' jobs won't run.

The entire processor is turned off during sleep, kernel, Apple extensions, and all. Some of the power management runs on a separate processor called the PMU.

Thank you. So it is the PMU one should get rid of. :-)

Hans Aberg

Message #29 - Posted 2006/01/04 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

It can take minutes before the kernel is loading, though.

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.

When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #30 - Posted 2006/01/04 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

So how is this kernel structured then? I gather it can't be just a jumble of different code. A traditional UNIX kernel just handles processes (and threads).

That sounds more like a microkernel design. Most Unix and Unix-like systems aren't microkernel systems, these days.

This is just the standard description of UNIX and BSD UNIX, as in books: Bach, "The Design of the UNIX operating system" Leffler et al., "The Design and Omplementaion of the BSD UNIX OS"

So this other code added to the kernel must be handling something else. And then there needs to be some organization between the components.

Mach *is* a microkernel. As such, it doesn't provide very much; just low-level process management and message-passing, basically. The traditional approach, with microkernel systems, is to host a 'personality' on top of the microkernel which provides a larger set of basic system services, like a fully-fledged process model, networking, security, etc.

The original Mach required a lot of information being passed thorugh it, making it slow, but later versions, I am told, have been more monolithic, whatever that means.

The downside to this approach, however, is that if you implement this stuff outside of the kernel, you have to pass a lot of messages into and out of kernel space. This is slow. So, what Apple did in OS X, was move the BSD code that implements these higher-level services into kernel space, and integrate it more tightly with Mach.

The question is really what controls what: If it is the Mach kernel that controls the rest, or if there is a kernel extension which controls the Mach kernel.

There's a decent high-level overview at:

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology _Overview/index.html

Try:
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #31 - Posted 2006/01/04 - Hans Aberg

Previously, ZnU wrote:

It can take minutes before the kernel is loading, though.

Err? The kernel loads almost instantly. It's a little 4.3 MB file called 'mach_kernel' that lives at the root of the boot volume:

If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with the structure of the xmu kernel you mentioned.

When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.

Right, but they should load early on.

Hans Aberg

Message #32 - Posted 2006/01/04 - Hans Aberg

Previously, ZnU wrote:

http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramm ing/Architecture/chapter_3_section_3.html#//apple_ref/doc/uid/TP30000905- CH1g-TPXREF102

That is better. As for kernel vs. microkernel, there is probably a considerable flux as how to term what is what; see:
http://en.wikipedia.org/wiki/Kernel_%28computer_science%29 http://en.wikipedia.org/wiki/Microkernel

Hans Aberg

Message #33 - Posted 2006/01/04 - ZnU

Previously, Hans Aberg wrote:

Previously, ZnU wrote:

It can take minutes before the kernel is loading, though.

Err? The kernel loads almost instantly. It's a little 4.3 MB file called
'mach_kernel' that lives at the root of the boot volume:

If you set a cron job, it will not run at least one or two minutes after the computer has booted. So it seems that some significant non-UNIX stuff is run, before the UNIX daemons are started. It would then have to do with
the structure of the xmu kernel you mentioned.

When daemons are started is something controlled by the boot scripts and various other mechanisms, not by the kernel.

Right, but they should load early on.

Sure, daemons will typically load during the bit of the boot sequence where the progress bar is displayed. You can hold down command-v (which switches to verbose boot mode) to see some of this.

"Those who enter the country illegally violate the law." -- George W. Bush in Tucson, Ariz., Nov. 28, 2005

Message #34 - Posted 2006/01/04 - Matthew Russotto

Previously, Geoff Welsh wrote:

I am hoping at this point, one of the readers of the "sleep from..." thread can give a hint as to why a mouse would not work after sleep?

iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.

If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep. --
There's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one.

Message #35 - Posted 2006/01/05 - Geoff Welsh

Matthew Russotto wrote:

Previously, Geoff Welsh wrote:

iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem. Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.

If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.

Thanks. IIRC, without the Logitech driver, the mouse response was unbearable. (Adjust in AppleSysPrefs all the way fast but would still take a foot to drag across screen.)
I got this machine in July and the problem started in October or November. That's why I suspect an OS glitch from an update.
GW

Message #36 - Posted 2006/01/05 - Malcolm

On 2006-01-05 01:15:00 -0500, Geoff Welsh said:

Matthew Russotto wrote:

Previously, Geoff Welsh wrote:

iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem.
Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.

If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.

Thanks. IIRC, without the Logitech driver, the mouse response was unbearable. (Adjust in AppleSysPrefs all the way fast but would still take a foot to drag across screen.)
I got this machine in July and the problem started in October or November. That's why I suspect an OS glitch from an update.
GW

You could try removing the Logitech drivers and installing USB Overdrive. <http://www.usboverdrive.com>

Message #37 - Posted 2006/01/06 - Geoff Welsh

Malcolm wrote:

On 2006-01-05 01:15:00 -0500, Geoff Welsh said:

Matthew Russotto wrote:

Previously, Geoff Welsh wrote:

iMac 2 GHZ G5 running OS 10.4.3. I am using the same Logitech cordless mouse that I had plugged in to my 333mhz G3 iMac, and never had a problem.
Now, after the maybe 6th or 7th time the machine sleeps, there is no mouse response upon waking.

If the mouse works without it, you might try removing the Logitech drivers entirely. Getting sleep/wake right on OS X is tricky, and it's possible Logitech has some bugs in there. I don't think it's a hardware issue, as the USB bus remains powered up during sleep.

Thanks. IIRC, without the Logitech driver, the mouse response was unbearable.
That's why I suspect an OS glitch from an update.
GW

You could try removing the Logitech drivers and installing USB Overdrive. <http://www.usboverdrive.com>

Good tip, thanks. I started reading about that Overdrive the other day, but haven't finished.
Anyone know how to remove a driver? It shows in the "Other" section of System Prefs as "Logitech Control Center"
GW

Need Help? Have a Question?

Looking for more help, comments, and answers?

Ask your questions on Ask Different. Ask Different is a community of Apple users ready to help.