Slashdot Mirror
Intel Slashes Computer Startup Times
An anonymous reader writes "At Intel's Developer Forum in Taiwan, Intel introduced a new Non-volatile caching technology called 'Robson'." The new Robson cache technology allows computers to start up almost immediately and load programs much faster. Intel declined to comment on the specifics of how the technology works only saying that 'More information will be revealed later'.
From TFA:
"Chipmaker demonstrates 'Robson' flash memory to boost laptop startup speeds."
Mystery solved.
- boot to login = 29 sec.
- login = ~25 sec (extended by startup items like iCal and stickies)
- shutdown = 11 sec
These numbers are a huge improvement to 10.3.9 running on my cube but then again the cube is nearly 5 years old.Regarding the non-volatile booting, I would like to point out that my C-64 was already doing that.
Most of the boot time of a camera isn't memory loading, its hardware initialization and calibration.
I still have more fans than freaks. WTF is wrong with you people?
Yes... osx boot times completely suck. That's why I only reboot after updates.
Time from opening lid of powerboot to idle desktop: 2-3 sec.
Time from closing lid of powerbook to glowing white "sleep" light: 4-5 seconds, but doesn't much matter.
I wouldn't want to be called an apologist or anything, but my laptop seems *way* faster to me than my xp box, just because my pb is essentially instant-on, what with the quick sleep times. It is annoying when you have to do a full boot though. Although 10.4 is some better in this regard than 10.3. Guess it's dictated by usage. Perhaps they spent time optimizing sleep times, not boot times, in that they expected people to sleep more often. Dunno.
Someone feel free to correct me if I'm wrong, but Acrobat 7 finally fixed the issue of loading a bazillion plugins at startup that almost no one uses. I believe it now dynamically loads them as needed.
Load times for Acrobat 7 vs. Acrobat 6 are clearly far less. The fix often mentioned is to delete/move non-key plugins from the Acrobat plugin folder, but their solution finally fixes the problem in an elegant way.
You complain about the zoom extending. Uhu, have you looked at compact multi-element zoom designs? 12 or more elements, many or even most of which geared independantly is not uncommon. The longer the zoom - comsumer guys want optical 10 times zooms, which would be unheard of in a professional lens for many other considerations (predominantly aperture speed and distortion characteristics) and that means even more complicated designs, even allowing small lenses are easier and simpler to design. Now try shifting all those elements _accurately_ with a tiny low voltage low torque servo (see why it's low torque here - too fe2w turns possible in such a small space to get a focus throw long enough to try to do this quickly and accurately and repeatably*). This is why my piezo-wave-effect ring-motor driven Nikkor zoom is several times more expensive of itself than almost any digicam.
Got the idea?
To the above poster - i sure hope there's not much calibration going on when i boot my Nikon. Unless it's to compensate for working temperature effects, if i've spent time and effort having a lens tuned to how i like it (yes this doesn't just happen, it's common) i want it to be left alone at that spec. Now that even modest digicams such as the Fuji F10/11 boot instantly and respond extremely quickly, there's simply no excuse for slow electronics and (electronic) shutter save at the real budget segment.
* even some (sadly many) professional photogs insist on continuing the myth that because the lens / sensor is small, everything remains sharp because the DOF (depth of field) is greater in those conditions. Er, DOF is a psychological effect which is a function of the print enlargement factor, print size, viewing distance and airy dic resolving limit - so the assumption is not true at equivalent apertures, hence the need even in very small "format" cameras to _still_ focus accurately, in OP's case, sadly, slowly too. The effect observed is anecdotally true however at small print sizes like 6" by 4".
The difference is, in unix type systems, SIGTERM and SIGKILL are handled by the OS and the process is only informed of them (so it can try to shut down properly), in Windows, the process is being asked nicely to close. Windows process is free to ignore these events.
No, no, and no. It's true that in the "Tasks" or "Applications" tab, hitting End Task will send a request (WM_QUIT) to exit. That's not what I'm talking about. I mean the Processes tab. That is handled by the OS; it routes through Win32 first but ends up at NtTerminateProcess (ZwTerminateProcess). Go read the API reference or even the DDK if you don't believe me. Maybe in the dark days of Win9x that was true, but the NT kernel is a real OS, no matter what other crap you layer on top of it.
There are only three states a process can be in where it's unkillable.
1. "Access denied". This happens on some system processes because they run as the user SYSTEM (equivalent to root), where your task manager process is not. The security descriptor on those processes is set so that nobody except SYSTEM (not even Administrators) can kill them. They can be killed by running task manager as SYSTEM. There are various methods to run a process under the system account; the easiest is by using the "at" command to have the scheduler service start it. Newer versions of task manager also have a list of processes it will refuse to kill, but you can still kill them by using pskill or some other third-party utility that has no such restrictions.
2. Process is stuck in the kernel somewhere. Happens when system calls never return, which isn't supposed to happen. Often due to bad drivers -- even with flaky hardware it SHOULD timeout eventually. I've seen add-on firewall software that hooks the TCP stack and can cause this condition. Sometimes you can get one unstuck by kicking the kernel in the head (i.e. removing or stopping the offending device), otherwise a reboot is the only way to clear it. Unless you're running a checked build with a remote serial debugger, but not many people outside of driver developers do that.
3. Process has a debugger attached. In this case, simply kill the debugger instead.