Whenever I'm doing exploratory coding and trying to figure things out, I tend to spend a few hours googling around on related topics. Often you'll turn up the solutions you need, or at least things that move you in the right direction. Doesn't matter whether what you find is a paper like the ones you're talking about, or the source code of some crappy perl module someone wrote - if it's related, you'll find it through google.
People with defensible political positions don't need to be anonymous in such a trivial matter. The Dems in the referenced matter acted like whiny bitches, and did waste our time and money. I understand that the Republicans were twisting the re-districting to their advantage, but they were doing it within the letter of the law, which is all you can ask for these days. To walk out of the state and refuse to even participate in congress was pathetic and childish, but typical.
At first I figured the output, while long lasting, would just be too low to be useful. I went to beta-batt's website, got the numbers and did the math. These batteries are surprisingly good.
The first-gen tritium ones (and tritium ones is probably all we'll ever see in commercial applications) put out 400 microwatts per cubic centimeter of nuclear battery volume, half-lifing at 12 years of course.
Based on various data I pulled from Energizer's website and Betabatt's website, it comes out like this:
A regular AA-sized NiMH rechargeable battery (2,500mAh @ 1.2V) can be recharged by a nuke battery of identical volume (picture a companion Nuclear-AA battery next to it) from empty to full in roughly one month. Or five AA-sized nuked batteries could recharge a normal NiMH AA in a little under a week. In either case, that's for years (obviously, the charging rate gets slower as the years go on).
Even in that form, it's quite useful. Assuming linear scalability in both regular and nuke batteries, that means if you have a device which can last up to two months on a rechargeable battery of some size, you can stick a nuke-charged of equivalent volume to your battery next to it, and between the two of them your device will stay continuously powered for at least 12.3 years.
Imagine when the next generations come out and get more efficient. I can't wait. For useful largish devices you'll always need a chemical battery for bursty amperage, but have a nuke-batt as a recharger is so handy.
Who lets these crackheads post stories? Linux has been running native 64-bit on several platforms for years, and years, and years. Hell even in the x86 world, I've got ~9,000 Opteron CPUs chugging under the power of Linux in 64-bit mode at work, and they're just trashy lease boxes.
Whereas tracking and killing innocent animals on foot is just fine?
You're damn right it is. God forbid all you liberal weenies ever have to rough it living outdoors on your own, you'd never make it trying to subsist on berries. By the way, didn't you ever stop to consider how the berries feel about it? Welcome to Nature, we kill things to eat them here. Cheetahs use their speed; spiders use their venom; humans use their brains to build whatever implements they might need.
We all know this is what's really going on, that essentially we're getting corporations to pay our salaries while we work together for the common benefit of all. We also know that doing this is in the corporation itself's best interest if the corporation can use the resulting software, which is why we don't have any guilt about it.
But the PHB types really don't get it. As long as we keep them thinking that a large chunk of the software they're running is being given to them for free by some smart guy in mom's basement, and the collaborator they hired is there to make sure their needs are met, they feel like they're getting a good deal, and they are. When they realize what's really going on, they'll throw a shit fit because they can't fathom the idea that they are collaborating with their competitors for mutual benefit.
Guns don't belong on that list. Wake up and get out to your local gun range and start shooting, and you'll eventually figure out why once you get into it and start hanging out with more gun owners. To elucidate here would just raise ignorant arguments against them.
Absolutely brilliant, fairly original, well-made, engaging, simple arcade-ish games. I especially liked the fish-tank game and the one with the spiral tracks of balls that you shoot.
Right outta the box you're going to subject them to learning the semantics of the editor that wishes it was an operating system and requires 8 metakeys and 3 floor pedals to operate? Talk about BOFH.
And don't forget the most important lesson of all, imparted on the world by a minority of US citizens mostly residing in CA and NY: How to be a whining liberal bitch that backstabs your own country by trumpeting logical fallacies and other non-arguments from their pseudo-intellectual rooftops.
They are lacking the vision to see the purpose of Google's efforts, and the purpose of libraries like themselves in general.
The purpose of a traditional library is to collect, catalog, and preserve the writings of humanity for the benefit of ourselves and our children to come.
The purpose of digitization projects like Google's is to bring this into a new era. The purpose is not to turn each individual library into an electronic form of its current self - the very idea of disparate libraries was merely a consequence of the times. The purpose is to build a single worldwide virtual digital library, covering more ground and providing more accessibility than any single library could hope to.
Google's project isn't there yet, but that's the direction they are pushing. And these libraries are being divisive and standing in the way of progress. They lack the vision of what they should be doing, and they're harming progress in the name of pride.
There are some subtleties that most people don't realize, however.
For the sake of example, assume a given project has only a single author. Said author owns the copyright to the code, and distributes it to the public in an unrestricted fashion under the terms of the GPL.
If a random member of the public wanted to fork/commercialize his code, they are bound by the GPL to keep re-releasing their changes under the GPL. However if the original Author wanted to fork his own work and make a commercial effort out of it, he can do that and make his future contributions proprietary, as the GPL doesn't apply to the Author himself (he didn't license it to himself, he owns the copyright to begin with).
Therefore, it is entirely possible for an individual author to write and maintain a peice of free software for years, and then fork his own work into a proprietary commercial derivative that nobody has any future rights to the code of except him. What he cannot do, of course, is revoke any code he already published under the GPL. This leaves his user community able to pick up the work from the last GPL version the Author released and continue the effort under the terms of the GPL.
However, most significant projects have multiple Authors, and all of the Authors would have to agree on this course of action in order to do it. That's why such a thing can't really happen to a body of work like glibc, gcc, or the linux kernel: there are far too many authors with the copyrights in the code all over the place, and you could never get them to all agree to come under one commercial roof together and make a proprietary fork.
Just the throw a monkey wrench in your line of reasoning, I didn't get an IT degree, didn't get a certification, and didn't get a CS degree. I didn't even try to. And yet I've worked a productive 10 years in the IT field, and spent the vast majority of that time doing CS tasks (systems research and design, and *tons* of coding). I'm more a computer scientist than anyone who actually has a CS degree that I've ever personally met, and I'm in IT.
It kinda boils down to the domain-specific knowledge thing another poster was talking about. Just as it might be useful to get someone with say a Financial degree/background to learn how to code and have them write a financial application, as opposed to having some pure CS person do it, the same applies in IT.
IT-related software*, when written by CS guys, tends to suck in my experience in the industry. You need sysadmins from the trenches who have a solid skill and interest in computer science to do these things. And these guys, who I count myself among, are IT professionals doing CS tasks.
*(And by IT software I mean: clustering solutions for scalability and/or reliability, systems monitoring software (ever try to pull statistical information as well as near-real-time availability alerts from a 5000+ machine datacenter?), distributed systems configuration management and administration, etc)
Back when it used to seem like a lot (~1997?), we used to "steal" all the processing time on 4 Sun E10Ks and 7 frames of IBM SP/2 nodes and do SETI and Distributed.Net work on them when they idle between real projects.
What about cool home science gear that doesn't belong in a home? A guy at my office has 2 and a half electron microscopes in his garage he uses to peek at anything and everything that interests him around the house. I believe between the 2.5 microscopes worth of parts, one is actually running at the moment.
PCI-X is not PCI-Express, and the two technologies don't even have compatible pinouts or signals. PCI-X is the follow-on to traditional parallel PCI, with speeds of 100 and 133 Mhz and a 64-bit wide data path (compared to previous parallel PCI standards of 32/64-bits at 33/66 Mhz). PCI-Express is PCI re-done serially instead of in parallel, in an attepmt to be fashionable like the new Serial ATA standard. It's also potentially faster than PCI-X, and not at all compatible.
You'll notice just about every communications standard that doesn't go long haul alternates back and forth between parallel and serial methods every few years just to sound new and exciting and better.
Aside from what others have already pointed out, namely that your chosen CPU and Chipset don't appear to support dual processors to begin with, the idea of having a custom motherboard made is silly.
Motherboards are extremely complex peices of equipment. An enormous amount of work goes into getting them production-quality, it's a lot more than just wiring the rights pins of the right chips and sockets together. There's all the EMF and heat effects to consider, trace lengths and their effect on signal propogation, etc. Then ocne you have a baord that's even capable of functioning reliably, you have to make a BIOS for it and get all the right parameters tweaked correctly to initialize the board the right way - there's a lot of values tuned by the vendor for the board in question that you never see in your little BIOS setup screen.
Even among commercial boards, as we've seen on review sites, there are varying levels of success at building a rock-solid stable board. It requires an enormous amount of engineering man-hours to go through the design and testing process, and sometimes they still can't get it quite right, and half the boards are a little "flaky" under the wrong conditions.
So even if you wanted to drop some enormous sums of money (very enormous, I would imagine, orders of magnitude more than the cost of any custom built PC), it would be unsupported by other vendors (drivers, etc), and likely be plagued by little one-off problems like so many new boards are. Usually the vendor can see the trends in the problems based on numerous end-user bug reports, and fix it in the BIOS - but with just one user, good luck.
Chances are that if you actually made a competent choice about what motherboard features and components really suit your needs, you'd find they already make it anyways.
To elaborate - as an example we can take the existing population density of the state of New York (400 ppl per sq mi in y2k), the existing population density of Iowa (52.4 ppl per sq mi in y2k). These are two extremes - New York is a good example of tightly packed first world citizens, but it relies on a lot of external resources. Iowa is the exact opposite, supplying a lot of those resources to more densly packed areas.
Average the two population densities for a rough in-between figure, multiply by the world's population - and you arrive at approximately 78 million square miles of space needed to house the world's popluation and provide all their needs, versus a quarter million square miles in TX.
Because of the complexity and differentiation of linux platforms and whatnot, LSB will likely never be fully adhered to in a consistent manner by all vendors/distros.
What I'd really like to see is a much simpler subset of really basic standards, with a different name, that would be relatively easy for all the vendors and distros to be compliant with. For example, I would expect this to be the nature of things it enforces:
* Documentation other than man pages is always in/usr/share/doc for vendor supplied packages.
* Man pages are always in/usr/share/man for vendor supplied packages
* Init scripts should always exist in the location/etc/init.d/SVCNAME, and should always usefully accept the arguments "start", "stop", and "restart".
* The following environment variables are always set to some correct-ish value in the default environment based on user configuration of the OS: TZ, HOSTNAME, PATH, USER, etc
* The following basic *nix commands are available in/bin: [...], ditto for/usr/bin,/sbin,/usr/sbin.
* The following list of common shells and language interpreters will always be installed in these pathnames: [bash, pdksh, perl, python, etc] (There might be an alternative "lite" version of the standard which excludes a requirement like perl or pythong or specific shells, for minimal/embedded environments)......
You get the idea - these are things that *most* distributions already do *mostly* the same anyways. After a few quick tweaks any distro should be able to re-release themselves as compliant with this standard. And once it's popular, vendors have a document to look at that tells them certain things they can rely on when writing linux-specific applications at the operating system level (aside from the stuff at other levels, like the linux and glibc and whatever else API/ABI stuff).
Yeah but nscd just caches for your local server box, it doesn't re-serve the cached results to your remote clients. He's describing actual dns cache/forward servers ignoring TTL and handing outdated/bad data to client machines.
We all know the reasons not to run anything as root unneccesarily are many, but you have to think from his perspective as well. He's picturing clueless linux desktop users, using a shrinkwrapped distro at home for personal use. If they were to only log in as a user rather than root, what does it buy them? Whoever gets them to run malicious code by exploiting them or their software will still get access to all of their data, since it was all stored as that user. And they still get access to backdoor all of the software they use, since they can screw the user's environment (PATH, LD_LIBRARY_PATH, etc).
About the only thing not running as root saves the poor nontechnical home end-user from is wiping out their hard drive, but all the data that's important to them contained therein is still destructable.
I'm not sure this article is really appropriate for Open Sources. While it claims otherwise, it has the tone of a defensive article trying to justify his past and defending his reputation.
I treat every job I do like a foreign spy with a few million to blow would be after my data, even if in fact there's little to no chance of any targetted attack of any caliber. Better to be safe than sorry. And it's really not that hard to be safe.
Slashdot Mirror
Whenever I'm doing exploratory coding and trying to figure things out, I tend to spend a few hours googling around on related topics. Often you'll turn up the solutions you need, or at least things that move you in the right direction. Doesn't matter whether what you find is a paper like the ones you're talking about, or the source code of some crappy perl module someone wrote - if it's related, you'll find it through google.
People with defensible political positions don't need to be anonymous in such a trivial matter. The Dems in the referenced matter acted like whiny bitches, and did waste our time and money. I understand that the Republicans were twisting the re-districting to their advantage, but they were doing it within the letter of the law, which is all you can ask for these days. To walk out of the state and refuse to even participate in congress was pathetic and childish, but typical.
At first I figured the output, while long lasting, would just be too low to be useful. I went to beta-batt's website, got the numbers and did the math. These batteries are surprisingly good.
The first-gen tritium ones (and tritium ones is probably all we'll ever see in commercial applications) put out 400 microwatts per cubic centimeter of nuclear battery volume, half-lifing at 12 years of course.
Based on various data I pulled from Energizer's website and Betabatt's website, it comes out like this:
A regular AA-sized NiMH rechargeable battery (2,500mAh @ 1.2V) can be recharged by a nuke battery of identical volume (picture a companion Nuclear-AA battery next to it) from empty to full in roughly one month. Or five AA-sized nuked batteries could recharge a normal NiMH AA in a little under a week. In either case, that's for years (obviously, the charging rate gets slower as the years go on).
Even in that form, it's quite useful. Assuming linear scalability in both regular and nuke batteries, that means if you have a device which can last up to two months on a rechargeable battery of some size, you can stick a nuke-charged of equivalent volume to your battery next to it, and between the two of them your device will stay continuously powered for at least 12.3 years.
Imagine when the next generations come out and get more efficient. I can't wait. For useful largish devices you'll always need a chemical battery for bursty amperage, but have a nuke-batt as a recharger is so handy.
Who lets these crackheads post stories? Linux has been running native 64-bit on several platforms for years, and years, and years. Hell even in the x86 world, I've got ~9,000 Opteron CPUs chugging under the power of Linux in 64-bit mode at work, and they're just trashy lease boxes.
Whereas tracking and killing innocent animals on foot is just fine?
You're damn right it is. God forbid all you liberal weenies ever have to rough it living outdoors on your own, you'd never make it trying to subsist on berries. By the way, didn't you ever stop to consider how the berries feel about it? Welcome to Nature, we kill things to eat them here. Cheetahs use their speed; spiders use their venom; humans use their brains to build whatever implements they might need.
Don't tell the PHBs!
We all know this is what's really going on, that essentially we're getting corporations to pay our salaries while we work together for the common benefit of all. We also know that doing this is in the corporation itself's best interest if the corporation can use the resulting software, which is why we don't have any guilt about it.
But the PHB types really don't get it. As long as we keep them thinking that a large chunk of the software they're running is being given to them for free by some smart guy in mom's basement, and the collaborator they hired is there to make sure their needs are met, they feel like they're getting a good deal, and they are. When they realize what's really going on, they'll throw a shit fit because they can't fathom the idea that they are collaborating with their competitors for mutual benefit.
Guns don't belong on that list. Wake up and get out to your local gun range and start shooting, and you'll eventually figure out why once you get into it and start hanging out with more gun owners. To elucidate here would just raise ignorant arguments against them.
Absolutely brilliant, fairly original, well-made, engaging, simple arcade-ish games. I especially liked the fish-tank game and the one with the spiral tracks of balls that you shoot.
Which models of Opteron would have these improvements?
Right outta the box you're going to subject them to learning the semantics of the editor that wishes it was an operating system and requires 8 metakeys and 3 floor pedals to operate? Talk about BOFH.
And don't forget the most important lesson of all, imparted on the world by a minority of US citizens mostly residing in CA and NY: How to be a whining liberal bitch that backstabs your own country by trumpeting logical fallacies and other non-arguments from their pseudo-intellectual rooftops.
They are lacking the vision to see the purpose of Google's efforts, and the purpose of libraries like themselves in general.
The purpose of a traditional library is to collect, catalog, and preserve the writings of humanity for the benefit of ourselves and our children to come.
The purpose of digitization projects like Google's is to bring this into a new era. The purpose is not to turn each individual library into an electronic form of its current self - the very idea of disparate libraries was merely a consequence of the times. The purpose is to build a single worldwide virtual digital library, covering more ground and providing more accessibility than any single library could hope to.
Google's project isn't there yet, but that's the direction they are pushing. And these libraries are being divisive and standing in the way of progress. They lack the vision of what they should be doing, and they're harming progress in the name of pride.
There are some subtleties that most people don't realize, however.
For the sake of example, assume a given project has only a single author. Said author owns the copyright to the code, and distributes it to the public in an unrestricted fashion under the terms of the GPL.
If a random member of the public wanted to fork/commercialize his code, they are bound by the GPL to keep re-releasing their changes under the GPL. However if the original Author wanted to fork his own work and make a commercial effort out of it, he can do that and make his future contributions proprietary, as the GPL doesn't apply to the Author himself (he didn't license it to himself, he owns the copyright to begin with).
Therefore, it is entirely possible for an individual author to write and maintain a peice of free software for years, and then fork his own work into a proprietary commercial derivative that nobody has any future rights to the code of except him. What he cannot do, of course, is revoke any code he already published under the GPL. This leaves his user community able to pick up the work from the last GPL version the Author released and continue the effort under the terms of the GPL.
However, most significant projects have multiple Authors, and all of the Authors would have to agree on this course of action in order to do it. That's why such a thing can't really happen to a body of work like glibc, gcc, or the linux kernel: there are far too many authors with the copyrights in the code all over the place, and you could never get them to all agree to come under one commercial roof together and make a proprietary fork.
Just the throw a monkey wrench in your line of reasoning, I didn't get an IT degree, didn't get a certification, and didn't get a CS degree. I didn't even try to. And yet I've worked a productive 10 years in the IT field, and spent the vast majority of that time doing CS tasks (systems research and design, and *tons* of coding). I'm more a computer scientist than anyone who actually has a CS degree that I've ever personally met, and I'm in IT.
It kinda boils down to the domain-specific knowledge thing another poster was talking about. Just as it might be useful to get someone with say a Financial degree/background to learn how to code and have them write a financial application, as opposed to having some pure CS person do it, the same applies in IT.
IT-related software*, when written by CS guys, tends to suck in my experience in the industry. You need sysadmins from the trenches who have a solid skill and interest in computer science to do these things. And these guys, who I count myself among, are IT professionals doing CS tasks.
*(And by IT software I mean: clustering solutions for scalability and/or reliability, systems monitoring software (ever try to pull statistical information as well as near-real-time availability alerts from a 5000+ machine datacenter?), distributed systems configuration management and administration, etc)
Back when it used to seem like a lot (~1997?), we used to "steal" all the processing time on 4 Sun E10Ks and 7 frames of IBM SP/2 nodes and do SETI and Distributed.Net work on them when they idle between real projects.
What about cool home science gear that doesn't belong in a home? A guy at my office has 2 and a half electron microscopes in his garage he uses to peek at anything and everything that interests him around the house. I believe between the 2.5 microscopes worth of parts, one is actually running at the moment.
PCI-X is not PCI-Express, and the two technologies don't even have compatible pinouts or signals. PCI-X is the follow-on to traditional parallel PCI, with speeds of 100 and 133 Mhz and a 64-bit wide data path (compared to previous parallel PCI standards of 32/64-bits at 33/66 Mhz). PCI-Express is PCI re-done serially instead of in parallel, in an attepmt to be fashionable like the new Serial ATA standard. It's also potentially faster than PCI-X, and not at all compatible.
You'll notice just about every communications standard that doesn't go long haul alternates back and forth between parallel and serial methods every few years just to sound new and exciting and better.
Aside from what others have already pointed out, namely that your chosen CPU and Chipset don't appear to support dual processors to begin with, the idea of having a custom motherboard made is silly.
Motherboards are extremely complex peices of equipment. An enormous amount of work goes into getting them production-quality, it's a lot more than just wiring the rights pins of the right chips and sockets together. There's all the EMF and heat effects to consider, trace lengths and their effect on signal propogation, etc. Then ocne you have a baord that's even capable of functioning reliably, you have to make a BIOS for it and get all the right parameters tweaked correctly to initialize the board the right way - there's a lot of values tuned by the vendor for the board in question that you never see in your little BIOS setup screen.
Even among commercial boards, as we've seen on review sites, there are varying levels of success at building a rock-solid stable board. It requires an enormous amount of engineering man-hours to go through the design and testing process, and sometimes they still can't get it quite right, and half the boards are a little "flaky" under the wrong conditions.
So even if you wanted to drop some enormous sums of money (very enormous, I would imagine, orders of magnitude more than the cost of any custom built PC), it would be unsupported by other vendors (drivers, etc), and likely be plagued by little one-off problems like so many new boards are. Usually the vendor can see the trends in the problems based on numerous end-user bug reports, and fix it in the BIOS - but with just one user, good luck.
Chances are that if you actually made a competent choice about what motherboard features and components really suit your needs, you'd find they already make it anyways.
To elaborate - as an example we can take the existing population density of the state of New York (400 ppl per sq mi in y2k), the existing population density of Iowa (52.4 ppl per sq mi in y2k). These are two extremes - New York is a good example of tightly packed first world citizens, but it relies on a lot of external resources. Iowa is the exact opposite, supplying a lot of those resources to more densly packed areas.
Average the two population densities for a rough in-between figure, multiply by the world's population - and you arrive at approximately 78 million square miles of space needed to house the world's popluation and provide all their needs, versus a quarter million square miles in TX.
This is a great strategy on his part. I view this as analogous to the great gcc2->egcs->gcc3 "fork", which was quite successful.
Because of the complexity and differentiation of linux platforms and whatnot, LSB will likely never be fully adhered to in a consistent manner by all vendors/distros.
What I'd really like to see is a much simpler subset of really basic standards, with a different name, that would be relatively easy for all the vendors and distros to be compliant with. For example, I would expect this to be the nature of things it enforces:
* Documentation other than man pages is always in
* Man pages are always in
* Init scripts should always exist in the location
* The following environment variables are always set to some correct-ish value in the default environment based on user configuration of the OS: TZ, HOSTNAME, PATH, USER, etc
* The following basic *nix commands are available in
* The following list of common shells and language interpreters will always be installed in these pathnames: [bash, pdksh, perl, python, etc] (There might be an alternative "lite" version of the standard which excludes a requirement like perl or pythong or specific shells, for minimal/embedded environments).
You get the idea - these are things that *most* distributions already do *mostly* the same anyways. After a few quick tweaks any distro should be able to re-release themselves as compliant with this standard. And once it's popular, vendors have a document to look at that tells them certain things they can rely on when writing linux-specific applications at the operating system level (aside from the stuff at other levels, like the linux and glibc and whatever else API/ABI stuff).
The duct tape will restrict airflow to the little vent slots on some adapters, causing the transformers in them to overheat and fail early.
Yeah but nscd just caches for your local server box, it doesn't re-serve the cached results to your remote clients. He's describing actual dns cache/forward servers ignoring TTL and handing outdated/bad data to client machines.
We all know the reasons not to run anything as root unneccesarily are many, but you have to think from his perspective as well. He's picturing clueless linux desktop users, using a shrinkwrapped distro at home for personal use. If they were to only log in as a user rather than root, what does it buy them? Whoever gets them to run malicious code by exploiting them or their software will still get access to all of their data, since it was all stored as that user. And they still get access to backdoor all of the software they use, since they can screw the user's environment (PATH, LD_LIBRARY_PATH, etc).
About the only thing not running as root saves the poor nontechnical home end-user from is wiping out their hard drive, but all the data that's important to them contained therein is still destructable.
His point is in fact arguable - why bother?
I'm not sure this article is really appropriate for Open Sources. While it claims otherwise, it has the tone of a defensive article trying to justify his past and defending his reputation.
I treat every job I do like a foreign spy with a few million to blow would be after my data, even if in fact there's little to no chance of any targetted attack of any caliber. Better to be safe than sorry. And it's really not that hard to be safe.