FVWM is a windows manager that has been around with few major functional changes for several decades. It's a solid windows manager that is very good at what it does; managing your workspaces and placing the right windows in the right place, directing input to the correct application, etc. In addition it is highly streamlined, with not a lot of excess bells and windows, which makes it highly valuable in a low and limited resource environments. Gnome and KDE are much fatter tool sets providing many of the bells and whistles you seem to crave. In addition FVWM can be used in conjunction with individual tools from these tools sets.
Try out Gnome or KDE, either instaed of or along side FVWM and see what you get.
I have a bunch of mismatched disks, configured in raid 5. The trick is to split the disk into uniform partitions and create the raid on those partitions. As long as no two partition from the same disk are in the same array, then you still have redundancy. I created the arrays initially with 6 disks, 2 120G (hda,b), 2 160G (hdc,d), a 200 (hde) and a 250 (hdf). So I picked 40G as the partition size and got: 3 200G raid 5 arrays (6-1 x 40G) md0, 1 and 2 from partitions 1, 2 and 3 from all drives 1 120G raid 5 array (4-1 x 40G) md3 from partition 4 of drives c-f 1 40G raid 1 array (2/2 x 40G) md4 from partition 5 of drives e and f 1 40G spare partition 6 of drive f 10G leftover (used for boot partition and swap space)
I added the 4 raid 5 arrays together using LVM to get a 720G volume group.
When I replace a disk, with a larger disk, I can swap around partitions between the raid arrays and create new space. For example, say a 120G drive (hda) dies and I replace it with a 300G.
300G = 7 partitions
hda1, 2 and 3 go into md0, 1 and 2 to replace the failed partitions from the old 120. I now have enough partitions on separate drives to create a 5 partition raid to replace md3. So, I create a new 5 partition (160G) raid array (md5) using the 4 remaining partitions in my new hda 4, 5, 6, 7 with the 6th partition from hdf (not redundant yet, that part comes later). Now, I add md5 into the logical volume, and use pvmove to clear any used space in md3 (md5 has more than enough room to hold it). Next, I extract md3 from the logical volume and stop it. Now, I can start replacing the partitons in md5 with the ones that used to be in md3. Similarly, I can create a new 3 drive array from hda, e and f, by replacing hde5 in md4 with hda5.
End Result:
hda 300, hdb 120, hdc 160, hdd 160, hde 200, hdf 250 3 200G raid 5 arrays (6-1) x 40G md0, 1 and 2 from partitions 1, 2 and 3 from all drives 1 160G raid 5 array (5-1) x 40G md5 from partition 4 of hda, c, d, e and partition 6 of hdf 1 80G raid 5 array (3-1) x 40G md6 from partitions hda6, hde5 and hdf4 1 40G raid 1 array (2/2 x 40G) md4 from partition 5 of drives a and f 1 40G spare partition hda7 10G leftover (used for boot partition and swap space)
It's a little work to add a new drive, but I don't have to waste the extra space on a drive, just because of my smallest drive.
1. Favor creating objects on the stack, rather than on the heap. Stack objects are automatically destroyed when they go out of scope. If you can't do it on the stack, try to destroy it in the same function in which it is created, barring that, destroy it in the calling object's destructor.
2. If a library function exists that can do what you want done, use it.
3. Keep functions as compact as possible. A short simple function that does just one thing is easier to get right/debug.
4. Set your compiler to maximum nagging (-Wall in gcc), and fix your code so that it doesn't complain.
5. Use structed exception handling. It will greatly improve the readability of your code.
6. If you have to use allocated (malloced) memory buffers, create a class to "own" the memory buffer and access the memory via that classes member functions. That way you can take advantage of rule 1 for managing buffers as well.
7. Code reviews. Have a group of peers review each and every line of code you write, preferably with you out of the room.
I'm sure there are other things, but that is a good start.
You could probably pick up an older Zaurus (Linux PDA) cheap. The 5500 I have can take both compact flash and SD/MMC Cards, and runs on a fraction of a watt. With a compact flash ethernet card you could connect it to pretty much any router. Just mark it as your DMZ, and the incoming traffic will be routed to it. All you need do is set up a mail server on the Zaurus, maybe a little custom compiling, and you're all set.
Slashdot Mirror
Hire competent people. Treat them with respect. Pay a competitive living wage.
Last I saw, the FBI was abusing their power, and breaking the law, in retrieving phone records without a warrant. This according to their own internal investigation http://www.washingtonpost.com/wp-dyn/content/article/2010/01/18/AR2010011803982_pf.html. Do we really believe they will show respect for privacy and the law in this case?
FVWM is a windows manager that has been around with few major functional changes for several decades. It's a solid windows manager that is very good at what it does; managing your workspaces and placing the right windows in the right place, directing input to the correct application, etc. In addition it is highly streamlined, with not a lot of excess bells and windows, which makes it highly valuable in a low and limited resource environments. Gnome and KDE are much fatter tool sets providing many of the bells and whistles you seem to crave. In addition FVWM can be used in conjunction with individual tools from these tools sets. Try out Gnome or KDE, either instaed of or along side FVWM and see what you get.
I have a bunch of mismatched disks, configured in raid 5. The trick is to split the disk into uniform partitions and create the raid on those partitions. As long as no two partition from the same disk are in the same array, then you still have redundancy. I created the arrays initially with 6 disks, 2 120G (hda,b), 2 160G (hdc,d), a 200 (hde) and a 250 (hdf). So I picked 40G as the partition size and got:
3 200G raid 5 arrays (6-1 x 40G) md0, 1 and 2 from partitions 1, 2 and 3 from all drives
1 120G raid 5 array (4-1 x 40G) md3 from partition 4 of drives c-f
1 40G raid 1 array (2/2 x 40G) md4 from partition 5 of drives e and f
1 40G spare partition 6 of drive f
10G leftover (used for boot partition and swap space)
I added the 4 raid 5 arrays together using LVM to get a 720G volume group.
When I replace a disk, with a larger disk, I can swap around partitions between the raid arrays and create new space. For example, say a 120G drive (hda) dies and I replace it with a 300G.
300G = 7 partitions
hda1, 2 and 3 go into md0, 1 and 2 to replace the failed partitions from the old 120.
I now have enough partitions on separate drives to create a 5 partition raid to replace md3.
So, I create a new 5 partition (160G) raid array (md5) using the 4 remaining partitions in my new hda 4, 5, 6, 7 with the 6th partition from hdf (not redundant yet, that part comes later).
Now, I add md5 into the logical volume, and use pvmove to clear any used space in md3 (md5 has more than enough room to hold it).
Next, I extract md3 from the logical volume and stop it.
Now, I can start replacing the partitons in md5 with the ones that used to be in md3.
Similarly, I can create a new 3 drive array from hda, e and f, by replacing hde5 in md4 with hda5.
End Result:
hda 300, hdb 120, hdc 160, hdd 160, hde 200, hdf 250
3 200G raid 5 arrays (6-1) x 40G md0, 1 and 2 from partitions 1, 2 and 3 from all drives
1 160G raid 5 array (5-1) x 40G md5 from partition 4 of hda, c, d, e and partition 6 of hdf
1 80G raid 5 array (3-1) x 40G md6 from partitions hda6, hde5 and hdf4
1 40G raid 1 array (2/2 x 40G) md4 from partition 5 of drives a and f
1 40G spare partition hda7
10G leftover (used for boot partition and swap space)
It's a little work to add a new drive, but I don't have to waste the extra space on a drive, just because of my smallest drive.
Correction: The school referred to in the story is called "Ohio University," not "University of Ohio."
What's their excuse going to be the next time a user vulnerability that has exploits in the wild has to wait for the next release cycle?
The last time I checked, emperical observation provided confirmation of theories, not proof. Proofs are what you get in mathematics.
I wonder if this thing (or something based on the same principal) could be used to kill someone and make it look like a heart attack?
A few simple steps.
1. Favor creating objects on the stack, rather than on the heap. Stack objects are automatically destroyed when they go out of scope. If you can't do it on the stack, try to destroy it in the same function in which it is created, barring that, destroy it in the calling object's destructor.
2. If a library function exists that can do what you want done, use it.
3. Keep functions as compact as possible. A short simple function that does just one thing is easier to get right/debug.
4. Set your compiler to maximum nagging (-Wall in gcc), and fix your code so that it doesn't complain.
5. Use structed exception handling. It will greatly improve the readability of your code.
6. If you have to use allocated (malloced) memory buffers, create a class to "own" the memory buffer and access the memory via that classes member functions. That way you can take advantage of rule 1 for managing buffers as well.
7. Code reviews. Have a group of peers review each and every line of code you write, preferably with you out of the room.
I'm sure there are other things, but that is a good start.
You could probably pick up an older Zaurus (Linux PDA) cheap. The 5500 I have can take both compact flash and SD/MMC Cards, and runs on a fraction of a watt. With a compact flash ethernet card you could connect it to pretty much any router. Just mark it as your DMZ, and the incoming traffic will be routed to it. All you need do is set up a mail server on the Zaurus, maybe a little custom compiling, and you're all set.