It really doesn't happen that often at all - but when it does, the size of our cars make it a deadly situation. Also, in most of the cases where I've heard of this happening, it was brake failure or something to that effect. Also, it can happen in city situations, but those are just small accidents since the relative speeds of travel are slow.
The side of your car cannot possibly have strong enough support to make a difference if a 3000 pound (~1300 kg) SUV hits you at 55 MPH (~90 KPH) with a stiffened (for better crash test ratings!) front end.
In America we have many traffic lights where the freeway ends and an in town area starts. The physical layout of the US means that we have to have many high speed highways between residential areas and the points at which they meet make for dangerous spots. Just the realities of our environment and culture.
I like to think that by driving a very light vehicle I'm keeping other people safer in a collision. That probably makes me a bad American, valuing the lives of others as much as my own.
While I applaud and appreciate your sentiments, you cut down your fellow American by assuming malice where ignorance is most likely the correct attribute for which to assign blame. No one is getting up the in the morning and saying, "today I'm going to be a bad person", but it has never occurred to them that they are endangering everyone else for their own perception of safety. Do not attribute to malice what is better attributed to ignorance.
Value others lives over your own if you want to make a difference.;)
It's not undoable by any account, but it goes against how the platform natively views a package. It just means that it will be extra effort to do things like updates. As with all things, it's just usually easier to use the underlying platforms built in functionality than to work around it. Windows mostly views an application as a monolithic entity (which makes sense for pushing updates as deltas) rather than a collection of packages.
Though, cygwin does installs and updates exactly as you describe, so it's definitely doable.
I agree. The way that Windows package management, if you will, is geared towards single file binary installers. Or, a network admin install, as MSI supports both. Really, I haven't seen much legit use of DLLs as they were intended (shared libraries) when it comes to applications. After "DLL Hell" everyone just started statically linking in the libraries, and can you blame them? I mean, MSI does have some really cool features, but dependency tracking for DLLs is not one of them.
I routinely have statically linked executables that will just refuse to uninstall and I can't get rid of the entry. Then I'm stuck ripping out shards of the program from every folder structure and the registry... for the next two years. At that point, they're still resident when I blow away my OS partition and steamroller a new Windows install.
People are used to Windows install routines by now; you get the programName-setup.exe or.msi, double click on it, and watch the bar go across the screen. And, for the most part, Windows does this well, barring the usual head-desk moments that we all love (aha! let's use spaces in the %programfiles% directory name and then half support them and leave everyone guessing where they should put quotes!) and I don't think that we should try force Linux style library schemes on to a system that doesn't want or need it. Doubly so for users that won't understand it!
Full disclosure: I run Slackware and Windows at home (and BSD and Mac) and prefer to compile from source, at work we use RHEL and Windows and if not for the ease of having repositories, I'd take MSI-2/3 over RPM-2/3 any day of the week.
Erm, I can't tell you another company that does the wii-boxing thing. It was an ironic musing of a story I heard from a friend about his grandfather. Apparently the grandfather went to school in a single room schoolhouse and the teacher had an 'old skool' approach to conflicts between students; take them out back and give 'em each boxing gloves to go at it. I guess after that, the matter was considered settled. The high tech juxtaposition in my mind was two geeks duking it out, then gaming it out, and then, wii boxing! I snickered and then realized it could work.
I'm adding you to my friend list; keep me updated on how things are working out!
The Riemann zeta function is \zeta(s) = \sum_{n=1}^{\infty} \frac{1}{n^{s}} [written for LaTeX], or "the sum of 1/(n^s) as n goes from 0 to infinity (increasing by 1 repeatedly)" [in more human-readable form].
You have a slight typo. Should be: "... as n goes from 1 to infinity..."
You have a slight typo. It should be: "You have a slight typo. It should be:..."
You have a slight typo. It should be: "You have an off by one error."
So long as it's not your stupid bank storing unencrypted info on tapes that went MIA. I guess the few million people that it has happened to this year, alone, would be annoyed, if not stupid.
The Itanicium didn't fail on its own; Intels own Xeons killed it. Xeons simply crushed Itaniums for price/performance ratio. Especially the newly non netburst based Xeons.
Another thing to think about (besides cache coherency, ping ponging between sockets over the bus, locking overhead, etc.):
You can have a million cores and it won't matter. You're only as fast as your weakest link. Right now, that's storage, but solid state hard drives will be common in the next decade for first tier storage (as straight memory bank storage becomes more common for high performance applications), the average disk access time will improve by a few orders of magnitude. Still, that only moves the problem 'forward' a level.
You still choke on the Memory Wall; you have to feed all those cores data, and you're going a few orders of magnitude slower than the CPU cores. Increasing bandwidth on the front side bus doesn't help, as you have to increase bandwidth and decrease latency. You compound this when you have many cores/sockets doing backward cache flushes to RAM.
Even if you've got a hypertransport link (as Intel doesn't, they push bits on the front side bus between sockets, IIRC) to the north bridge for each socket, you've still only got a single north bridge. You're bottlenecked again. OK, use two front side buses with an interlink. Now we're back to coherency problems, but at two points. At some point, you have to either give each socket its own RAM bank (NUMA) and isolate data (and make CPU migration for tasks take an extra hit) or figure out how to perfectly isolate and stripe your data over multiple paths to a single backing store.
No. Thunderdome is the correct response. Seriously. Wii-boxing. Geek game showdown. No physical contact, and an enjoyable way for everyone else to ease the tension that conflict can bring. Don't tell them about it... just keep a console around and when the opportunity is right, take each of them under an arm and lead them off. If you do it right and pull it off, it's one of those "... hey, did you hear about so and so... he freakin' made them Wii Box!" stories that will precede you where ever you go.
You won't even have to break the ice the first time you meet a client. It sounds nuts, but sane solutions don't solve problems and get great results. They become political and accounting decisions if left rational for too long. As for the vendors, make them fear you by telling them to have free hardware dropped off to your tech guys to play with before you even consider making a purchasing decision. After all, if this wacky device is nearly as great as they say, the geeks'll love it! Also, Cisco and Sun were kind enough to give you a full rack to play with for a few months.;) If they call your bluff, let the geeks eat 'em alive with technical questions like, "so, is your LDAP backend X500 DIT compliant? We need it to work with our hacked together NIS/perl-fu directory. Here, we can show you the code!"
Whom exactly do you think will be leading you? Alexander was the last general to ride in front of his troops!
Seriously, though, he didn't say he failed at CS but, rather, that programming wasn't his forte. But chances are he knows more about CS than a good portion of the managers out there. He isn't clueless, he just doesn't have a knack for programming. Most programmers don't have a knack for management. This situation works well for both parties when they can find common ground.
You are in a unique position; us programmers can't stand to be in management, we simply cannot do our jobs there (not to mention we're slightly introverts!). If you are skilled and don't mind managing, you can bring home a decent wage. Especially if you know how to manage programmers! Good management for a development team is a sorely needed position.
Just my $0.02. Any fellow programmers want to back me up or dispute my claims?
I've done it when I've got two or three computers on my desk, but I always look at the wrong monitor with the wrong keyboard. You've got to have the right most monitor matched to lowest tiered keyboard if you want to do anything productive.
And, it's worth noting that win+D will blast away most modal dialog boxes that are keeping you from launching something else while $company shows you a splash screen. Or a dialog box that you need to see a text file to get the input for (man, I freakin' hate that!).
Now, I'm hoping to remap win+C to a shotgun macro and disable Clippy for good!
Grab 4 disks, take the last 15%-20% (read: slowest tracks) of each disk and make them a four disk raid 5. Use that for your 'archive' since it's slow anyways, and you'll not want the seek performance of reaching to the inside track during regular use. Since we all know you're rolling off to DVD/CD/tape/whatever, losing this four disk RAID 5 won't matter much to you.
Then do either raid 6 over the four disks through the next 50% of the drives, and make the first 25% a blazing fast (albeit expensive in cost/MB) RAID 10.
Line up all the stripes to 256KB chunks on the RAID 5's, 128KB on the RAID 6's and 64KB on the RAID 10's (32KB where databases are) and make sure your file system/logical volume manager align to this chunk size, as well. Keeps everything fast and peppy, even while transferring to the 'archive' tracks at the end of the disk.
Re:nuttin' wrong with growin' your own
on
What NAS To Buy?
·
· Score: 1
Take a look at the RAID card he chose, though, that's from $400-$1000 right there, depending on the version/options. Still seems a bit high, but RAM also didn't cost $25/gig two years ago! (I still can't believe the DDRII prices... if only DDRI would come down!)
I put together a 4u file server last year. 4 500 GB, WD AAKS'es. I ended up using a stripped down Slackware build with iscsi enterprise target. Since it had 2 gigs of RAM, and the OS took like 35 MB from a cold boot, I turned down the vfs_cache_pressure and let it cache inodes all day long. When I setup iscsi Enterprise Target, I gave honkin' big buffers to the app, and set huge buffers for the RAID stripes. Each disk is sliced in to 9 partitions, the last partition for archive since the slowest 15% of a disk is all but unusable.
You can mount the iscsi target from any initiator (Microsoft provides one for free from their site, and all RPM distros have the iscsi initiator as part of the extras disk/repo) and it acts just like raw disk.
My box is somewhat extravagant, but if you're feeling froggy, jump. I stripe three gigE connections to two cascaded switches, (two on one, one on the other) and do the same for my server which is mounting the exported disks. Then I have two connections to my LAN which my Windows and Linux desktops mount directly.
This also allows me to utilize buffering in the Linux kernel at the file system level by mounting a dd'ed raw image. Since it's on a loopback mount, everything passes the inodes (when shared as a file instead of a blockdev) cache, and instead is buffered. That means I've got a bunch of 20 Gig raw image files lying around that I just mount on a loopback and export over iscsi with a ~1.5 gig buffer dedicated to it.
Granted, it took weeks and a lot of heads down time to get setup (not to mention kernel compiles!), but it's stable as a rock and faster than greased lightning!
Slashdot Mirror
It really doesn't happen that often at all - but when it does, the size of our cars make it a deadly situation. Also, in most of the cases where I've heard of this happening, it was brake failure or something to that effect. Also, it can happen in city situations, but those are just small accidents since the relative speeds of travel are slow.
The side of your car cannot possibly have strong enough support to make a difference if a 3000 pound (~1300 kg) SUV hits you at 55 MPH (~90 KPH) with a stiffened (for better crash test ratings!) front end.
In America we have many traffic lights where the freeway ends and an in town area starts. The physical layout of the US means that we have to have many high speed highways between residential areas and the points at which they meet make for dangerous spots. Just the realities of our environment and culture.
I like to think that by driving a very light vehicle I'm keeping other people safer in a collision. That probably makes me a bad American, valuing the lives of others as much as my own.
While I applaud and appreciate your sentiments, you cut down your fellow American by assuming malice where ignorance is most likely the correct attribute for which to assign blame. No one is getting up the in the morning and saying, "today I'm going to be a bad person", but it has never occurred to them that they are endangering everyone else for their own perception of safety. Do not attribute to malice what is better attributed to ignorance.
;)
Value others lives over your own if you want to make a difference.
[...]
Now if only I could figure out how many Rods to the Hogshead that is...
When you figure that out, could you convert it to Libraries of Congress per furlong for me? :)
You're lucky I ran out of mod points a few articles ago!
-1 Alliteration
;)
It's not undoable by any account, but it goes against how the platform natively views a package. It just means that it will be extra effort to do things like updates. As with all things, it's just usually easier to use the underlying platforms built in functionality than to work around it. Windows mostly views an application as a monolithic entity (which makes sense for pushing updates as deltas) rather than a collection of packages.
Though, cygwin does installs and updates exactly as you describe, so it's definitely doable.
I agree. The way that Windows package management, if you will, is geared towards single file binary installers. Or, a network admin install, as MSI supports both. Really, I haven't seen much legit use of DLLs as they were intended (shared libraries) when it comes to applications. After "DLL Hell" everyone just started statically linking in the libraries, and can you blame them? I mean, MSI does have some really cool features, but dependency tracking for DLLs is not one of them.
.msi, double click on it, and watch the bar go across the screen. And, for the most part, Windows does this well, barring the usual head-desk moments that we all love (aha! let's use spaces in the %programfiles% directory name and then half support them and leave everyone guessing where they should put quotes!) and I don't think that we should try force Linux style library schemes on to a system that doesn't want or need it. Doubly so for users that won't understand it!
I routinely have statically linked executables that will just refuse to uninstall and I can't get rid of the entry. Then I'm stuck ripping out shards of the program from every folder structure and the registry... for the next two years. At that point, they're still resident when I blow away my OS partition and steamroller a new Windows install.
People are used to Windows install routines by now; you get the programName-setup.exe or
Full disclosure: I run Slackware and Windows at home (and BSD and Mac) and prefer to compile from source, at work we use RHEL and Windows and if not for the ease of having repositories, I'd take MSI-2/3 over RPM-2/3 any day of the week.
Erm, I can't tell you another company that does the wii-boxing thing. It was an ironic musing of a story I heard from a friend about his grandfather. Apparently the grandfather went to school in a single room schoolhouse and the teacher had an 'old skool' approach to conflicts between students; take them out back and give 'em each boxing gloves to go at it. I guess after that, the matter was considered settled. The high tech juxtaposition in my mind was two geeks duking it out, then gaming it out, and then, wii boxing! I snickered and then realized it could work.
I'm adding you to my friend list; keep me updated on how things are working out!
I salute you!
That being said, you owe me a keyboard and a caffeinated beverage.
The Riemann zeta function is \zeta(s) = \sum_{n=1}^{\infty} \frac{1}{n^{s}} [written for LaTeX], or "the sum of 1/(n^s) as n goes from 0 to infinity (increasing by 1 repeatedly)" [in more human-readable form].
You have a slight typo. Should be: "... as n goes from 1 to infinity ..."
You have a slight typo. It should be: "You have a slight typo. It should be: ..."
You have a slight typo. It should be: "You have an off by one error."
So long as it's not your stupid bank storing unencrypted info on tapes that went MIA. I guess the few million people that it has happened to this year, alone, would be annoyed, if not stupid.
kill -9 spammer_init
That's how I roll.
The Itanicium didn't fail on its own; Intels own Xeons killed it. Xeons simply crushed Itaniums for price/performance ratio. Especially the newly non netburst based Xeons.
Another thing to think about (besides cache coherency, ping ponging between sockets over the bus, locking overhead, etc.): You can have a million cores and it won't matter. You're only as fast as your weakest link. Right now, that's storage, but solid state hard drives will be common in the next decade for first tier storage (as straight memory bank storage becomes more common for high performance applications), the average disk access time will improve by a few orders of magnitude. Still, that only moves the problem 'forward' a level.
You still choke on the Memory Wall; you have to feed all those cores data, and you're going a few orders of magnitude slower than the CPU cores. Increasing bandwidth on the front side bus doesn't help, as you have to increase bandwidth and decrease latency. You compound this when you have many cores/sockets doing backward cache flushes to RAM.
Even if you've got a hypertransport link (as Intel doesn't, they push bits on the front side bus between sockets, IIRC) to the north bridge for each socket, you've still only got a single north bridge. You're bottlenecked again. OK, use two front side buses with an interlink. Now we're back to coherency problems, but at two points. At some point, you have to either give each socket its own RAM bank (NUMA) and isolate data (and make CPU migration for tasks take an extra hit) or figure out how to perfectly isolate and stripe your data over multiple paths to a single backing store.
No. Thunderdome is the correct response. Seriously. Wii-boxing. Geek game showdown. No physical contact, and an enjoyable way for everyone else to ease the tension that conflict can bring. Don't tell them about it... just keep a console around and when the opportunity is right, take each of them under an arm and lead them off. If you do it right and pull it off, it's one of those "... hey, did you hear about so and so... he freakin' made them Wii Box!" stories that will precede you where ever you go.
;) If they call your bluff, let the geeks eat 'em alive with technical questions like, "so, is your LDAP backend X500 DIT compliant? We need it to work with our hacked together NIS/perl-fu directory. Here, we can show you the code!"
You won't even have to break the ice the first time you meet a client. It sounds nuts, but sane solutions don't solve problems and get great results. They become political and accounting decisions if left rational for too long. As for the vendors, make them fear you by telling them to have free hardware dropped off to your tech guys to play with before you even consider making a purchasing decision. After all, if this wacky device is nearly as great as they say, the geeks'll love it! Also, Cisco and Sun were kind enough to give you a full rack to play with for a few months.
paradigm.
Pfft. Newbie. I'm still using AOL floppy disks for coasters.
Prodigy. 5 and a quarter. What now, punk?!
Wasn't "Frozen Theater Rope" 10BASE2?
*I was born in '84, slightly before my time, but I've heard War Stories*
Whom exactly do you think will be leading you? Alexander was the last general to ride in front of his troops!
Seriously, though, he didn't say he failed at CS but, rather, that programming wasn't his forte. But chances are he knows more about CS than a good portion of the managers out there. He isn't clueless, he just doesn't have a knack for programming. Most programmers don't have a knack for management. This situation works well for both parties when they can find common ground.
You are in a unique position; us programmers can't stand to be in management, we simply cannot do our jobs there (not to mention we're slightly introverts!). If you are skilled and don't mind managing, you can bring home a decent wage. Especially if you know how to manage programmers! Good management for a development team is a sorely needed position.
Just my $0.02. Any fellow programmers want to back me up or dispute my claims?
I've done it when I've got two or three computers on my desk, but I always look at the wrong monitor with the wrong keyboard. You've got to have the right most monitor matched to lowest tiered keyboard if you want to do anything productive.
And, it's worth noting that win+D will blast away most modal dialog boxes that are keeping you from launching something else while $company shows you a splash screen. Or a dialog box that you need to see a text file to get the input for (man, I freakin' hate that!).
Now, I'm hoping to remap win+C to a shotgun macro and disable Clippy for good!
one turd swallows another turd, all you got is a bigger turd...
You are a true poet.
Psh. Everyone knows he's just ripping off Poe.
Grab 4 disks, take the last 15%-20% (read: slowest tracks) of each disk and make them a four disk raid 5. Use that for your 'archive' since it's slow anyways, and you'll not want the seek performance of reaching to the inside track during regular use. Since we all know you're rolling off to DVD/CD/tape/whatever, losing this four disk RAID 5 won't matter much to you.
Then do either raid 6 over the four disks through the next 50% of the drives, and make the first 25% a blazing fast (albeit expensive in cost/MB) RAID 10.
Line up all the stripes to 256KB chunks on the RAID 5's, 128KB on the RAID 6's and 64KB on the RAID 10's (32KB where databases are) and make sure your file system/logical volume manager align to this chunk size, as well. Keeps everything fast and peppy, even while transferring to the 'archive' tracks at the end of the disk.
Take a look at the RAID card he chose, though, that's from $400-$1000 right there, depending on the version/options. Still seems a bit high, but RAM also didn't cost $25/gig two years ago! (I still can't believe the DDRII prices... if only DDRI would come down!)
I put together a 4u file server last year. 4 500 GB, WD AAKS'es. I ended up using a stripped down Slackware build with iscsi enterprise target. Since it had 2 gigs of RAM, and the OS took like 35 MB from a cold boot, I turned down the vfs_cache_pressure and let it cache inodes all day long. When I setup iscsi Enterprise Target, I gave honkin' big buffers to the app, and set huge buffers for the RAID stripes. Each disk is sliced in to 9 partitions, the last partition for archive since the slowest 15% of a disk is all but unusable.
You can mount the iscsi target from any initiator (Microsoft provides one for free from their site, and all RPM distros have the iscsi initiator as part of the extras disk/repo) and it acts just like raw disk.
My box is somewhat extravagant, but if you're feeling froggy, jump. I stripe three gigE connections to two cascaded switches, (two on one, one on the other) and do the same for my server which is mounting the exported disks. Then I have two connections to my LAN which my Windows and Linux desktops mount directly.
This also allows me to utilize buffering in the Linux kernel at the file system level by mounting a dd'ed raw image. Since it's on a loopback mount, everything passes the inodes (when shared as a file instead of a blockdev) cache, and instead is buffered. That means I've got a bunch of 20 Gig raw image files lying around that I just mount on a loopback and export over iscsi with a ~1.5 gig buffer dedicated to it.
Granted, it took weeks and a lot of heads down time to get setup (not to mention kernel compiles!), but it's stable as a rock and faster than greased lightning!