or, what I use in my workplace (execute via an init script/or add to/etc/rc.d/rc.local):
# create new chain "SSHRULES"
# if packet is NEW, coming in on eth0, on port 22 apply rules in "SSHRULES"
#
# SSHRULES:
# if is on our subnet, accept the connection, stop reading the chain
# record a connection attempt
# if has more than 2 connection attempts in the last 7 seconds, reject
iptables -N SSHRULES
#insert at the top of the "INPUT" chain
iptables -I INPUT 1 -p tcp -i eth0 -m state --state NEW --dport 22 -j SSHRULES
iptables -A SSHRULES -m iprange --src-range 129.65.0.0-129.65.255.255 -j ACCEPT
iptables -A SSHRULES -m recent --update --hitcount 2 --seconds 7 -j REJECT
iptables -A SSHRULES -m recent --set -j ACCEPT
I've seen stuff like this a bunch of times, and I've collected the data/tools that I have found on our infected systems, in my university department. For us, it seems like the main angle of attack is ssh, where our servers get hammered several times per second. Often, when we give students root access to some of these systems, they tend to make users like test/test, and in a matter of days, the computers are scanning large subnets looking for other systems to compromise.
There is nothing new or first about these attacks.
So you could put thirty three hard drives in RAID 0 and have the same number of IOPS, and your latency would still be worse.
Actually, thats incorrects, Here's why:
When you calculate IOPS, a good portion small of reads and writes get executed at random places on the disks. When you you make one filesystem write on a raid0 set (depending on how smart the raid0 controller is), it will be locking up several or ALL the disk spindles for that individual read/write.
The IOPS are negligibly better on a 33 disk raid0 set, and depending on your disk controller, it might be worse (every write equates to 33 dma requests).
It is faster for reading large files though, but that is NOT what a fair IOPS test measures.
For read operations, you can double your read IOPS by using a mirror. This is because ony semi decent controller will split all the read requests between the drives in the mirror. When your issuing lots of read requests from several threads, the load should be approximately equal across the drives.
It is written in python. All you do it put an nzb in the directory that it is watching, wait a few hours, and you have all your data, par'ed, decoded, patched together, and unrared, sitting in the output folder.
If you have a network storage server, you can conveniently share the queue directory with samba or NFS, and centralize all your downloading.
What is considered a malfunction? And perhaps having the latest and greatest object of the year inspires people to treat the phone with a little more care?
I would consider durability a major point of reliability for a phone. Its a device that you carry around with you, it should be able to stand up to being banged around a bit.
Flipping "B" (detected errors):
A1 != B2^C2^P2
B1 != A3^C3^P3
C1 != A4^B4^P4
From this, any of the bits (examples shown with b and c, or the parity can be assumed to be wrong).
I stand by the first guy's reply to this. With raid5, and a random silent bit error, there is no way to tell which bit is wrong.
A1^B1^C1 = P1
randomly flip bit C1, and you get
A1^B1^C1 != P1, whoops, there is an error, but there is no indication where the error is.
Raid5 covers this case:
A1^B1^[OFFLINE](?) = P1
In this case you can easily use the P1 bit to reconstruct C1.
Really, there is only one copy of the data, with a the bits xored across (bit P gets flipped for every 1 bit seen across a b and c, and stays the same for every 0 bit). In terms of disk space, you have to think about it like this: you are losing one disk to parity. If raid5 worked that way, you would need to lose two disks to parity, and that's not raid5...
Someone with mod points should really mod up the previous reply....
You are probably referring to "silent" errors, which for performance reasons, isn't read/detected by most raid5 implementations. And in reality there is little reason to actively read parity, unless they are running/recovering in degraded mode: Sure, you'll be informed that there is data corruption, but there is no way to tell whether the parity, or the original data is at fault (though its true, some implementations will scrub/update the parity to match the original data on an occasional basis).
I don't see a single set of raid5 disks as a backup solution at any measure though (disk reliability is only one aspect of this, hardware/driver/filesystem bugs can also cause hard or impossible to detect corruption), but it is a great 'best effort' to prevent a bit of downtime on high availability disks.
End to end CRC checking, metadata backups (even on a single disk, and alomst full IO throughput on writes (partly thanks to the fact that there isn't a journal, all metadata changes are atomic).
The filesystem is also very snapshot friendly, which makes backing up data from user mistakes very fast and easy.
Storage pooling/Mirroring/Raid-Z could become a new standard for home users, though, that aspect probably won't catch on in the consumer market
And all WinFS has is search. It doesn't have the ability to watch a hard disk for bitrot, it doesn't know when files get silently corrupted, etc
Was DOS ready for the desktop? Yes it was. Compared to other solutions at the time, it was easy to use, relatively consistent, and stable (though this one would have been hard to mess up).
Slashdot Mirror
Actually:
;-) .
http://digg.com/odd_stuff/Huge_Cannon_Fires_Pumpkins_at_600_MPH_VIDEO
It hit the top of digg yesterday
http://www.pettingers.org/code/sshblack.html
/etc/rc.d/rc.local):
or, what I use in my workplace (execute via an init script/or add to
# create new chain "SSHRULES"
# if packet is NEW, coming in on eth0, on port 22 apply rules in "SSHRULES"
#
# SSHRULES:
# if is on our subnet, accept the connection, stop reading the chain
# record a connection attempt
# if has more than 2 connection attempts in the last 7 seconds, reject
iptables -N SSHRULES
#insert at the top of the "INPUT" chain
iptables -I INPUT 1 -p tcp -i eth0 -m state --state NEW --dport 22 -j SSHRULES
iptables -A SSHRULES -m iprange --src-range 129.65.0.0-129.65.255.255 -j ACCEPT
iptables -A SSHRULES -m recent --update --hitcount 2 --seconds 7 -j REJECT
iptables -A SSHRULES -m recent --set -j ACCEPT
I've seen stuff like this a bunch of times, and I've collected the data/tools that I have found on our infected systems, in my university department. For us, it seems like the main angle of attack is ssh, where our servers get hammered several times per second. Often, when we give students root access to some of these systems, they tend to make users like test/test, and in a matter of days, the computers are scanning large subnets looking for other systems to compromise. There is nothing new or first about these attacks.
I have written scripts for my job, which would break dns was hijacked by my isp. It's not acceptable.
;-)
I added a stub section to an article on wikipedia about this a while ago, it would be great if someone would lengthen it
http://en.wikipedia.org/wiki/DNS_hijacking#Use_by_ISPs
So you could put thirty three hard drives in RAID 0 and have the same number of IOPS, and your latency would still be worse.
Actually, thats incorrects, Here's why:
When you calculate IOPS, a good portion small of reads and writes get executed at random places on the disks. When you you make one filesystem write on a raid0 set (depending on how smart the raid0 controller is), it will be locking up several or ALL the disk spindles for that individual read/write.
The IOPS are negligibly better on a 33 disk raid0 set, and depending on your disk controller, it might be worse (every write equates to 33 dma requests).
It is faster for reading large files though, but that is NOT what a fair IOPS test measures.
For read operations, you can double your read IOPS by using a mirror. This is because ony semi decent controller will split all the read requests between the drives in the mirror. When your issuing lots of read requests from several threads, the load should be approximately equal across the drives.
Welcome the Great Firewall of Australia!
Hmm, I'm not so sure this is a good idea..... How do simpler devices that write to FAT deal with it? cameras, pdas, etc
I prefer hellanzb.
It is written in python. All you do it put an nzb in the directory that it is watching, wait a few hours, and you have all your data, par'ed, decoded, patched together, and unrared, sitting in the output folder.
If you have a network storage server, you can conveniently share the queue directory with samba or NFS, and centralize all your downloading.
Oh, you can already do that!
http://www.dtecnetusa.com/intro.html
Linked from: http://www.respectcopyrights.org/faqs.html
I'm in Computer Science, a somewhat related field, and I've had to take a few hardware courses during my time in school.
I felt like Xilinx Schematic layout was a great first step, because it introduced the circuit theory in a visual way.
You wouldn't want to infringe on IBM's form validation patent ;-) :
http://yro.slashdot.org/article.pl?sid=09/05/26/159249
We're not trying to fight the borg here!
Maybe, this time, we will make it to the moon!
under RHEL that might easily screw up your RH support contract
It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.
/usr/local/bin before /usr/bin, or even /bin.
See: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-filesystem-fhs.html
/usr/local/, its taken from fhs, which redhat honors.
Also, the standard redhat PATH contains
The 20th anniversary mac was made in 1997. It is now 2009 (12 years later).
Interesting....
its more like the (c)2003 sun demo http://www.sun.com/software/looking_glass/media/k5_media.jsp#lg1 *years* before leopard.
What is considered a malfunction? And perhaps having the latest and greatest object of the year inspires people to treat the phone with a little more care?
I would consider durability a major point of reliability for a phone. Its a device that you carry around with you, it should be able to stand up to being banged around a bit.
In your example, the 4 copies with bit c being "incorrect"
Data layouts:
1: {A1,B1,C1}
2: {B2^C2^P2,B2,C2}
3: {A3,A3^C3^P3,C3}
4: {A4,B4,A4^B4^P4}
Flipping "C" (detected errors):
A1 != B2^C2^P2
B1 != A3^C3^P3
C1 != A4^B4^P4
Flipping "B" (detected errors):
A1 != B2^C2^P2
B1 != A3^C3^P3
C1 != A4^B4^P4
From this, any of the bits (examples shown with b and c, or the parity can be assumed to be wrong).
I stand by the first guy's reply to this. With raid5, and a random silent bit error, there is no way to tell which bit is wrong.
A1^B1^C1 = P1 randomly flip bit C1, and you get A1^B1^C1 != P1, whoops, there is an error, but there is no indication where the error is.
Raid5 covers this case: A1^B1^[OFFLINE](?) = P1
In this case you can easily use the P1 bit to reconstruct C1. Really, there is only one copy of the data, with a the bits xored across (bit P gets flipped for every 1 bit seen across a b and c, and stays the same for every 0 bit). In terms of disk space, you have to think about it like this: you are losing one disk to parity. If raid5 worked that way, you would need to lose two disks to parity, and that's not raid5...
Someone with mod points should really mod up the previous reply....
The mathematical theory behind raid5 is not complicated at all. http://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5
And there is parity, that's how raid5 works.
You are probably referring to "silent" errors, which for performance reasons, isn't read/detected by most raid5 implementations. And in reality there is little reason to actively read parity, unless they are running/recovering in degraded mode: Sure, you'll be informed that there is data corruption, but there is no way to tell whether the parity, or the original data is at fault (though its true, some implementations will scrub/update the parity to match the original data on an occasional basis).
I don't see a single set of raid5 disks as a backup solution at any measure though (disk reliability is only one aspect of this, hardware/driver/filesystem bugs can also cause hard or impossible to detect corruption), but it is a great 'best effort' to prevent a bit of downtime on high availability disks.
http://www.southparkzone.com/episodes/1206/Over-Logging.html
So, they released the spec, great.
Unfortunately, everyone else already reverse engineered it, and *basically* had perfect support anyway.
End to end CRC checking, metadata backups (even on a single disk, and alomst full IO throughput on writes (partly thanks to the fact that there isn't a journal, all metadata changes are atomic).
The filesystem is also very snapshot friendly, which makes backing up data from user mistakes very fast and easy.
Storage pooling/Mirroring/Raid-Z could become a new standard for home users, though, that aspect probably won't catch on in the consumer market
And all WinFS has is search. It doesn't have the ability to watch a hard disk for bitrot, it doesn't know when files get silently corrupted, etc
Thats a horrible idea. SQLLite is *really*, *really* slow compared to an in memory database.
ZFS is the way to go. ZFS fixes real world problems. WinFS just makes searching/tagging more convienient? That is useless to most users.