He's not just speaking crap. There's a whole lot of "layers" within X11 itself, although in recent times xorg still manages to perform reasonably well. The X11 architecture is quite dated - especially wrt to extensions (not that everything under the sun hasn't been hacked onto the side of it anyways), widgets, and the assumptions that underly X11 (and therein, especially its assumptions about networking). The *nix world is due for a better windowing system sometime Real Soon Now. Either the xorg/fdo guys will revamp X11 to the point of being nearly unrecognizable and keep around a backwards-compatible api layer for legacy X11 apps, or some startup similar in nature to Y-windows will take hold (Y-windows was a really nice concept, but it died an early death due to lack of interest from some of the main developers because xorg/x11 started to tack on the features that were the partial impetus for the project).
Just use PostgreSQL and be happy. As soon as you start having to ask yourself questions about what "storage engine" you're using, or whether your transactions are really coherent, or start thinking maybe you really did need proper modern (OO)RDBMS features, it's time to drop the toy and start using the real option.
Here's a clue if you don't want to think for yourself:
1) Athlon64 architecture rules, just dump Intel. 2) Better yet, wait for their new socket design to appear early next year or so, since the current Athlon64 socket interface is about to die, and the new has twice the memory speed. 3) When you see the new Athlon64's come out, look at the price curve of the various speed offerings in the new socket. Pick the one somewhere in the middle just before the price goes skyrocketing upwards - that one's probably your best overall price/performance ratio, and you'll never know the difference from the fast one unless you break out the artificial benchmarks. 4) When you see the new Athlon64's come out, it'll say what the name of the new socket is (I'd tell you now, but you'll just get confused and forget). Buy a motherboard with that socket, they'll all be about the same. Preferably from a manufacturer like Asus or Abit. 5) Buy as much RAM as you can afford, of the fastest speed supported by the motherboard above, up to say 2GB tops. Buy it as an evenly matched pair of two sticks. Getting 2GB instead of 1GB is probably worth more than getting the lowest CAS latency, so just ignore that factor. Buy ECC RAM too - it's slightly slower, but it's so much less headache when you know for sure whether your RAM is the issue without running a 32 hour memory test every time you suspect something. 6) Buy your graphics card from the same company as the motherboard above. Buy the latest most expensive NVidia, and it will last you through your next couple of motherboard/cpu upgrades. It should be the same graphics interface as the board above (which would be PCI-Express x16). 7) If you put in any plexiglass or glowing neon shit in your case, I'll come to your house and shoot you.
But you see, putting up money for a Darwin Exhibit is merely a charitable contribution to science education. There is no agenda or stand to take in that. It's no different that putting up money in a charitable way to fund putting crayons in 1st grader's desks at a local school.
What has made it an issue is the asshat Fundie-Christians spouting bullshit. And I don't want any part in a corporation which is so collectively stupid as to fall for that crap.
The only solid practice for maintaining Windows, if it can be said to be one, is to re-install on a regular basis. Set a schedule for yourself, somewhere between every 1-6 months. Keep a list of all the things you need to do (settings, software to re-install, etc).
1984 and H2G2, but no Sirens of Titan?
on
Top 20 Geek Novels
·
· Score: 3, Informative
I think they polled a not-so-well read segment of the geek population. Anyone who loved 1984 and H2G2 (which made spots 2 and 1 on the list) should have also read Vonnegut's The Sirens of Titan. It fills the space inbetween those two seemingly disconnected books we love so much; in many ways it is the literary bridge from 1984 to H2G2, and one of the greatest works of modern fiction on its own. A fan of either (or both) would see the connections readily, and appreciate it, and it certainly belongs in that list with them.
I don't dispute that the UN did those things. But you have to bear in mind what the UN actually is. The UN is socialism between governments on a grand scale. Effectively the UN is a body where a whole lot of otherwise deadbeat countries get to vote to decide the course of action of said body, but virtually all of the resources which the body needs to take action are provided by the wealthiest countries in the body. In practical terms, it's a way for the rest of the world to leverage some control over the US, EU, former USSR, and Australia, and in turn a way for those countries to leverage some control over each other, and especially the US (since we're the current king of the hill). Leverage in the downward direction (from dominant countries to lesser ones) is automatic without a UN body - that's just the law of nature. The purpose of the UN is to provide a framework for leveraging back in the other direction.
And to at least some degree, even what the UN provides would be automatic without it. Those 16 peacekeeping operations mostly rely on US (and some EU) resources in terms of money, hardware, and troops. If the UN didn't exist, chances are high that the same US/EU resources would still be deployed to the same places, just not under a UN flag.
I care very much how other people perceive me, and I care what they think. But what I would like them to think is, "This guy is focused on absolutely nothing but the most efficient way to solve the technical problem at hand", not "Gee he's a slick dresser, he must be trying to impress The Boss/Secretary". How you dress is entirely about social matters, not technical ones. Caring about what you wear implies that some brain cells that could be spent on the problem at hand are being spent on useless social drama.
Typically on a traditional 32-bit OS files within a filesystem were limited to 2GB in size. Some people have easily more than 2GB of mail, and if your mail system stores all of a user's mail within a single "mailbox" file, you see the problem.
OTOH, it's not really smart at all for a mail server to have one file per user (or even one file per "mail folder") - methods akin to the unix Maildir standard are far more efficient on modern filesystems that scale well as dentry lists grow.
And OTOOH, most 32-bit OS's on 32-bit processors support 64-bit filesystem extensions, allowing files much larger than 2GB anyways, although perhaps not as efficiently as they could in a native 64-bit environment (but we're not talking about a huge, or even normally noticeable, efficiency difference).
In the unlikely event that any of your projects involve Perl (even if just peripherally as build tool scripts and whatnot), I'd highly recommend setting your company's Perl coding standards to just be "follow the Perl Best Practices book". It just came out this summer, and it's pretty much all you need for a fairly rigorous and insightful set of coding practices for Perl.
Moore's Law is not neccesarily about what the maximum gflops/dollar is over time (actually, who really knows what it's really about for sure... see: http://en.wikipedia.org/wiki/Moore's_Law), and on top of that, a Cray Y-MP was probably never the best gflops/dollar package, even in its heyday. The old Crays were more about maximum gflops, period. There was probably a low-end processor at the time that cranked out more gflops/dollar, but commodity clusters of cheap processors were virtually unheard of at the time.
Perhaps in academia, but don't forget that where some of us work, we're private users of supercomputer horsepower. And at least in my private area, it's still all about raw computer power per dollar (where dollars include hardware purchase, maintenance, administration, power, air conditioning... and yes, even programmer time, but see next sentence). However, our algorithms change infrequently, while bulk data to be processed and mined and whatnot comes in constantly. If we had to change our algorithms for every job, then perhaps we'd be back in the same boat as academia, but we don't.
MD5 is dead. SHA-1 is currently dying. They're both based on the same fundamental math, and the attacks on SHA1 are getting stronger and stronger. Now would be a really good time to get off of that entire family of hashes if you can (MD4, MD5, RIPEMD-* SHA-*, etc).
The crypto world is in a little bit of a bind when it comes to strong hashes now. We simply don't have any left that both have a long proven track record of analysis and haven't been seriously compromised. Best bet, IMHO, is to go with a new-blood hash algorithm. They seem to be the answer we're looking for - but of course what they lack is more years of intensive study by the experts for flaws they themselves might harbor.
So if you want to give them a whirl, I'd recommend looking at Tiger and Whirlpool:
There are trust-relationship algorithms for dealing with the poisoning/honeypot problems. There are known methods from clustering research that are applicable in terms of bootstrapping without trying to go down a serial list of every possible active node, and for using distributed hashes such that nobody needs to know the entire content index at once. Real p2p is possible, it's just that nobody has yet pulled all the peices together to make it happen (which, in the p2p coders' defense, is a very complex problem for sure).
What sucks is that the neccesity of home NAT-ing and the ubiquity of asymmetric home uplinks make it painful at best for p2p code to do what it wants to do efficiently. Someday (soon I hope) we'll all be part of local loose ad-hoc wireless meshes in addition to the assorted real uplink connections scattered around, and at least then p2p will begin to scale more like it promises to.
Hello, anonymous Sequoia promoter seeking free advertising. (BTW, You might try picking a product name that normal people can spell without thinking about it).
Your solution is not database clustering, and should not be advertised as such. It's more a long the lines of a database connection proxy which supports multiple simultaneous backends and operating on them in parallel, with some added features to make HA-like solutions relatively easy.
The downside of this style of approach, as opposed to an architecture of the likes of Oracle "RAC", is that it doesn't scale up as you add backend nodes (at least not for writes, but in any case for read-only scaling there are simpler solutions for all of the vendors, even the free ones), and it must have limits on how many transactions it can backlog and replay to a temporarily-unreachable/down server before that server has to be re-synced from scratch in order to catch back up (and I have to wonder if there's really any real-world scenario under real transaction load in which the practical net effect wouldn't be a complete resync of a backend server anytime something goes wrong with it, in which case one could throw out any attempt to backlog transactions for a single failed server and just keep things simple - you fall out of sync, you resync).
The open source world really needs a RAC-like solution for PostgreSQL and MySQL (I'm a fan of friendly open-source competition, so while my personal preference is PostgreSQL, I hope both projects stay current and popular for many years to come). Unfortunately there is unlikely to be a generic way to do this, it will probably have to be re-invented for each database project.
I took a brief look around PostgreSQL's guts a while back, and it actually seemed like the architecture they use isn't far off from something RAC-capable to begin with, just nobody's quite buttoned together a few peices here and there to make it happen. Basically on SMP multiple co-operating backends already serve parallel requests and synchronized on a shared memory cache. There's patches out there for the linux kernel to support network-synchronized distributed shared memory. Put two and two together, and what do you get? Something not far off from a first-pass hack at a RAC-like network-distributed database caching system. Most of the other details are easy to solve (start/shutdown, join/leave cluster, tracking of processes across the cluster, etc), or belong in another problem domain (implementing shared storage filesystems (hey, we have GFS, Oracle OCFS, etc available...)). One of the biggest issues would be multiple nodes all having pg "Writer" processes. The first step would probably be to put the writer on one node and failover the writer functionality when that node dies, to be quickly replaced by a scheme whereby multiple writers can work by synchronizing through a distributed lock manager (there are already dlm modules available for linux). Then there's the issue of making the current distributed shared-memory patches do the right thing performance-wise for this kind of usage, and so on. It's not easy, but it's not outside the realm of possibility.
The big difference is that the types of multiprocessing you can typically achieve with MPI on a tight-knit cluster is different than what you can achieve with a loose-knit cluster like seti@home. Seti@home, in terms of clusters, has very low bandwidth between nodes, and a very high interconnect latency, making certain tasks infeasibly slow on such a layout. Contrasted against a distributed setup like Set@home, the current gen of Top500 linux clusters tend to have very high bandwidth and very low latency between nodes.
But for problems which can be reasonably broken up into large chunks with low inter-node communication, obviously, the distributed approach is capable of winning by brute force if enough people throw their PCs at it.
A lot of shared memory synchronization and/or caching problems can be solved on Linux through the effective use of a few simple things:
1) shm_open (if seperately-started processes which need to coordinate in shared memory), or mmap(MAP_SHARED|MAP_ANONYMOUS) for a process which will fork children which need to communicate/share between themselves and the parent.
2) Use 's "atomic_t" integer type within that shared memory array (atomic_t* my_shm_array = mmap(....)). The atomic_t type has several functions defined in that header for atomic read, write, increment, etc for the linux hardware platform at hand. On most sane (cache-coherent) SMP architectures, reading and writing are already atomic operations, so this basically devolves to just setting and getting integers like normal (with a little bit of syntactic sugar (struct { volatile int val }) to make sure the C compiler doesn't optimize things away that it shouldn't. And you can implement a whole lot of sane algorithms using nothing but shared memory integer reads and writes with no locking or special atomic increment ops.
3) If you need more advanced or complex locking on the shared memory for synchronization, use Linux's "futex"'s. They're in the man pages, and they're really fast.
I agree with you in theory, but the line of reasoning that Nintendo would use is that they might want to design new products based on their old patents, and they should have exclusive right to do so. For example, they might theoretically introduce a miniature retro-NES which contains NES guts + 200 popular oldschool games all bundled inside a single controller with a TV-out (like the other retro games machines in controller form factor we've seen lately).
Mostly he's referring to minor libc updates that happen regularly. libc5 -> libc6 was a massive change that in some cases involved a lot more than running an updater and rebooting for some distros. libc5 -> libc6 was one of those rare few and far between changes where everything gets broken. There will always be major marks in time like that.
You're very lucky you got a year's notice. Take advantage of that to find your new position with lots of time to spare. If you find one before the year's up, leave. They clearly don't care about your future, stop caring about thiers. The only time compensation packages are really appropriate or neccesary is in the case of layoffs without much notice (say, less than 3 months notice). No reasonable compensation package from your company is going to make up for sticking it out to the end. You're much better off using your time wisely to locate a new employer and jumping ship as soon as you find a good one.
I strongly suspect this is the primary reason they gave a year's notice - in hopes that several of the employees will jump ship to new jobs before the year is up and not take the compensation plan for staying until the actual layoff, which saves them some cash.
Troll a politician or something. Whatever happened to respect for those that deserve it? I may have ideological disagreements with both Mr Cerf and Mr Stallman, but I'd never show either of them any personal disrepect. They are both incredibly intelligent and talented, and were both absolutely essential in building the world in which I live today; one that would be far worse without their past efforts.
Re:Factored... Big Deal
on
RSA-640 Factored
·
· Score: 1, Interesting
Scratch that, I read some more about the GNFS they're using, and while I don't claim to understand completely, I don't think it would take them 2^32 longer to reach RSA-704 - it may well be in reach in the relatively near future.
Re:Factored... Big Deal
on
RSA-640 Factored
·
· Score: 2, Interesting
The 212 digit one (RSA-704) won't be cracked for a long, long time yet using current algorithms like the ones the RSA-640 winners did. 640->704 doesn't sound like much, but it is monumental. I did some back-of-the-envelope math. I'm naively assuming that with a 64-bit gain in key size, the problem complexity is 2^32 harder (since one factor is always under the square root). I'm sure that seive algorithm they're using manages to cut that 2^32 down some, but it's not going to make a practical difference I don't think. If you happen to have ~8000 Opteron cpus at your disposal instead of their 80, and you have the same code they cracked RSA-640 in 5 months with, and it scales up to 8000 cpus just fine, it would take somewhere in the neighborhood of hundreds of millions of years to break RSA-704.
Slashdot Mirror
He's not just speaking crap. There's a whole lot of "layers" within X11 itself, although in recent times xorg still manages to perform reasonably well. The X11 architecture is quite dated - especially wrt to extensions (not that everything under the sun hasn't been hacked onto the side of it anyways), widgets, and the assumptions that underly X11 (and therein, especially its assumptions about networking). The *nix world is due for a better windowing system sometime Real Soon Now. Either the xorg/fdo guys will revamp X11 to the point of being nearly unrecognizable and keep around a backwards-compatible api layer for legacy X11 apps, or some startup similar in nature to Y-windows will take hold (Y-windows was a really nice concept, but it died an early death due to lack of interest from some of the main developers because xorg/x11 started to tack on the features that were the partial impetus for the project).
Just use PostgreSQL and be happy. As soon as you start having to ask yourself questions about what "storage engine" you're using, or whether your transactions are really coherent, or start thinking maybe you really did need proper modern (OO)RDBMS features, it's time to drop the toy and start using the real option.
Here's a clue if you don't want to think for yourself:
1) Athlon64 architecture rules, just dump Intel.
2) Better yet, wait for their new socket design to appear early next year or so, since the current Athlon64 socket interface is about to die, and the new has twice the memory speed.
3) When you see the new Athlon64's come out, look at the price curve of the various speed offerings in the new socket. Pick the one somewhere in the middle just before the price goes skyrocketing upwards - that one's probably your best overall price/performance ratio, and you'll never know the difference from the fast one unless you break out the artificial benchmarks.
4) When you see the new Athlon64's come out, it'll say what the name of the new socket is (I'd tell you now, but you'll just get confused and forget). Buy a motherboard with that socket, they'll all be about the same. Preferably from a manufacturer like Asus or Abit.
5) Buy as much RAM as you can afford, of the fastest speed supported by the motherboard above, up to say 2GB tops. Buy it as an evenly matched pair of two sticks. Getting 2GB instead of 1GB is probably worth more than getting the lowest CAS latency, so just ignore that factor. Buy ECC RAM too - it's slightly slower, but it's so much less headache when you know for sure whether your RAM is the issue without running a 32 hour memory test every time you suspect something.
6) Buy your graphics card from the same company as the motherboard above. Buy the latest most expensive NVidia, and it will last you through your next couple of motherboard/cpu upgrades. It should be the same graphics interface as the board above (which would be PCI-Express x16).
7) If you put in any plexiglass or glowing neon shit in your case, I'll come to your house and shoot you.
But you see, putting up money for a Darwin Exhibit is merely a charitable contribution to science education. There is no agenda or stand to take in that. It's no different that putting up money in a charitable way to fund putting crayons in 1st grader's desks at a local school.
What has made it an issue is the asshat Fundie-Christians spouting bullshit. And I don't want any part in a corporation which is so collectively stupid as to fall for that crap.
The only solid practice for maintaining Windows, if it can be said to be one, is to re-install on a regular basis. Set a schedule for yourself, somewhere between every 1-6 months. Keep a list of all the things you need to do (settings, software to re-install, etc).
I think they polled a not-so-well read segment of the geek population. Anyone who loved 1984 and H2G2 (which made spots 2 and 1 on the list) should have also read Vonnegut's The Sirens of Titan. It fills the space inbetween those two seemingly disconnected books we love so much; in many ways it is the literary bridge from 1984 to H2G2, and one of the greatest works of modern fiction on its own. A fan of either (or both) would see the connections readily, and appreciate it, and it certainly belongs in that list with them.
I don't dispute that the UN did those things. But you have to bear in mind what the UN actually is. The UN is socialism between governments on a grand scale. Effectively the UN is a body where a whole lot of otherwise deadbeat countries get to vote to decide the course of action of said body, but virtually all of the resources which the body needs to take action are provided by the wealthiest countries in the body. In practical terms, it's a way for the rest of the world to leverage some control over the US, EU, former USSR, and Australia, and in turn a way for those countries to leverage some control over each other, and especially the US (since we're the current king of the hill). Leverage in the downward direction (from dominant countries to lesser ones) is automatic without a UN body - that's just the law of nature. The purpose of the UN is to provide a framework for leveraging back in the other direction.
And to at least some degree, even what the UN provides would be automatic without it. Those 16 peacekeeping operations mostly rely on US (and some EU) resources in terms of money, hardware, and troops. If the UN didn't exist, chances are high that the same US/EU resources would still be deployed to the same places, just not under a UN flag.
I care very much how other people perceive me, and I care what they think. But what I would like them to think is, "This guy is focused on absolutely nothing but the most efficient way to solve the technical problem at hand", not "Gee he's a slick dresser, he must be trying to impress The Boss/Secretary". How you dress is entirely about social matters, not technical ones. Caring about what you wear implies that some brain cells that could be spent on the problem at hand are being spent on useless social drama.
Perhaps you're about to keel over tommorow and the signs are obvious, but you're in denial of the symptoms
Typically on a traditional 32-bit OS files within a filesystem were limited to 2GB in size. Some people have easily more than 2GB of mail, and if your mail system stores all of a user's mail within a single "mailbox" file, you see the problem.
OTOH, it's not really smart at all for a mail server to have one file per user (or even one file per "mail folder") - methods akin to the unix Maildir standard are far more efficient on modern filesystems that scale well as dentry lists grow.
And OTOOH, most 32-bit OS's on 32-bit processors support 64-bit filesystem extensions, allowing files much larger than 2GB anyways, although perhaps not as efficiently as they could in a native 64-bit environment (but we're not talking about a huge, or even normally noticeable, efficiency difference).
In the unlikely event that any of your projects involve Perl (even if just peripherally as build tool scripts and whatnot), I'd highly recommend setting your company's Perl coding standards to just be "follow the Perl Best Practices book". It just came out this summer, and it's pretty much all you need for a fairly rigorous and insightful set of coding practices for Perl.
http://search.barnesandnoble.com/booksearch/isbnI
Moore's Law is not neccesarily about what the maximum gflops/dollar is over time (actually, who really knows what it's really about for sure... see: http://en.wikipedia.org/wiki/Moore's_Law), and on top of that, a Cray Y-MP was probably never the best gflops/dollar package, even in its heyday. The old Crays were more about maximum gflops, period. There was probably a low-end processor at the time that cranked out more gflops/dollar, but commodity clusters of cheap processors were virtually unheard of at the time.
Perhaps in academia, but don't forget that where some of us work, we're private users of supercomputer horsepower. And at least in my private area, it's still all about raw computer power per dollar (where dollars include hardware purchase, maintenance, administration, power, air conditioning... and yes, even programmer time, but see next sentence). However, our algorithms change infrequently, while bulk data to be processed and mined and whatnot comes in constantly. If we had to change our algorithms for every job, then perhaps we'd be back in the same boat as academia, but we don't.
MD5 is dead. SHA-1 is currently dying. They're both based on the same fundamental math, and the attacks on SHA1 are getting stronger and stronger. Now would be a really good time to get off of that entire family of hashes if you can (MD4, MD5, RIPEMD-* SHA-*, etc).
The crypto world is in a little bit of a bind when it comes to strong hashes now. We simply don't have any left that both have a long proven track record of analysis and haven't been seriously compromised. Best bet, IMHO, is to go with a new-blood hash algorithm. They seem to be the answer we're looking for - but of course what they lack is more years of intensive study by the experts for flaws they themselves might harbor.
So if you want to give them a whirl, I'd recommend looking at Tiger and Whirlpool:
http://en.wikipedia.org/wiki/Tiger_(hash)
http://en.wikipedia.org/wiki/Whirlpool_(algorithm
There are trust-relationship algorithms for dealing with the poisoning/honeypot problems. There are known methods from clustering research that are applicable in terms of bootstrapping without trying to go down a serial list of every possible active node, and for using distributed hashes such that nobody needs to know the entire content index at once. Real p2p is possible, it's just that nobody has yet pulled all the peices together to make it happen (which, in the p2p coders' defense, is a very complex problem for sure).
What sucks is that the neccesity of home NAT-ing and the ubiquity of asymmetric home uplinks make it painful at best for p2p code to do what it wants to do efficiently. Someday (soon I hope) we'll all be part of local loose ad-hoc wireless meshes in addition to the assorted real uplink connections scattered around, and at least then p2p will begin to scale more like it promises to.
Hello, anonymous Sequoia promoter seeking free advertising. (BTW, You might try picking a product name that normal people can spell without thinking about it).
Your solution is not database clustering, and should not be advertised as such. It's more a long the lines of a database connection proxy which supports multiple simultaneous backends and operating on them in parallel, with some added features to make HA-like solutions relatively easy.
The downside of this style of approach, as opposed to an architecture of the likes of Oracle "RAC", is that it doesn't scale up as you add backend nodes (at least not for writes, but in any case for read-only scaling there are simpler solutions for all of the vendors, even the free ones), and it must have limits on how many transactions it can backlog and replay to a temporarily-unreachable/down server before that server has to be re-synced from scratch in order to catch back up (and I have to wonder if there's really any real-world scenario under real transaction load in which the practical net effect wouldn't be a complete resync of a backend server anytime something goes wrong with it, in which case one could throw out any attempt to backlog transactions for a single failed server and just keep things simple - you fall out of sync, you resync).
The open source world really needs a RAC-like solution for PostgreSQL and MySQL (I'm a fan of friendly open-source competition, so while my personal preference is PostgreSQL, I hope both projects stay current and popular for many years to come). Unfortunately there is unlikely to be a generic way to do this, it will probably have to be re-invented for each database project.
I took a brief look around PostgreSQL's guts a while back, and it actually seemed like the architecture they use isn't far off from something RAC-capable to begin with, just nobody's quite buttoned together a few peices here and there to make it happen. Basically on SMP multiple co-operating backends already serve parallel requests and synchronized on a shared memory cache. There's patches out there for the linux kernel to support network-synchronized distributed shared memory. Put two and two together, and what do you get? Something not far off from a first-pass hack at a RAC-like network-distributed database caching system. Most of the other details are easy to solve (start/shutdown, join/leave cluster, tracking of processes across the cluster, etc), or belong in another problem domain (implementing shared storage filesystems (hey, we have GFS, Oracle OCFS, etc available...)). One of the biggest issues would be multiple nodes all having pg "Writer" processes. The first step would probably be to put the writer on one node and failover the writer functionality when that node dies, to be quickly replaced by a scheme whereby multiple writers can work by synchronizing through a distributed lock manager (there are already dlm modules available for linux). Then there's the issue of making the current distributed shared-memory patches do the right thing performance-wise for this kind of usage, and so on. It's not easy, but it's not outside the realm of possibility.
The big difference is that the types of multiprocessing you can typically achieve with MPI on a tight-knit cluster is different than what you can achieve with a loose-knit cluster like seti@home. Seti@home, in terms of clusters, has very low bandwidth between nodes, and a very high interconnect latency, making certain tasks infeasibly slow on such a layout. Contrasted against a distributed setup like Set@home, the current gen of Top500 linux clusters tend to have very high bandwidth and very low latency between nodes.
But for problems which can be reasonably broken up into large chunks with low inter-node communication, obviously, the distributed approach is capable of winning by brute force if enough people throw their PCs at it.
The new Opterons on the new socket architecture actually will have DDR2, it was just announced publicly a week ago or so.
A lot of shared memory synchronization and/or caching problems can be solved on Linux through the effective use of a few simple things:
1) shm_open (if seperately-started processes which need to coordinate in shared memory), or mmap(MAP_SHARED|MAP_ANONYMOUS) for a process which will fork children which need to communicate/share between themselves and the parent.
2) Use 's "atomic_t" integer type within that shared memory array (atomic_t* my_shm_array = mmap(....)). The atomic_t type has several functions defined in that header for atomic read, write, increment, etc for the linux hardware platform at hand. On most sane (cache-coherent) SMP architectures, reading and writing are already atomic operations, so this basically devolves to just setting and getting integers like normal (with a little bit of syntactic sugar (struct { volatile int val }) to make sure the C compiler doesn't optimize things away that it shouldn't. And you can implement a whole lot of sane algorithms using nothing but shared memory integer reads and writes with no locking or special atomic increment ops.
3) If you need more advanced or complex locking on the shared memory for synchronization, use Linux's "futex"'s. They're in the man pages, and they're really fast.
I agree with you in theory, but the line of reasoning that Nintendo would use is that they might want to design new products based on their old patents, and they should have exclusive right to do so. For example, they might theoretically introduce a miniature retro-NES which contains NES guts + 200 popular oldschool games all bundled inside a single controller with a TV-out (like the other retro games machines in controller form factor we've seen lately).
Mostly he's referring to minor libc updates that happen regularly. libc5 -> libc6 was a massive change that in some cases involved a lot more than running an updater and rebooting for some distros. libc5 -> libc6 was one of those rare few and far between changes where everything gets broken. There will always be major marks in time like that.
You're very lucky you got a year's notice. Take advantage of that to find your new position with lots of time to spare. If you find one before the year's up, leave. They clearly don't care about your future, stop caring about thiers. The only time compensation packages are really appropriate or neccesary is in the case of layoffs without much notice (say, less than 3 months notice). No reasonable compensation package from your company is going to make up for sticking it out to the end. You're much better off using your time wisely to locate a new employer and jumping ship as soon as you find a good one.
I strongly suspect this is the primary reason they gave a year's notice - in hopes that several of the employees will jump ship to new jobs before the year is up and not take the compensation plan for staying until the actual layoff, which saves them some cash.
Dumbass Troll.
Troll a politician or something. Whatever happened to respect for those that deserve it? I may have ideological disagreements with both Mr Cerf and Mr Stallman, but I'd never show either of them any personal disrepect. They are both incredibly intelligent and talented, and were both absolutely essential in building the world in which I live today; one that would be far worse without their past efforts.
Scratch that, I read some more about the GNFS they're using, and while I don't claim to understand completely, I don't think it would take them 2^32 longer to reach RSA-704 - it may well be in reach in the relatively near future.
The 212 digit one (RSA-704) won't be cracked for a long, long time yet using current algorithms like the ones the RSA-640 winners did. 640->704 doesn't sound like much, but it is monumental. I did some back-of-the-envelope math. I'm naively assuming that with a 64-bit gain in key size, the problem complexity is 2^32 harder (since one factor is always under the square root). I'm sure that seive algorithm they're using manages to cut that 2^32 down some, but it's not going to make a practical difference I don't think. If you happen to have ~8000 Opteron cpus at your disposal instead of their 80, and you have the same code they cracked RSA-640 in 5 months with, and it scales up to 8000 cpus just fine, it would take somewhere in the neighborhood of hundreds of millions of years to break RSA-704.