Slashdot Mirror

no one knows the day or hour when these things will happen,

So all I have to do is write a cron script:

0 * * * * echo "I Predict The World Will End This Very Hour" | mail -s "IMPORTANT -- READ THIS NOW" Pope@Vatican.va God@Whitehouse.gov GodJr@Heaven.com

...and the world will never end. Problem solved -- well THAT was easy.

- Paul Cron:5 - Crontab:5


For my next act: Whirled Peas, anyone?

Really: the only thing that actually upsets me about the EotW people are the idiots that actually want to help make it happen.

Putting an @reboot entry in the user's crontab would start anything you want when the machine boots, without the user even logging in.

...and would do so not only on OS X, but on many Linux distributions and FreeBSD and NetBSD and OpenBSD and....

For the possibility that you are being sincere...it's a frequently used Unix command that, in some of its simpler usage forms, copies the contents of a file to another file, or to a communications port (such as the serial port as discussed here), or to the computer's screen.

Hmmm... You've made it clear you're not expecting free hardcopy, so you must be wanting links.

Of course to have found that you probably would have needed some uber-l337 mad google skillz.

First of all, this is completely irrelevant to what I said.

Secondly, it actually would make sense to lock a running executable.

Most advanced operating systems read code pages from the executable. That is, when they need to make room in RAM, rather than swapping out parts of the executable, they just toss them. When they need that part of it back, they just reload it from the executable.

So, if you do something like this while myprog is running:

vi myprog.c

gcc myprog.c -o myprog

there's a good chance that myprog will crash as a result. This is because gcc overwrites the file "myprog" in place.

If, instead, you do this:

vi myprog.c

rm myprog

gcc myprog.c -o myprog

then you're fine, for the reason the parent described:

Basically, *nix filesystems keep a list of links to a file. The filesystem doesn't erase the file until there are no more links to it. Most of the time, a link is a directory name but if there's an open filehandle to that file or if it is a running executable, that also links to the file.

The "rm" file unlinks the file from the current directory but because the program is still running, the file continues to exist, albeit without a name so the program can keep running.

Of course, if you don't unlink the file before recompiling, gcc opens the same file for writing and overwrites a new executable into it. The OS, the next time it needs to page, reads the file from that but since it's now a different executable, the program crashes. This used to happen to me all the time before I wised up and put an "rm" command before the final link in my Makefiles.

But what does this have to do with locking? Not much.

It'd be nice if Linux locked running executables in a manditory way, but not enough to really be a bother.

And anyway, as I said in the grandparent, *nix locks are (usually) advisory, not mandatory. Really. It's in the Fine Manual.

First of all, this is completely irrelevant to what I said.

Secondly, it actually would make sense to lock a running executable.

Most advanced operating systems read code pages from the executable. That is, when they need to make room in RAM, rather than swapping out parts of the executable, they just toss them. When they need that part of it back, they just reload it from the executable.

So, if you do something like this while myprog is running:

vi myprog.c

gcc myprog.c -o myprog

there's a good chance that myprog will crash as a result. This is because gcc overwrites the file "myprog" in place.

If, instead, you do this:

vi myprog.c

rm myprog

gcc myprog.c -o myprog

then you're fine, for the reason the parent described:

Basically, *nix filesystems keep a list of links to a file. The filesystem doesn't erase the file until there are no more links to it. Most of the time, a link is a directory name but if there's an open filehandle to that file or if it is a running executable, that also links to the file.

The "rm" file unlinks the file from the current directory but because the program is still running, the file continues to exist, albeit without a name so the program can keep running.

Of course, if you don't unlink the file before recompiling, gcc opens the same file for writing and overwrites a new executable into it. The OS, the next time it needs to page, reads the file from that but since it's now a different executable, the program crashes. This used to happen to me all the time before I wised up and put an "rm" command before the final link in my Makefiles.

But what does this have to do with locking? Not much.

It'd be nice if Linux locked running executables in a manditory way, but not enough to really be a bother.

And anyway, as I said in the grandparent, *nix locks are (usually) advisory, not mandatory. Really. It's in the Fine Manual.

Within the Linux 2.6 kernel, the window size for the send buffer is taken as defined by the user in the call, but the receive buffer is doubled automatically. You can verify the size of each buffer using the getsockopt call.

NOTES

Linux assumes that half of the send/receive buffer is used for internal kernel structures; thus the sysctls are twice what can be observed on the wire.

VERSIONS

SO_BINDTODEVICE was introduced in Linux 2.0.30. SO_PASSCRED is new in Linux 2.2. The sysctls are new in Linux 2.2. SO_RCVTIMEO and SO_SNDTIMEO are supported since Linux 2.3.41. Earlier, timeouts were fixed to a protocol specific setting, and could not be read or written.

NOTES

Linux assumes that half of the send/receive buffer is used for internal kernel structures; thus the sysctls are twice what can be observed on the wire.

Display a dialog, asking Microsoft Windows has been found! Would you like to remove it?. The return code will be 0 (true in shell) if OK is selected, and 1 (false) if Cancel is selected.

zenity --question --title "Alert" --text "Microsoft Windows has been found! Would you like to remove it?"