A site-license of almost any software will be a negliegable part of your operating budget.
It depends on what the software is. Some things are genuinely expensive, enough that while maybe a Fortune 500 can handle it, the many smaller companies out there tend to swoon at the prices charged. (These pieces of software tend to be in areas without major OSS competition.)
But a 400W LED fixture would produce nearly the same heat overall [as 400W HPS lights].
Well yes. Duh. All those watts have got to go somewhere, and that's virtually all going to be heat eventually. What matters is how much light you get for that power. And LEDs and HPS are fairly similar (enough that the details of exactly what you're doing and how they were manufactured matter; the luminosities per unit power are similar, according to Wikipedia).
Actually that was Eric Raymond, and it is evident that in fact there never are enough eyeballs (at least ones that can comprehend what they are looking at). The theory is sound but in practice it is not.
It's a fundamental truth that, the more of the system you have to comprehend to truly understand it, the harder it is to debug. Syntax problems? Trivial. Global liveness checking? Much harder. (There's just so many ways to screw up.)
The Economist is a *lot* more US-normative than most UK publications, yes. For one thing, a lot of their market is US; for another, they're generally proponents of the US and UK becoming more similar -- mostly by the UK changing.
Having bought the Economist in various places around the world, you should be aware that the apparent focus of the magazine is different in different places. The content is formally the same, the articles are identical, but the ordering is not; this changes surprisingly strongly how one feels it is centric towards one place or another. Always buy in the US? It will be US centric. It's quite different in France.
First, we shouldn't confuse Coverity's numerical measurements with actual code quality, which is a much more nuanced property.
Yeah, but good quality might well correspond to some sort of measurable anyway. Provided you've got the right measure. Maybe some sort of measure of the degree of interconnectedness of the code? The more things are isolated from each other, across lots of levels (in a fractal dimension sense, perhaps) the better things are likely to be.
Maybe that would only apply to a larger project, and I'm not sure what effect system libraries (and other externals) would have. Yet the fact that it might be a scale-invariant approach makes me a bit more hopeful, as it wouldn't be so susceptible to the "ravioli code" problem, where the code's nicely packaged up into little pieces, but the pieces interconnect in a horrible mess of higher-level spaghetti code. Worked on a large project? You'll have probably seen it in the wild. (Yeah, I've had people argue to me that their code didn't use goto and so it had no spaghetti code problems, despite the fact that everything was so nastily interconnected that nobody else could understand it. If that's not indicative of a problem, what is?)
Thanks for the link. To summarize for everyone else, it essentially declares that all able-bodied male US citizens (or men who have declared their intent to become citizens) are automatically members of the militia if they are between 17 and 45 years old, and women are as well if they are US citizens that are members in the National Guard. For vets from the Regular military (i.e. Army, Navy, Air Force, and Marines), the age limit is extended from 45 to 64.
So... automatic conscription is basically in place already? Only needs a minor step, calling on militia members to formally defend their country, and you've got a fully-fledged military police state. Nice one, sheeple.
And that's why having bills cover lots of things at once (rather than being automatically restricted to the principal subject area of the bill) is a truly awful practice. It's beyond corrupt as it specifically enables effectively sidestepping oversight of the legislative process. The pork-barrel politics the practice enables are merely the most visible and least harmful parts of this.
Also, April 1st is the *WORST* day to notify ANYONE that there is a severe security flaw..
Major public holidays (e.g., Christmas) are much worse, as there's a really good chance nobody will even look at the warning, and may decide that their family time trumps fixing security problems.
April 1 is just the worst day to announce a major breakthrough or groundbreaking new product.
How do I become a trusted root certificate authority ?
You ask the browser vendors, who respond by asking some very pointed questions about how trusted you are. These sorts of questions include "do you have regular audits to ensure that you're managing your keys correctly?" and "what policies do you have in place for dealing with a security breach that compromises one of the keys you've signed?" Convince enough people that you're really trustworthy, and congratulations, you're a root CA. At least until the next time they ask those questions. It's only really recommended that you seek to become a root CA if you really like acting bureaucratically.
You can also become a root CA for a particular browser by just installing a self-signed certificate in its list of trust roots. This is disappointingly common, and often a marker of an untrustworthy organisation, as the main reason for doing this is to enable SSL sniffing. Not recommended at all (and totally does not make your site trustworthy to anyone else, which is the usual point of having HTTPS set up). It does work better for specialist applications.
Becoming a non-root CA is much easier. Just pay another CA enough money (or know the right people).
But that seems to be what a lot of people on Slashdot want. Look at the Mozilla and DropBox controversies. Lots of people posting and moderating support those.
Doesn't matter. If anyone or any organisation insists on doing things beyond their financial means, they've got a problem. If they keep on doing it, they've got a serious problem. Sometimes you've got to be unkind to someone and say "no" because otherwise you'll go bankrupt and get to do nothing at all with anyone. Being able to say "no" on the grounds that what people seek to do is too far away from your mission is a critical life skill. (It's why having an actual mission is important!)
Sure, sometimes you can restructure your finances to be able to do more, taking on more debt in the hope of being able to generate more income in the future to pay it off. Sometimes that even works. If you're going to take on significant debt though, you need to be darn sure about how it is going to improve your ability to get income. There's no room for wishy-washy thinking here, as getting debt wrong can really screw you over.
All of the above is without looking at the details of what the GNOME Foundation were supposed to do or actually trying to do. It applies to them and to everyone else.
I've had same issues when Apple items are on any mixed OS network
That's almost certainly the fault of using shitty access points. Anyone doing large-scale WiFi deployments is going to have to cope with lots of different client systems connecting all at once; there's no excuse for getting it wrong. Consumer grade stuff is definitely worse, but it only really hits home once there's a lot of devices loading everything up.
Energy is not the issue – it is the rate of fire. Diesel engines power the supper capacitors, they discharge to fire the gun, and then fill them up again. I have read that this cycle might be measured in minutes instead of seconds. How big of an issue that it will be is a big question.
That depends on how many capacitor banks you've got, yes? Or possibly the sustained power output of the generators, though that's perhaps more of an issue for sustained firing. (Naval ships are pretty big; you can fit a lot of capacitors and generators in there.)
What I'm impressed at is that they can fire the railgun multiple times instead of needing to strip it down and rebuild it each time. That was always the problem with the early railguns; they'd be fine firing once but after that would be so burned up from the currents that they'd be unable to take a second shot on any reasonable timescale. They were cool, but not practical weapons. I'm guessing that that must've been solved, and the result is that pure kinetic weaponry starts to make sense again for ship-level encounters.
Mod parent up; it's very informative and worth reading.
Whether you get anything truly interesting out of the attack is a separate matter. Fortunately, the attacker can't control where the read is from (just its length) so you're more likely to get the session key (which the attacker will have anyway) than the private key from this sort of poking around around.
Beware memcpy()! If you don't know exactly where you're reading from and writing to and that you've got big enough memory chunks at both ends, you've got trouble. (OK, beware with memmove(), strcpy(), etc. too.)
Just charge a tax on the total value of whatever is bought/sold. Like 0.1%. This would eliminate any incentive for the micro-game of HFT.
It shouldn't be a sales tax. It should be a tax that is required to be paid at the point where the request to trade goes in, even if it is subsequently cancelled. That stops anyone from doing tricks like trying to probe what's going on using phantom trades. It wouldn't even need to be much of a tax to discourage the bad behaviour; like that it wouldn't deter anyone who's actually interested in holding the instrument for any substantial period of time.
2k was a bit sterile, XP now offered everything they needed. Much better USB support, WLan out of the box, a much smoother user experience altogether and near perfect stability (outside of driver woes).
The stability only really came with SP1 if I remember right; there were a few core problems (especially with networking) prior to that.
It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.
Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal your money or your identity — who you're really protecting against.
In reality, at some point you hit a noise threshold, and, anyway, down at the bottom, electrons and photons are discrite.
You virtually always hit the noise limit before you get to the point where you have to worry about the fundamental discreteness of matter and energy. The majority of quantum experiments involve a lot of cooling and isolating of systems with very good reason!
Also, to be usable, whatever is used for the key has to be of finite size, and preferably not too big.
But we've got lots more bandwidth and storage than we used to have, at least in some applications. We shouldn't worry unduly about key sizes (except for infinite ones, of course, which really require you to stay up fretting about them all night </snark>).
What's tricky about it? If they're so stupid that they're willing to put their children in that sort of danger, the children are likely to have inherited the lack of basic intelligence and foresight. Good Darwinian principles suggests that culling the herd in that sort of situation is reasonable; no action is needed beyond telling the parents "I told you so" after the fact if they survive, before suggesting that this indicates that they'd be best off getting sterilised for the good of the rest of humanity.
No, they don't. There are far too many variations in API and SQL dialects (let alone actual functionality) for two DBs to be considered to be plug-compatible. Instead you have whole layers of goop (err, ORM frameworks) on top to hide the differences. Those layers are, of course, usually incompatible with each other...
Slashdot Mirror
On the contrary - it's all publicly-funded business.
By that argument, so is everyone's tax affairs.
A site-license of almost any software will be a negliegable part of your operating budget.
It depends on what the software is. Some things are genuinely expensive, enough that while maybe a Fortune 500 can handle it, the many smaller companies out there tend to swoon at the prices charged. (These pieces of software tend to be in areas without major OSS competition.)
But a 400W LED fixture would produce nearly the same heat overall [as 400W HPS lights].
Well yes. Duh. All those watts have got to go somewhere, and that's virtually all going to be heat eventually. What matters is how much light you get for that power. And LEDs and HPS are fairly similar (enough that the details of exactly what you're doing and how they were manufactured matter; the luminosities per unit power are similar, according to Wikipedia).
Halesowen? Cradley Heath? Oldbury? Shropshire? Where are these towns, Middle Earth?
Where do you think Tolkien stole the names from? Though he should've avoided getting creative with "Mordor" and stuck with Wolverhampton.
Actually that was Eric Raymond, and it is evident that in fact there never are enough eyeballs (at least ones that can comprehend what they are looking at). The theory is sound but in practice it is not.
It's a fundamental truth that, the more of the system you have to comprehend to truly understand it, the harder it is to debug. Syntax problems? Trivial. Global liveness checking? Much harder. (There's just so many ways to screw up.)
The Economist is a *lot* more US-normative than most UK publications, yes. For one thing, a lot of their market is US; for another, they're generally proponents of the US and UK becoming more similar -- mostly by the UK changing.
Having bought the Economist in various places around the world, you should be aware that the apparent focus of the magazine is different in different places. The content is formally the same, the articles are identical, but the ordering is not; this changes surprisingly strongly how one feels it is centric towards one place or another. Always buy in the US? It will be US centric. It's quite different in France.
First, we shouldn't confuse Coverity's numerical measurements with actual code quality, which is a much more nuanced property.
Yeah, but good quality might well correspond to some sort of measurable anyway. Provided you've got the right measure. Maybe some sort of measure of the degree of interconnectedness of the code? The more things are isolated from each other, across lots of levels (in a fractal dimension sense, perhaps) the better things are likely to be.
Maybe that would only apply to a larger project, and I'm not sure what effect system libraries (and other externals) would have. Yet the fact that it might be a scale-invariant approach makes me a bit more hopeful, as it wouldn't be so susceptible to the "ravioli code" problem, where the code's nicely packaged up into little pieces, but the pieces interconnect in a horrible mess of higher-level spaghetti code. Worked on a large project? You'll have probably seen it in the wild. (Yeah, I've had people argue to me that their code didn't use goto and so it had no spaghetti code problems, despite the fact that everything was so nastily interconnected that nobody else could understand it. If that's not indicative of a problem, what is?)
You are not free from being threatened by guns.
Yeah, there's all these mad asshole gun-freaks in the USA that are seeking to export their crazy to everywhere else. Keep it at home, jerks!
Thanks for the link. To summarize for everyone else, it essentially declares that all able-bodied male US citizens (or men who have declared their intent to become citizens) are automatically members of the militia if they are between 17 and 45 years old, and women are as well if they are US citizens that are members in the National Guard. For vets from the Regular military (i.e. Army, Navy, Air Force, and Marines), the age limit is extended from 45 to 64.
So... automatic conscription is basically in place already? Only needs a minor step, calling on militia members to formally defend their country, and you've got a fully-fledged military police state. Nice one, sheeple.
And that's why having bills cover lots of things at once (rather than being automatically restricted to the principal subject area of the bill) is a truly awful practice. It's beyond corrupt as it specifically enables effectively sidestepping oversight of the legislative process. The pork-barrel politics the practice enables are merely the most visible and least harmful parts of this.
Also, April 1st is the *WORST* day to notify ANYONE that there is a severe security flaw..
Major public holidays (e.g., Christmas) are much worse, as there's a really good chance nobody will even look at the warning, and may decide that their family time trumps fixing security problems.
April 1 is just the worst day to announce a major breakthrough or groundbreaking new product.
Oh, wait, humans can actually see by starlight alone.
Which works just fine when it is cloudy (like it is quite a lot in the Netherlands). Oh, wait...
How do I become a trusted root certificate authority ?
You ask the browser vendors, who respond by asking some very pointed questions about how trusted you are. These sorts of questions include "do you have regular audits to ensure that you're managing your keys correctly?" and "what policies do you have in place for dealing with a security breach that compromises one of the keys you've signed?" Convince enough people that you're really trustworthy, and congratulations, you're a root CA. At least until the next time they ask those questions. It's only really recommended that you seek to become a root CA if you really like acting bureaucratically.
You can also become a root CA for a particular browser by just installing a self-signed certificate in its list of trust roots. This is disappointingly common, and often a marker of an untrustworthy organisation, as the main reason for doing this is to enable SSL sniffing. Not recommended at all (and totally does not make your site trustworthy to anyone else, which is the usual point of having HTTPS set up). It does work better for specialist applications.
Becoming a non-root CA is much easier. Just pay another CA enough money (or know the right people).
But that seems to be what a lot of people on Slashdot want. Look at the Mozilla and DropBox controversies. Lots of people posting and moderating support those.
Doesn't matter. If anyone or any organisation insists on doing things beyond their financial means, they've got a problem. If they keep on doing it, they've got a serious problem. Sometimes you've got to be unkind to someone and say "no" because otherwise you'll go bankrupt and get to do nothing at all with anyone. Being able to say "no" on the grounds that what people seek to do is too far away from your mission is a critical life skill. (It's why having an actual mission is important!)
Sure, sometimes you can restructure your finances to be able to do more, taking on more debt in the hope of being able to generate more income in the future to pay it off. Sometimes that even works. If you're going to take on significant debt though, you need to be darn sure about how it is going to improve your ability to get income. There's no room for wishy-washy thinking here, as getting debt wrong can really screw you over.
All of the above is without looking at the details of what the GNOME Foundation were supposed to do or actually trying to do. It applies to them and to everyone else.
I've had same issues when Apple items are on any mixed OS network
That's almost certainly the fault of using shitty access points. Anyone doing large-scale WiFi deployments is going to have to cope with lots of different client systems connecting all at once; there's no excuse for getting it wrong. Consumer grade stuff is definitely worse, but it only really hits home once there's a lot of devices loading everything up.
Energy is not the issue – it is the rate of fire. Diesel engines power the supper capacitors, they discharge to fire the gun, and then fill them up again. I have read that this cycle might be measured in minutes instead of seconds. How big of an issue that it will be is a big question.
That depends on how many capacitor banks you've got, yes? Or possibly the sustained power output of the generators, though that's perhaps more of an issue for sustained firing. (Naval ships are pretty big; you can fit a lot of capacitors and generators in there.)
What I'm impressed at is that they can fire the railgun multiple times instead of needing to strip it down and rebuild it each time. That was always the problem with the early railguns; they'd be fine firing once but after that would be so burned up from the currents that they'd be unable to take a second shot on any reasonable timescale. They were cool, but not practical weapons. I'm guessing that that must've been solved, and the result is that pure kinetic weaponry starts to make sense again for ship-level encounters.
Mod parent up; it's very informative and worth reading.
Whether you get anything truly interesting out of the attack is a separate matter. Fortunately, the attacker can't control where the read is from (just its length) so you're more likely to get the session key (which the attacker will have anyway) than the private key from this sort of poking around around.
Beware memcpy()! If you don't know exactly where you're reading from and writing to and that you've got big enough memory chunks at both ends, you've got trouble. (OK, beware with memmove(), strcpy(), etc. too.)
Just charge a tax on the total value of whatever is bought/sold. Like 0.1%. This would eliminate any incentive for the micro-game of HFT.
It shouldn't be a sales tax. It should be a tax that is required to be paid at the point where the request to trade goes in, even if it is subsequently cancelled. That stops anyone from doing tricks like trying to probe what's going on using phantom trades. It wouldn't even need to be much of a tax to discourage the bad behaviour; like that it wouldn't deter anyone who's actually interested in holding the instrument for any substantial period of time.
Why are there no oil company start ups?
What makes you say this? Is it just because you don't notice them?
2k was a bit sterile, XP now offered everything they needed. Much better USB support, WLan out of the box, a much smoother user experience altogether and near perfect stability (outside of driver woes).
The stability only really came with SP1 if I remember right; there were a few core problems (especially with networking) prior to that.
MITM requires active interception to eavsdrop
It's not like it's impossible to have toolkits for making active interception nearly trivial to do (provided you've got the hardware to run it on) and if you're thinking about ISPs or governments as the attackers, they've got access to the sorts of hardware which can run active interception on a massive scale.
Your main defence against them is that your life is very boring and ordinary and they don't give a shit about you. It's the other major group of attackers — plain old criminals who want to steal your money or your identity — who you're really protecting against.
In reality, at some point you hit a noise threshold, and, anyway, down at the bottom, electrons and photons are discrite.
You virtually always hit the noise limit before you get to the point where you have to worry about the fundamental discreteness of matter and energy. The majority of quantum experiments involve a lot of cooling and isolating of systems with very good reason!
Also, to be usable, whatever is used for the key has to be of finite size, and preferably not too big.
But we've got lots more bandwidth and storage than we used to have, at least in some applications. We shouldn't worry unduly about key sizes (except for infinite ones, of course, which really require you to stay up fretting about them all night </snark>).
Yeah, I can't wait for a half-gigabyte executables.
You mean you're not working with them already?
One tricky part there, people have children.
What's tricky about it? If they're so stupid that they're willing to put their children in that sort of danger, the children are likely to have inherited the lack of basic intelligence and foresight. Good Darwinian principles suggests that culling the herd in that sort of situation is reasonable; no action is needed beyond telling the parents "I told you so" after the fact if they survive, before suggesting that this indicates that they'd be best off getting sterilised for the good of the rest of humanity.
Go on, rub it in.
Database implementers get this
No, they don't. There are far too many variations in API and SQL dialects (let alone actual functionality) for two DBs to be considered to be plug-compatible. Instead you have whole layers of goop (err, ORM frameworks) on top to hide the differences. Those layers are, of course, usually incompatible with each other...