If I remember correctly from seeing watching the tech talk on youtube about a year or so ago, the idea is not to produce a continuous, stable fusion reaction, but to produce an unstable reaction that lasts for only a moment. By creating reactions many times per second, substantial amounts of energy are produced. (Hopefully more than is needed to initiate the reactions in the first place.)
The device is in some ways similar to a spark plug.
Whoa... a spark plug from hell that could start the leviathan engines that power the forge of God.
Now only $29,999,999 from United Fusion Corp! Buy now!
I'm guessing that by better quality they mean materialistically. Being a US citizen I would prefer to live in a place where human rights are championed, personal liberty is maximized and freedom of speech and freedom from government oppression is paramount.
Unless someone is afraid of being randomly assaulted or imprisoned, then no one cares. It's human nature. Bread and circuses you know? I've been to China. It's not Mao's China, not at all.
So, I guess I'm saying where should I move to?
Canada?
Canada is cold. Come to Australia! I wore a T-Shirt through most of winter in Sydney, but we've got a couple of token mountains that see snow in the winter for people who like that kind of thing. 8)
For *any* kind of hosted service, having backups measures just slightly below "is it turned on" in terms of importance. And for a year and a half, NONE WERE DONE? Further, they did a major update to a SAN and didn't backup first?
That's not what happened... of course they were doing backups. Apparently the issue (still stupid, but slightly less so) is that a backup started *while* they were updating the SAN, so the backup got corrupted. And also stupid, apparently they didn't have a very recent backup of the backup...
That's not how backups work. You don't overwrite one set of media over and over, because during the backup itself, you have no backup. The absolute minimum number of copies is two, because then you still have one good backup while overwriting one set of media. Also, for backups to be useful, they usually need to be made at least daily.
What you described there is an asynchronous mirror, which is not that much protection. Secondly, from what I've seen happen during SAN upgrades, they first thing they do is disable all scheduled tasks, all mirrors, etc... Once the update has succeeded, then the engineer turns stuff back on one thing at a time. Doing an update while some major process is going on is insane.
Realistically, a hosted system like this should have some huge tape library, and dozens of copies going back at least a month or two, just in case there's a need to recover from ongoing data corruption. For the amount of data involved in this case, this is a relatively cheap and ordinary setup.
The real scary part of cloud hosting is that most of the really big hosts (Google, Amazon, etc...) can't afford 'proper' backups. They just mirror their data around a couple of times, and hope it's good enough. Read up on Google FS (GFS). They don't even replicate out of a data center yet, so if they lose a building from some disaster like an earthquake or fire, they'd lose hundreds of petabytes of data. That was acceptable for their web index, as they can always re-crawl the web, but I'm surprised they're doing hosting now with the same underlying technology.
In fact, it's common for the main conductors coming out of power plants to be made of pure sodium metal submerged in oil, due to the fact that sodium has a very, very high conductance at normal temperatures.
I can't imagine how that could possibly be true. Sodium is a poor conductor, several times worse than copper. The only three conductors in common industrial use are copper, aluminium where weight matters, or silver where the best possible conductivity is required.
You must have confused the liquid sodium cooling used in some nuclear reactors with the electrical generation going on at those plants. The sodium itself is only used to transport heat.
It gets worse. In 2007, Paul Vixie wrote an article in ACM Queue basically praising the vagueness of the DNS protocol specifications:
From this overview, it is possible to conclude that DNS is a poorly specified protocol, but that would be unfair and untrue. DNS was specified loosely, on purpose. This protocol design is a fine example of what M.A. Padlipsky meant by “descriptive rather than prescriptive” in his 1984 thriller, The Elements of Networking Style (Prentice Hall). Functional interoperability and ease of implementation were the goals of the DNS protocol specification, and from the relative ease with which DNS has grown from its petri dish into a world-devouring monster, it’s clear to me that those goals were met. A stronger document set would have eliminated some of the “gotchas” that DNS implementers face, but the essential and intentional looseness of the specification has to be seen as a strength rather than a weakness.
Correlation does not imply causation.
DNS didn't grow to be huge because it was designed loosely, it happened to grow big because coincidentally the Internet took off and become huge, and the Internet happened to use DNS. It would be a bit of a stretch to say that the Internet become the size it is today because one of the many underpinning protocols and standards was loosely specified.
The Internet could have used any number of alternate name lookup systems, and it would have grown to its current size just fine. The only element of DNS design that really helped at all was its hierarchical nature, which helped it scale.
I think the big failure here is that anyone is ever editing the file by hand. It should be created programatically and edited only with a tool so that an error like this can never happen. (Of course, other errors are possible; now you have to vet your code. But the tool need not be complex, and in fact should be small enough to be provable if you so desire.)
I agree, but I'll also be a monkey's uncle when free software is designed this way.
What does this failure have to do with free software? If anything, it should be easy.
Even if you have an open source DNS server that uses text files, a major DNS registrar should be automating the hell out of it. I'm struggling to think of a reason why you wouldn't generate all your DNS records from a database. The files aren't that complicated, and they're essentially tabular data anyway.
I once saw an admin go on about how much 'better' Linux DNS servers were, then spend 5 hours hunting typos in the DNS config and zone files. Eventually he got fed up, and then I took over and spent about 5 minutes clicking "next, next, next" to get a Microsoft AD DNS up and running, flawlessly. The difference is that AD builds most of the configuration automatically, gives no opportunity to use invalid zone files, and stores entries in a database. There is just no reason a large DNS registrar couldn't implement the same with a few days of scripting something around a database.
I actually noticed the original source research on the web a couple of months ago, and it should be mentioned that what these guys are creating is not a bulk material that you can pop into a freezer and levitate magnets over or whatever.
Their strategy is to produce a mix of many different variations of their target substance by carefully crystallizing it so that slightly different ratios of the constituent elements turn up in small crystals that are a part of a larger aggregate. They then test the conductivity of the mix as they lower the temperature. If any one crystal superconducts, then they observe a small drop in the conductivity graph at that temperature. With complex mixes, you get multiple drops, at different temperatures. They pick the highest temperature at which they observed a drop, and they try to isolate the crystal.
This method is very clever because it lets experimenters test a large number of related compounds 'in parallel', but what it doesn't do is provide a method for actually making bulk quantities of a discovered compound. It's almost like those mathematical proofs, where you can show that a solution exists, you just can't actually determine what it is. In this case, making significant quantities of the pure superconductor might be quite challenging, possibly harder than finding it in the first place.
On the other hand, once they do succeed, we'll have superconductors within the temperature range achievable with solid-state chillers like the Peltier Coolers familiar to overclockers. That's big. If the superconductors have decent max current limits, expect superconducting power-electronics to be commercially available in 15 to 20 years.
There are plausible reports as to how this happened here.
tl;dr - They tried upgrading their SAN without making a backup first, and the upgrade somehow hosed the entire SAN.
That's the thing that has always worried me most about SANs: you have all your eggs in one basket. No matter how redundant or reliable the hardware is, one bad update or trigger-happy admin can cause the instant loss of all your data. That's only slightly better than having your data center burn down. You still have your hardware, but a total restore like that can be a nightmare. I've heard somewhere that 80% of corporations couldn't recover from a scenario like that.
Here's some fun numbers: a typical tape restore runs at something like 70MB/sec, if you're lucky, per tape drive. Some small low-end SANs that I see people buying these days are 10TB or bigger. At those speeds, it takes 40 hours to restore the complete system. What's worse is that it doesn't scale all that well either, you can get more drives, but the storage controllers and back-end FC loops become a limit. If you have some big cloud provider scenario, a complete restore could take days, or even weeks.
What's scary is that mirroring or off-site replicas don't help. If your array starts writing bad blocks, those will get mirrored also.
Yeah, this turns up all the time in real-world scenarios.
A common case is accessing things via network shares, as it adds a prefix. In particular, DFS adds a very long prefix, such as: "\\mydomainname\dfsroot\share\...".
If you have a multi-domain environment, then you often need to use the FQDN of the domain name instead of the short alias, which means that I've seen 60-character prefixes in real-world scenarios. There goes half your path quota!
The first ASP.NET site I developed was an internal engineering timesheet app for an IT company. It was standard practice to cut & paste scripts and code into the "notes" field for other engineers to reference later. The default ASP.NET behavior is to DENY such form submissions, which is just retarded, as code in a text field is... still text.
I had to turn the 'security check' off, because if you use parameterized SQL statements together with correct use of HTML encoding, then scripts or code in text fields presents zero risk, but Microsoft's dirty hack of a security check breaks basic functionality. It randomly causes actions to fail with a security error, when nothing other than text manipulation is going on.
Think about how pathetic that is: Would you expect, say, Notepad.exe to give you an "Access Denied" error message if you used it to edit a javascript file?!? Would you ship a user application that as a feature throws meaningless messages in the face of the user if they accidentally enter some magic sequence of characters?
I love the blurb: "...determines whether ASP.NET examines input from the browser for dangerous values" (emphasis mine). Are you kidding me? It's text! Microsoft considers plain text dangerous now? What next? Threatening colors? Risky sounds?
The fact that there's a config entry like that at all is just sad beyond words. It tells me that Microsoft so utterly failed to get ASP.NET right, that they had to layer a filthy hack on top to make it the slightest bit secure.
Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.
This is what I mean when I say Microsoft's attitude to security is still half-assed.
Or rather that's their attitude to standards. With the security issues being one of the consequences.
Exactly. One of the side-effects of incorrectly encoded output is that some webpages will not be 100% valid XHTML, because they will contain invalid character sequences. This is particularly nasty, because it will usually validate, possibly even pass QA tests, but then when some user adds some crap to a field somewhere, then XHTML compliant browsers will simply refuse to show you the page with an "invalid markup" error, or similar.
Although I agree it has taken quite a while, but sometimes one does need to output with and without the encoding, so I find it nice to have an explicit and easily identifiable way to do both.
Interesting, but it only seems to solve encoding issues of strings returned by in-line code, not data binding, which uses <%#... %>.
Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.
This is what I mean when I say Microsoft's attitude to security is still half-assed.
For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks.
I would be pretty upset if everything I pulled from DB was automagically HTML encoded. I protect against XSS where it needs to be done. There are places where HTML encoding your data would not work. I do, however, always use parameterized inserts to protect against sql injection on top of an appropriate string cleaning function. Few things aggravate me like shitty ad-hoc inserts and the absence of string cleaning tied to a client-driven interface.
Nobody said that you'd be forced into HTML encoding everything, always. It should be an option that can be toggled, and it should be available on every data bound field, and it should be on by default. Turning it off should be simple, just set a flag. Note that the asp:Literal control has just such as flag ("Mode"), but AFAIK, it's the only control that can toggle encoding.
The drag & drop designers in VS do the wrong thing by default, especially for DataGrid and FormsView templates. Even the examples in MSDN are full of technically incorrect examples.
I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.
Well, I just tested it with 3.5, and it's still just as broken as when I first tried it with 2.0.
First of all, "div" and "span" aren't controls at all, but are simply markup elements, and neither support data binding (which is what I was talking about), and neither do any kind of encoding at all, so I think you might be missing my point entirely. Also, "Label" is not that rare - it's the default control inserted by the GUI designer in Visual Studio if you bind a text field in a FormView, and as you noticed, it fails to encode.
Second, while some controls do perform encoding, this only works sometimes, usually if the target control is a "Literal", or effectively the same (e.g.: If a Literal control is generated by a data bound control as a child control). As far as I know, the Literal control is the only control that has a "Mode" property that can be used to toggle HTML encoding modes, so most other text fields are not encoded.
For example, if you bind the "Text" property of a HyperLinkField of a DataGrid, then no HTML encoding is done, and no encoding options are available. The only option is to do a manual bind to a code-behind method that performs the encoding for you.
What particularly shits me is how random the encoding is. Sometimes it works (literals), sometimes it doesn't (hyperlinks), but then sometimes it randomly works again, such as the Alt text of Image fields. It's not documented either!
Is this the quality and attention to security you'd expect from the world's biggest software company? Random, unpredictable, undocumented, insecure behavior in their flagship web framework? Really?
All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.
There's no backwards compatibility, ASP.NET was a completely new framework, written from the ground up. It should have done escaping correctly, right from the start. Ideally, it should be a flag that you can toggle on and off on the level of individual text fields, controls, or a whole page, and the default should be safe.
Storing HTML in databases is one thing, and there are controls for emitting such data, such as XML, Literal or Placeholder controls, but that's a special case where a page is assembled from HTML fragments, which is actually relatively rare(*). The common case is a simple text field bound to a database column such as "user name", or "product name". There is just no good reason to allow arbitrary HTML in all database columns that are potentially user writeable. This is how you end up with shit databases that have encoded characters like "&" in them, which breaks sorting, comparisons, and non-HTML applications such as reporting engines.
The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.
The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings. The dirty compromise is to use null-terminated strings together with an explicit length. Naively, one would think that this is now compatible with both, but it isn't - the NT API strings are a superset of the C-style API strings, because they can contain \0 characters, which the latter cannot handle.
This is a glaring flaw, has been known for many years, and will probably never get completely fixed. The SysInternals guys wrote a nice article about it once, I think, but I can't find it any more. It's lost in the mists of time. It's been exploited repeatedly too. You can create files and registry entries with \0 in them, and then none of the user-mode tools will be able to modify or delete those, including Explorer and the command-line tools. Viruses and other malware make use of this 'feature' often.
What really shits me is that Microsoft hasn't learned a thing. They talk big about security, but it's just talk. For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
If Microsoft can sit on a related security holes for years, don't hold your breath for a patch for this one. Even if they do fix it, I suspect they'll do something half-assed, like create a patch for IE only, instead of the cryptographic subsystem as a whole.
I am really saddened that it's taken people this long to realize this was a KICK ASS Idea.
Disclaimer: Everything said below this runs under the assumption the game is made correctly. There are LOTS of ways they could mess this up, interface, command structure, how to reward playstyles, how the teaming is done, etc etc.
But IF they get this right, it will be a fantastic game. Some people love strategy, others love killing shit. Some people like both, but more often some people like one and hate the other. Lots of people love having some voice in the sky doing the thinking for them so they can focus on killing shit, as long as that voice helps them kill shit better.
This is demonstrated on a LOT of big multiplayer games with voice enabled, you end up getting 1-5 guys out of dozens who are barking out useful info, the rest feeding off them without much complaint. I think there are better system sthan the everyone can talk to everyone method, but it hink it's a good start.
This has been done before, the human side in Natural Selection had this years ago. One guy on the team was a commander with an overhead RTS view, everyone else played as a standard FPS. The commander could drop items, place buildings (but the FPS players had to actually construct them), and give orders.
My experience was that if you had a good commander, the overall game was good. If you had a shit commander, which was often, then the game was pretty bad. The problem is the ratios. You can't have everyone being the commander. What often happened was that one guy was voted in to become the commander because he was good, but then nobody else got to practice the commander role, so it was very self-reinforcing. The first few times you play commander suck a lot, everyone swears at you while you try to figure out which button does what. A lot of people never really got to play the commander at all, because they'd be kicked from the role within seconds, so they never got any practice.
Funny thing: I wanted to get a quote for the Sun/Oracle Database Machine that they are advertising as having these ungodly performance numbers. You know how Oracle licenses their database software per CPU? Well, they have extended their ungodly license to their Exadata storage with a $10,000 per HARD DRIVE license. Yes, that's correct. Oracle takes standard Intel based Sun servers, loads them up with SATA drives, and charges you a $10,000 per spindle license fee to store data on them. This is their business model.
Does anyone know of any open source alternatives to Exadata? The architecture looks appealing from a performance standpoint: Standard Intel servers with SATA drives connected to a 40 gigabit Infiniband fabric and serving data to Oracle servers, but I'm not willing to pay $10K per spindle to license my storage in the same way that Oracle licenses their database software.
Look at Sun Thumpers: they're 48-disk storage servers that use ZFS to RAID data. Use iSCSI and high-end NICs to connect to Oracle. You can get multi-port 10GbE NICs for a reasonable cost these days, and a lot of vendors include iSCSI offload.
Some 10GbE switches now have very low latency, comparable to Infiniband. Or, if you've already got Infiniband infrastructure, just keep using that.
For performance, pack the Thumpers with RAM (I think 128GB+ is doable), and use the ARC cache feature of SUN Solaris in combination with a FusionIO SSD PCI-E card. Those things will do 100,000 IOPS, or more. The card acts as a cache for the slower spinning disks, and the RAM acts as a final layer of cache. You can get 128GB of RAM, upwards of 1TB of SSD, and 80TB of disk per 4U device. That's a good combo, and can be had for under $100K per box ($2K/drive), even if you get really high-end components.
Stripe your databases across a couple of those boxes, and you could get gigabytes/second and almost 1M IOPS for a tiny fraction of the price you're paying now. You'd probably also save on power usage and rack-space usage too. You might lose a few niceties though like fancy replication systems, but ZFS can do snapshots (however, synchronized snapshots across multiple boxes is probably impossible).
Sorry , that makes no sense. By definition you could do it on the same hardware without a VM unless your VM somehow magics processing power out of the ether.
Except that unless you have a magic crystal ball, you'll never be able to predict application load ahead of time. Hence, some servers will be underutilized, and some will be sitting at 100% half the time. The only alternative is to install every application onto every server you have, and load balance everything - but that requires that every app is compatible with every other app, and that every app can operate as a cluster. In practice, that's impossible for typical businesses.
What the latest virtualization platforms do is load balance, on the fly. A large VMware cluster will analyze the load pattern and redistribute virtual machines around the cluster to balance things out, so that each host is evenly loaded. I've seen clusters set to an average of 70% CPU load, and it was just fine. If one host starts heading towards 100%, a few VMs are shuffled around until the load is evened out again. Users can't really tell the difference between, say, 20% and 70% load. It's only at 90% or higher that you get contention and increases in response latency. It takes about 5 seconds to move a VM, but the actual outage is only a few milliseconds, if that, so users never notice.
One thing I noticed with VM deployments is that most apps get faster on less hardware. This is counterintuitive, but I've seen it before in well designed Terminal Server / Citrix deployments. The basic concept is that you can afford much better hardware if you need less of it. You can buy beefier servers, 10Gb ethernet, SAN storage, etc... When 1 app needs lots of power, it gets it, and then it gives up its share when it doesn't to other apps that do.
So yeah, in a sense, virtualization does magic processing power of the ether, because it actually lets you use the processing power you paid Intel or AMD thousands of dollars for.
I thinl you're missing my point - why have multiple OSes if they're all the same type of OS and the apps could all happily run on the same OS instance? As for deployment - have you never heard of a tarball? OS dies - take app tarball to new server , untar. Hows that different to copying a VM machine file over?
In the real world, people run apps like Exchange or Oracle, which take hours to install to a vanilla state, and that's not counting the potentially terabytes of data associated with them.
Even the most primitive "tar ball" Linux app will have dependencies on the OS, and those can and will eventually break, unless you freeze your OS version forever. If you have enough apps and servers, that will become a nightmare to manage. Do I upgrade or not upgrade? Will this patch or that patch break one of the apps? This is how people end up running Linux 2.2, or 32-bit Windows on 64-bit platforms, because migrating 1 app is hard enough, but migrating a server with 20 apps on it is a recipe for disaster.
Virtualization lets you quite literally drag & drop a running host OS from server to server. During maintenance time, that's like magic. No more 3am hardware replacement jobs for me! You can clone a machine while it's running, isolate the clone onto a virtual network, and test an upgrade without interrupting users. Sure, you can do that with most backup & restore tools, but VM platforms do it quicker, and with fewer admin steps. You don't even need spare hardware.
I once replaced every single hardware component of a running VM farm, servers, cables, switches, even the SAN, while it was running. During the day. Zero outage, no packets lost, no TCP/IP connections closed or user sessions disconnected. We even had terminal server (Citrix) and console (SSH) users on. Not one user even noticed what was going on. I'd love to see you try that with 'tar'.
Not even that. OpenLDAP supports user-defined schemas. Active Directory doesn't. You have to go out and buy something if you don't like the stock set. Kerberos and one or more LDAP servers come standard with all the major Linux distros.
100% wrong, AD does allow schema customizations, using a simple command-line tool. Many applications do exactly this, not just Microsoft software. Developers steer clear of it, because a forest-wide schema change terrifies most PHBs, but it's actually rather trivial if you need it. Microsoft does request that if you sell boxed software that makes schema extensions, then you should register your schema IDs with them to prevent conflicts, but that's not enforced or anything.
What I especially like about AD is that once you've extended your schema (say by adding a few attributes to the User class), you can then write a management console add-in that adds an extra tab to the User property dialog box. Nifty.
but then system folders encrypted too, a pain to manage. I liek just the encrypted home folders
I like that... if it's more work, and has to be carefully managed, then it's somehow... better. I'm struggling to see how simply ticking a checkbox apparently causes you pain. Actually... it's not even that much work! In practice, all deployments will have the Bitlocker step simply run as a script after the image is deployed to the machine. No checkbox ticking, hands off, zero effort after the first one is done.
Not to mention that Windows does have per-folder (even per-file) encryption, it's called EFS. That's also just a checkbox away.
Of course, since you're a competent admin, you should full well know that the reason Bitlocker encrypts the whole disk is to avoid information leakage through channels such as the pagefile, hyberfil, and memory dumps. Right? You also know that file-level encryption often leaks confidential information through file names, such as "HR - Termination notice for the IT admin.doc".
Yeah, I know what you mean. And that's just 6 years.
Imagine what it would be like if you went back in time with a laptop like that to say, World War II, and popped in for a visit to Bletchley Park for a quick 'demo'. Can you imagine the jaw-to-floor contact you'd get from the LCD screen alone? Then one could simply demonstrate a program running their deciphering algorithms orders of magnitude faster than their 'Colossus' just for the fun of it.
At least they'd mostly understand what they were witnessing. Go back a few hundred years, and people would struggle to even grasp the concept of what a computer is, other than 'magic'.
Add an SSD and a good I7 laptop will certainly blow the socks of most desktops out there. Laptops are now just a few MHz and disk spins away from desktops really. Add an SSD and this kind of processor and the gap is as good as gone. I'm already planning on using my PC just for development, my other tasks just don't need (cheap) 8GB of memory and a stack of hard drives.
That makes zero sense... if a laptop with an SSD is good, then an SSD in a good i7 workstation will be even better, for 1/2 the price. In practice, laptops will always be behind desktops, because of the compromises they have to make for weight, size, cooling, and power consumption. They're not catching up to a stationary target.
For example, I have a laptop with 8GB of memory, a high-end SSD, and a dual-core CPU. It rocks. It's so fast, it gives me tunnel vision. However, the RAM was expensive, 8GB is the upper limit, and the CPU is anemic compared to what I'd like to have in it.
Meanwhile, my friends and coworkers are getting 3GHz quad-core desktops with 12GB of memory, an SSD, terabytes of disk, etc... Those machines are beasts. If you do real work, like running multiple virtual machines, databases, and heavy-weight development environments, they're a real time saver. Unfortunately, I'm a consultant, so I need my work machine to be portable. 8(
The real difference is that my laptop cost me about AUD 6000 all up, but you can have almost 2x that performance for AUD 3000 if you buy a workstation instead. I don't know what the US price is like, but here in Australia, you can have 12 GB of DDR3 memory for AUD 400. That's just... wrong. In the same price range as my laptop, you can get a dual-socket (8 core) workstation with 24GB of memory, an SSD, and 8TB of spinning disk. In 6 months, when octo-core CPUs are available, up that to 16 cores! A laptop with an even remotely similar spec won't be available for at least a year and a half.
Still, I don't see IPv6 adoption happening until you can actually have it provided by most ISPs for residential access, have it go through a cheap ADSL/cable routers, and deliver the web pages people want to access.
From what I've heard, less than 1% of the web is IPv6 accessible, less than 5% of residential internet connections allow IPv6, and very few home routers support it.
It's basically like NetBEUI or IPX - used on LANs, but not on the Internet.
Slashdot Mirror
If I remember correctly from seeing watching the tech talk on youtube about a year or so ago, the idea is not to produce a continuous, stable fusion reaction, but to produce an unstable reaction that lasts for only a moment. By creating reactions many times per second, substantial amounts of energy are produced. (Hopefully more than is needed to initiate the reactions in the first place.)
The device is in some ways similar to a spark plug.
Whoa... a spark plug from hell that could start the leviathan engines that power the forge of God.
Now only $29,999,999 from United Fusion Corp! Buy now!
I'm guessing that by better quality they mean materialistically. Being a US citizen I would prefer to live in a place where human rights are championed, personal liberty is maximized and freedom of speech and freedom from government oppression is paramount.
Unless someone is afraid of being randomly assaulted or imprisoned, then no one cares. It's human nature. Bread and circuses you know? I've been to China. It's not Mao's China, not at all.
So, I guess I'm saying where should I move to?
Canada?
Canada is cold. Come to Australia! I wore a T-Shirt through most of winter in Sydney, but we've got a couple of token mountains that see snow in the winter for people who like that kind of thing. 8)
For *any* kind of hosted service, having backups measures just slightly below "is it turned on" in terms of importance. And for a year and a half, NONE WERE DONE? Further, they did a major update to a SAN and didn't backup first?
That's not what happened... of course they were doing backups. Apparently the issue (still stupid, but slightly less so) is that a backup started *while* they were updating the SAN, so the backup got corrupted. And also stupid, apparently they didn't have a very recent backup of the backup...
That's not how backups work. You don't overwrite one set of media over and over, because during the backup itself, you have no backup. The absolute minimum number of copies is two, because then you still have one good backup while overwriting one set of media. Also, for backups to be useful, they usually need to be made at least daily.
What you described there is an asynchronous mirror, which is not that much protection. Secondly, from what I've seen happen during SAN upgrades, they first thing they do is disable all scheduled tasks, all mirrors, etc... Once the update has succeeded, then the engineer turns stuff back on one thing at a time. Doing an update while some major process is going on is insane.
Realistically, a hosted system like this should have some huge tape library, and dozens of copies going back at least a month or two, just in case there's a need to recover from ongoing data corruption. For the amount of data involved in this case, this is a relatively cheap and ordinary setup.
The real scary part of cloud hosting is that most of the really big hosts (Google, Amazon, etc...) can't afford 'proper' backups. They just mirror their data around a couple of times, and hope it's good enough. Read up on Google FS (GFS). They don't even replicate out of a data center yet, so if they lose a building from some disaster like an earthquake or fire, they'd lose hundreds of petabytes of data. That was acceptable for their web index, as they can always re-crawl the web, but I'm surprised they're doing hosting now with the same underlying technology.
In fact, it's common for the main conductors coming out of power plants to be made of pure sodium metal submerged in oil, due to the fact that sodium has a very, very high conductance at normal temperatures.
I can't imagine how that could possibly be true. Sodium is a poor conductor, several times worse than copper. The only three conductors in common industrial use are copper, aluminium where weight matters, or silver where the best possible conductivity is required.
You must have confused the liquid sodium cooling used in some nuclear reactors with the electrical generation going on at those plants. The sodium itself is only used to transport heat.
It gets worse. In 2007, Paul Vixie wrote an article in ACM Queue basically praising the vagueness of the DNS protocol specifications:
From this overview, it is possible to conclude that DNS is a poorly specified protocol, but that would be unfair and untrue. DNS was specified loosely, on purpose. This protocol design is a fine example of what M.A. Padlipsky meant by “descriptive rather than prescriptive” in his 1984 thriller, The Elements of Networking Style (Prentice Hall). Functional interoperability and ease of implementation were the goals of the DNS protocol specification, and from the relative ease with which DNS has grown from its petri dish into a world-devouring monster, it’s clear to me that those goals were met. A stronger document set would have eliminated some of the “gotchas” that DNS implementers face, but the essential and intentional looseness of the specification has to be seen as a strength rather than a weakness.
Correlation does not imply causation.
DNS didn't grow to be huge because it was designed loosely, it happened to grow big because coincidentally the Internet took off and become huge, and the Internet happened to use DNS. It would be a bit of a stretch to say that the Internet become the size it is today because one of the many underpinning protocols and standards was loosely specified.
The Internet could have used any number of alternate name lookup systems, and it would have grown to its current size just fine. The only element of DNS design that really helped at all was its hierarchical nature, which helped it scale.
I think the big failure here is that anyone is ever editing the file by hand. It should be created programatically and edited only with a tool so that an error like this can never happen. (Of course, other errors are possible; now you have to vet your code. But the tool need not be complex, and in fact should be small enough to be provable if you so desire.)
I agree, but I'll also be a monkey's uncle when free software is designed this way.
What does this failure have to do with free software? If anything, it should be easy.
Even if you have an open source DNS server that uses text files, a major DNS registrar should be automating the hell out of it. I'm struggling to think of a reason why you wouldn't generate all your DNS records from a database. The files aren't that complicated, and they're essentially tabular data anyway.
I once saw an admin go on about how much 'better' Linux DNS servers were, then spend 5 hours hunting typos in the DNS config and zone files. Eventually he got fed up, and then I took over and spent about 5 minutes clicking "next, next, next" to get a Microsoft AD DNS up and running, flawlessly. The difference is that AD builds most of the configuration automatically, gives no opportunity to use invalid zone files, and stores entries in a database. There is just no reason a large DNS registrar couldn't implement the same with a few days of scripting something around a database.
I actually noticed the original source research on the web a couple of months ago, and it should be mentioned that what these guys are creating is not a bulk material that you can pop into a freezer and levitate magnets over or whatever.
Their strategy is to produce a mix of many different variations of their target substance by carefully crystallizing it so that slightly different ratios of the constituent elements turn up in small crystals that are a part of a larger aggregate. They then test the conductivity of the mix as they lower the temperature. If any one crystal superconducts, then they observe a small drop in the conductivity graph at that temperature. With complex mixes, you get multiple drops, at different temperatures. They pick the highest temperature at which they observed a drop, and they try to isolate the crystal.
This method is very clever because it lets experimenters test a large number of related compounds 'in parallel', but what it doesn't do is provide a method for actually making bulk quantities of a discovered compound. It's almost like those mathematical proofs, where you can show that a solution exists, you just can't actually determine what it is. In this case, making significant quantities of the pure superconductor might be quite challenging, possibly harder than finding it in the first place.
On the other hand, once they do succeed, we'll have superconductors within the temperature range achievable with solid-state chillers like the Peltier Coolers familiar to overclockers. That's big. If the superconductors have decent max current limits, expect superconducting power-electronics to be commercially available in 15 to 20 years.
There are plausible reports as to how this happened here.
tl;dr - They tried upgrading their SAN without making a backup first, and the upgrade somehow hosed the entire SAN.
That's the thing that has always worried me most about SANs: you have all your eggs in one basket. No matter how redundant or reliable the hardware is, one bad update or trigger-happy admin can cause the instant loss of all your data. That's only slightly better than having your data center burn down. You still have your hardware, but a total restore like that can be a nightmare. I've heard somewhere that 80% of corporations couldn't recover from a scenario like that.
Here's some fun numbers: a typical tape restore runs at something like 70MB/sec, if you're lucky, per tape drive. Some small low-end SANs that I see people buying these days are 10TB or bigger. At those speeds, it takes 40 hours to restore the complete system. What's worse is that it doesn't scale all that well either, you can get more drives, but the storage controllers and back-end FC loops become a limit. If you have some big cloud provider scenario, a complete restore could take days, or even weeks.
What's scary is that mirroring or off-site replicas don't help. If your array starts writing bad blocks, those will get mirrored also.
Yeah, this turns up all the time in real-world scenarios.
A common case is accessing things via network shares, as it adds a prefix. In particular, DFS adds a very long prefix, such as: "\\mydomainname\dfsroot\share\...".
If you have a multi-domain environment, then you often need to use the FQDN of the domain name instead of the short alias, which means that I've seen 60-character prefixes in real-world scenarios. There goes half your path quota!
Define "crap".
The first ASP.NET site I developed was an internal engineering timesheet app for an IT company. It was standard practice to cut & paste scripts and code into the "notes" field for other engineers to reference later. The default ASP.NET behavior is to DENY such form submissions, which is just retarded, as code in a text field is... still text.
I had to turn the 'security check' off, because if you use parameterized SQL statements together with correct use of HTML encoding, then scripts or code in text fields presents zero risk, but Microsoft's dirty hack of a security check breaks basic functionality. It randomly causes actions to fail with a security error, when nothing other than text manipulation is going on.
Think about how pathetic that is: Would you expect, say, Notepad.exe to give you an "Access Denied" error message if you used it to edit a javascript file?!? Would you ship a user application that as a feature throws meaningless messages in the face of the user if they accidentally enter some magic sequence of characters?
At first, I thought ASP.NET was nice, but my opinion dropped several notches when I saw this config option: PagesSection.ValidateRequest Property
I love the blurb: "...determines whether ASP.NET examines input from the browser for dangerous values" (emphasis mine). Are you kidding me? It's text! Microsoft considers plain text dangerous now? What next? Threatening colors? Risky sounds?
The fact that there's a config entry like that at all is just sad beyond words. It tells me that Microsoft so utterly failed to get ASP.NET right, that they had to layer a filthy hack on top to make it the slightest bit secure.
Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.
This is what I mean when I say Microsoft's attitude to security is still half-assed.
Or rather that's their attitude to standards. With the security issues being one of the consequences.
Exactly. One of the side-effects of incorrectly encoded output is that some webpages will not be 100% valid XHTML, because they will contain invalid character sequences. This is particularly nasty, because it will usually validate, possibly even pass QA tests, but then when some user adds some crap to a field somewhere, then XHTML compliant browsers will simply refuse to show you the page with an "invalid markup" error, or similar.
Actually they have addressed the HTML encoding in ASP.net 4.0: http://haacked.com/archive/2009/09/25/html-encoding-code-nuggets.aspx
Although I agree it has taken quite a while, but sometimes one does need to output with and without the encoding, so I find it nice to have an explicit and easily identifiable way to do both.
Interesting, but it only seems to solve encoding issues of strings returned by in-line code, not data binding, which uses <%# ... %>.
Several users have pointed out that Microsoft's "solution" doesn't encode HTML attributes correctly, and doesn't handle several other cases, like embedded XML fragments, or embedded script blocks, which use a different encoding scheme.
This is what I mean when I say Microsoft's attitude to security is still half-assed.
For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks.
I would be pretty upset if everything I pulled from DB was automagically HTML encoded. I protect against XSS where it needs to be done. There are places where HTML encoding your data would not work. I do, however, always use parameterized inserts to protect against sql injection on top of an appropriate string cleaning function. Few things aggravate me like shitty ad-hoc inserts and the absence of string cleaning tied to a client-driven interface.
Nobody said that you'd be forced into HTML encoding everything, always. It should be an option that can be toggled, and it should be available on every data bound field, and it should be on by default. Turning it off should be simple, just set a flag. Note that the asp:Literal control has just such as flag ("Mode"), but AFAIK, it's the only control that can toggle encoding.
The drag & drop designers in VS do the wrong thing by default, especially for DataGrid and FormsView templates. Even the examples in MSDN are full of technically incorrect examples.
I just tried it with ASP.Net 2.0. A TextBox, HTMLInputText, div, and span control all escaped HTML properly. A Label did not properly escape the Text property. I can't think of very many situations where you would use user supplied values for label text, that a span wouldn't be more appropriate for. By default TextBoxes don't allow HTML to be submitted at all. BTW, ASP.Net 2.0 is four years old.
Well, I just tested it with 3.5, and it's still just as broken as when I first tried it with 2.0.
First of all, "div" and "span" aren't controls at all, but are simply markup elements, and neither support data binding (which is what I was talking about), and neither do any kind of encoding at all, so I think you might be missing my point entirely. Also, "Label" is not that rare - it's the default control inserted by the GUI designer in Visual Studio if you bind a text field in a FormView, and as you noticed, it fails to encode.
Second, while some controls do perform encoding, this only works sometimes, usually if the target control is a "Literal", or effectively the same (e.g.: If a Literal control is generated by a data bound control as a child control). As far as I know, the Literal control is the only control that has a "Mode" property that can be used to toggle HTML encoding modes, so most other text fields are not encoded.
For example, if you bind the "Text" property of a HyperLinkField of a DataGrid, then no HTML encoding is done, and no encoding options are available. The only option is to do a manual bind to a code-behind method that performs the encoding for you.
What particularly shits me is how random the encoding is. Sometimes it works (literals), sometimes it doesn't (hyperlinks), but then sometimes it randomly works again, such as the Alt text of Image fields. It's not documented either!
Is this the quality and attention to security you'd expect from the world's biggest software company? Random, unpredictable, undocumented, insecure behavior in their flagship web framework? Really?
To be fair, that's the kind of thing Microsoft really can't fix: plenty of people depend on outputting HTML stored in the database, and making escaping the default would break these users. We can debate the usefulness of Microsoft's compatibility-über-alles approach, but you can't fix that problem and preserve backward compatibility.
There's no backwards compatibility, ASP.NET was a completely new framework, written from the ground up. It should have done escaping correctly, right from the start. Ideally, it should be a flag that you can toggle on and off on the level of individual text fields, controls, or a whole page, and the default should be safe.
Storing HTML in databases is one thing, and there are controls for emitting such data, such as XML, Literal or Placeholder controls, but that's a special case where a page is assembled from HTML fragments, which is actually relatively rare(*). The common case is a simple text field bound to a database column such as "user name", or "product name". There is just no good reason to allow arbitrary HTML in all database columns that are potentially user writeable. This is how you end up with shit databases that have encoded characters like "&" in them, which breaks sorting, comparisons, and non-HTML applications such as reporting engines.
Oblig XKCD: http://xkcd.com/327/
(*) at least it SHOULD be rare, because it totally breaks the separation between UI, Code and Data, by mixing all three together into one huge mess.
The people who need to make sure to get everything secure in order to for the web to function have waited longer than -9 weeks- to get something fixed? When the thing was presented at... Defcon? What else do these people have to do other than fix these -major- flaws. When something is shown at Defcon, BlackHat, HOPE or any other major security conference, the first thing for these people to do would be to fix the flaw. 9 weeks is inexcusable.
The problem is that this is not just some buffer overflow where you can replace single function call with an equivalent function call that does a safety length check. Security holes that depend on '\0' characters in strings exploit a systematic flaw in the Windows API design: the mix of two entirely different and incompatible types of strings all over the place. The 'native NT' API uses Unicode strings with an explicit length, but the Win32 API and C/C++ libraries usually use null-terminated strings. The dirty compromise is to use null-terminated strings together with an explicit length. Naively, one would think that this is now compatible with both, but it isn't - the NT API strings are a superset of the C-style API strings, because they can contain \0 characters, which the latter cannot handle.
This is a glaring flaw, has been known for many years, and will probably never get completely fixed. The SysInternals guys wrote a nice article about it once, I think, but I can't find it any more. It's lost in the mists of time. It's been exploited repeatedly too. You can create files and registry entries with \0 in them, and then none of the user-mode tools will be able to modify or delete those, including Explorer and the command-line tools. Viruses and other malware make use of this 'feature' often.
What really shits me is that Microsoft hasn't learned a thing. They talk big about security, but it's just talk. For example, the entire ASP.NET API suffers from a similar mismatch of encodings flaw: All of the data binding controls fail to properly HTML encode strings coming from a database. This makes virtually all ASP.NET applications ripe for exploits via XSS or other script injection attacks. The one time I wrote an ASP.NET app, I had to spend weeks going through and replacing all of the simple-looking bind statements with explicit calls to a method that would both bind and encode. Even in the upcoming 4.0 release, the flaw is still there. I suspect that it won't ever get fixed.
If Microsoft can sit on a related security holes for years, don't hold your breath for a patch for this one. Even if they do fix it, I suspect they'll do something half-assed, like create a patch for IE only, instead of the cryptographic subsystem as a whole.
I am really saddened that it's taken people this long to realize this was a KICK ASS Idea.
Disclaimer: Everything said below this runs under the assumption the game is made correctly. There are LOTS of ways they could mess this up, interface, command structure, how to reward playstyles, how the teaming is done, etc etc .
But IF they get this right, it will be a fantastic game. Some people love strategy, others love killing shit. Some people like both, but more often some people like one and hate the other. Lots of people love having some voice in the sky doing the thinking for them so they can focus on killing shit, as long as that voice helps them kill shit better.
This is demonstrated on a LOT of big multiplayer games with voice enabled, you end up getting 1-5 guys out of dozens who are barking out useful info, the rest feeding off them without much complaint. I think there are better system sthan the everyone can talk to everyone method, but it hink it's a good start.
This has been done before, the human side in Natural Selection had this years ago. One guy on the team was a commander with an overhead RTS view, everyone else played as a standard FPS. The commander could drop items, place buildings (but the FPS players had to actually construct them), and give orders.
My experience was that if you had a good commander, the overall game was good. If you had a shit commander, which was often, then the game was pretty bad. The problem is the ratios. You can't have everyone being the commander. What often happened was that one guy was voted in to become the commander because he was good, but then nobody else got to practice the commander role, so it was very self-reinforcing. The first few times you play commander suck a lot, everyone swears at you while you try to figure out which button does what. A lot of people never really got to play the commander at all, because they'd be kicked from the role within seconds, so they never got any practice.
Funny thing: I wanted to get a quote for the Sun/Oracle Database Machine that they are advertising as having these ungodly performance numbers. You know how Oracle licenses their database software per CPU? Well, they have extended their ungodly license to their Exadata storage with a $10,000 per HARD DRIVE license. Yes, that's correct. Oracle takes standard Intel based Sun servers, loads them up with SATA drives, and charges you a $10,000 per spindle license fee to store data on them. This is their business model.
Does anyone know of any open source alternatives to Exadata? The architecture looks appealing from a performance standpoint: Standard Intel servers with SATA drives connected to a 40 gigabit Infiniband fabric and serving data to Oracle servers, but I'm not willing to pay $10K per spindle to license my storage in the same way that Oracle licenses their database software.
Look at Sun Thumpers: they're 48-disk storage servers that use ZFS to RAID data. Use iSCSI and high-end NICs to connect to Oracle. You can get multi-port 10GbE NICs for a reasonable cost these days, and a lot of vendors include iSCSI offload.
Some 10GbE switches now have very low latency, comparable to Infiniband. Or, if you've already got Infiniband infrastructure, just keep using that.
For performance, pack the Thumpers with RAM (I think 128GB+ is doable), and use the ARC cache feature of SUN Solaris in combination with a FusionIO SSD PCI-E card. Those things will do 100,000 IOPS, or more. The card acts as a cache for the slower spinning disks, and the RAM acts as a final layer of cache. You can get 128GB of RAM, upwards of 1TB of SSD, and 80TB of disk per 4U device. That's a good combo, and can be had for under $100K per box ($2K/drive), even if you get really high-end components.
Stripe your databases across a couple of those boxes, and you could get gigabytes/second and almost 1M IOPS for a tiny fraction of the price you're paying now. You'd probably also save on power usage and rack-space usage too. You might lose a few niceties though like fancy replication systems, but ZFS can do snapshots (however, synchronized snapshots across multiple boxes is probably impossible).
Sorry , that makes no sense. By definition you could do it on the same hardware without a VM unless your VM somehow magics processing power out of the ether.
Except that unless you have a magic crystal ball, you'll never be able to predict application load ahead of time. Hence, some servers will be underutilized, and some will be sitting at 100% half the time. The only alternative is to install every application onto every server you have, and load balance everything - but that requires that every app is compatible with every other app, and that every app can operate as a cluster. In practice, that's impossible for typical businesses.
What the latest virtualization platforms do is load balance, on the fly. A large VMware cluster will analyze the load pattern and redistribute virtual machines around the cluster to balance things out, so that each host is evenly loaded. I've seen clusters set to an average of 70% CPU load, and it was just fine. If one host starts heading towards 100%, a few VMs are shuffled around until the load is evened out again. Users can't really tell the difference between, say, 20% and 70% load. It's only at 90% or higher that you get contention and increases in response latency. It takes about 5 seconds to move a VM, but the actual outage is only a few milliseconds, if that, so users never notice.
One thing I noticed with VM deployments is that most apps get faster on less hardware. This is counterintuitive, but I've seen it before in well designed Terminal Server / Citrix deployments. The basic concept is that you can afford much better hardware if you need less of it. You can buy beefier servers, 10Gb ethernet, SAN storage, etc... When 1 app needs lots of power, it gets it, and then it gives up its share when it doesn't to other apps that do.
So yeah, in a sense, virtualization does magic processing power of the ether, because it actually lets you use the processing power you paid Intel or AMD thousands of dollars for.
I thinl you're missing my point - why have multiple OSes if they're all the same type of OS and the apps could all happily run on the same OS instance? As for deployment - have you never heard of a tarball? OS dies - take app tarball to new server , untar. Hows that different to copying a VM machine file over?
In the real world, people run apps like Exchange or Oracle, which take hours to install to a vanilla state, and that's not counting the potentially terabytes of data associated with them.
Even the most primitive "tar ball" Linux app will have dependencies on the OS, and those can and will eventually break, unless you freeze your OS version forever. If you have enough apps and servers, that will become a nightmare to manage. Do I upgrade or not upgrade? Will this patch or that patch break one of the apps? This is how people end up running Linux 2.2, or 32-bit Windows on 64-bit platforms, because migrating 1 app is hard enough, but migrating a server with 20 apps on it is a recipe for disaster.
Virtualization lets you quite literally drag & drop a running host OS from server to server. During maintenance time, that's like magic. No more 3am hardware replacement jobs for me! You can clone a machine while it's running, isolate the clone onto a virtual network, and test an upgrade without interrupting users. Sure, you can do that with most backup & restore tools, but VM platforms do it quicker, and with fewer admin steps. You don't even need spare hardware.
I once replaced every single hardware component of a running VM farm, servers, cables, switches, even the SAN, while it was running. During the day. Zero outage, no packets lost, no TCP/IP connections closed or user sessions disconnected. We even had terminal server (Citrix) and console (SSH) users on. Not one user even noticed what was going on. I'd love to see you try that with 'tar'.
Not even that. OpenLDAP supports user-defined schemas. Active Directory doesn't. You have to go out and buy something if you don't like the stock set. Kerberos and one or more LDAP servers come standard with all the major Linux distros.
100% wrong, AD does allow schema customizations, using a simple command-line tool. Many applications do exactly this, not just Microsoft software. Developers steer clear of it, because a forest-wide schema change terrifies most PHBs, but it's actually rather trivial if you need it. Microsoft does request that if you sell boxed software that makes schema extensions, then you should register your schema IDs with them to prevent conflicts, but that's not enforced or anything.
Oh look.. it's even documented for you:
LDIF Scripts
http://msdn.microsoft.com/en-us/library/ms677268%28VS.85%29.aspx
What I especially like about AD is that once you've extended your schema (say by adding a few attributes to the User class), you can then write a management console add-in that adds an extra tab to the User property dialog box. Nifty.
but then system folders encrypted too, a pain to manage. I liek just the encrypted home folders
I like that... if it's more work, and has to be carefully managed, then it's somehow... better. I'm struggling to see how simply ticking a checkbox apparently causes you pain. Actually... it's not even that much work! In practice, all deployments will have the Bitlocker step simply run as a script after the image is deployed to the machine. No checkbox ticking, hands off, zero effort after the first one is done.
Not to mention that Windows does have per-folder (even per-file) encryption, it's called EFS. That's also just a checkbox away.
Of course, since you're a competent admin, you should full well know that the reason Bitlocker encrypts the whole disk is to avoid information leakage through channels such as the pagefile, hyberfil, and memory dumps. Right? You also know that file-level encryption often leaks confidential information through file names, such as "HR - Termination notice for the IT admin.doc".
Yeah, I know what you mean. And that's just 6 years.
Imagine what it would be like if you went back in time with a laptop like that to say, World War II, and popped in for a visit to Bletchley Park for a quick 'demo'. Can you imagine the jaw-to-floor contact you'd get from the LCD screen alone? Then one could simply demonstrate a program running their deciphering algorithms orders of magnitude faster than their 'Colossus' just for the fun of it.
At least they'd mostly understand what they were witnessing. Go back a few hundred years, and people would struggle to even grasp the concept of what a computer is, other than 'magic'.
Add an SSD and a good I7 laptop will certainly blow the socks of most desktops out there. Laptops are now just a few MHz and disk spins away from desktops really. Add an SSD and this kind of processor and the gap is as good as gone. I'm already planning on using my PC just for development, my other tasks just don't need (cheap) 8GB of memory and a stack of hard drives.
That makes zero sense... if a laptop with an SSD is good, then an SSD in a good i7 workstation will be even better, for 1/2 the price. In practice, laptops will always be behind desktops, because of the compromises they have to make for weight, size, cooling, and power consumption. They're not catching up to a stationary target.
For example, I have a laptop with 8GB of memory, a high-end SSD, and a dual-core CPU. It rocks. It's so fast, it gives me tunnel vision. However, the RAM was expensive, 8GB is the upper limit, and the CPU is anemic compared to what I'd like to have in it.
Meanwhile, my friends and coworkers are getting 3GHz quad-core desktops with 12GB of memory, an SSD, terabytes of disk, etc... Those machines are beasts. If you do real work, like running multiple virtual machines, databases, and heavy-weight development environments, they're a real time saver. Unfortunately, I'm a consultant, so I need my work machine to be portable. 8(
The real difference is that my laptop cost me about AUD 6000 all up, but you can have almost 2x that performance for AUD 3000 if you buy a workstation instead. I don't know what the US price is like, but here in Australia, you can have 12 GB of DDR3 memory for AUD 400. That's just... wrong. In the same price range as my laptop, you can get a dual-socket (8 core) workstation with 24GB of memory, an SSD, and 8TB of spinning disk. In 6 months, when octo-core CPUs are available, up that to 16 cores! A laptop with an even remotely similar spec won't be available for at least a year and a half.
Addressable is not the same as accessible.
Still, I don't see IPv6 adoption happening until you can actually have it provided by most ISPs for residential access, have it go through a cheap ADSL/cable routers, and deliver the web pages people want to access.
From what I've heard, less than 1% of the web is IPv6 accessible, less than 5% of residential internet connections allow IPv6, and very few home routers support it.
It's basically like NetBEUI or IPX - used on LANs, but not on the Internet.