This is because it is the simplest theory which fits available data.
But it doesn't fit the data -- the dark matter theory is constantly being revised. First it's "90%" of the mass of the universe, then it's "70%", then we're back to "98%", then there's dark energy, then the fractions change again, and again, and again.
That's not a fit! It's not like we started at, say, 80%, then refined the fit to 82.5%, then an additional data helped us narrow it down to 82.515%, and so on. It's just jumping all over the place.
Secondly, it's not "fitting to the data", it's fitting to the difference between a theory and the data. There's a huge difference. And it's particularly galling that the "theory" used is Newtonian gravity, when it's been known to be wrong for a century! Several papers have been released that show that it's possible to make the need for dark matter vanish by using relativistic mechanics. Not exactly surprising that the "difference" is affected by the theory chosen!
Every research paper about dark matter reads something like "we use a simplified theory of gravity because of [excuse], and then oh look, we find that our hugely simplified model doesn't agree with observations, so clearly there's an invisible something out there". The excuses vary between: "The other paper did it too", "Relativistic equations are hard, and I'm lazy", "I don't understand relativity so I don't know how it could possibly apply to galaxy sized masses thousands of light years in size", and "my computer is too slow to do this properly".
This is because average Slashdotters do not have even the beginnings of a clue about astrophysics
Yeah, well, I studied Physics at a university level, and I think dark matter smacks of hubris, laziness, and weak logic. It sounds an awful lot like chasing the error terms in Epicycles a century too late.
The latest attempts to explain dark matter are an ever bigger joke, like Modified Newtonian dynamics. Here's a hint... we already have a "modified" theory for motion -- it's called relativistic dynamics!
Until some physicist demonstrates that dark matter is still required to explain measurements when the theory used is the full general relativistic model with speed of light delay included, I'm just going to automatically assume that dark matter is bullshit.
This kind of thinking is all too common in Physics. A classic example is the double-slit experiment. Every textbook states a formula for the spacing of the interference fringes that disregards a bunch of things, handwaving them away as "unimportant". A math-geek friend of mine in my physics class was upset by this lack of rigor, walked up to the whiteboard, and demonstrated that the simplifications can result in errors as large as ten percent or more in real-world scenarios!
Imagine someone basing a new theory of light based on the difference between observed interference fringe spacing and the simplified theory. That would be stupid, wouldn't it? Why is it then acceptable for gravity?
The easy (and correct) way to solve this is to set up a private "Enterprise CA", and use policy to ensure that every machine trusts the root CA key. After that, your "self signed" certs become "normal" certs, and the browsers stop complaining. This way, you can have all of the free internal certificates you ever wanted, and the browser security model doesn't have to be broken.
With Windows server this is trivial to do: any domain member CA server's root key is automatically trusted by all domain member computers. I'm sure it's possible to do something similar for Linux, it just won't be quite as simple.
I've dropped a 200 MB Oracle.NET client into source control before, for example, to prevent exactly the kind of issues you're talking about. We had several incompatible versions floating about on servers. By having it in the source control and using relative linking, my app always used the specific version it needed. Similarly, I've dropped all of the binaries and libraries of the ANTLR parser generator into a project. It can be checked out of source control and used automatically with no intervention from the developer at all. They just edit the grammar file, hit compile, and it works. That's a quite complex scenario: it's a program that's used as a part of the build process to generate code and it has a redistributable runtime DLL!
Similarly, security patching ought not to be a concern for DLLs used during the development process. I mean, seriously, what are you developing, a web browser? And then testing it on seedy porn sites?
In turn, if you release software that uses third-party libraries, it should cater for security patching by allowing a range of versions, OR it should ship with the specific DLL required in the application folder, and then you should release patches yourself.
This is why most application installers are so huge -- they ship with all of the dependencies, even system components.
you can cross-reference projects quite well, if you put them all in a humungous single solution.
You're meant to do that!
You can completely unload projects from a solution -- to speed up the IDE performance even if there are hundreds or even thousands of projects. Even if you don't unload the projects, you can temporarily remove them from builds. A solution file is literally just a 1kb config file, not exactly a huge burden on a modern workstation.
And third-party projects are also meant to go into your source control along with everything else, or otherwise some poor bastard who'll have to build an 3 year old version of the system will tear his hair out trying to track down the exact right version of the library required.
I usually just drag & drop the DLLs directly into the project folders. They get stored in source control, included in output paths and setup projects, and all the references just work automagically.
As for versioning, it always uses the version built against, unless explicitly overridden.
That's the feature that fixes DLL hell! If that wasn't the rule, then developers could be linking against DLLs in the GAC installed by completely unrelated third-party software, and not realise it. Similarly, they could have, say, tested a newer version of the solution, ran the installer (populating the GAC), and then went back to work on an older version to reproduce a bug. Boom... wrong DLLs, unless the version linked is the version used in the build.
Don't try to reproduce your C++ build system for a.NET project. Actually, some of the things you appear to be doing aren't a good idea for a C++ project either...
but the crap way references are handled and the lack of some things that are needed by professional programmers (eg no system wide 'include' path to pick up references, so you have great difficulty unless all your devs use the same relative path)
Don't blame the ergonomics of your hammer if you're using the handle to hit the nail.
The Visual Studio project system -- or any sane source control based development process for that matter -- uses relative paths. It's just how it's done in professional environments.
With more than a single developer, absolute paths can't be used any more. You sort-of realise this yourself, but you simply decided to force every developer to use the same absolute paths instead of fixing your project structure. That wallpapers over the issue for a while, but the problem with that is that even a single developer can't use absolute paths if they need to keep multiple complete copies of the source tree around, which is essential for most projects.
For us that know how to use our tools properly, Visual Studio has a brilliant dependency and reference resolution system. I can cross-reference projects trivially and have it automatically determine the build order, include library DLLs in output paths, and build manifests automatically. The binding system is flexible -- it can be used to select the version of a library based on a bunch of different rules.
Because for small random I/O operations, SSDs are about 100x as fast as mechanical drives, but nowhere near 100x as expensive. This is not too dissimilar to moving from spools of tape to hard drives. Tape still has better capacity per dollar than disk, but you don't see anybody booting their PC off tape, do you?
You don't have to be a mega-corp for the speed advantage to make sense, which is why usage is increasing across the board.
For example, I recently installed a relatively small terminal server farm, and one of the performance tests I did revealed that for typical business application usage it's just not possible to utilise much more than 30% of the CPU and memory capacity of a server blade using mechanical drives!
Server OEMs like HP are already shipping blades with SSDs as a standard option, and I've seen SSD storage arrays in production usage. The time is coming very soon now when "storage" in the enterprise will mean solid state only, and spinning media will be used for the same role as tape is now: archival and backup.
Just because you're good at what you do doesn't mean that what you do is good.
Microseconds? Why not nanoseconds? How about femtoseconds? Why wouldn't that make just as much sense?
What could possibly change in the underlying value of a corporation made up of flesh and blood humans and capital with decades of depreciation in a fucking microsecond? Here's a hint: nothing. You are not investing, or trading, but simply racing other gamblers. Investing doesn't benefit from microsecond response times, and trading doesn't need it either. People could buy IPO shares just fine over the phone. Nobody ever needed a microsecond response time to buy a thousand bushels of wheat, and never will, because bread is baked daily, not a million times a fucking second.
If politicians had two braincells to rub together, they'd enact a law to prevent trades faster than some tick, say, an hour. Your 'trading' company would go out of business in a week, and nobody would care. Farmers would still sell their wheat, and bakers would still buy it, but without you leeches skimming off the top.
But it isn't really 'your' water pipe. You merely signed up for a service created, implemented, and hosted by the water company.
Or your electricity. Or phone service. Or mail service.
The thing is, with Google, if you do one thing wrong with one service, free or not, they instantly cut you off from everything, even the paid services, with zero warning. This is akin to a billing dispute with your water company resulting in your gas, electricity, and your phone getting cut off simultaneously.
And what's "wrong" anyway? Nobody can tell for sure except Google. It's not even clear even if you do read the 500 page long terms of service. The example of child pornography is perfect -- laws vary wildly between different countries! There's differences in intellectual property law too, I can see people being cut off for posting material that is copyrighted in the US, but public domain in their home country.
Having everything cut off instantly for one misstep with no recourse is terrifying. I'm certainly rethinking my future usage of Google services.
A modern cellphone emits on the order of 1 W of radiated power. That would take an hour and a half to heat an adult brain up by 1 Kelvin, but our brains are liquid cooled, so that just can't happen.
If an increase in the temperature of the brain causes cancer, then people who work outdoors in tropical countries ought to get a very high rate of brain cancers. They don't. People who get fevers more often than average ought to get a high rate of brain cancers. They don't. The average person's body temperature changes by 0.5 degrees C due simply to natural daily rhythms! That's the same amount of 'heating' as 45 minutes of cell phone use, every day.
The cellphone-cancer link is pure pseudoscience. It's not enough to come up with some vague correlation if every other verified theory tells us that it just can't happen. A mechanism for the cause has to be proposed (a model), and it has to be shown to be valid rigorously, using double-blind studies and falsifiable experiments. Nobody has come even close, and nobody should expect to be taken seriously until they do.
The problem is that all such methods add a substantial overhead in terms of % loss of energy and as a significant infrastructure expense. For example, it's surprisingly hard to expose microbes to sunlight without fouling issues, or contamination from other microbes. A lot of trivial demonstrations have been done, but a small, short-term project that isn't intended to make a profit is a far cry from doing this on an industrial scale, where the people operating the system are poorly educated country folk.
On top of that, the low overall efficiency means that enormous areas would have to be paved over with the growth medium of these things. It's doable in some places like Australia, Spain, or the United States, but is not viable in many European countries. They're already using that space to grow food!
Maybe, but throwing around numbers that are 25x higher than a realistic estimate and pretending that it is being spent at 30x of the actual rate makes it sound like a nuclear accident would instantly bankrupt even a large insurer, when in reality it would do no such thing.
Many insurance companies could handle $1B/yr, and there's nothing wrong with governments providing extra protection, like they do with banks.
And anyway, who cares how nuclear power is insured? You either pay for it directly through the cost of insurance that's factored into the electricity bill, or indirectly via your taxes. Either way, the cost is roughly the same, and not very large.
That's an estimate by some 'think tank' of the 'possible' total costs for the next decade. So even if it were true, it's just $25B/yr, or about 1/4 the annual cost of the war in Iraq.
It can't possibly be the total cost so far -- there's literally no way to buy stuff that is that expensive and make use of it in a constructive way in such a short period of time.
To put it another way, all money spent eventually becomes labor. Raw materials are priced essentially by the labor required to obtain them, as is energy. Even if the money was spent on quite expensive people, such as nuclear technicians, at an annual salary of say $300K, your quote of $240B spent would be the equivalent of 2.27 million such professional people working full time over the 134 days since the accident.
What could 2.27 million people possibly be doing? It would be impossible to fit even 1% of them onto the area of the plant! The materials and technologies used for the cleanup are quite ordinary and cheap, and can be applied using simple techniques. Think soap and water!
More realistic estimates from reputable sources are around $10B over a decade. That sounds about right for a large and complex engineering project like a nuclear cleanup involving hundreds of specialist technicians.
To put it another way, there are 442 nuclear reactors around the world used to generate power, and 2 have had a major disasters costing about a billion dollars per year. That works out to something like $2B/yr / 442 reactors = $4.5M/yr/reactor. That's a negligible overhead, and easily handled by private insurance.
In all seriousness, newer technology is generally safer than old technology, and several proposed reactor designs reduce nuclear waste, which is the biggest issue with nuclear power.
Most people these days are advocating molten salt reactors, which do not use dangerous liquid metals. Salts are much safer than anything currently used to generate power. There's no risk of the coolant or fuel igniting, for example, which is a risk even with water cooled plants. Fukushima is a practical example: the loss of coolant water allowed Zirconium fuel element cladding to become exposed to air and catch fire. That kind of thing just can't happen with a salt. Meltdown isn't a risk either in a reactor designed to operate in a molten state to begin with!
Flywheels are a huge safety risk. You either run them at low speeds, making them less efficient than batteries, or you run them at very high speeds, in which case a mechanical failure leads to an explosion. Check out this video for an idea of what happens when a lot of stored rotational energy is suddenly released. Now imagine that in every car!
I love renewable, clean energy, I do, but I wish journalists remembered enough junior school level mathematics to understand why technology like this will not be replacing coal, oil, and nuclear power any time soon. This is a positive step forward, but lets not pretend it's going to solve the looming energy crisis.
Lets do some back-of-the-envelope maths to understand why:
The specs of the Oyster 2 say that it generates a peak output of 800kW and has a length of 26 meters. Of course, you can't put them exactly side-by-side, not all locations are suitable, and 800kW is the maximum burst power output, not the average power, but lets just use optimistic numbers for the moment.
I can't find power usage numbers for Scotland, but the average citizen of Great Britain uses 5218.2 W total, factoring in indirect energy use (oil, coal, manufacturing, etc...). Multiply that by the population of Scotland, which is apparently 5.2 million people, and you get a reasonable sounding 27 GW of power usage.
That doesn't sound too bad relative to Scotland's 11,800 km of coastline, but that's counting every little bay, nook, cranny, and island. The coastline of a country depends on how you measure it. Wave energy comes from big waves created in the ocean, so a much more reasonable estimate for the coastline is the perimeter of a circle with the same area as the land mass. For Scotland, this is a mere 995 km, from which we may as well subtract the 95 km land border with England, leaving 900 km.
This means that the estimate of 882 km of needed wave power generators is 98% of the available coastline. Oops.
Don't believe me? Here's another source that states that the total exploitable power available near the shore (ignoring overheads, inefficiencies, etc...) is 18.5 kW/m, which works out to 16.7 GW. In practice, there's no hope of achieving anywhere near 100% of that. The maths for solar and wind power is similar, for much the same reasons.
The inevitable conclusion of this kind of trivial mathematics is that densely populated countries would have to pave over huge fractions of their land with solar cells, put wind farms on every hilltop, and surround much of their coastline with wave generators to even begin to approach their present power needs, let alone future growth.
Don't think biofuels like ethanol or biodiesel help either, the most efficient plants are only 9% efficient at best, in ideal tropical conditions, and that's not factoring in the energy overheads of fertilizer, harvesting, and conversion!
Meanwhile, a nuclear power plant with an output of 1 GW requires a mere hectare of land area, which is why nations that have leadership with some common sense are planning on building more nuclear power, not less.
On the bright side, I live in Australia, where we have plenty of land, coastline, sunlight, coal, and uranium. This all sounds like someone else's problem to me! 8)
There are benefits to a native PowerShell module, like discoverability, tab-complete, strong-typing, support for common and preference parameters, session variables (e.g.: "trust this SSH key for this session only"), object-oriented result sets, and a bunch of other things.
The elegant way to support SCP in PowerShell would be to write a PowerShell virtual filesystem provider. This would allow scripts to use all of the built-in PowerShell commands on the remote filesystem as if they were normal mounted drives. For example, dir, copy, and del, would all work. It's much easier writing a PowerShell provider than a full filesystem driver, so even for a complex user-mode protocol like SCP it wouldn't be too difficult. Similarly, the SSH key store could be treated like a virtual drive too, just like the built-in Certificate provider.
Alternatively, the even simpler solution is to do something like what VMware did for copying files onto ESXi servers, like Copy-VMGuestFile, and Copy-DatastoreItem.
SSH wouldn't be as easy to wrap, but I suppose it would be possible to create a set of commands such as Invoke-SSHCommand, Enter-SSHSession, and the like, with analogy to Invoke-Command and Enter-PSSession. The problem is that PowerShell doesn't really have a built-in concept of a non-PowerShell session, so a bit of wheel-reinventing would be needed to get a complete set of commands.
The same is not true on servers, of course, the heavier random load makes IOPs a big deal in various servers (databases particularly).
Did you actually read the article and look at the numbers?
SSDs stomp all over mechanical drives for random IO throughput, by 3 orders of magnitude or more!
My old SATA II SSD outperformed a 48-spindle enterprise SAN volume for real-world database performance, and my current SSD is at least 3x faster!
To perform complex schema changes I would often make a copy of the production database onto my laptop, perform the IO intensive operations like re-indexing on there, and then copy the result back to production, because that way it only took a few tens of minutes instead of a day or more!
Stop guessing, or blaming my system for what is clearly a flaw in the application.
I just tested it: I watched the firefox.exe process in task manager while pressing a key until it 'glitched'. It did 0 bytes of I/O activity, so it can't possibly be my hard drive.
Feel free to explain to me how that's possible on a system with 12 GB of memory, while Firefox is using 700MB, and I have no other applications running.
And before I forget, I have an SSD, so I often don't even notice it when applications really do start swapping. Nonetheless, on one of the faster desktop PCs money can buy, Firefox freezes regularly.
It's doing it right now, pausing for a about 500ms before responding to keystrokes every 10 seconds or so.
It also does it on my work laptop, which has 8GB of memory, and also has an SSD, but on that it can be worse, freezing for 3-4 seconds at a time.
Well, I'm a consultant working primarily for government, and I can honestly say that those aren't the reasons why these projects fail.
Corruption in hiring is surprisingly rare in western countries, and usually involves only a small subset of the people on a large project. I've heard it's a serious problem in developing countries, but I've only seen it a few times here, and and I've only ever seen it lead to a project failure when the project team was only a handful of people.
You'd be surprised about the work ethic of consultants.
For some consulting organizations, there's so much work that they prefer to have their consultants finish projects quickly so that they can go on to other projects and hence satisfy all of their customers, not just some of them. Not turning up at all is a surefire way of losing a customer to your competition, which can go from nonexistent to serious in very little time if they suddenly start landing big projects.
More commonly, consulting is only a part of what a company does. Large vendors like SAP sell licenses, support contracts, and consulting separately. If one branch of the company starts annoying the customers (too expensive, slow, incompetent, etc...) then this drags down the results of other branches too, and then their executives become very angry and complain directly to the CEO. God help the consultant working for an organization that makes most of their profit from licenses if the fuck up a sales deal!
Lastly, consulting firms tend to hire better-than-average people, and those tend to be high achievers and motivated professionals. Delivering projects on time and on budget looks good on a CV, and can lead to even more lucrative positions.
I've seen enough projects that I've figured out that government contracts go over budget or time for several inter-related reasons:
- Ridiculous levels of risk aversion -- if there's no bonus or profit to be had, then no risk is worth it. This leads to some very stupid decisions, over-engineering, etc... - Management overhead -- big bureaucracies ignore the cost of management overhead, because the only way to reduce it is to fire a bunch of managers, but management makes hiring and firing decisions! Almost nobody would ever fire themselves. Instead, managers rationalize the need for management. There's no arguing with people about useless processes, when the existence of that process, useful or not, keeps them employed. - Conservative approach to IT -- a big project is hard enough, but when you also have to deal with decades old software and sometimes even hardware, the difficulty becomes astronomical. In quite recent times, I've come across all sorts of fun things in the core infrastructure of large organizations. For example, OS/2 is still in use. Novell NetWare refuses to die. I've seen Windows 95 as a server in a data center just recently. I did a lot of work on an enterprise DOS application just a couple of years ago. It's not just systems, but processes to. Why change anything, just because the software is completely different, and the hardware is six orders of magnitude bigger or faster?
So imagine being the consultant hired to rip up and replace 10s of millions of lines of code across hundreds of undocumented systems, most of which should have been cleansed with purifying fire decades ago, but you're not allowed to. Instead, you have to sit patiently through a never ending series of pointless meetings that serve only to prevent any bureaucrat from ever having to make a decision, or take any blame for anything.
We have only 3 primary color channels (4 if you count rods separately, 5 if also counting tetrachromats), not "65000". We can't see 1 million different intensities simultaneously either -- while the human eye does have an enormous dynamic range, this adaptation takes a while (minutes). At any one time, we can see maybe 300-1000 distinct intensity levels per color channel. This only requires 10 bits to represent per channel. Even your 125 Mpixels is an exaggeration, because we have roughly 125 million sensor cells total, not 125 per color channel!
This then works out to 125*10^6 cells * 10 bits * 30 Hz = 38 Gbps, which is a lot, but is almost 7 orders of magnitude less than your estimate!
In practice, even 38 Gbps is overestimating things substantially -- the cells in the retina have a trade-off between temporal resolution ('framerate') and dynamic range, so we can't simultaneously get 10 bits of intensity detail and 30 Hz of temporal resolution. Additionally, the image on the retina isn't focused very well, reducing the actual image detail quite a bit, especially near the edge of our field of view.
Whatever the real raw bandwidth is, the optic nerve transmits only about 8.75 Mbps per eye!
No, *not* end of story. They still launch RTGs, in spite of the real risks involved. They didn't "ignore" the risks completely (they did shield the reactors), but they still went ahead with these launches, even though there are risks involved.
Of course they did, because at the cutting edge of engineering and human achievement nothing is risk free. Asking people to stop doing risky things is just stupid, because it's not going to happen. There's an acceptable level of risk, and everybody with any common sense accepts it, because the benefits are worth it.
Harping on about a 1 in 10^20 chance that you'll personally die from some rocket launch is simply insane, because you have something like a 1 in 10^8 chance of being killed every time you drive to the shops, and you have no problem with that!
People are shockingly bad at judging risk due to their emotions, perceived level of control, and their past experiences. Driving drunk? Sure, I made it home last time with no problems! Nuclear power on a space probe? How dare they risk my life!
Open a damned wiki page once in while, and learn about the long list of people who died from plain old non-nuclear chemical reactions in the space industry. It's not like the deaths are restricted to aerospace engineers and astronauts, civilians have been killed in their homes: Intelsat 708 killed 6 and injured dozens. Should we stop all spaceflight so that never happens again? Really?
I'm just trying to show that concern is reasonable. Engineer-types tend to mischaracterize anyone who dares question the safety of nuclear systems as some sort of crazy person.
But that's just the thing -- your concerns are not reasonable, because the probabilities say that the risk is negligible compared to the benefits. Ignoring the maths and engineering and concentrating on your personal misgivings is not reasonable, it's irrational.
...but you have no business speaking on behalf of others.
That works both ways: you have no business speaking on my behalf to restrict the technologies that can be applied to advance our understanding of the universe.
Don't believe the BS about corporations not liking change as the reason for the failure of Firefox in the corporate world. Corporations have to deploy new updates and versions of every damned thing on a regular basis, what's one more application, really? A lot of corporations don't care about "enterprise support", especially for applications that are offered on an "as-is" basis. Think: IE for your intranet apps, Firefox for browsing. They don't necessarily need to certify, or test, but no matter what, they'll have to deploy.
Deployment can be trivial, or it can be quite a lot of work, depending on how the application is packaged. Firefox is one of those wonderful applications that despite having a user base of mostly Windows users, doesn't follow most of the Windows application deployment methods. It doesn't use MSI installers or MSP patches, and doesn't come with ADM or ADMX policy files.
In other words, deploying it is a bitch because it's non-standard, and hence it requires administrators to spend precious time fixing issues that shouldn't occur in the first place.
I'd deploy Firefox in a heartbeat, but until I can drop an MSI from an official build into SCCM, and then lock it down with an ADMX template that configures policies instead of settings, I don't have the time. I don't have the time to waste chasing down some virus-infested hand-made MSI on Bob's Blog, and combine it with some half-baked group policy template from somewhere else. I don't have the time to roll my own system either, especially considering the regular update cycle.
This wouldn't be hard for Mozilla to fix. They'd literally have to write just a couple of simple config files, and add some WiX steps to the build scripts.
This has been a top request on Bugzilla for almost a decade, and has been consistently ignored by the Mozilla team. I cannot begin to imagine why.
Don't like it so verbose? You can also use the shorter aliases instead, such as: "ps | epcsv procs.csv"
Yes, Linux is free and open, and that's a good thing. Yes, it scales well and runs on all sorts of unusual or purpose-built hardware. Yes, it can be very secure if managed properly. But no, it is absolutely not more usable than Windows.
Linux doesn't have the central control required for the kind of consistency of design that is required for user friendliness. The "ps" and "service" programs were written by different people in different ways, and are wildly different. The OS hotfix install/query commands aren't even consistent across contemporary Linux releases!
Slashdot Mirror
This is because it is the simplest theory which fits available data.
But it doesn't fit the data -- the dark matter theory is constantly being revised. First it's "90%" of the mass of the universe, then it's "70%", then we're back to "98%", then there's dark energy, then the fractions change again, and again, and again.
That's not a fit! It's not like we started at, say, 80%, then refined the fit to 82.5%, then an additional data helped us narrow it down to 82.515%, and so on. It's just jumping all over the place.
Secondly, it's not "fitting to the data", it's fitting to the difference between a theory and the data. There's a huge difference. And it's particularly galling that the "theory" used is Newtonian gravity, when it's been known to be wrong for a century! Several papers have been released that show that it's possible to make the need for dark matter vanish by using relativistic mechanics. Not exactly surprising that the "difference" is affected by the theory chosen!
Every research paper about dark matter reads something like "we use a simplified theory of gravity because of [excuse], and then oh look, we find that our hugely simplified model doesn't agree with observations, so clearly there's an invisible something out there". The excuses vary between: "The other paper did it too", "Relativistic equations are hard, and I'm lazy", "I don't understand relativity so I don't know how it could possibly apply to galaxy sized masses thousands of light years in size", and "my computer is too slow to do this properly".
This is because average Slashdotters do not have even the beginnings of a clue about astrophysics
Yeah, well, I studied Physics at a university level, and I think dark matter smacks of hubris, laziness, and weak logic. It sounds an awful lot like chasing the error terms in Epicycles a century too late.
The latest attempts to explain dark matter are an ever bigger joke, like Modified Newtonian dynamics. Here's a hint... we already have a "modified" theory for motion -- it's called relativistic dynamics!
Until some physicist demonstrates that dark matter is still required to explain measurements when the theory used is the full general relativistic model with speed of light delay included, I'm just going to automatically assume that dark matter is bullshit.
This kind of thinking is all too common in Physics. A classic example is the double-slit experiment. Every textbook states a formula for the spacing of the interference fringes that disregards a bunch of things, handwaving them away as "unimportant". A math-geek friend of mine in my physics class was upset by this lack of rigor, walked up to the whiteboard, and demonstrated that the simplifications can result in errors as large as ten percent or more in real-world scenarios!
Imagine someone basing a new theory of light based on the difference between observed interference fringe spacing and the simplified theory. That would be stupid, wouldn't it? Why is it then acceptable for gravity?
The easy (and correct) way to solve this is to set up a private "Enterprise CA", and use policy to ensure that every machine trusts the root CA key. After that, your "self signed" certs become "normal" certs, and the browsers stop complaining. This way, you can have all of the free internal certificates you ever wanted, and the browser security model doesn't have to be broken.
With Windows server this is trivial to do: any domain member CA server's root key is automatically trusted by all domain member computers. I'm sure it's possible to do something similar for Linux, it just won't be quite as simple.
Drop a 3rd party project into your SCM?
Yes!
I've dropped a 200 MB Oracle .NET client into source control before, for example, to prevent exactly the kind of issues you're talking about. We had several incompatible versions floating about on servers. By having it in the source control and using relative linking, my app always used the specific version it needed. Similarly, I've dropped all of the binaries and libraries of the ANTLR parser generator into a project. It can be checked out of source control and used automatically with no intervention from the developer at all. They just edit the grammar file, hit compile, and it works. That's a quite complex scenario: it's a program that's used as a part of the build process to generate code and it has a redistributable runtime DLL!
Similarly, security patching ought not to be a concern for DLLs used during the development process. I mean, seriously, what are you developing, a web browser? And then testing it on seedy porn sites?
In turn, if you release software that uses third-party libraries, it should cater for security patching by allowing a range of versions, OR it should ship with the specific DLL required in the application folder, and then you should release patches yourself.
This is why most application installers are so huge -- they ship with all of the dependencies, even system components.
you can cross-reference projects quite well, if you put them all in a humungous single solution.
You're meant to do that!
You can completely unload projects from a solution -- to speed up the IDE performance even if there are hundreds or even thousands of projects. Even if you don't unload the projects, you can temporarily remove them from builds. A solution file is literally just a 1kb config file, not exactly a huge burden on a modern workstation.
And third-party projects are also meant to go into your source control along with everything else, or otherwise some poor bastard who'll have to build an 3 year old version of the system will tear his hair out trying to track down the exact right version of the library required.
I usually just drag & drop the DLLs directly into the project folders. They get stored in source control, included in output paths and setup projects, and all the references just work automagically.
As for versioning, it always uses the version built against, unless explicitly overridden.
That's the feature that fixes DLL hell! If that wasn't the rule, then developers could be linking against DLLs in the GAC installed by completely unrelated third-party software, and not realise it. Similarly, they could have, say, tested a newer version of the solution, ran the installer (populating the GAC), and then went back to work on an older version to reproduce a bug. Boom... wrong DLLs, unless the version linked is the version used in the build.
Don't try to reproduce your C++ build system for a .NET project. Actually, some of the things you appear to be doing aren't a good idea for a C++ project either...
I think what the OP is arguing is, why bother that lot at all?
Because when Microsoft releases Windows 8 with ARM support, existing .NET binaries compiled for "AnyCPU" will Just Work.
but the crap way references are handled and the lack of some things that are needed by professional programmers (eg no system wide 'include' path to pick up references, so you have great difficulty unless all your devs use the same relative path)
Don't blame the ergonomics of your hammer if you're using the handle to hit the nail.
The Visual Studio project system -- or any sane source control based development process for that matter -- uses relative paths. It's just how it's done in professional environments.
With more than a single developer, absolute paths can't be used any more. You sort-of realise this yourself, but you simply decided to force every developer to use the same absolute paths instead of fixing your project structure. That wallpapers over the issue for a while, but the problem with that is that even a single developer can't use absolute paths if they need to keep multiple complete copies of the source tree around, which is essential for most projects.
For us that know how to use our tools properly, Visual Studio has a brilliant dependency and reference resolution system. I can cross-reference projects trivially and have it automatically determine the build order, include library DLLs in output paths, and build manifests automatically. The binding system is flexible -- it can be used to select the version of a library based on a bunch of different rules.
Because for small random I/O operations, SSDs are about 100x as fast as mechanical drives, but nowhere near 100x as expensive. This is not too dissimilar to moving from spools of tape to hard drives. Tape still has better capacity per dollar than disk, but you don't see anybody booting their PC off tape, do you?
You don't have to be a mega-corp for the speed advantage to make sense, which is why usage is increasing across the board.
For example, I recently installed a relatively small terminal server farm, and one of the performance tests I did revealed that for typical business application usage it's just not possible to utilise much more than 30% of the CPU and memory capacity of a server blade using mechanical drives!
Server OEMs like HP are already shipping blades with SSDs as a standard option, and I've seen SSD storage arrays in production usage. The time is coming very soon now when "storage" in the enterprise will mean solid state only, and spinning media will be used for the same role as tape is now: archival and backup.
Just because you're good at what you do doesn't mean that what you do is good.
Microseconds? Why not nanoseconds? How about femtoseconds? Why wouldn't that make just as much sense?
What could possibly change in the underlying value of a corporation made up of flesh and blood humans and capital with decades of depreciation in a fucking microsecond? Here's a hint: nothing. You are not investing, or trading, but simply racing other gamblers. Investing doesn't benefit from microsecond response times, and trading doesn't need it either. People could buy IPO shares just fine over the phone. Nobody ever needed a microsecond response time to buy a thousand bushels of wheat, and never will, because bread is baked daily, not a million times a fucking second.
If politicians had two braincells to rub together, they'd enact a law to prevent trades faster than some tick, say, an hour. Your 'trading' company would go out of business in a week, and nobody would care. Farmers would still sell their wheat, and bakers would still buy it, but without you leeches skimming off the top.
But it isn't really 'your' water pipe. You merely signed up for a service created, implemented, and hosted by the water company.
Or your electricity. Or phone service. Or mail service.
The thing is, with Google, if you do one thing wrong with one service, free or not, they instantly cut you off from everything, even the paid services, with zero warning. This is akin to a billing dispute with your water company resulting in your gas, electricity, and your phone getting cut off simultaneously.
And what's "wrong" anyway? Nobody can tell for sure except Google. It's not even clear even if you do read the 500 page long terms of service. The example of child pornography is perfect -- laws vary wildly between different countries! There's differences in intellectual property law too, I can see people being cut off for posting material that is copyrighted in the US, but public domain in their home country.
Having everything cut off instantly for one misstep with no recourse is terrifying. I'm certainly rethinking my future usage of Google services.
slight but measurable heating of the brain.
A modern cellphone emits on the order of 1 W of radiated power. That would take an hour and a half to heat an adult brain up by 1 Kelvin, but our brains are liquid cooled, so that just can't happen.
If an increase in the temperature of the brain causes cancer, then people who work outdoors in tropical countries ought to get a very high rate of brain cancers. They don't. People who get fevers more often than average ought to get a high rate of brain cancers. They don't. The average person's body temperature changes by 0.5 degrees C due simply to natural daily rhythms! That's the same amount of 'heating' as 45 minutes of cell phone use, every day.
The cellphone-cancer link is pure pseudoscience. It's not enough to come up with some vague correlation if every other verified theory tells us that it just can't happen. A mechanism for the cause has to be proposed (a model), and it has to be shown to be valid rigorously, using double-blind studies and falsifiable experiments. Nobody has come even close, and nobody should expect to be taken seriously until they do.
Sure, energy is fungible.
The problem is that all such methods add a substantial overhead in terms of % loss of energy and as a significant infrastructure expense. For example, it's surprisingly hard to expose microbes to sunlight without fouling issues, or contamination from other microbes. A lot of trivial demonstrations have been done, but a small, short-term project that isn't intended to make a profit is a far cry from doing this on an industrial scale, where the people operating the system are poorly educated country folk.
On top of that, the low overall efficiency means that enormous areas would have to be paved over with the growth medium of these things. It's doable in some places like Australia, Spain, or the United States, but is not viable in many European countries. They're already using that space to grow food!
Maybe, but throwing around numbers that are 25x higher than a realistic estimate and pretending that it is being spent at 30x of the actual rate makes it sound like a nuclear accident would instantly bankrupt even a large insurer, when in reality it would do no such thing.
Many insurance companies could handle $1B/yr, and there's nothing wrong with governments providing extra protection, like they do with banks.
And anyway, who cares how nuclear power is insured? You either pay for it directly through the cost of insurance that's factored into the electricity bill, or indirectly via your taxes. Either way, the cost is roughly the same, and not very large.
has cost the Japanese over $240 Billion
No. Just... no.
That's an estimate by some 'think tank' of the 'possible' total costs for the next decade. So even if it were true, it's just $25B/yr, or about 1/4 the annual cost of the war in Iraq.
It can't possibly be the total cost so far -- there's literally no way to buy stuff that is that expensive and make use of it in a constructive way in such a short period of time.
To put it another way, all money spent eventually becomes labor. Raw materials are priced essentially by the labor required to obtain them, as is energy. Even if the money was spent on quite expensive people, such as nuclear technicians, at an annual salary of say $300K, your quote of $240B spent would be the equivalent of 2.27 million such professional people working full time over the 134 days since the accident.
What could 2.27 million people possibly be doing? It would be impossible to fit even 1% of them onto the area of the plant! The materials and technologies used for the cleanup are quite ordinary and cheap, and can be applied using simple techniques. Think soap and water!
More realistic estimates from reputable sources are around $10B over a decade. That sounds about right for a large and complex engineering project like a nuclear cleanup involving hundreds of specialist technicians.
To put it another way, there are 442 nuclear reactors around the world used to generate power, and 2 have had a major disasters costing about a billion dollars per year. That works out to something like $2B/yr / 442 reactors = $4.5M/yr/reactor. That's a negligible overhead, and easily handled by private insurance.
In all seriousness, newer technology is generally safer than old technology, and several proposed reactor designs reduce nuclear waste, which is the biggest issue with nuclear power.
Most people these days are advocating molten salt reactors, which do not use dangerous liquid metals. Salts are much safer than anything currently used to generate power. There's no risk of the coolant or fuel igniting, for example, which is a risk even with water cooled plants. Fukushima is a practical example: the loss of coolant water allowed Zirconium fuel element cladding to become exposed to air and catch fire. That kind of thing just can't happen with a salt. Meltdown isn't a risk either in a reactor designed to operate in a molten state to begin with!
Flywheels are a huge safety risk. You either run them at low speeds, making them less efficient than batteries, or you run them at very high speeds, in which case a mechanical failure leads to an explosion. Check out this video for an idea of what happens when a lot of stored rotational energy is suddenly released. Now imagine that in every car!
I love renewable, clean energy, I do, but I wish journalists remembered enough junior school level mathematics to understand why technology like this will not be replacing coal, oil, and nuclear power any time soon. This is a positive step forward, but lets not pretend it's going to solve the looming energy crisis.
Lets do some back-of-the-envelope maths to understand why:
The specs of the Oyster 2 say that it generates a peak output of 800kW and has a length of 26 meters. Of course, you can't put them exactly side-by-side, not all locations are suitable, and 800kW is the maximum burst power output, not the average power, but lets just use optimistic numbers for the moment.
I can't find power usage numbers for Scotland, but the average citizen of Great Britain uses 5218.2 W total, factoring in indirect energy use (oil, coal, manufacturing, etc...). Multiply that by the population of Scotland, which is apparently 5.2 million people, and you get a reasonable sounding 27 GW of power usage.
This means that the total length of coastline needed to generate that amount of power using technology like the Oyster 2 is: 5218.2 W * 5,200,000 * 26 m / 800,000 W = 882 km.
That doesn't sound too bad relative to Scotland's 11,800 km of coastline, but that's counting every little bay, nook, cranny, and island. The coastline of a country depends on how you measure it. Wave energy comes from big waves created in the ocean, so a much more reasonable estimate for the coastline is the perimeter of a circle with the same area as the land mass. For Scotland, this is a mere 995 km, from which we may as well subtract the 95 km land border with England, leaving 900 km.
This means that the estimate of 882 km of needed wave power generators is 98% of the available coastline. Oops.
Don't believe me? Here's another source that states that the total exploitable power available near the shore (ignoring overheads, inefficiencies, etc...) is 18.5 kW/m, which works out to 16.7 GW. In practice, there's no hope of achieving anywhere near 100% of that. The maths for solar and wind power is similar, for much the same reasons.
The inevitable conclusion of this kind of trivial mathematics is that densely populated countries would have to pave over huge fractions of their land with solar cells, put wind farms on every hilltop, and surround much of their coastline with wave generators to even begin to approach their present power needs, let alone future growth.
Don't think biofuels like ethanol or biodiesel help either, the most efficient plants are only 9% efficient at best, in ideal tropical conditions, and that's not factoring in the energy overheads of fertilizer, harvesting, and conversion!
Meanwhile, a nuclear power plant with an output of 1 GW requires a mere hectare of land area, which is why nations that have leadership with some common sense are planning on building more nuclear power, not less.
On the bright side, I live in Australia, where we have plenty of land, coastline, sunlight, coal, and uranium. This all sounds like someone else's problem to me! 8)
There are benefits to a native PowerShell module, like discoverability, tab-complete, strong-typing, support for common and preference parameters, session variables (e.g.: "trust this SSH key for this session only"), object-oriented result sets, and a bunch of other things.
The elegant way to support SCP in PowerShell would be to write a PowerShell virtual filesystem provider. This would allow scripts to use all of the built-in PowerShell commands on the remote filesystem as if they were normal mounted drives. For example, dir, copy, and del, would all work. It's much easier writing a PowerShell provider than a full filesystem driver, so even for a complex user-mode protocol like SCP it wouldn't be too difficult. Similarly, the SSH key store could be treated like a virtual drive too, just like the built-in Certificate provider.
Alternatively, the even simpler solution is to do something like what VMware did for copying files onto ESXi servers, like Copy-VMGuestFile, and Copy-DatastoreItem.
SSH wouldn't be as easy to wrap, but I suppose it would be possible to create a set of commands such as Invoke-SSHCommand, Enter-SSHSession, and the like, with analogy to Invoke-Command and Enter-PSSession. The problem is that PowerShell doesn't really have a built-in concept of a non-PowerShell session, so a bit of wheel-reinventing would be needed to get a complete set of commands.
The same is not true on servers, of course, the heavier random load makes IOPs a big deal in various servers (databases particularly).
Did you actually read the article and look at the numbers?
SSDs stomp all over mechanical drives for random IO throughput, by 3 orders of magnitude or more!
My old SATA II SSD outperformed a 48-spindle enterprise SAN volume for real-world database performance, and my current SSD is at least 3x faster!
To perform complex schema changes I would often make a copy of the production database onto my laptop, perform the IO intensive operations like re-indexing on there, and then copy the result back to production, because that way it only took a few tens of minutes instead of a day or more!
Stop guessing, or blaming my system for what is clearly a flaw in the application.
I just tested it: I watched the firefox.exe process in task manager while pressing a key until it 'glitched'. It did 0 bytes of I/O activity, so it can't possibly be my hard drive.
Feel free to explain to me how that's possible on a system with 12 GB of memory, while Firefox is using 700MB, and I have no other applications running.
And before I forget, I have an SSD, so I often don't even notice it when applications really do start swapping. Nonetheless, on one of the faster desktop PCs money can buy, Firefox freezes regularly.
It's doing it right now, pausing for a about 500ms before responding to keystrokes every 10 seconds or so.
It also does it on my work laptop, which has 8GB of memory, and also has an SSD, but on that it can be worse, freezing for 3-4 seconds at a time.
Well, I'm a consultant working primarily for government, and I can honestly say that those aren't the reasons why these projects fail.
Corruption in hiring is surprisingly rare in western countries, and usually involves only a small subset of the people on a large project. I've heard it's a serious problem in developing countries, but I've only seen it a few times here, and and I've only ever seen it lead to a project failure when the project team was only a handful of people.
You'd be surprised about the work ethic of consultants.
For some consulting organizations, there's so much work that they prefer to have their consultants finish projects quickly so that they can go on to other projects and hence satisfy all of their customers, not just some of them. Not turning up at all is a surefire way of losing a customer to your competition, which can go from nonexistent to serious in very little time if they suddenly start landing big projects.
More commonly, consulting is only a part of what a company does. Large vendors like SAP sell licenses, support contracts, and consulting separately. If one branch of the company starts annoying the customers (too expensive, slow, incompetent, etc...) then this drags down the results of other branches too, and then their executives become very angry and complain directly to the CEO. God help the consultant working for an organization that makes most of their profit from licenses if the fuck up a sales deal!
Lastly, consulting firms tend to hire better-than-average people, and those tend to be high achievers and motivated professionals. Delivering projects on time and on budget looks good on a CV, and can lead to even more lucrative positions.
I've seen enough projects that I've figured out that government contracts go over budget or time for several inter-related reasons:
- Ridiculous levels of risk aversion -- if there's no bonus or profit to be had, then no risk is worth it. This leads to some very stupid decisions, over-engineering, etc...
- Management overhead -- big bureaucracies ignore the cost of management overhead, because the only way to reduce it is to fire a bunch of managers, but management makes hiring and firing decisions! Almost nobody would ever fire themselves. Instead, managers rationalize the need for management. There's no arguing with people about useless processes, when the existence of that process, useful or not, keeps them employed.
- Conservative approach to IT -- a big project is hard enough, but when you also have to deal with decades old software and sometimes even hardware, the difficulty becomes astronomical. In quite recent times, I've come across all sorts of fun things in the core infrastructure of large organizations. For example, OS/2 is still in use. Novell NetWare refuses to die. I've seen Windows 95 as a server in a data center just recently. I did a lot of work on an enterprise DOS application just a couple of years ago. It's not just systems, but processes to. Why change anything, just because the software is completely different, and the hardware is six orders of magnitude bigger or faster?
So imagine being the consultant hired to rip up and replace 10s of millions of lines of code across hundreds of undocumented systems, most of which should have been cleansed with purifying fire decades ago, but you're not allowed to. Instead, you have to sit patiently through a never ending series of pointless meetings that serve only to prevent any bureaucrat from ever having to make a decision, or take any blame for anything.
Your maths is quite a bit off.
We have only 3 primary color channels (4 if you count rods separately, 5 if also counting tetrachromats), not "65000". We can't see 1 million different intensities simultaneously either -- while the human eye does have an enormous dynamic range, this adaptation takes a while (minutes). At any one time, we can see maybe 300-1000 distinct intensity levels per color channel. This only requires 10 bits to represent per channel. Even your 125 Mpixels is an exaggeration, because we have roughly 125 million sensor cells total, not 125 per color channel!
This then works out to 125*10^6 cells * 10 bits * 30 Hz = 38 Gbps, which is a lot, but is almost 7 orders of magnitude less than your estimate!
In practice, even 38 Gbps is overestimating things substantially -- the cells in the retina have a trade-off between temporal resolution ('framerate') and dynamic range, so we can't simultaneously get 10 bits of intensity detail and 30 Hz of temporal resolution. Additionally, the image on the retina isn't focused very well, reducing the actual image detail quite a bit, especially near the edge of our field of view.
Whatever the real raw bandwidth is, the optic nerve transmits only about 8.75 Mbps per eye!
No, *not* end of story. They still launch RTGs, in spite of the real risks involved. They didn't "ignore" the risks completely (they did shield the reactors), but they still went ahead with these launches, even though there are risks involved.
Of course they did, because at the cutting edge of engineering and human achievement nothing is risk free. Asking people to stop doing risky things is just stupid, because it's not going to happen. There's an acceptable level of risk, and everybody with any common sense accepts it, because the benefits are worth it.
Harping on about a 1 in 10^20 chance that you'll personally die from some rocket launch is simply insane, because you have something like a 1 in 10^8 chance of being killed every time you drive to the shops, and you have no problem with that!
People are shockingly bad at judging risk due to their emotions, perceived level of control, and their past experiences. Driving drunk? Sure, I made it home last time with no problems! Nuclear power on a space probe? How dare they risk my life!
Open a damned wiki page once in while, and learn about the long list of people who died from plain old non-nuclear chemical reactions in the space industry. It's not like the deaths are restricted to aerospace engineers and astronauts, civilians have been killed in their homes: Intelsat 708 killed 6 and injured dozens. Should we stop all spaceflight so that never happens again? Really?
I'm just trying to show that concern is reasonable. Engineer-types tend to mischaracterize anyone who dares question the safety of nuclear systems as some sort of crazy person.
But that's just the thing -- your concerns are not reasonable, because the probabilities say that the risk is negligible compared to the benefits. Ignoring the maths and engineering and concentrating on your personal misgivings is not reasonable, it's irrational.
...but you have no business speaking on behalf of others.
That works both ways: you have no business speaking on my behalf to restrict the technologies that can be applied to advance our understanding of the universe.
Don't believe the BS about corporations not liking change as the reason for the failure of Firefox in the corporate world. Corporations have to deploy new updates and versions of every damned thing on a regular basis, what's one more application, really? A lot of corporations don't care about "enterprise support", especially for applications that are offered on an "as-is" basis. Think: IE for your intranet apps, Firefox for browsing. They don't necessarily need to certify, or test, but no matter what, they'll have to deploy.
Deployment can be trivial, or it can be quite a lot of work, depending on how the application is packaged. Firefox is one of those wonderful applications that despite having a user base of mostly Windows users, doesn't follow most of the Windows application deployment methods. It doesn't use MSI installers or MSP patches, and doesn't come with ADM or ADMX policy files.
In other words, deploying it is a bitch because it's non-standard, and hence it requires administrators to spend precious time fixing issues that shouldn't occur in the first place.
I'd deploy Firefox in a heartbeat, but until I can drop an MSI from an official build into SCCM, and then lock it down with an ADMX template that configures policies instead of settings, I don't have the time. I don't have the time to waste chasing down some virus-infested hand-made MSI on Bob's Blog, and combine it with some half-baked group policy template from somewhere else. I don't have the time to roll my own system either, especially considering the regular update cycle.
This wouldn't be hard for Mozilla to fix. They'd literally have to write just a couple of simple config files, and add some WiX steps to the build scripts.
This has been a top request on Bugzilla for almost a decade, and has been consistently ignored by the Mozilla team. I cannot begin to imagine why.
The hilarity is that Windows now has a better CLI shell than any Linux or Unix too.
If you Linux fans don't believe me, then quickly, tell me how to get the following three pieces of information as a CSV formatted text file:
- The list of running processes
- The list of running system services
- The list of installed OS hotfixes/patches
For each one, make sure you capture at least a few columns of relevant or related information (e.g.: the pid of a process).
I can do all three with Windows PowerShell in seconds:
Get-Process | Export-Csv 'processes.csv'
Get-Service | Export-Csv 'services.csv'
Get-HotFix | Export-Csv 'hotfixes.csv'
Don't like it so verbose? You can also use the shorter aliases instead, such as: "ps | epcsv procs.csv"
Yes, Linux is free and open, and that's a good thing. Yes, it scales well and runs on all sorts of unusual or purpose-built hardware. Yes, it can be very secure if managed properly. But no, it is absolutely not more usable than Windows.
Linux doesn't have the central control required for the kind of consistency of design that is required for user friendliness. The "ps" and "service" programs were written by different people in different ways, and are wildly different. The OS hotfix install/query commands aren't even consistent across contemporary Linux releases!
What Linux desperately needs is a set of guidelines for developers. For an example, take a look at Microsoft's guidelines for PowerShell snap-in developers.
Imagine for a second what a nirvana Linux CLI scripting would be if every Linux tool was written that consistently!