Search results

Your (gnome) process is swapping madly because you honestly oughtn't be running openorfice with only 128M of RAM (gnome) periodic weekly is running and your timezone is set wrong so it's indexing your hard-drive in the middle of siesta (porn) time You have a bad habit of punching the power...

High Compatibility #1! Who could say no to that?

That isn't a hard rule, AFIK. Programs that exit immediately (xset being an obvious candidate) will leave your process list littered with zombie shes. Not harmful, but annoying. What I've done in the dim & distant past is to create an executable script named ~/.xsession like #!/bin/sh...

Well, it's 100% uptime with a margin of error of -+10%, you understand. Or, to put it another way, guaranteed 100% uptime with a confidence of 95.4%.

Well, suffice it to say that it's a bit dense for me (and based on the concentrations of CH3CH2OH coursing through my bloodstream, probably will be for a while), but login.conf looks like your beast, yeah?

It is supposed to be SCO compatible (as with ibcs2.ko et al), though running file on the executables contained within gives: > file ./* ./doscopy: MS Windows COFF Intel 80386 object file ./isis: MS Windows COFF Intel 80386 object file So I dunno what to say.

I would back up /etc/ when I was able to log in and then diff that against the running copy of /etc/ when I wasn't able to log in.

If the filesystem is still there you can force mount it dirty or mount it read-only to backup your information.

If it is a timing issue, you could also place a sleep in your script.

tunefs will not, AFIK, as the ufs label is stored in the same place as the other ufs information. And glabel will if there is information in that last sector, otherwise no. Also, you need to have swap turned off on that partition to label it properly, so it should be # swapoff -a # glabel...

Easier to use tunefs from a fixit disk (using tunefs in single user mode the label won't "stick" to your root filesystem) as tunefs -L hostnamerootfs /dev/da0s1a & mount your root fs and edit its etc/fstab.

If you don't pass the -f flag it'll leave anything that something else depends upon, so it's generally very safe like that. ports-mgmt/pkg_cutleaves also does a dandy job of removing unneeded libraries safely & recursively, as well.

You can grab a ufsid via dumpfs as dumpfs filesystem| grep id > dumpfs /usr | grep id superblock location 65536 id [ 4bce0894 1a07cb0c ] That number can be used prior to filesystem mount (usually by adding it to your /etc/fstab) as /dev/ufsid/4bce08941a07cb0c. You can also use...

presenting with crisp, golden skin and a moist interior. After an initial diagnosis of "yum", patient was treated with a liberal dose of gravy and mashed potatoes. Sadly the patient did not survive the procedure.

I cannot confirm any particular slow-ness (it's faster than trying to resolve google.com, in any case), but my intar-net has pretty terrific latency and bandwidth anyway. Yay for 4G.

Thanks for the heads up on that. There is also a thread here about camcontrol for fiddling /dev/ada* device timeouts, but I'll be damned if my drinking will let me find it.

ports-mgmt/pkg_cutleaves has a -V mode that provides a vi interface with one-line descriptions. If you make a mistake, you can say "no" at the prompt, & it will check for newly leaf ports after you delete something. It's fun! Try it! If you don't know at least some vi syntax you might take...

Get Off My Lawn

No, Apple uses a variant of the mach kernel. There is some FreeBSD userland under there (I think they even use tcsh as the standard shell), and you can use gcc of various versions, but anything that requires their proprietary libraries won't port.

Doesn't your shell parse the wildcards first and then pass it to rm? & wouldn't that be affected by which shell you are using?