Reaching room temperature super conduction would bring huge benefits to modern day technology. Power usage of chips would plummet to almost nothing and allow a brand new generation of processors. Amongst several other very useful things.
I thought most energy losses in chips were in the actual transistors rather than in the wires? Now, if they find a way to make this stuff switch very quickly between "superconducting" and "very good insulator"...
Wow. I'll bet the guys at Cern are feeling pretty foolish right about now.
No, "high temperature" superconductors cannot be used in magnets. That's why they're using liquid helium (or was it liquid hydrogen?) instead of the much cheaper liquid nitrogen -- all the superconductors that work at the warmer liquid nitrogen temperatures will stop working in a moderately strong magnetic field.
I have yet to see any woman, or man be treated differently in this industry in terms of skill.
I've seen a little bit, but it got stomped on rather quickly by the project leaders. Then of course there was the rails/couchdb/etc mess, which afaict seems to have resulted in the broader community stomping on that smaller community and its leaders.
The alternatives function on a business method too foreign for the BSA and their constituents to understand.....competence. Since the OSS product makes money mostly on providing effective support for the product,
But doesn't the need for support indicate that whoever wrote the documentation or designed the software in the first place was not competent, because it either confuses people or keeps needing to be fixed?
But it's true that piracy is hurting the industry (be that software, games, music or movies). Yeah it would be nice if all of that would be free, but it's not a good model to sustain the development and producment.
So if Jimmy the Geeklet pirates Windows and Photoshop and MS Office, and then when he grows up to be James the Geek with a real job he already knows Windows and MS Office and Photoshop and expects to be able to use those at work and maybe even buys copies (err, licenses) for his own use at home, this is a net loss to the "industry" compared to his knowing and wanting to use KDE and the GIMP and Open Office?
Since certificates are tied to domain names, why don't we have registrars be defacto certificate authorities?
This will happen somewhat automatically when DNSSEC is finally implemented (in a couple years, I think). Then all you'll need is a standardized DNS record type to give your cert fingerprint, there might even be a standard ready and waiting.
What use is encryption if you can't guarantee that there's not a man in the middle? This is why self-signed certs are a bad idea. That is, unless you want your users calling you up to manually verify your key.
Or using something like Perspectives to get much the same effect.
If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".
Frankly, a video game web forum doesn't need encryption except for the matter of identifying users, and something like OpenID could be used for that.
I thought the goal was to have everything encrypted, regardless of whether it's illegal and needs to be hidden, if for no other reason than to mildly annoy the NSA.
C'mon, no professional just pokes "apt-get update" into the root shell on a live production server. That's just asking for hilarity, fail, and unemployment.
Because "professionals" are perfect and have unlimited time and resources, right?
A couple days ago, I had something failing in test that worked in production... turns out someone had put an emergency fix for this in the production system, and because it was an "emergency" they hadn't bothered to update the test environment first (or at all, actually). Shit happens everywhere, so it's a bad idea to rely on shit not happening.
If your custom apps required you to install a package, it'll already be listed as manually installed, so it'll never be automatically uninstalled.
The idea is that $app depends on $foo and $bar. But because $foo also depends on $bar, someone was able to goof up and only document that $app depends on $foo. So when $foo gets updated and drops its dependency on $bar, $bar goes away (due to being automatically installed) and $app stops working.
Why would you not want to use APT on a server? What part of automatic dependency handling, automatic unneeded package pruning, easy security update application, and secure package retrieval do you not want on your servers?
Possibly the "automatic unneeded package pruning". It could be dangerous if your custom apps don't specify their dependencies correctly (say, they rely on something that had been automatically installed by one of their other dependencies).
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.
Something else that should work (once DNSSEC is actually implemented everywhere) would be to list your SSL fingerprint as a DNS entry. This is less secure in some ways (say, if someone hijacks your account with whoever you bought your domain from), but better in others (better assurance on first visit, you can change the fingerprint if your server is compromised and someone else gets hold of your cert's private key).
It was cheaper for them to buy the WHOLE COMPANY that had built this technology, than it was to continue running/maintaining a.NET application. The.NET application was built and maintained by accenture, who can just as easily hire cheap devs in india or sri lanka as any other outsourced IT consultancy.
I suspect that this reflects more on the quality of Accenture (and the entire industry that apparently can't out-compete them) than that of.NET. It probably has something to do with better developers writing better code more quickly, and ending up with fewer billable hours.
At 3,751 errors per DIMM/year it means that a system with 2 sticks (very common for dual channel) is getting 20 bits flipped per day.
No, from the actual paper it looks like the errors are very "bunched up". So in a given day you're only, say, 10x as likely as thought to get a memory error, but when you do you'll get a whole bunch all at once. There's also the issue that most DIMMs had no errors.
What it looks like to me, is that say 80-90% of DIMMs are "good" and will never see errors, most of the rest are "iffy" and overly susceptible to EMI or something (maybe the ones that barely made their speed bin?), and a few are just "bad" and will garble your data at the slightest excuse. Kinda makes me wonder if running at say 10% underclock might make the errors mostly go away.
the mobo's used by google are the cheapest boards they can get made. There is NO testing until they hit the datacenter floor. Crap mobo plus poor environment (high heat and vibration + poor power controls) makes for a high failure rate. ECC ram has an odd number of memory chips. The odd chip allows for the parity ram. Google memory has even chip counts since non-ECC ram is much MUCH less expensive. So the bios is custom and carves out ECC function from non-ECC ram
It sounds like you don't know what you're talking about. Would you care to show why we should believe you?
I have linked twice to the Federal Reserve Bank of Chicago, proving my claim that they say banks create money. Your posts are enough evidence to prove that you say they don't. Except the places where you admit that they do but claim that it doesn't really count.
No. I am saying that this form of money creation is not specific to banks or banking laws.
It isn't a property of money that allows it to be in two places at once, it is a property of banking laws
What enables banks to create money is that people treat bank account balances the same as cash.
This is independent of banking laws, and has happened for longer than we've had our banking laws, and happens to some extent for things other than bank accounts (the most common probably being stocks/bonds (or money market accounts, assuming those are different from regular bank accounts)). The degree to which this happens for something is how "liquid" that particular kind of asset is.
I know full well that is what is meant by banks creating money. It is fraudulent because money can not really be in two places at once, they only get away with pretending that because people don't call them on it, ie: withdraw their money.
It is not fraudulent, because they do not lie about it.
The bank has $1. They write a loan to your friend for $100. They now declare that they have $101 dollars of assets, and represent this balance sheet as collateral on further loans, and as the basis for other financial instruments they trade. $100 dollars were 'conjured' into existence.
Slashdot Mirror
Are women being paid less for free code?
Yes. In fact, I have it on very good authority that they typically are only paid half as much.
"254K should be warm enough for anyone"
I want one that works at 640 K, so I can use it to replace the heating element in my oven. Because superconductors make everything more efficient.
Reaching room temperature super conduction would bring huge benefits to modern day technology. Power usage of chips would plummet to almost nothing and allow a brand new generation of processors. Amongst several other very useful things.
I thought most energy losses in chips were in the actual transistors rather than in the wires? Now, if they find a way to make this stuff switch very quickly between "superconducting" and "very good insulator"...
Wow. I'll bet the guys at Cern are feeling pretty foolish right about now.
No, "high temperature" superconductors cannot be used in magnets. That's why they're using liquid helium (or was it liquid hydrogen?) instead of the much cheaper liquid nitrogen -- all the superconductors that work at the warmer liquid nitrogen temperatures will stop working in a moderately strong magnetic field.
So a few bad apples spoiled the whole cart?
How many "bad apples" are needed before they become evidence of the tendencies of their group?
I have yet to see any woman, or man be treated differently in this industry in terms of skill.
I've seen a little bit, but it got stomped on rather quickly by the project leaders. Then of course there was the rails/couchdb/etc mess, which afaict seems to have resulted in the broader community stomping on that smaller community and its leaders.
The alternatives function on a business method too foreign for the BSA and their constituents to understand.....competence. Since the OSS product makes money mostly on providing effective support for the product,
But doesn't the need for support indicate that whoever wrote the documentation or designed the software in the first place was not competent, because it either confuses people or keeps needing to be fixed?
But it's true that piracy is hurting the industry (be that software, games, music or movies). Yeah it would be nice if all of that would be free, but it's not a good model to sustain the development and producment.
So if Jimmy the Geeklet pirates Windows and Photoshop and MS Office, and then when he grows up to be James the Geek with a real job he already knows Windows and MS Office and Photoshop and expects to be able to use those at work and maybe even buys copies (err, licenses) for his own use at home, this is a net loss to the "industry" compared to his knowing and wanting to use KDE and the GIMP and Open Office?
Since certificates are tied to domain names, why don't we have registrars be defacto certificate authorities?
This will happen somewhat automatically when DNSSEC is finally implemented (in a couple years, I think). Then all you'll need is a standardized DNS record type to give your cert fingerprint, there might even be a standard ready and waiting.
What use is encryption if you can't guarantee that there's not a man in the middle? This is why self-signed certs are a bad idea. That is, unless you want your users calling you up to manually verify your key.
Or using something like Perspectives to get much the same effect.
If all I'm saying is "I'm a video game web forum" then my visitors don't need anything more than "I'm using the same self-signed certificate I used the last time".
Frankly, a video game web forum doesn't need encryption except for the matter of identifying users, and something like OpenID could be used for that.
I thought the goal was to have everything encrypted, regardless of whether it's illegal and needs to be hidden, if for no other reason than to mildly annoy the NSA.
It also happens if you use 'aptitude' instead of 'apt-get'.
Shit does happen everywhere, but that shouldn't be your policy.
No, it should: "given that we can't prevent all shit from happening, how can we be most resilient against the shit that does happen?".
In fact, you could accelerate a million ton spacecraft up to .5 c with half a kilogram of propellent if you could put enough energy into it.
The question then becomes, how much does that amount of energy weigh?
Why take starlight as-is when you can use solar collectors to gather it up and power a laser to drive your sail?
Here's a handy tip: next time you fall in a hole, you can get out by lifting yourself by your own bootstraps.
Anything you're moving towards should push you away, so you'll slow down automatically when you get close to anything.
C'mon, no professional just pokes "apt-get update" into the root shell on a live production server. That's just asking for hilarity, fail, and unemployment.
Because "professionals" are perfect and have unlimited time and resources, right?
A couple days ago, I had something failing in test that worked in production... turns out someone had put an emergency fix for this in the production system, and because it was an "emergency" they hadn't bothered to update the test environment first (or at all, actually). Shit happens everywhere, so it's a bad idea to rely on shit not happening.
If your custom apps required you to install a package, it'll already be listed as manually installed, so it'll never be automatically uninstalled.
The idea is that $app depends on $foo and $bar. But because $foo also depends on $bar, someone was able to goof up and only document that $app depends on $foo. So when $foo gets updated and drops its dependency on $bar, $bar goes away (due to being automatically installed) and $app stops working.
Why would you not want to use APT on a server? What part of automatic dependency handling, automatic unneeded package pruning, easy security update application, and secure package retrieval do you not want on your servers?
Possibly the "automatic unneeded package pruning". It could be dangerous if your custom apps don't specify their dependencies correctly (say, they rely on something that had been automatically installed by one of their other dependencies).
I believe the only way forward is for browsers to change the model: associate a certificate SKI with a web site on first visit, warn if that changes. Don't worry about certificate validity, since the hierarchical trust model has been compromised from the root.
Something else that should work (once DNSSEC is actually implemented everywhere) would be to list your SSL fingerprint as a DNS entry. This is less secure in some ways (say, if someone hijacks your account with whoever you bought your domain from), but better in others (better assurance on first visit, you can change the fingerprint if your server is compromised and someone else gets hold of your cert's private key).
It was cheaper for them to buy the WHOLE COMPANY that had built this technology, than it was to continue running/maintaining a .NET application. The .NET application was built and maintained by accenture, who can just as easily hire cheap devs in india or sri lanka as any other outsourced IT consultancy.
I suspect that this reflects more on the quality of Accenture (and the entire industry that apparently can't out-compete them) than that of .NET. It probably has something to do with better developers writing better code more quickly, and ending up with fewer billable hours.
At 3,751 errors per DIMM/year it means that a system with 2 sticks (very common for dual channel) is getting 20 bits flipped per day.
No, from the actual paper it looks like the errors are very "bunched up". So in a given day you're only, say, 10x as likely as thought to get a memory error, but when you do you'll get a whole bunch all at once. There's also the issue that most DIMMs had no errors.
What it looks like to me, is that say 80-90% of DIMMs are "good" and will never see errors, most of the rest are "iffy" and overly susceptible to EMI or something (maybe the ones that barely made their speed bin?), and a few are just "bad" and will garble your data at the slightest excuse. Kinda makes me wonder if running at say 10% underclock might make the errors mostly go away.
the mobo's used by google are the cheapest boards they can get made. There is NO testing until they hit the datacenter floor. Crap mobo plus poor environment (high heat and vibration + poor power controls) makes for a high failure rate. ECC ram has an odd number of memory chips. The odd chip allows for the parity ram. Google memory has even chip counts since non-ECC ram is much MUCH less expensive. So the bios is custom and carves out ECC function from non-ECC ram
It sounds like you don't know what you're talking about. Would you care to show why we should believe you?
I have linked twice to the Federal Reserve Bank of Chicago, proving my claim that they say banks create money. Your posts are enough evidence to prove that you say they don't. Except the places where you admit that they do but claim that it doesn't really count.
No. I am saying that this form of money creation is not specific to banks or banking laws.
It isn't a property of money that allows it to be in two places at once, it is a property of banking laws
What enables banks to create money is that people treat bank account balances the same as cash.
This is independent of banking laws, and has happened for longer than we've had our banking laws, and happens to some extent for things other than bank accounts (the most common probably being stocks/bonds (or money market accounts, assuming those are different from regular bank accounts)). The degree to which this happens for something is how "liquid" that particular kind of asset is.
I know full well that is what is meant by banks creating money. It is fraudulent because money can not really be in two places at once, they only get away with pretending that because people don't call them on it, ie: withdraw their money.
It is not fraudulent, because they do not lie about it.
You are not describing the system as it exists.
You are delusional.
The bank has $1. They write a loan to your friend for $100. They now declare that they have $101 dollars of assets, and represent this balance sheet as collateral on further loans, and as the basis for other financial instruments they trade. $100 dollars were 'conjured' into existence.
Do you know what a "money multiplier" is?