World: r3wp

Use Syllable. :-) It gives scheduling priority to the user interface

We've had bugs with some applet using 100% CPU that people didn't 
notice for a long while because it didn't affect operation :-)

stats - inside rebol. Hmm.. that could help sometime, but I'm looking 
for something that can restrict any linux app.

I just read about AppArmor being used more in Ubuntu 8.04 HardyHeron. 
I will look into that.

Anton; look at   nice

Good idea, I will see how nice changes things.

And   priocntl  may help  too

Kaj, that is a good feature.

I'll look at priocntl too.

But a user-oriented scheduler versus a server-oriented scheduler 
(as Kaj mentioned with Syllable already on the crest) will be the 
next wave in Desktop Linux, umm, I hope.

We've been hearing that and similar claims for a decade

Improving one segment of a chain, even if it's the weakest one, only 
exposes the next-weakest

A scheduler is not much use if the rest of the system doesn't present 
meaningful pieces to schedule

Major apps like Thunderbird and REBOL effectively locking the rest 
of the system means that the system is not meaningfully handling 
apps in a concurrent way, so I would venture to say that the scheduler 
has very little if any effect on this

In fact, Syllable used to have a very primitive scheduler and was 
already as responsive as now, except for some corner cases

Does mounting a filesystem change anything on the filesystem ?

I'm on Kubuntu and I've taken a new laptop's 80GB internal disk into 
an external drive enclosure and connected it via USB to my computer.
Kubuntu detected it and automounted the filesystem.

My task was to duplicate the disk, in the pursuit of which I've used 
various combinations of dd and gzip.

However, I can't get a straight 80GB image to compare equally (using 
cmp or diff) with a compressed image.

(I decompress the compressed image on the fly and pipe it into cmp.)

After many hours, it occurs to me that having the filesystem mounted 
might be changing it slightly over time... which would make my images 
different. (This would make my mission a failure, as I wanted a pristine 
image.)
So can anyone answer the above question ?

From the depths of my memory comes a blurry message from someone 
who did this exact thing... I think I should have made sure not to 
automount it, and only mount it read-only. :-/

But the evidence collected so far does not support this theory strongly, 
actually... Hmm... It's confusing.

Linux does track accesstime to files.  So, I'd wouldn't be surprised 
if mounting doesn't touch at least a few bits.

Yes... (damn)... this discussion of atime agrees with that
http://lwn.net/Articles/244829/

I'm a little bit confused;  I didn't read the dd and gzip part until 
just now.  You want a compressed mirror?  I don't think that will 
ever cmp true to the original.   dd will include partition table 
info that is normally "invisible to the naked eye".  Including that 
in the compressed file doesn't give dd the chance to dump the invisible 
bits back into invisible places.


Or am I more than just a little bit confused?  Maybe Kaj will come 
by shortly and fill us in with the technicals instead of the voodoo. 
 :)

if it's journaled, mounting it will probably change the journal. 
also, mounting it will surely change a flag in the filesystem. you 
need to mount it read only.

Yes, this all makes sense in retrospect, now. Thanks for the confirmation.

Mounting it on juggernauts like (K)Ubuntu is also likely to unleash 
automatic indexing tools on the partition

Unless I'm very mistaken, you don't have to mount a disk to dd it, 
as dd works on bare disk blocks

Otherwise, indeed mount it read-only

For backup purposes, be aware that dd-ing a partition mounted read-write 
is likely to result in a more or less inconsisten state of the backup, 
as data is changed on the partition at the same time, and dd has 
no knowledge of the file structure

Also, you would only be able to restore the dd backup to a disk of 
exactly the same size

Kaj, you're right. dd works at device level. After practising my 
mount skillz, I can automount it 'ro', so this is looking good. (There 
is only a HAL error to deal with now, during unmount.)

(sorry, HAL error, during "Safely remove").

(I umount it myself)

I have sshd running on my Kubuntu, and when I fish: across to it 
from another kubuntu box on the local network, it takes a long time 
to connect. Today I counted 45 seconds before authentication dialog 
popped up. I think I remember reading something about a delay for 
encryption etc. but I'm wondering if that's a "normal" length of 
time to wait.

45 seconds seeems long.  My nodes usually (including Dev - old) in 
under 4.

One point; you set no root login in /etc/ssh/sshd_config ?  Otherwise 
brute force password attackers will try, and try, and try...  I'm 
not sure why ssh ships with root login enabled.  If an admin is remote 
configuring a bunch of nodes, let them configure it to allow; ti 
shouldn't be a default imho.

Thanks Brian, I will investigate further this delay.

I have a long password, so brute force attackers should be kept at 
bay.

Anton.. dont be fooled by thinking your ssh password is save.. the 
remote root user knows it anyway... ;-)

:-)

That's true, actually, the remote computer could be compromised and 
then keylog me. But I set up the "remote" computer, being my flatmate's 
in the next room. I can't remember if our firewall allows ssh between 
local and wide area network...

I think that needs a port-forwarding rule and there isn't one enabled 
for ssh.

wouldn't it be better to disable password, use a key, move from port 
22 to some other port (just to reduce noise) , port knocking.. ?

Anton... You could use "FUSE" very easy quick sshFS mount...  works 
like a charm. no sftp scp or ssh needed to access the remote fs....http://fuse.sourceforge.net/sshfs.html

Yes; there are quite a few ways to secure Secure Shell ... but you 
do have to stay on your toes.  Just turning it on ... bad idea.  
;)  With most distros that is ... Cygwin included.  There are copies 
that default to lockdown and you have to work to open them up, but 
those are the exception still.   Assigning ports above 1024 is always 
smart, and the $40 firewall routers can easily be setup to forward 
port 22 or 80 etc, to a usermode port.  You might still get broken 
into, but at least not with root access.  And hey, iptables is fun 
stuff.  Light reading.  :)


And, just because I'm being gabby ... rsync is a wonderful tool if 
you have multiple nodes and want hot backups.  This article expalins 
how to set it up, and while doing so, explains setting up ssh keys 
and locking things down.
http://www.debianhelp.co.uk/rsync.htm

Will, I'm not sure what you mean about using a key instead of a password. 
Wouldn't I still need to login to my box ? Or does using a separate 
ssh key just mean that it's easier to revoke access (without having 
to change my root password) ?

Umm, read that link Anton.  You can set authorization keys for SSH. 
 It takes a liitle to setup, but handy dandy once set.  Then you 
can disallow password login.   And if you don't know the machine 
and have shared keys, no looky no touchy.  It's part of what I'd 
like to see with the REBOL ring of trust.  Digital signatures.

Norman, sshFS looks useful (but I'll keep that for a future project).

I already have ssh, scp and fish installed, so I avoid adding another 
package on top...

I'm quite familiar with rsync since last year, when I used it to 
transfer a whole bunch of files from WinXP to Kubuntu.

btiffin, ok, so using a key with ssh looks like a good thing to do 
then. It's on my list.... :)

The Open Source community took an emotional hit when veteran Linux 
programmer Hans Reiser was convicted of first degree murder. How 
will this verdict impact the technology in play for Linux file system 
dominance?  

really??

sounds like a slashdot headline