This strange world view is held by lots of people, and I've never quite understood why.
First of all, the 'written record' has been translated at least twice before you've heard it, and not even between contemporary languages, but across a vast gulf of time which has resulted in many subtle changes of meaning that are lost of modern translators. Second, the old testament also suffers from the ambiguity of written Hebrew, which omits the vowels from words.
This is all after things have been written down, but it was much worse when only an oral tradition existed.
Have you ever played Chinese whispers? The error rate with even a trivial sentence is enormous, even if the experiment is performed in seconds, so that everyone's memory of the phrase is fresh. Now try to imagine how this would go across 1000 generations of people, each one waiting 3-20 years to pass on some knowledge to their descendants. Factor in the slowly changing nature of language, errors in memory, embellishments to make stories sound more interesting, individuals adding their own personal opinion, deliberate dissent from the status quo, or whatever...
Even if somehow, magically, some facts were correctly passed down for thousands of years, across many generations, languages, places, and peoples... you'd have no way of knowing that the process was successful! You couldn't tell which fact was still true, and what had become distorted, or embellished, or plain false. There is absolutely no way to differentiate between lies and truth based on age or authority alone.
There is an inherent risk in all power generation technologies -- just about the truly safe power generation method is solar, but that's not practical everywhere, and has only been cost-effective recently.
All other methods kill people. Coal kills thousands a year directly, tens of thousands indirectly. Oil kills people -- think oil rig fires, accidents, wars over oil, etc... Natural gas isn't fantastic either, producing it is just as dangerous as drilling for oil, it just pollutes somewhat less. Even wind power has the occasional industrial accident, mechanics falling off the tall towers, getting electrocuted, or whatever.
We aren't better off without power either -- the availability of cheap energy enables fertilizers, medicines, and heating -- without which we'd starve, get diseased, or freeze. Manufacturing of all modern goods requires electricity, and we need manufactured goods to live! There's too many of us now to survive without tools, machines, and automation.
Essentially, it's a tradeoff: one thing that kills people vs another source of death. We just pick the one that's better overall. In that sense, nuclear power is a very good trade: it's killed something like 40 people directly in its entire history, and no more than a few thousand indirectly, mostly from one accident at a poorly-managed old plant. Nuclear material from Fukushima has killed 0 people so far.
For contrast, the construction of the Hoover dam has claimed 112 lives, but you'd be hard pressed to find people who think that it was a bad idea to build it.
NVIDIA and AMD should implement this and related algorithms for their LCD upscaling!
The algorithm looks like it could be parallelized onto the GPU easily enough, and doing it transparently at the video card driver level would enable PC gamers to play classic games on large LCDs without the thumbnail sized pixels.
Just imagine what this scaling algorithm could do for classic low-res games like Diablo.
This is why closed-source sucks... I'd have done it myself by now if I had access to the AMD GPU Windows driver source code!
But isn't that result for just a single layer made as a test?
The trick with capacitors is making them in bulk, not just coming up with some material that could only be used if we also invent atomic-scale fabrication at the same time!
From what I've read, the amazing thing about tantalum capacitors wasn't that tantalum is such a wonderful electronic material, but that it was trivial to manufacture a large surface area of flaw-free oxide in a block of compressed tantalum powder.
No scientist ever said anything along those lines. Political pundits, shills, brainless TV presenters, or lobbyists maybe, but no scientist.
The cause was CFCs, the fix was to stop using them, the fix has now been demonstrated to be effective, precisely at the predicted rate.
The result doesn't make science look bad, it makes you look like an idiot for not even bothering to understand the most basic aspects of the second biggest global man-made environmental disaster after global warming.
Next thing, you'll be telling us how global warming is also BS, and not to trust those crazy lab-coat wearing geeks for telling us that we all had monkeys for grandparents.
I've got a similar issue, but with old business applications instead of games.
I have clients that are still running 16-bit DOS applications for thousands of users (don't ask), and are having real trouble with them because support for 32-bit operating systems is slowly but surely disappearing. For example, terminal services requires "Server" editions of Windows, but since 2008 R2, there are no more 32-bit editions, and the 64-bit editions cannot run 16-bit applications at all.
I've been looking for a DOS emulator for 64-bit Windows with decent performance that has the same (or similar) features as the emulation in 32-bit Windows editions, such as cut & paste, transparent access drives, etc...
The DOS emulators designed for games behave more like VMware: they emulate a physical machine with peripherals. What I'm looking for is more of a backwards-compatibility layer like the NTVDM system that can be found in 32-bit editions of Windows, but capable of running under a 64-bit OS.
The green folks are pretty clear on what they want to see: widespread use of wind and solar power.
Except that they are both inefficient in terms of land area use, and are only really usable for countries with large amounts of unused land and few overcast days per year. Nordic countries are out of luck too, they don't get enough sunlight for much of the year.
I've seen an analysis that basically demonstrated that with any type of renewable green power that's based on sunlight, Great Britain would basically have to pave over half their countryside to meet their current energy needs, let alone future growth!
The economic numbers aren't all that fantastic either, which is why investment has been low. For example, lets just do a bit of computation based on some web sources: "The costs for a commercial scale wind turbine in 2007 ranged from $1.2 million to $2.6 million, per MW of nameplate capacity installed.", combined with "On average then, a typical onshore turbine in the UK, rated at 2 MW, produces 5.3 million units of electricity each year. This is equivalent to 5,256 MWh or 5.3 GWh.". Here in Australia, coal-based electricity is particularly cheap, at $50/MWh. This works out to a 2 MW turbine costing $2.4M-$5.2M for the hardware alone, but generating only $250K per year. In other words, at best, it'll be 10-20 years to pay off the capital cost. Then you have to add interest payments, land usage cost, profits, tax, and maintenance fees. I suspect few if any wind farms pay off faster than 30 years, and possibly 50+ in many cases!
This irony is that energy costs a lot more in Great Britain, but they don't have the land area to go green. Meanwhile, here in Australia where we have huge tracts of uninhabited land with uninterrupted sunlight, energy is cheap.
It may not be needed this instant, but there's no such thing as too much bandwidth. Just off the top of my head, I can think a whole bunch of reasons one would want terabit Ethernet:
- For High Performance Computing and Database Replication -- both of these can result in systems that have performance that is almost entirely limited by the network, or very careful (expensive) programming is required to work around the network. Think about Google's replication bandwidth requirements between data centers! Cloud computing providers will have similar problems. - Latency sensitive computing -- n-Tier applications like SAP have CPUs waiting for the network an awful lot. Users have to put up with multi-second response times because of the chattiness of the RPC protocols between the layers. Faster networks have lower latency, and when microseconds count, there's no such thing as too much bandwidth, even if the bandwidth isn't utilized. - Converged Networking -- lots of people are merging their Ethernet and Storage (FC) networks, using iSCSI or FCoE. Fibre is already at 8Gbps, and SSD disks are going to create a situation where the disks have many times the speed of the interconnect. Note that bandwidth goes up as the IO response times drop, and we're about to see a drop from ~3ms for 15K RPM disks to under 1 microsecond for next-gen enterprise SSDs! SAN vendors are going to want 100Gbps ports soon, which implies 1Tbps aggregation ports. - Bladesystems -- even today, a chassis can take 12-16 blades, each of which has 20 cores at around 3 Ghz. That's the equivalent of 1THz of aggregate computer power! The uplinks can become bottlenecks, especially when they are used for both storage and data. - Movie and TV Studios -- there are digital movie cameras just around the corner that can capture 260Mpixel images at 24fps. That's something like 300Gbps if transmitted uncompressed! Throw in stereo, multiple angles, and then 1Tbps starts to sound like a good idea. - On-Demand TV -- the aggregate bandwidth requirements of millions of households watching 4 hours of TV a day is just insane. Even with clever replication and multicast technologies, serious bandwidth is required to enable everyone to watch whatever they want, whenever they want.
Remember that networking is more or less fungible -- interconnects are all about moving bits about. At least in principle, almost any data cable could be replaced by Ethernet, or any similar technology. This 'unification' of networking is an ongoing process: Thunderbolt merged PCI-e and DisplayPort, Ethernet is starting to replace Fibre Channel, USB has eliminated a whole bunch of ports and cables, etc...
With that in mind, think of 1Tbps Ethernet not as something you'd plug a file server into, but as the interconnect between core switches for metro networks that feed 1Gbps into every house, or the campus uplinks for when 10Gbps to the workstations becomes reasonably common, or a link used by dozens of specialists to perform telepresense surgeries around the country from one central location, or things we haven't even thought of yet...
I'm a programmer-slash-sysadmin, and I've taken a stab at writing both command-line tools using C/C++,.NET, and these days with PowerShell, so I might be able to answer your question.
When I write complex software, I usually provide some command-line tools for the admins to do things like import data, export logs, or whatever. This is a royal pain in the ass, but I do it because it's useful. I always end up spending something like 80% of the time on annoying stuff like handling command-line parameters, input validation, and error messages. Of course, because whatever I come up with is new and different, I have to write doco for it, train staff, and so on.
Now, with PowerShell, instead of having to write a whole new program to implement a command, I can simply extend a class from a framework library. The PS framework does almost everything automagically: handle the pipeline, input parameters, parameter validation, parameter sets, optional parameters, help, tab-complete, wildcard matching, output formatting, etc...
To give you an idea, it is possible to write a PowerShell command in C# (.NET) with several parameters and complex output that does a useful task in about 50 lines of rather trivial code. The equivalent C program would be thousands of lines.
More importantly, the resulting PowerShell command will be orthogonal, consistent, discoverable, and embeddable
By orthogonal, I mean things like: every PS command that handles wildcards does it with the same shared library, which is trivial to use. Hence, I can do things like: Get-VM "prod_win_[a-k]*" which is a VMware snapin, and the behavior will be exactly the same as if I had called a Citrix XenApp snapin to lists farm servers with: Get-XAServer "prod_win_[a-k]*". Similarly, the output of commands is structured data. You can say: Get-VM | Export-CSV or Get-XAServer | Export-Csv and get similar results. Compare with legacy command line tools, which often implement such formatting internally, and badly. I just had to work on some Novell systems, for example, which export invalid XML files because the utility doesn't escape ampersands! Of course, our example 50 line command will get all of that. Export to CSV? You have it! Export to XML? Done! Quickly, tell me how to export CSV formatted data from the following 3 Linux command-line tools: 'ls', 'apt-get', and 'ps'.
By consistent, I mean that parameters are always specified with "-param", never "/param", or "--param", or "-abcdgh" where each letter does something that you can only determine by reading a five page document. Similarly, Microsoft has established a strict naming system for developers, so that instead of "retrieve-foo", "ask-foo", "query-foo", "request-foo", "list-foo", "foo-list", "fooenum", or god knows what else, the only acceptable standard is "get-foo". VMware has "Get-VM", Citrix has "Get-XAServer", Microsoft has "Get-Process", etc... no guessing! There are standards for command names, parameter names, and coding conventions. E.g.: Verb Naming Rules, and Cmdlet Development Guidelines.
By discoverable, I mean that if I write a little 50-line utility with a bunch of parameters, an administrator at the command line can simply press 'tab' and have both the command and the parameter names automatically completed. The help is automatically generated from my 50 lines of code. GUI script wizards can load a bunch of metadata about each parameter to enable drag & drop script development.
By embeddable, I mean that even a 50-line utility can be called not just from the shell, but from within a hosting application in the same process. Instead of having to handle text-based streams, PS commands take.NET objects, and return.NET objects. There's no guessw
He was asking about Windows server administration, and PowerShell is the right way to do that.
For most new Microsoft server products, the script bindings are only available for PowerShell (in the form of snapins or modules). Many third-party vendors are releasing products that are PowerShell only. It is also the only shell that can call all mainstream APIs (COM, WMI, WinRM, and.NET).
Perl specifically is one of the worst possible options for Windows scripting. It is a text processing scripting language designed for Linux, where most applications and even system APIs are text based. Windows mostly uses object-oriented binary APIs. Very few Microsoft server products have text-based command-line tools that could be automated with Perl.
Suggesting Perl for Windows automation is a bit like trying to script Linux with VBScript. Does that sound like a good idea to you?
Essentially, for newer versions of Exchange and SharePoint, Powershell is the only scripting option, and is excellent. For older versions, you don't have a lot of options, but you can probably call COM APIs using PowerShell as well, but the effort is a lot higher. The APIs exposed by Exchange (e.g.: MAPI) are hideous. SharePoint can be managed via direct SQL database queries from anything, with some care.
For Windows servers in general, stick to PowerShell. It's by far the best shell/scripting language by a wide margin. There's a learning curve, but it's absolutely worth it. To get set up to an equivalent level to Bash+SSH:
- Install PS2 + WinRM2 on pre-2008 R2 servers. It's not installed by default, and 2008 comes with PS1. There's a hotfix that updates PowerShell and all associated components to v2 on XP, 2003, Vista, and 2008. - Enable unsigned scripts to run. Preventing.ps1 script files from running by default is a shit workaround for not having an execute bit, and is totally useless. Just turn it off. - Enable WinRM. This is the equivalent of SSH, but has to be enabled on both servers (which is obvious), and the clients (for no discernible reason). - Enable CredSSP. This improves WinRM by allowing delegated credentials to be used remotely. Unlike SSH, WinRM is an RPC protocol, and due to limitations of Windows authentication, the remote server cannot use network resources with the client's credentials (one hop security). The workaround is credentials delegation. This requires a server-side setting, and two client-side settings. - Install plugins. There are about a dozen that ship with Windows 2008 R2, a plugin for Exchange 2007 and 2010, and a plugin for Sharepoint. To set up the AD plugin on pre-2008 R2 domains, there's a module that has to be deployed, it's basically a web service that the PS plugin uses. The SQL plugin is an optional download that is particularly handy for SharePoint.
That seems like a lot, but can be done in seconds from the command-line, and even better, can be done completely automatically using Group Policy. For new server deployments, I ask for my servers to be created under an AD container, and I just set those options up in a common policy configured on that container, and then everything just works.
The equivalent of a remote SSH session in: Enter-PSSession 'computername'
However, it gets better: You can create and store sessions in variables by creating them using New-PSSession. You can pipe objects into remote sessions and invoke commands on them, or arrays of them. In other words, a single line of code lets you invoke commands in bulk across farms of servers.
For example, as a Citrix XenApp admin, I often have to update machine policy across a farm. This is just two lines with PowerShell:
That will query the list of XenApp servers, extract the server names into an array, and invoke "gpupdate" in parallel across all of them using a temporary secure shell session.
There might be equivalent capabilities on Linux, but nothing on the Windows platform comes close to what you can do with PowerShell.
Those reactors are 45 year old technology, took a direct tsunami hit right after an earthquake that was in the top 3 worst ever recorded, exploded, caught fire, and resulted in a grand total of... zero deaths.
Meanwhile, all other forms of cost-effective power generation are much more dangerous, killing far more people than nuclear technology, even including nuclear bombs! For example, the worst dam failure of all time, the Banqiao Dam killed 171K people, about the same number that were killed by the atomic bombs dropped on Hiroshima and Nagasaki combined.
The worst nuclear disaster of all time, Chernobyl, killed only 31 people. For comparison, that's about 0.5% of the deaths attributed to coal miningper year. The United States coal mining industry alone has about the same number of deaths per year as the total deaths due to nuclear power, ever. That number by the way is 40 people. That's like... 3 per decade.
Also, people generally forget that accidents aren't the only source of deaths related to power generation. The United States has gone to war multiple times to protect their interests in oil, leading to several hundred thousand more deaths.
For some reason, people are terrified of the safest form of power generation that is in common use, but have no problem with the US military using Uranium bullets to shoot Iraqi citizens by their thousands.
Also, each cell write is much faster (because it can be "sloppier" with only two states per cell), which greatly affects random write speeds even if the speeds are the same for sequential writes. And random writes is often a bottleneck in master databases.
I hear this come up every time even though existing SSDs, both MLC and SLC, already run circles around hard drives for both random read and random write performance.
I have an old SSD in my laptop that can outperform a very expensive SAN array for database workloads -- I've tested it with the same database and the same query side-by-side with the 16-core production database server with a 48-spindle LUN behind it, and my laptop won every time.
Stop quoting stuff that was barely true for some first-generation drives. The latest stuff is faster than a spinning disk at everything, often by orders of magnitude.
startups need the type of coders who know how to do solve certain problems without the automatic processing.NET offers.
No they don't! Startups are not there to educate their staff, that's what schools are for. Startups, more than any other kind of company, are there to write a marketable product quickly and cheaply.
Look at IntelliJ IDEA, which was written just like that: A bunch of smart guys sat down a wrote a fantastic IDE with far more features than you'd ever find in anything else at the time exactly because they used a high-level language that saved them a bunch of time. By avoiding C++, where a single API call can be upwards of 2 pages of code, they used Java, and concentrated on the fancy algorithms that made their product special, and worth money.
What kind of business manager wants to hire time wasters on-purpose?
Would you automatically get billed $250 just because somebody decided to send you a bunch of messages, even though you didn't want to receive them?
In a word? Yes.
In every country I've been in, telco and ISP companies are the only entities allowed to charge unlimited amounts of money for a service that you aren't even aware you are using. Here in Australia, there's been lots of horror stories of kids watching youtube videos, and then the next monthly bill on the "$25/mo" plan is $40,000! I've had this kind of thing happen to a friend, she had a bill arrive for 1 month that was bigger than her life savings.
There was a point here in Australia where Telstra had a cable plan where you could exceed your monthly quota in about 40 minutes, and subsequent to that, every hour would cost you about $5000. That's more than the most expensive prostitute, or the most expensive lawyer you can hire as an individual. In other words, they've found a way to make the Internet not the best source for porn, and cheaper to sue them than pay the bill!
What do politicians do about this? Nothing. Absolutely nothing. They're not even aware that there's a problem with companies being allowed to hold their customer to ransom, bankrupt them, and ruin their credit rating. Yet, we keep voting them into power, and they keep getting fat checks from corporations.
Once the benefits of going into space outweigh the costs, _everyone_ will be doing it, and we'll be worried about unregulated access in space.
What benefits?
No really, I want to hear what these supposed benefits are. I hear a lot of discussion about "reducing costs", and "thresholds", and "privatization of space", all with a supposed long-term goal of colonization or private enterprise, but I just don't see what everyone is going to be doing up there, except perhaps tourism.
You know what space contains? Cold rocks in a vacuum. What's so exciting about that that we should be spending trillions to make it more accessible to everyone? We have cold rocks here! Sure, they're not in a vacuum, but I don't see how that's not better!
There's no resource in space that is not available here, on Earth, at a vastly lower price point. There is no territory in space that is more cost effective to inhabit than any existing uninhabited area on Earth. There is nothing special or magic about any location in space within a 50 light year radius that would allow any industrial activity that cannot be performed terrestrially or in low earth orbit.
Ignoring a small tourism industry "it was fun but I wouldn't want to live there", and the possible novelty factor that might attract the ultra rich, there really isn't anything of interest up there.
We'd have to discover either intelligent alien life AND faster-than-light travel, OR find unobtanium to make serious space colonization, travel, or industry worth it. Without those we'll never do anything except tourism, scientific research, and low-earth orbit satellite launches. There's just no point.
Everybody who knows anything about SSDs knows that they have significantly more raw storage than logical capacity, and that the extra storage capacity is used for redundancy. Because of the wear levelling systems used, writes don't go back to the same place, so data can't be overwritten. This has been well known and obvious to everyone for years.
Pro Tip: Full Disk Encryption. Problem. Fucking. Solved.
You do realize that "more advanced" graphics isn't just about upping the polygon count, right?
Crysis was not just the most technically advanced game of its time, but also had fantastic art direction. While the first half was set in a fairly generic location, the second half made my jaw drop. The interior of the spaceship was more impressive than any science fiction movie I had ever seen, but was rendered in real time. That's the kind of achievement that should have netted these guys the a "PC Gaming Academy Award" or something.
I upgraded my PC specifically for Crysis, and it was worth it. I wasn't the only one.
NTFS still doesn't have shared cluster filesystem capability. This has a bunch of flow-on effects, which basically means that Windows Server clusters are actually "Failover Clusters". The key part of that being the "Fail".
Really basic services like the file shares are impossible to make truly highly available using Windows, because neither NTFS nor SMB support transparent fail-over of open files. There isn't even a way of doing a clean administrative cluster fail-over, such as a drain-stop. The only option is forcibly closing all open files, potentially corrupting user data, and forcing users to click through dirty error messages that their PCs may or may not recover from.
I've tried things like Polyserve, which is a third-party filesystem that has proper cluster support, but it's still hamstrung by SMB. What's doubly ridiculous is that Microsoft basically re-engineered SMB for Vista, and called it "SMB2", but it still can't do clean fail-over!
Similarly, SQL Server can't do proper failover of cluster nodes, nor can it do proper active-active database clusters that share a single database file, because of the limitations of the underlying filesystem. It can no active-active clustering for read-only files, but that's only rarely useful.
Even within Microsoft, workarounds had to be found to make some of their key products somewhat resilient. Both SQL Server and Exchange now use software mirroring for cleaner failover. Ignoring the cost of having to purchase twice as much disk, mirroring has other issues too, like becoming bottle-necked by the network speed, or limiting the features that can be used. For example, if your application performs queries across two databases in a single query, then you can't use Mirroring, because there's no way to specify that the two databases should fail over in a group.
VMware has become a multi-billion dollar company in a few short years because a single non-clustered Windows Server on a VMware cluster is more robust than a cluster of Windows Servers!
There's a historical reason why SSL is not more common: because the hierarchy of certificate trust was not propagated through the hierarchy of DNS. That's the logical thing to do: If you control the domain name servers for your own domain, you can publish your own public keys. It would have been free and open, reducing the barrier of entry to practically zero. Instead, administrators have been forced to establish the relationship between certificates and DNS names using a commercial third party. Instead of extending the DNS protocol, we pay people to perform a workaround.
This was a huge mistake that basically led to companies like Verisign extorting billions of dollars in exchange for permitting web administrators to encrypt traffic to their sites. What's brilliant is that Verisign owns a significant chunk of the root DNS name servers! It's a conflict of interest for them to enable a free and open hierarchy of trust based on DNS, because it would eliminate most of their business overnight.
That, right there, is corporate corruption on a billion dollar scale that is directly detrimental to human rights, privacy, and information safety.
I wonder how many people have been executed or imprisoned due to Verisign's stifling of internet cryptography enabling corrupt governments to spy on their citizens?
Windows 7 went RTM in July 2009, that article is from January, 2010.
Microsoft just pretended that the latest.NET version was 3.5 SP1 during the entire Windows 7 beta, and even for a while after RTM, even though they were shipping a new point release with breaking changes in it!
Windows 7 has the.NET framework built-in, with a version number of 3.5.1, which was an undocumented stealth release. Microsoft's website made no mention of it, Visual Studio could not target it or verify compatibility for it. It seemed to be almost identical to 3.5 SP1, except that it broke VMware Virtual Centre. The issue was a subtle change with the way self-signed cryptographic certificates were verified, and hence probably didn't affect any other application.
This was right around the time that Microsoft had released Hyper-V, and was desperately trying to be relevant in the market next to the vastly superior VMware vSphere product suite. I might just be imagining a conspiracy theory where none exists, but introducing a small API change to break a competitor's product is exactly the kind of underhanded thing Microsoft has done in the past.
This comes up all the time, and has been disproved decades ago.
I don't know what the official term for it is, but I call the solution to these "irreducible complexity" arguments the "A B C evolution sequence":
Lets say a scientist looks at a modern organism and sees that the organism has a complex organ or chemical system, or whatever, made of two parts, B and C. Neither B, nor C will work individually. How did this evolve?
The explanation is that the organism originally had a much simpler organ, or chemical, or whatever. Call it 'A'. At some point, a variant evolved that had an enhancement added to A, call it B. Now, B doesn't work by itself, but A does. Together, A & B are better than A alone. At some later point, A gets a mutation, and becomes 'C', which doesn't work by itself, but works together with B. So now you have B & C, neither of which work together, yet it was possible for evolution to take "baby steps" to get to that point.
Practical examples have been investigated by scientists. I believe the canonical example of such a complex inter-dependent system are the proteins involved in blood clotting. A significant number are required, and the whole process fails without any one of them. Obviously, at some point, blood clotting was achieved with just one protein, which then become two, then three, and then the original protein was lost, etc... The evolutionary steps involved can be investigated by looking at the blood clotting proteins in related species, looking for the patterns and commonalities up the evolutionary tree.
Slashdot Mirror
This strange world view is held by lots of people, and I've never quite understood why.
First of all, the 'written record' has been translated at least twice before you've heard it, and not even between contemporary languages, but across a vast gulf of time which has resulted in many subtle changes of meaning that are lost of modern translators. Second, the old testament also suffers from the ambiguity of written Hebrew, which omits the vowels from words.
This is all after things have been written down, but it was much worse when only an oral tradition existed.
Have you ever played Chinese whispers? The error rate with even a trivial sentence is enormous, even if the experiment is performed in seconds, so that everyone's memory of the phrase is fresh. Now try to imagine how this would go across 1000 generations of people, each one waiting 3-20 years to pass on some knowledge to their descendants. Factor in the slowly changing nature of language, errors in memory, embellishments to make stories sound more interesting, individuals adding their own personal opinion, deliberate dissent from the status quo, or whatever...
Even if somehow, magically, some facts were correctly passed down for thousands of years, across many generations, languages, places, and peoples... you'd have no way of knowing that the process was successful! You couldn't tell which fact was still true, and what had become distorted, or embellished, or plain false. There is absolutely no way to differentiate between lies and truth based on age or authority alone.
For comparison, the science and facts you denigrate has dragged us out of the dark ages, and made it possible to bring people back from the dead, grant sight to the blind, and cure leprosy.
Common sense, but wrong.
There is an inherent risk in all power generation technologies -- just about the truly safe power generation method is solar, but that's not practical everywhere, and has only been cost-effective recently.
All other methods kill people. Coal kills thousands a year directly, tens of thousands indirectly. Oil kills people -- think oil rig fires, accidents, wars over oil, etc... Natural gas isn't fantastic either, producing it is just as dangerous as drilling for oil, it just pollutes somewhat less. Even wind power has the occasional industrial accident, mechanics falling off the tall towers, getting electrocuted, or whatever.
We aren't better off without power either -- the availability of cheap energy enables fertilizers, medicines, and heating -- without which we'd starve, get diseased, or freeze. Manufacturing of all modern goods requires electricity, and we need manufactured goods to live! There's too many of us now to survive without tools, machines, and automation.
Essentially, it's a tradeoff: one thing that kills people vs another source of death. We just pick the one that's better overall. In that sense, nuclear power is a very good trade: it's killed something like 40 people directly in its entire history, and no more than a few thousand indirectly, mostly from one accident at a poorly-managed old plant. Nuclear material from Fukushima has killed 0 people so far.
For contrast, the construction of the Hoover dam has claimed 112 lives, but you'd be hard pressed to find people who think that it was a bad idea to build it.
NVIDIA and AMD should implement this and related algorithms for their LCD upscaling!
The algorithm looks like it could be parallelized onto the GPU easily enough, and doing it transparently at the video card driver level would enable PC gamers to play classic games on large LCDs without the thumbnail sized pixels.
Just imagine what this scaling algorithm could do for classic low-res games like Diablo.
This is why closed-source sucks... I'd have done it myself by now if I had access to the AMD GPU Windows driver source code!
But isn't that result for just a single layer made as a test?
The trick with capacitors is making them in bulk, not just coming up with some material that could only be used if we also invent atomic-scale fabrication at the same time!
From what I've read, the amazing thing about tantalum capacitors wasn't that tantalum is such a wonderful electronic material, but that it was trivial to manufacture a large surface area of flaw-free oxide in a block of compressed tantalum powder.
No scientist ever said anything along those lines. Political pundits, shills, brainless TV presenters, or lobbyists maybe, but no scientist.
The cause was CFCs, the fix was to stop using them, the fix has now been demonstrated to be effective, precisely at the predicted rate.
The result doesn't make science look bad, it makes you look like an idiot for not even bothering to understand the most basic aspects of the second biggest global man-made environmental disaster after global warming.
Next thing, you'll be telling us how global warming is also BS, and not to trust those crazy lab-coat wearing geeks for telling us that we all had monkeys for grandparents.
I've got a similar issue, but with old business applications instead of games.
I have clients that are still running 16-bit DOS applications for thousands of users (don't ask), and are having real trouble with them because support for 32-bit operating systems is slowly but surely disappearing. For example, terminal services requires "Server" editions of Windows, but since 2008 R2, there are no more 32-bit editions, and the 64-bit editions cannot run 16-bit applications at all.
I've been looking for a DOS emulator for 64-bit Windows with decent performance that has the same (or similar) features as the emulation in 32-bit Windows editions, such as cut & paste, transparent access drives, etc...
The DOS emulators designed for games behave more like VMware: they emulate a physical machine with peripherals. What I'm looking for is more of a backwards-compatibility layer like the NTVDM system that can be found in 32-bit editions of Windows, but capable of running under a 64-bit OS.
Anyone here know of something like that?
The green folks are pretty clear on what they want to see: widespread use of wind and solar power.
Except that they are both inefficient in terms of land area use, and are only really usable for countries with large amounts of unused land and few overcast days per year. Nordic countries are out of luck too, they don't get enough sunlight for much of the year.
I've seen an analysis that basically demonstrated that with any type of renewable green power that's based on sunlight, Great Britain would basically have to pave over half their countryside to meet their current energy needs, let alone future growth!
The economic numbers aren't all that fantastic either, which is why investment has been low. For example, lets just do a bit of computation based on some web sources: "The costs for a commercial scale wind turbine in 2007 ranged from $1.2 million to $2.6 million, per MW of nameplate capacity installed.", combined with "On average then, a typical onshore turbine in the UK, rated at 2 MW, produces 5.3 million units of electricity each year. This is equivalent to 5,256 MWh or 5.3 GWh.". Here in Australia, coal-based electricity is particularly cheap, at $50/MWh. This works out to a 2 MW turbine costing $2.4M-$5.2M for the hardware alone, but generating only $250K per year. In other words, at best, it'll be 10-20 years to pay off the capital cost. Then you have to add interest payments, land usage cost, profits, tax, and maintenance fees. I suspect few if any wind farms pay off faster than 30 years, and possibly 50+ in many cases!
This irony is that energy costs a lot more in Great Britain, but they don't have the land area to go green. Meanwhile, here in Australia where we have huge tracts of uninhabited land with uninterrupted sunlight, energy is cheap.
It may not be needed this instant, but there's no such thing as too much bandwidth. Just off the top of my head, I can think a whole bunch of reasons one would want terabit Ethernet:
- For High Performance Computing and Database Replication -- both of these can result in systems that have performance that is almost entirely limited by the network, or very careful (expensive) programming is required to work around the network. Think about Google's replication bandwidth requirements between data centers! Cloud computing providers will have similar problems.
- Latency sensitive computing -- n-Tier applications like SAP have CPUs waiting for the network an awful lot. Users have to put up with multi-second response times because of the chattiness of the RPC protocols between the layers. Faster networks have lower latency, and when microseconds count, there's no such thing as too much bandwidth, even if the bandwidth isn't utilized.
- Converged Networking -- lots of people are merging their Ethernet and Storage (FC) networks, using iSCSI or FCoE. Fibre is already at 8Gbps, and SSD disks are going to create a situation where the disks have many times the speed of the interconnect. Note that bandwidth goes up as the IO response times drop, and we're about to see a drop from ~3ms for 15K RPM disks to under 1 microsecond for next-gen enterprise SSDs! SAN vendors are going to want 100Gbps ports soon, which implies 1Tbps aggregation ports.
- Bladesystems -- even today, a chassis can take 12-16 blades, each of which has 20 cores at around 3 Ghz. That's the equivalent of 1THz of aggregate computer power! The uplinks can become bottlenecks, especially when they are used for both storage and data.
- Movie and TV Studios -- there are digital movie cameras just around the corner that can capture 260Mpixel images at 24fps. That's something like 300Gbps if transmitted uncompressed! Throw in stereo, multiple angles, and then 1Tbps starts to sound like a good idea.
- On-Demand TV -- the aggregate bandwidth requirements of millions of households watching 4 hours of TV a day is just insane. Even with clever replication and multicast technologies, serious bandwidth is required to enable everyone to watch whatever they want, whenever they want.
Remember that networking is more or less fungible -- interconnects are all about moving bits about. At least in principle, almost any data cable could be replaced by Ethernet, or any similar technology. This 'unification' of networking is an ongoing process: Thunderbolt merged PCI-e and DisplayPort, Ethernet is starting to replace Fibre Channel, USB has eliminated a whole bunch of ports and cables, etc...
With that in mind, think of 1Tbps Ethernet not as something you'd plug a file server into, but as the interconnect between core switches for metro networks that feed 1Gbps into every house, or the campus uplinks for when 10Gbps to the workstations becomes reasonably common, or a link used by dozens of specialists to perform telepresense surgeries around the country from one central location, or things we haven't even thought of yet...
I'm a programmer-slash-sysadmin, and I've taken a stab at writing both command-line tools using C/C++, .NET, and these days with PowerShell, so I might be able to answer your question.
When I write complex software, I usually provide some command-line tools for the admins to do things like import data, export logs, or whatever. This is a royal pain in the ass, but I do it because it's useful. I always end up spending something like 80% of the time on annoying stuff like handling command-line parameters, input validation, and error messages. Of course, because whatever I come up with is new and different, I have to write doco for it, train staff, and so on.
Now, with PowerShell, instead of having to write a whole new program to implement a command, I can simply extend a class from a framework library. The PS framework does almost everything automagically: handle the pipeline, input parameters, parameter validation, parameter sets, optional parameters, help, tab-complete, wildcard matching, output formatting, etc...
To give you an idea, it is possible to write a PowerShell command in C# (.NET) with several parameters and complex output that does a useful task in about 50 lines of rather trivial code. The equivalent C program would be thousands of lines.
More importantly, the resulting PowerShell command will be orthogonal, consistent, discoverable, and embeddable
By orthogonal, I mean things like: every PS command that handles wildcards does it with the same shared library, which is trivial to use. Hence, I can do things like: Get-VM "prod_win_[a-k]*" which is a VMware snapin, and the behavior will be exactly the same as if I had called a Citrix XenApp snapin to lists farm servers with: Get-XAServer "prod_win_[a-k]*". Similarly, the output of commands is structured data. You can say: Get-VM | Export-CSV or Get-XAServer | Export-Csv and get similar results. Compare with legacy command line tools, which often implement such formatting internally, and badly. I just had to work on some Novell systems, for example, which export invalid XML files because the utility doesn't escape ampersands! Of course, our example 50 line command will get all of that. Export to CSV? You have it! Export to XML? Done! Quickly, tell me how to export CSV formatted data from the following 3 Linux command-line tools: 'ls', 'apt-get', and 'ps'.
By consistent, I mean that parameters are always specified with "-param", never "/param", or "--param", or "-abcdgh" where each letter does something that you can only determine by reading a five page document. Similarly, Microsoft has established a strict naming system for developers, so that instead of "retrieve-foo", "ask-foo", "query-foo", "request-foo", "list-foo", "foo-list", "fooenum", or god knows what else, the only acceptable standard is "get-foo". VMware has "Get-VM", Citrix has "Get-XAServer", Microsoft has "Get-Process", etc... no guessing! There are standards for command names, parameter names, and coding conventions. E.g.: Verb Naming Rules, and Cmdlet Development Guidelines.
By discoverable, I mean that if I write a little 50-line utility with a bunch of parameters, an administrator at the command line can simply press 'tab' and have both the command and the parameter names automatically completed. The help is automatically generated from my 50 lines of code. GUI script wizards can load a bunch of metadata about each parameter to enable drag & drop script development.
By embeddable, I mean that even a 50-line utility can be called not just from the shell, but from within a hosting application in the same process. Instead of having to handle text-based streams, PS commands take .NET objects, and return .NET objects. There's no guessw
When in Rome, do as the Romans do.
He was asking about Windows server administration, and PowerShell is the right way to do that.
For most new Microsoft server products, the script bindings are only available for PowerShell (in the form of snapins or modules). Many third-party vendors are releasing products that are PowerShell only. It is also the only shell that can call all mainstream APIs (COM, WMI, WinRM, and .NET).
Perl specifically is one of the worst possible options for Windows scripting. It is a text processing scripting language designed for Linux, where most applications and even system APIs are text based. Windows mostly uses object-oriented binary APIs. Very few Microsoft server products have text-based command-line tools that could be automated with Perl.
Suggesting Perl for Windows automation is a bit like trying to script Linux with VBScript. Does that sound like a good idea to you?
Essentially, for newer versions of Exchange and SharePoint, Powershell is the only scripting option, and is excellent. For older versions, you don't have a lot of options, but you can probably call COM APIs using PowerShell as well, but the effort is a lot higher. The APIs exposed by Exchange (e.g.: MAPI) are hideous. SharePoint can be managed via direct SQL database queries from anything, with some care.
For Windows servers in general, stick to PowerShell. It's by far the best shell/scripting language by a wide margin. There's a learning curve, but it's absolutely worth it. To get set up to an equivalent level to Bash+SSH:
- Install PS2 + WinRM2 on pre-2008 R2 servers. It's not installed by default, and 2008 comes with PS1. There's a hotfix that updates PowerShell and all associated components to v2 on XP, 2003, Vista, and 2008. .ps1 script files from running by default is a shit workaround for not having an execute bit, and is totally useless. Just turn it off.
- Enable unsigned scripts to run. Preventing
- Enable WinRM. This is the equivalent of SSH, but has to be enabled on both servers (which is obvious), and the clients (for no discernible reason).
- Enable CredSSP. This improves WinRM by allowing delegated credentials to be used remotely. Unlike SSH, WinRM is an RPC protocol, and due to limitations of Windows authentication, the remote server cannot use network resources with the client's credentials (one hop security). The workaround is credentials delegation. This requires a server-side setting, and two client-side settings.
- Install plugins. There are about a dozen that ship with Windows 2008 R2, a plugin for Exchange 2007 and 2010, and a plugin for Sharepoint. To set up the AD plugin on pre-2008 R2 domains, there's a module that has to be deployed, it's basically a web service that the PS plugin uses. The SQL plugin is an optional download that is particularly handy for SharePoint.
That seems like a lot, but can be done in seconds from the command-line, and even better, can be done completely automatically using Group Policy. For new server deployments, I ask for my servers to be created under an AD container, and I just set those options up in a common policy configured on that container, and then everything just works.
The equivalent of a remote SSH session in: Enter-PSSession 'computername'
However, it gets better: You can create and store sessions in variables by creating them using New-PSSession. You can pipe objects into remote sessions and invoke commands on them, or arrays of them. In other words, a single line of code lets you invoke commands in bulk across farms of servers.
For example, as a Citrix XenApp admin, I often have to update machine policy across a farm. This is just two lines with PowerShell:
$xaservers = Get-XAServer | Select -ExpandProperty ServerName
Invoke-Command -CN $xaservers { gpupdate }
That will query the list of XenApp servers, extract the server names into an array, and invoke "gpupdate" in parallel across all of them using a temporary secure shell session.
There might be equivalent capabilities on Linux, but nothing on the Windows platform comes close to what you can do with PowerShell.
That's actually a good analogy!
Diablo is to Rougelikes as RTS games are to Chess.
Your sarcasm is ill deserved.
Those reactors are 45 year old technology, took a direct tsunami hit right after an earthquake that was in the top 3 worst ever recorded, exploded, caught fire, and resulted in a grand total of... zero deaths.
Meanwhile, all other forms of cost-effective power generation are much more dangerous, killing far more people than nuclear technology, even including nuclear bombs! For example, the worst dam failure of all time, the Banqiao Dam killed 171K people, about the same number that were killed by the atomic bombs dropped on Hiroshima and Nagasaki combined.
The worst nuclear disaster of all time, Chernobyl, killed only 31 people. For comparison, that's about 0.5% of the deaths attributed to coal mining per year. The United States coal mining industry alone has about the same number of deaths per year as the total deaths due to nuclear power, ever. That number by the way is 40 people. That's like... 3 per decade.
Also, people generally forget that accidents aren't the only source of deaths related to power generation. The United States has gone to war multiple times to protect their interests in oil, leading to several hundred thousand more deaths.
For some reason, people are terrified of the safest form of power generation that is in common use, but have no problem with the US military using Uranium bullets to shoot Iraqi citizens by their thousands.
Also, each cell write is much faster (because it can be "sloppier" with only two states per cell), which greatly affects random write speeds even if the speeds are the same for sequential writes.
And random writes is often a bottleneck in master databases.
I hear this come up every time even though existing SSDs, both MLC and SLC, already run circles around hard drives for both random read and random write performance.
I have an old SSD in my laptop that can outperform a very expensive SAN array for database workloads -- I've tested it with the same database and the same query side-by-side with the 16-core production database server with a 48-spindle LUN behind it, and my laptop won every time.
Stop quoting stuff that was barely true for some first-generation drives. The latest stuff is faster than a spinning disk at everything, often by orders of magnitude.
startups need the type of coders who know how to do solve certain problems without the automatic processing .NET offers.
No they don't! Startups are not there to educate their staff, that's what schools are for. Startups, more than any other kind of company, are there to write a marketable product quickly and cheaply.
Look at IntelliJ IDEA, which was written just like that: A bunch of smart guys sat down a wrote a fantastic IDE with far more features than you'd ever find in anything else at the time exactly because they used a high-level language that saved them a bunch of time. By avoiding C++, where a single API call can be upwards of 2 pages of code, they used Java, and concentrated on the fancy algorithms that made their product special, and worth money.
What kind of business manager wants to hire time wasters on-purpose?
Would you automatically get billed $250 just because somebody decided to send you a bunch of messages, even though you didn't want to receive them?
In a word? Yes.
In every country I've been in, telco and ISP companies are the only entities allowed to charge unlimited amounts of money for a service that you aren't even aware you are using. Here in Australia, there's been lots of horror stories of kids watching youtube videos, and then the next monthly bill on the "$25/mo" plan is $40,000! I've had this kind of thing happen to a friend, she had a bill arrive for 1 month that was bigger than her life savings.
There was a point here in Australia where Telstra had a cable plan where you could exceed your monthly quota in about 40 minutes, and subsequent to that, every hour would cost you about $5000. That's more than the most expensive prostitute, or the most expensive lawyer you can hire as an individual. In other words, they've found a way to make the Internet not the best source for porn, and cheaper to sue them than pay the bill!
What do politicians do about this? Nothing. Absolutely nothing. They're not even aware that there's a problem with companies being allowed to hold their customer to ransom, bankrupt them, and ruin their credit rating. Yet, we keep voting them into power, and they keep getting fat checks from corporations.
Move along citizen, move along...
Once the benefits of going into space outweigh the costs, _everyone_ will be doing it, and we'll be worried about unregulated access in space.
What benefits?
No really, I want to hear what these supposed benefits are. I hear a lot of discussion about "reducing costs", and "thresholds", and "privatization of space", all with a supposed long-term goal of colonization or private enterprise, but I just don't see what everyone is going to be doing up there, except perhaps tourism.
You know what space contains? Cold rocks in a vacuum. What's so exciting about that that we should be spending trillions to make it more accessible to everyone? We have cold rocks here! Sure, they're not in a vacuum, but I don't see how that's not better!
There's no resource in space that is not available here, on Earth, at a vastly lower price point. There is no territory in space that is more cost effective to inhabit than any existing uninhabited area on Earth. There is nothing special or magic about any location in space within a 50 light year radius that would allow any industrial activity that cannot be performed terrestrially or in low earth orbit.
Ignoring a small tourism industry "it was fun but I wouldn't want to live there", and the possible novelty factor that might attract the ultra rich, there really isn't anything of interest up there.
We'd have to discover either intelligent alien life AND faster-than-light travel, OR find unobtanium to make serious space colonization, travel, or industry worth it. Without those we'll never do anything except tourism, scientific research, and low-earth orbit satellite launches. There's just no point.
If I'm understanding you correctly, then the eight and ninth chevrons are just packet header extensions?
Why is Slashdot posting these inane articles?
Everybody who knows anything about SSDs knows that they have significantly more raw storage than logical capacity, and that the extra storage capacity is used for redundancy. Because of the wear levelling systems used, writes don't go back to the same place, so data can't be overwritten. This has been well known and obvious to everyone for years.
Pro Tip: Full Disk Encryption. Problem. Fucking. Solved.
Why are we even talking about this?
You do realize that "more advanced" graphics isn't just about upping the polygon count, right?
Crysis was not just the most technically advanced game of its time, but also had fantastic art direction. While the first half was set in a fairly generic location, the second half made my jaw drop. The interior of the spaceship was more impressive than any science fiction movie I had ever seen, but was rendered in real time. That's the kind of achievement that should have netted these guys the a "PC Gaming Academy Award" or something.
I upgraded my PC specifically for Crysis, and it was worth it. I wasn't the only one.
NTFS still doesn't have shared cluster filesystem capability. This has a bunch of flow-on effects, which basically means that Windows Server clusters are actually "Failover Clusters". The key part of that being the "Fail".
Really basic services like the file shares are impossible to make truly highly available using Windows, because neither NTFS nor SMB support transparent fail-over of open files. There isn't even a way of doing a clean administrative cluster fail-over, such as a drain-stop. The only option is forcibly closing all open files, potentially corrupting user data, and forcing users to click through dirty error messages that their PCs may or may not recover from.
I've tried things like Polyserve, which is a third-party filesystem that has proper cluster support, but it's still hamstrung by SMB. What's doubly ridiculous is that Microsoft basically re-engineered SMB for Vista, and called it "SMB2", but it still can't do clean fail-over!
Similarly, SQL Server can't do proper failover of cluster nodes, nor can it do proper active-active database clusters that share a single database file, because of the limitations of the underlying filesystem. It can no active-active clustering for read-only files, but that's only rarely useful.
Even within Microsoft, workarounds had to be found to make some of their key products somewhat resilient. Both SQL Server and Exchange now use software mirroring for cleaner failover. Ignoring the cost of having to purchase twice as much disk, mirroring has other issues too, like becoming bottle-necked by the network speed, or limiting the features that can be used. For example, if your application performs queries across two databases in a single query, then you can't use Mirroring, because there's no way to specify that the two databases should fail over in a group.
VMware has become a multi-billion dollar company in a few short years because a single non-clustered Windows Server on a VMware cluster is more robust than a cluster of Windows Servers!
"Enterprise Edition" my ass.
There's a historical reason why SSL is not more common: because the hierarchy of certificate trust was not propagated through the hierarchy of DNS. That's the logical thing to do: If you control the domain name servers for your own domain, you can publish your own public keys. It would have been free and open, reducing the barrier of entry to practically zero. Instead, administrators have been forced to establish the relationship between certificates and DNS names using a commercial third party. Instead of extending the DNS protocol, we pay people to perform a workaround.
This was a huge mistake that basically led to companies like Verisign extorting billions of dollars in exchange for permitting web administrators to encrypt traffic to their sites. What's brilliant is that Verisign owns a significant chunk of the root DNS name servers! It's a conflict of interest for them to enable a free and open hierarchy of trust based on DNS, because it would eliminate most of their business overnight.
That, right there, is corporate corruption on a billion dollar scale that is directly detrimental to human rights, privacy, and information safety.
I wonder how many people have been executed or imprisoned due to Verisign's stifling of internet cryptography enabling corrupt governments to spy on their citizens?
Windows 7 went RTM in July 2009, that article is from January, 2010.
Microsoft just pretended that the latest .NET version was 3.5 SP1 during the entire Windows 7 beta, and even for a while after RTM, even though they were shipping a new point release with breaking changes in it!
I wouldn't be surprised.
Windows 7 has the .NET framework built-in, with a version number of 3.5.1, which was an undocumented stealth release. Microsoft's website made no mention of it, Visual Studio could not target it or verify compatibility for it. It seemed to be almost identical to 3.5 SP1, except that it broke VMware Virtual Centre. The issue was a subtle change with the way self-signed cryptographic certificates were verified, and hence probably didn't affect any other application.
This was right around the time that Microsoft had released Hyper-V, and was desperately trying to be relevant in the market next to the vastly superior VMware vSphere product suite. I might just be imagining a conspiracy theory where none exists, but introducing a small API change to break a competitor's product is exactly the kind of underhanded thing Microsoft has done in the past.
This comes up all the time, and has been disproved decades ago.
I don't know what the official term for it is, but I call the solution to these "irreducible complexity" arguments the "A B C evolution sequence":
Lets say a scientist looks at a modern organism and sees that the organism has a complex organ or chemical system, or whatever, made of two parts, B and C. Neither B, nor C will work individually. How did this evolve?
The explanation is that the organism originally had a much simpler organ, or chemical, or whatever. Call it 'A'. At some point, a variant evolved that had an enhancement added to A, call it B. Now, B doesn't work by itself, but A does. Together, A & B are better than A alone. At some later point, A gets a mutation, and becomes 'C', which doesn't work by itself, but works together with B. So now you have B & C, neither of which work together, yet it was possible for evolution to take "baby steps" to get to that point.
Practical examples have been investigated by scientists. I believe the canonical example of such a complex inter-dependent system are the proteins involved in blood clotting. A significant number are required, and the whole process fails without any one of them. Obviously, at some point, blood clotting was achieved with just one protein, which then become two, then three, and then the original protein was lost, etc... The evolutionary steps involved can be investigated by looking at the blood clotting proteins in related species, looking for the patterns and commonalities up the evolutionary tree.
No God required.