Yeah, except it seems like lately every other application that you install on a mac has it's own installer and doesn't use the drag-and-drop method. Adobe I'm looking at you.
The KILL signal does not allow a process to run any cleanup code, which means blasting away with kill -9 may leave
child processes of a parent orphaned
The child processes should check to see if the parent process is still running. Anyway, they'll probably die from SIGPIPE the next time the try to communicate with the parent.
temporary files open
No. It may leave temporary files existing, but not open. Some really smart programs even unlink(2) temporary files after they're open so that this isn't an issue.
shared memory segments active
That's an unfortunate result of a gaping design flaw in SysV IPC. Sometimes even processes that exit gracefully will forget to remove all their shared memory segments and semaphores. Judicious use of ipcs -mp is recommended.
and sockets busy
Again, incorrect. The kernel will automatically close all sockets (and any file descriptors for that matter) as part of its process cleanup. Even when you use kill -9.
Hence why I said "Regular kill, followed by a kill -9 if that doesn't work".
Those sites you posted have things a bit confused as well. If a process doesn't respond to SIGTERM, sending a SIGINT seems a little pointless. If anything, the order is reversed. A proper escalation would be something like this:
kill -HUP (user disconnected from terminal) kill -INT (user pressed CTRL+C) kill -TERM (user wants the process to exit) kill -KILL (user isn't giving it a choice anymore, wants OS intervention)
There are many programs that trap SIGHUP to re-read config file, and SIGINT (see vim/emacs or even bc) that will do a proper shutdown when sent SIGTERM. Sending them after a SIGTERM fails seems a bit wrong.
At least -9 isn't as evil as say, kill -BUS or kill -11;)
Yeah, no kidding. I've always considered myself a late-comer to slashdot (though I did read headlines for a long while before registering, probably could have snagged one in the 100,000 range if I wasn't lazy).
Under 300,000 is definitely not low ID. Under 100,000 maybe.
Use 'End Process' on the processes tab rather than 'End Eask' in the applications tab.
'End Task' sends the application's window a WM_QUIT message and gives it a chance to exit gracefully before timing out and prompting you to kill the process.
'End Process' kills the process immediately, like sending a kill -9.
FYI, xkill only seems to be fast because it causes the X server to immediately delete the target window. The actual process that was creating the window may or may not exit in a timely fashion when its connection is closed (if it's deadlocked, perhaps never). Regular kill, followed by a kill -9 if that doesn't work is the only sure way to go. Even then kill -9 may not work if the process is stuck in the kernel somewhere (e.g. NFS server disappeared).
Gah, you got lucky then. We have a Konica Minolta (forget exactly which model) with a Fiery X3e print controller (runs Linux!). Piece of crap doesn't have a working DHCP client so we were forced to make it be the only statically assigned IP in the company. Even then every few days it simply stops working and requires a power cycle to get the print controller back on the network. Minolta's been out a dozen times to look at it and have never been able to get it working acceptably.
We also have a bunch of Bizhub C351s which work mostly okay, though after a week or two the scanner component mysteriously stops uploading until the unit is power cycled.
Last I checked Dell printers were mostly rebranded Lexmarks (a brand I'll never buy again due to general crappy quality and bogus DMCA claims). Does anyone know if this is still the case or not?
Anyway, Linux lacks the secure media data paths technology that's required to implement AACS, the DRM used by HD-DVD and BR discs....on purpose.
Linux is all about an open architecture. So-call "secure" data paths are only possible in a closed, tightly controlled system.
Not that it's going to make a difference anyway. MS can require all the signed drivers they like but it will still get hacked. You can install all the TPM chips you want, but guess what: I'd bet some of the people working to bypass or compromise them are the same ones who helped design them at their day jobs. Physical access will always be the ultimate trump card, and information will always be copyable.
That's what happens when you try to enforce an idea that's almost a complete polar opposite of reality.
Pffft. With unlimited energy things like global warming become meaningless. You'd have enough energy to just move all the heat somewhere else (out past the atmosphere).
Not that I believe for a second these guys have managed to tap into some magical free magnetic energy. Might as well try to extract vacuum energy from an artificial pocket of subspace.
Funny you should make that statement; video via RDP on my locally connected 100Mbps link is absolutely horrible.
Ironically, I just discovered that video over X11 on a 100Mbps link worked much better than I expected.
I recently converted my old desktop into a pseudo docking station for my laptop, since the laptop is a faster machine but lacks the dual DVI connectors of a real video card. The laptop gets connected via a crossover cable to the desktop -- the laptop only has 100Mbps crappy builtin realtek. Everything gets remote displayed to the X server running on the desktop.
2D performance in KDE is great; almost indistinguishable from running locally. 3D is so-so, for that reason xscreensaver runs locally on the desktop.
Just for the hell of it, I tried running mplayer on the laptop to play a movie over the remote X11 connection. I expected it to be slow and choppy, trying to push that much information over a 100mbps connection. To my great surprise, the video was smooth and fluid. Since Xv handles the scaling on the server end, I could even fullscreen it without any slowdown. It probably wouldn't be able to handle HD resolutions, but for 640x360 divx files it was perfectly acceptable.
That doesn't make sense. VMware should provide exactly the same virtual hardware to the guest no matter what physical computer you run the image on. In fact, that is one of the biggest selling points for VMWare.
While that's true for most of the emulated hardware (SCSI/IDE controller, video, etc), there is a bit of "bleed-through" from the physical host. For example, CPU features such as MMX, SSE, and instructions that are specific to a certain CPU class will only be available if the physical CPU supports them. I mostly use BSD and other Unixish OSes, so I have to be careful not to specify too aggressive of a CPU optimization when compiling software otherwise it might have problems if migrated to a machine with a lesser CPU. This is also the reason VMware warns you if you try to resume a virtual machine that was suspended on another physical host.
Windows software usually targets i486 as the lowest-common-denominator (though that may have changed in Vista), so I'm not sure how it could be affected. Perhaps some software is saving information about CPU features persistently rather than detecting them at runtime...
Servers are much more likely to be network I/O bound, physical I/O bound, or CPU bound. VMware has done a lot of work to create accelerated network and disk drivers that communicate directly with the host VM software, avoiding the overhead of emulating hardware. Additionally, most software that runs on a server spends a lot of time processing things in user mode with occasional system calls to transfer chunks of data, so the VM overhead is very low for those applications.
Desktops are much more demanding on I/O. Applications with a GUI are constantly context switching between user mode and the kernel in order to update the screen, display pretty animations, get keyboard / mouse input, etc. Just drawing the graphics for a 1280x1024x24bpp display is an immense data transfer burden that has to be routed through the VM, often a few dozen pixels at a time rather than a bulk transfer. Even with accelerated drivers, the virtual framebuffer still has to be copied / multiplexed into the real one. Even small increases in latency are very user-perceptible, so a VM will seem more "sluggish" than a physical machine.
That's just for business applications. Once a user starts playing audio (it'll be uncompressed 44/48khz PCM data by the time it gets to the VM!), streaming video (no access to the hardware YUV conversion or scaling!), or trying to do anything that needs 3D acceleration, the full impact of the virtualization will be felt.
-- Ironically, the spell checker in Konqueror wanted to change "VMware" to "Vampire"
Seems like this would be a good case to challenge EULAs in general on. It's not out of the realm of possibility for a jury to decide that a provision saying you can't run software that you legally purchased on hardware that you own is unreasonable.
Apple says I don't have a right to run their software (that they're selling to the general public) unless I agree to their terms. I disagree -- and fair use case law would seem to support me.
Unfortunately I think Apple is too smart to try to enforce the EULA by suing individual users; they know their case is too weak. They'll try to shut down the sites that tell people how to do it by abusing DMCA or some such.
Slashdot Mirror
As someone who has worked on many of them over the last 5-6 years, I can tell you that the Vaio (at least the laptop line) was never a great product.
Errr, how is that possible? Surely they had to change the release name in there somewhere to remove the "RC".
If you immediately know the candlelight is fire, the meal was cooked a long time ago!
Bravo. That quote should be used in slashdot posts more often.
--
Though a candle burns in my house, there's nobody home.
I'm all for breeder reactors reusing fuel, but the liquid sodium coolant of IFR just seems like a bad idea to me...
Hell, if this goes pear shaped, you could drop the core miles beneath the sea never to be seen again.
Didn't you learn from Star Trek that core ejection systems never work when you need them to?
Yeah, except it seems like lately every other application that you install on a mac has it's own installer and doesn't use the drag-and-drop method. Adobe I'm looking at you.
...and then he ran into my knife. He ran into my knife ten times.
If Amazon is high up on the results list and Firefox is doing prefetching on the top few links, might that be how the Amazon cookie is getting set?
The KILL signal does not allow a process to run any cleanup code, which means blasting away with kill -9 may leave
- child processes of a parent orphaned
The child processes should check to see if the parent process is still running. Anyway, they'll probably die from SIGPIPE the next time the try to communicate with the parent.- temporary files open
No. It may leave temporary files existing, but not open. Some really smart programs even unlink(2) temporary files after they're open so that this isn't an issue.- shared memory segments active
That's an unfortunate result of a gaping design flaw in SysV IPC. Sometimes even processes that exit gracefully will forget to remove all their shared memory segments and semaphores. Judicious use of ipcs -mp is recommended.- and sockets busy
Again, incorrect. The kernel will automatically close all sockets (and any file descriptors for that matter) as part of its process cleanup. Even when you use kill -9.Hence why I said "Regular kill, followed by a kill -9 if that doesn't work".
;)
Those sites you posted have things a bit confused as well. If a process doesn't respond to SIGTERM, sending a SIGINT seems a little pointless. If anything, the order is reversed. A proper escalation would be something like this:
kill -HUP (user disconnected from terminal)
kill -INT (user pressed CTRL+C)
kill -TERM (user wants the process to exit)
kill -KILL (user isn't giving it a choice anymore, wants OS intervention)
There are many programs that trap SIGHUP to re-read config file, and SIGINT (see vim/emacs or even bc) that will do a proper shutdown when sent SIGTERM. Sending them after a SIGTERM fails seems a bit wrong.
At least -9 isn't as evil as say, kill -BUS or kill -11
CGI 4 EVER
Yeah, no kidding. I've always considered myself a late-comer to slashdot (though I did read headlines for a long while before registering, probably could have snagged one in the 100,000 range if I wasn't lazy).
Under 300,000 is definitely not low ID. Under 100,000 maybe.
Use 'End Process' on the processes tab rather than 'End Eask' in the applications tab.
'End Task' sends the application's window a WM_QUIT message and gives it a chance to exit gracefully before timing out and prompting you to kill the process.
'End Process' kills the process immediately, like sending a kill -9.
FYI, xkill only seems to be fast because it causes the X server to immediately delete the target window. The actual process that was creating the window may or may not exit in a timely fashion when its connection is closed (if it's deadlocked, perhaps never). Regular kill, followed by a kill -9 if that doesn't work is the only sure way to go. Even then kill -9 may not work if the process is stuck in the kernel somewhere (e.g. NFS server disappeared).
Gah, you got lucky then. We have a Konica Minolta (forget exactly which model) with a Fiery X3e print controller (runs Linux!). Piece of crap doesn't have a working DHCP client so we were forced to make it be the only statically assigned IP in the company. Even then every few days it simply stops working and requires a power cycle to get the print controller back on the network. Minolta's been out a dozen times to look at it and have never been able to get it working acceptably.
We also have a bunch of Bizhub C351s which work mostly okay, though after a week or two the scanner component mysteriously stops uploading until the unit is power cycled.
Never buying Konica Minolta again.
Last I checked Dell printers were mostly rebranded Lexmarks (a brand I'll never buy again due to general crappy quality and bogus DMCA claims). Does anyone know if this is still the case or not?
I suspect the MPAA will refuse to licence the HDCP decoding tech to anyone that doesn't go to extreme lengths to "protect" their content.
You mean just like VLC and mplayer licensed the CSS decoding algorithm from the DVD-CCA?
Grrrr, stupid slashdot non-deterministic formatting.
"...on purpose" was supposed to be in the next paragraph, not part of the original quote.
Anyway, Linux lacks the secure media data paths technology that's required to implement AACS, the DRM used by HD-DVD and BR discs. ...on purpose.
Linux is all about an open architecture. So-call "secure" data paths are only possible in a closed, tightly controlled system.
Not that it's going to make a difference anyway. MS can require all the signed drivers they like but it will still get hacked. You can install all the TPM chips you want, but guess what: I'd bet some of the people working to bypass or compromise them are the same ones who helped design them at their day jobs. Physical access will always be the ultimate trump card, and information will always be copyable.
That's what happens when you try to enforce an idea that's almost a complete polar opposite of reality.
I thought they were going to call it the Double Virus Defense Advantage (DVDA)
Pffft. With unlimited energy things like global warming become meaningless. You'd have enough energy to just move all the heat somewhere else (out past the atmosphere).
Not that I believe for a second these guys have managed to tap into some magical free magnetic energy. Might as well try to extract vacuum energy from an artificial pocket of subspace.
/Where's my ZPM?
Funny you should make that statement; video via RDP on my locally connected 100Mbps link is absolutely horrible.
Ironically, I just discovered that video over X11 on a 100Mbps link worked much better than I expected.
I recently converted my old desktop into a pseudo docking station for my laptop, since the laptop is a faster machine but lacks the dual DVI connectors of a real video card. The laptop gets connected via a crossover cable to the desktop -- the laptop only has 100Mbps crappy builtin realtek. Everything gets remote displayed to the X server running on the desktop.
2D performance in KDE is great; almost indistinguishable from running locally. 3D is so-so, for that reason xscreensaver runs locally on the desktop.
Just for the hell of it, I tried running mplayer on the laptop to play a movie over the remote X11 connection. I expected it to be slow and choppy, trying to push that much information over a 100mbps connection. To my great surprise, the video was smooth and fluid. Since Xv handles the scaling on the server end, I could even fullscreen it without any slowdown. It probably wouldn't be able to handle HD resolutions, but for 640x360 divx files it was perfectly acceptable.
That doesn't make sense. VMware should provide exactly the same virtual hardware to the guest no matter what physical computer you run the image on. In fact, that is one of the biggest selling points for VMWare.
While that's true for most of the emulated hardware (SCSI/IDE controller, video, etc), there is a bit of "bleed-through" from the physical host. For example, CPU features such as MMX, SSE, and instructions that are specific to a certain CPU class will only be available if the physical CPU supports them. I mostly use BSD and other Unixish OSes, so I have to be careful not to specify too aggressive of a CPU optimization when compiling software otherwise it might have problems if migrated to a machine with a lesser CPU. This is also the reason VMware warns you if you try to resume a virtual machine that was suspended on another physical host.
Windows software usually targets i486 as the lowest-common-denominator (though that may have changed in Vista), so I'm not sure how it could be affected. Perhaps some software is saving information about CPU features persistently rather than detecting them at runtime...
Server != Desktop
Servers are much more likely to be network I/O bound, physical I/O bound, or CPU bound. VMware has done a lot of work to create accelerated network and disk drivers that communicate directly with the host VM software, avoiding the overhead of emulating hardware. Additionally, most software that runs on a server spends a lot of time processing things in user mode with occasional system calls to transfer chunks of data, so the VM overhead is very low for those applications.
Desktops are much more demanding on I/O. Applications with a GUI are constantly context switching between user mode and the kernel in order to update the screen, display pretty animations, get keyboard / mouse input, etc. Just drawing the graphics for a 1280x1024x24bpp display is an immense data transfer burden that has to be routed through the VM, often a few dozen pixels at a time rather than a bulk transfer. Even with accelerated drivers, the virtual framebuffer still has to be copied / multiplexed into the real one. Even small increases in latency are very user-perceptible, so a VM will seem more "sluggish" than a physical machine.
That's just for business applications. Once a user starts playing audio (it'll be uncompressed 44/48khz PCM data by the time it gets to the VM!), streaming video (no access to the hardware YUV conversion or scaling!), or trying to do anything that needs 3D acceleration, the full impact of the virtualization will be felt.
-- Ironically, the spell checker in Konqueror wanted to change "VMware" to "Vampire"
Seems like this would be a good case to challenge EULAs in general on. It's not out of the realm of possibility for a jury to decide that a provision saying you can't run software that you legally purchased on hardware that you own is unreasonable.
Apple says I don't have a right to run their software (that they're selling to the general public) unless I agree to their terms. I disagree -- and fair use case law would seem to support me.
Unfortunately I think Apple is too smart to try to enforce the EULA by suing individual users; they know their case is too weak. They'll try to shut down the sites that tell people how to do it by abusing DMCA or some such.
For firefox, you want to set middlemouse.contentLoadURL to false (use about:config).
Konqueror has a similar feature, but there's a check box in the options dialog to turn it off (Middle click opens URL in selection).