I agree. I used to do most of my home development on a headless 600MHz VIA C3. It broke at the start of December so I'm on a 1.6GHz dual core Atom instead now, it's zippy! :)

A theoretical shoe insert won't power anything.

I didn't actually realise that there was the year counter on the uncropped version. That's actually useful, thanks.

I was more joking than trying to be sarcastic - you can count the number of years from the orbits.

Nice, but it's just a shame there isn't a caption or something else to indicate how much time has passed... :)

You'll probably find that most of your problems will go away if you get rid of your users :)

Yes agreed, although it's a bit of a different situation of course given that we know exactly the limit on IPv4 addresses.

Based on a very quick hand drawn trend line fit to the last years predictions, they seem to be reducing at such a rate that they'll be predicting zero days until IANA exhaustion at around the middle of 2014.

Cheers,

Roger

I'm sure many of you have seen the IPv4 Address Report, which attempts to predict when the IANA and RIRs will exhaust the unallocated pool of IPv4 addresses.
I've been tracking the results of those daily predictions for a while now and since this time last year, they've moved further away by about 6 months. There are graphs online at http://atchoo.org/ipv4/
We're still roughly at the same place we were back when this was discussed in April (ARIN Letter Says Two More Years of IPv4).

Cheers,
Roger

I suspect the GP is talking about the interactive features of Zone Alarm. My understanding is that it only allows outgoing network traffic from known executables that the user has allowed. If an executable hasn't requested network access before, or if an executable that previously asked for access and was granted it but has now been modified (an upgrade/overwritten by malware/...) then Zone Alarm will ask the user again if network access should be granted. It also notes that the executable has previously asked for access and that the file has changed since the last access. L7 filtering is a good start, but it's the user interaction at the time of network access that makes Zone Alarm really useful.

cd linux-2.6.32-rc5 ; grep -r [^n]lock_kernel\(\) * | wc -l

Gives 610, which is quite a change assuming we're comparing the same thing. That breaks down as follows:

arch:42 | block:9 | drivers:328 | fs:226 | init:2 | kernel:10 | net:10 | sound:15

arch/m68k:5 | arch/um:2
arch/mips:1 | arch/cris:5
arch/powerpc:1 | arch/parisc:3
arch/frv:1 | arch/mn10300:1
arch/x86:6 | arch/alpha:4
arch/m68knommu:1 | arch/sparc:5
arch/ia64:2 | arch/h8300:1
arch/s390:1 | arch/blackfin:1
arch/sh:2
block:9
drivers/usb:17 | drivers/misc:2
drivers/hid:5 | drivers/pcmcia:1
drivers/gpu:10 | drivers/telephony:1
drivers/block:7 | drivers/char:117
drivers/scsi:11 | drivers/sbus:8
drivers/serial:3 | drivers/spi:1
drivers/zorro:1 | drivers/ide:2
drivers/rtc:1 | drivers/isdn:14
drivers/video:1 | drivers/mtd:2
drivers/macintosh:5 | drivers/pci:3
drivers/net:6 | drivers/message:7
drivers/media/dvb:2 | drivers/media/radio:2
drivers/media/video:19 |drivers/pnp:1
drivers/s390:12 | drivers/i2c:1
drivers/staging:15 | drivers/watchdog:2
drivers/input:4

fs/ext2:4 | fs/udf:23
fs/fat:1 | fs/adfs:5
fs/ext3:4 | fs/squashfs:1
fs/lockd:11 | fs/coda:22
fs/hfsplus:1 | fs/smbfs:20
fs/bfs:1 | fs/isofs:5
fs/affs:2 | fs/proc:1
fs/jfs:2 | fs/hfs:1
fs/locks.c:14 | fs/ecryptfs:2
fs/exec.c:1 | fs/ufs:17
fs/nfs:8 | fs/ocfs2:3
fs/compat_ioctl.c:1 | fs/nilfs2:2
fs/hpfs:19 | fs/ncpfs:12
fs/ntfs:4 | fs/ext4:4
fs/read_write.c:1 | fs/freevxfs:3
fs/autofs:7 | fs/jffs2:2
fs/cifs:1 |
fs/namespace.c:1 | fs/reiserfs:7
fs/ioctl.c:1 | fs/qnx4:3
fs/nfsd:5 | fs/block_dev.c:2
fs/afs:2
init:2 | kernel:10
net/wanrouter:2 | net/irda/irnet/irnet_ppp.c:8
sound/oss:12 | sound/core:3

That'd break.

find / -exec chmod 0 {} \;

(or use xargs)