� December 2008 | Main | February 2009 �
January 23, 2009
BBC NEWS | Business | Fast bucks: how Porsche made billions
In October 2008, Porsche's takeover moves triggered an unprecedented stock market squeeze when it suddenly revealed it owned or had positions on more than 74% of Volkswagen shares.
The value of Volkswagen stock rocketed to more than 1,000 euros, briefly making it the most valuable company in the world.
Hedge funds, who had gambled that the value of Volkswagen shares would fall are said to have lost between 10bn and 40bn euros.
BBC NEWS | Business | Fast bucks: how Porsche made billions
Posted by thdyck at January 23, 2009 | Comments (0) | TrackBack
January 20, 2009
Renaming ethernet adapters in Debian Etch (e.g. eth2 to eth0)
I have a Dell PowerEdge 1950 server running Debian Sarge. It recently experienced the joy of a motherboard replacement (which will hopefully make the hardware faults go away). This normally isn't a big deal, except for the fact that I use the onboard gigabit NICs. See Debian "knows" which network card is which by MAC address and when you replace the motherboard you get 2 new MACs. So instead of having eth0 & eth1, you've got eth2 & eth3. I google'd around for a long time and couldn't find out how to make Debian "forget" the old NIC's, so I went with instructions I found on how to "Rename" the adapters using udev. Sadly... It didn't work.
As it turns out though, /etc/udev/rules.d/z25_persistent-net.rules is the home of where Debian remembers the network adapters. So I popped open that file and found my two old adapters and the two new ones. A few lines commented out, a few renamed lines (oh, and a reboot) - and I was off to the races.
Oh, and if you are wondering why I cared about eth0/1 versus eth2/3 - The G729 licenses for Asterisk are tied to the MAC of eth0. So without an eth0 my G729 enabled phones didn't work, and I couldn't re-register the licenses. Sigh... Oh well, I can use my phone now!
Posted by thdyck at January 20, 2009 | Comments (0) | TrackBack
January 19, 2009
InformIT: Software [In]security: Software Security Top 10 Surprises > Software Security Top 10 Surprises
Using the software security framework introduced in October (A Software Security Framework: Working Towards a Realistic Maturity Model), we interviewed nine executives running top software security programs in order to gather real data from real programs. Our goal is to create a maturity model based on these data, and we're busy working on that (stay tuned here for more). However, in the course of analyzing the data we gathered, we unearthed some surprises that we share in this article.
Nine Top Software Security Programs
Of the twenty-three large-scale software security initiatives we are aware of, we chose nine that we considered the most advanced. Our nine organizations are drawn from three verticals: financial services, independent software vendors, and technology firms.
On average, the target organizations have practiced software security for five years and four months (with the newest initiative being two and a half years old and the oldest initiative being a decade old). All nine have an internal group devoted to software security that we choose to call the Software Security Group or SSG. SSG size on average is 41 people (smallest 12, largest 100, median 35) with a "satellite" of others (developers, architects and people in the organization directly engaged in and promoting software security) of 79 people (smallest 0, largest 300, median 20). The average number of developers among our targets was 7550 people (smallest 450, largest 30,000, median 5000), yielding an average percentage of SSG to development of just over 1%.
We conducted the nine interviews in person and spent two hours going over each software security initiative in a conversation guided by the software security framework.
Posted by thdyck at January 19, 2009 | Comments (0) | TrackBack
January 18, 2009
End of Terrorism Statistics - Why Does Terrorism Occur? - Esquire
Through his work as an analyst for the Rand Corporation, he has found that 40 percent of terrorist groups are defeated by police and intelligence operations. Forty-three percent end because they give up violence and join the political process. Only 7 percent end as a result of military force.
It's incredible, really. Ever since 9/11, thousands of America's best minds have been grappling with the question of how to fight terrorism. General David Petraeus has come up with some of the best answers. Others appear in Lieutenant Colonel John Nagl's influential study of the guerrilla wars in Malaya and Vietnam, Learning to Eat Soup with a Knife. But until Seth Jones, nobody actually sought an empirical answer. Nobody crunched the numbers.
End of Terrorism Statistics - Why Does Terrorism Occur? - Esquire
Posted by thdyck at January 18, 2009 | Comments (0) | TrackBack
ZFS on Linux: my story and HOWTO you can have it too -- Rudd-O.com
What you do when you really, really want ZFS on Linux:
I had been salivating over the thought of using ZFS in my workstation because of several killer features:
* The first one that comes to mind is end-to-end data integrity thanks to checksumming -- I've already had many disks go bad on me, while others corrupted my data silently (which is, believe it or not, the most insidious thing ever, because after you've noticed it, backups won't help you with that -- you've probably already papered over your backups with new, bad data).
* The second one is compression. Together with tightly packed data, compression promises to increase performance and reduce disk utilization.
* The third one is the advanced transactional algorithm that yields an always-consistent disk structure. Unlike log-based filesystems, ZFS does copy-on-write and ripples the changes up through the filesystem tree; before the topmost node is updated, the changes don't affect consistency; when the topmost node is updated, the disk is consistent as well. Never fsck again!"Damn, gotta get me some of that, I thought"
ZFS on Linux: my story and HOWTO you can have it too -- Rudd-O.com
Posted by thdyck at January 18, 2009 | Comments (0) | TrackBack
In good faith
MMA's socially responsible investing blog
Posted by thdyck at January 18, 2009 | Comments (0) | TrackBack
Dr. Dobb's | Measuring Parallel Performance: Optimizing a Concurrent Queue | December 1, 2008
To improve scalability, we need to minimize contention:
* Reduce the size of critical sections so that we can get less contention and more concurrency among client threads.
* Reduce sharing of the same data by isolating threads to use different parts of a data structure. In our case, we moved the responsibility for cleanup from the producer to the consumer so that consumers touch only the head and producers touch only the tail.
* Reduce false sharing of different data on the same cache line, by adding padding to ensure that two separate variables that should be able to be used concurrently by different threads are also far enough apart in memory.To understand our code's scalability, we need to know what to measure and what to look for in the results:
* Identify the key different kinds of work (here, producer threads and consumer threads), and then use stress tests to measure the impact of having different quantities and combinations of these in our workload.
* Identify the different kinds of data (here, representative "small" and "large" queue items), and then vary those to measure their impact.
* Measure total throughput, or items handled per unit time.
* Look for scalability, or the change in throughput as we add more threads. Does using more threads do more total work? Why or why not? In what directions, and for what combinations of workloads?
* Look for contention, or the interference between multiple threads trying to do work concurrently.
* Watch for the cost of oversubscription, and eliminate it either algorithmically or by limiting the actual amount of concurrency to avoid it altogether.
* Beware of overreliance on automated trendlines. Apply them only after first examining the raw data.
Dr. Dobb's | Measuring Parallel Performance: Optimizing a Concurrent Queue | December 1, 2008
Posted by thdyck at January 18, 2009 | Comments (0) | TrackBack
January 17, 2009
Data Recovery - Lunarsoft Wiki
Good, practical guide on IDE and SATA hard drive recovery.
Welcome to DjLizard's data recovery guide. If you have any questions, comments, you've found errors, or need clarifications to this guide, please email DjLizard@DjLizard.net.
As this is an editorial with lots of opinions, anecdotal evidence, and personal experience, first-person informal particles "I", "me", and "my" will be used. This is unlike the rest of this wiki which is written in a hard-facts technical style.
Data Recovery - Lunarsoft Wiki
Posted by thdyck at January 17, 2009 | Comments (0) | TrackBack