Slashdot Mirror

The start menu may be flawed in some ways, but it is the evolution of years of interface feedback.

This same feedback is actually the driving force behind the new start screen. This msdn blog post explains that because of the new start bar win Windows 7, the start menu has become somewhat of a relic. In my own experience, I have to agree, as the only time I open the start menu is to search. So why continue to "evolve" something that has pretty much outlived its time. The start menu doesn't need any more evolution.

It's the distance one has to move the mouse (to "invisible icons" in the corners).

These "invisible icons" as you call them, or hot corners as they're commonly known, have infinite size, so according to Fitts's law, the distance you have to move to them has no bearing on the time it takes to target the corner.

It's the mandatory whole screen paradigm.

There is a whole screen paradigm, but it's not mandatory. You're free to use the desktop and open however many apps and windows you want.

It's the AOL look and feel

Not sure what this means but I enjoy the aesthetic, and certainly prefer it to faux textures and gradients/rounded edges/mirrored surfaces/shadows prevalent in every other interface out there.

snapping smart corners that are great on a touch screen - but not so much with a mouse.

For me the mouse analogues to touch features serve just fine.

It's the assumption that people want their desktop screen to be touch

This assumption has never been made; there are plenty of mouse gestures and keyboard shortcuts being designed specifically for keyboard/mouse. In fact, I can get around the interface pretty handily by just using a keyboard.

Make the start screen more efficient

You might be interested in this blog post, which tries to address concerns that the new start screen is less efficient. For example, you complain about things being further away and larger, but according to Fitts law, this exact combination maintains the efficiency of the menu, and if fact the math works out so that it's more efficient for a higher number of items. Further, the shape and grouping capability of the new start screen, which is only possible because it's a screen instead of a menu, make it possible to take advantage of different types of memory recall like spatial memory. After using the new start screen for a while, I find it much more useful than the start menu.

Microsoft took out a more efficient block method in hosts files in those versions of Windows!

To wit:

I'd even discussed this with the THEN head of the "Windows Client Performance Division" who posts here as "Foredecker" (Richard Russell), who said he'd 'get back to me on it' & he couldn't & WOULDN'T even try to DENY I was correct on it also and agreed with me too no less...

See here on that note:

http://slashdot.org/comments.pl?sid=1467692&cid=30384918

So, how & WHY are 0, &/or 0.0.0.0 faster & better on disk + reads than 127.0.0.1 is?

Well, the first octet(s) IS/ARE 2-7 bytes (16 bits) smaller each entry used is why: COMMON-SENSE!

Thus, over a large amount of entries (or even smaller ones, just less noticeable) in hosts files record entries??

The usage of 0 (shortform), vs. 0.0.0.0 (longform) or worse, 127.0.0.1 (loopback adapter address) just makes for FASTER loadtime & parsing hosts from disk into your local Caches!

(Be that the local diskcache, which is used in lieu of the faulty DNS clientside cache service on larger hosts files with its inflexible fixed size static structures it uses)!

Also, since 0 (and 0.0.0.0 too, the LongForm of that) perform no "loopback operation" and is an analog to a DROP request essentially vs. 127.0.0.1 doing essentially a DENY request (as in firewalls) and a loopback operation directing back to itself?

Via using 0, you have the MOST efficient operations doing 0 (or even 0.0.0.0 but less so due to larger size) vs. 127.0.0.1, the "loopback adapter" & its address!

(Yes, even on Windows where there is a loopback adapter one may bind to a protocol (which is only a dummy driver for systems that have no NIC in them, see here in that regard -> http://www.windowsitpro.com/article/john-savills-windows-faqs/what-is-the-microsoft-loopback-adapter-and-why-do-i-need-it-for-sql-server-.aspx ))

He never did 'get back to me' on it though!

Figures!

Still - you'd think he would since he was the head of a division @ MS as a Senior VP there in said area of "performance" of the Windows client OS' - I was quite disappointed.

* Lastly on this note?

This is 1 AREA I WILL GIVEN LINUX THE "ADVANTAGE":

Linux's TCP/IP stack design, BSD based like Windows is (except for API masked access to it, sockets vs. winsock/winsock2 + lack of RAW sockets IN WINDOWS MODERN VERSIONS FOR SURE for anyone but admin level users (not sure if RAW sockets are denied in Linux though))?

Linux has no such problems using more efficient 0 blocking addresses in hosts files, as well as not having size limits on hosts files!

(Which the faulty local DNS clientside cache service in Windows does also! I.E.-> Use too large of a hosts file for its static sized buffer structures vs. its FIFO algorithm for aging entries in cache? It lags your system - again, Linux has NO SUCH PROBLEM!)

APK

P.S.=> The "problem" is STILL THERE afaik also on Windows 7, VISTA, &/or Server 2008 (even R2 revision build of the latter)... & has NOT been corrected either!

Now - funniest part is, Windows 2000(SP2 onwards)/XP/Server 2003 will STILL let you use 0 vs. 0.0.0.0 or 127.0.0.1!

(Again - 0's just plain smaller & faster on a couple grounds of parsing + no 'loopback' there either vs. 0.0.0.0 (less bad, but larger to parse) & 127.0.0.1 (worst case of all, larger to parse and can do a 'loopback' if the loopback adapter's installed).

REPORTED TO MICROSOFT by myself, APK, here -> http://blogs.msdn.com/b/e7/archive/2009/02/25/feedback-and-engineering-windows-7.aspx?CommentPosted=true&PageIndex=3#comments

Still no correction... dumb!

... apk

I'm a developer at an ISV. Personally, I am waiting for XP to go. Microsoft has some great technology (WWSAPI, SQL Server 2012 LocalDB) that looks like it will solve some of the problems we need to solve with our application, but it's not available on XP.

I'm really intrigued by why you couldn't use SQLite3 instead of SQL Server 2012 LocalDB or any API other than WWSAPI for web services.

Microsoft says it pays and pays more that it receives, and they have stuff in the patent pool too http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx. So that probably is the case for Apple too.

No, most of win 7 is stripped out of windows 8 for ARM. They only get the simplified metro shell, and can't use the standard UI, or really anything that uses the traditional win32 API.

You're wrong. Win8/ARM does include the classic desktop, complete with the standard suite of apps (Explorer, Notepad and the likes), and also full desktop Office. The catch is that you can't run your own binaries there, and there's no SDK provided for desktop ARM apps - so third parties can only run code in Metro.

The building windows 8 blog goes into fairly good detail on the decisions they make and how they make them. http://blogs.msdn.com/b/b8/archive/2011/10/03/evolving-the-start-menu.aspx

Seriously.... a book?

Just Google what you want to know.

If you've done C#, then look at XNA. It lets you do game stuff in C#. You know how to program, now just pick up things you don't know to build on that toolbox. On sites like http://create.msdn.com/ you can find all the information you need, and better yet, full functioning examples projects to pick apart and learn from.

Why back in my day there was no Google machine. Much less any book son the subject. Now there is so much information out there, for free, you have no excuse to not just trip over it even if you take 10 seconds to look for it.

I am not really sure why that needs to be the case. The exception handler itself can use a different stack

Only if it's outside of the context in which the code which threw the exception was called. E.g. in Java or C++, you can return from the function or break a loop from within catch. It needs to be in the context of the original stack frame for that to work, or at least be able to restore it right before that point.

or it can just start at the top of the original stack, and can receive simply receive a pointer to the stack frame/instruction that should be returned to once the exception handling routine is finished.

That would work.

Interestingly enough, I've realized that Win32 low-level exception model (SEH) already has something along these lines: when an exception is thrown, it walks the stack without unwinding it, and calls the so-called "filter" callbacks for every registered exception record. Those filters return a value that tells the stack walker to either use that particular exception record to handle the current exception, or else to keep walking the chain. The stack walker than unwinds all records up until the one located, and executes its callback. The intent is that actual exception occurs in the main callback after the unwind, and the pre-unwind filter is only used to determine whether exception matches what the block can handle. But, in practice, filter is just a function, and it can just as well handle the exception entirely inside its body.

A similar facility exists in .NET, in form of exception filters, and is exposed in VB (as Catch ... When), but not in C#.

Does anyone know if MS Windows has introduced a UT internal time yet? If not, then we can reliably predict that such bugs will continue to plague their users.

According to an old MS guy [1], Windows NT stores UTC time internally but maintains the BIOS in local time. 1. http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx

There are a lot of ignorant posts on this article. I'm not meaning that to be insulting, just pointing out that a lot of the ranting is coming from a place of not really understading or knowing what's going on.

So I want to provide a link to anyone who is genuinely curious (rather than just being a knee-jerk basher or a person whose opinions are calcified and unlikely to change). It contains two videos.

The first video is just the 8 minute marketing video. But it shows things that answer a lot of the criticisms and questions leveled in a lot of these posts. So for less than 10 minutes of your time, you can learn and understand more than you do now. The second half deals with Windows 8 on laptops without touch.

The second video is the full 90 minute presentation from Barcelona at the announcement of the Win8 Consumer Preview.

From minute 23 to about 40, they cover desktop and non-touch scenarios. LOTS of interesting stuff there. And then there's even more at the end, when they show Windows 8 running on all sorts of hardware, including big game-rigs and beefy server class machines. I think the last ten or so minutes is really interesting.

If you really want to inform yourself, watching these videos is a good start:

http://www.engadget.com/2012/02/29/microsofts-windows-8-preview-event-videos-now-available/

And for more, you can always check out the Building Windows 8 Blog:

http://blogs.msdn.com/b/b8/

If all you've seen is the Developer Preview, then you haven't really seen the User Experience... and assumptions you may have about how things work, about work-flow, about mouse and keyboard support, are just not true.

I said desktop on ARM -- the desktop on 32/64-bit will work with existing applications just fine. The point was that "desktop" is not available as an option on the new platforms for any serious development (e.g. porting Photoshop or LibreOffice to ARM); you are relegated to using Metro and the WinRT APIs which are not designed for creating complex applications.

You can use any APIs you want, you can use native code as well, you could use Qt, for example, if you wanted to.

Using WOA “out of the box” will feel just like using Windows 8 on x86/64... ...You will have access to the intrinsic capabilities of Windows, from the new Start screen and Metro style apps and Internet Explorer, to peripherals, and if you wish, the Windows desktop with tools like Windows File Explorer and desktop Internet Explorer.
Building Windows 8

I said desktop on ARM -- the desktop on 32/64-bit will work with existing applications just fine. The point was that "desktop" is not available as an option on the new platforms for any serious development (e.g. porting Photoshop or LibreOffice to ARM); you are relegated to using Metro and the WinRT APIs which are not designed for creating complex applications.

App Suspension:

  1. http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx -- can't find the specific quote in the article, but checking out the comments: e.g. "I hate that the OS suspends the app when it's not in the foreground. To fix this issue, I always run it in Visual Studio, so it doesn't get suspended."

  2. http://hexus.net/tech/news/software/35057-microsoft-windows-8-feature-app-suspension/ -- "This time around it's Microsoft's announcement that its goal is to suspend Metro apps that are currently not visible on the screen to curtail and, with any luck, cut completely their power consumption" and bear in mind that the desktop is just another application (unless Microsoft are treating the desktop applications in the Desktop application differently to Metro applications in Metro).

  3. http://www.techpowerup.com/160208/Windows-8-To-Introduce-App-Suspension.html -- "Simply put, it is a kernel optimization that "suspends" applications that are running in the background without much activity." This is a further clarification on the suspension behaviour, which would mitigate the problem (e.g. what about an alarm clock application, an application polling a server infrequently, or VMware with a powered on but idle OS).

Slide 5 of the deck here says that initializer lists, template aliases, variadic templates, and other features are coming in a series of out of band releases after VC11 RTM (but sooner than the next major release of VC). That slide also lists the stdlib and language features that are included in VC11 Beta/RTM.

Slide 5 of the deck here says that initializer lists, template aliases, variadic templates, and other features are coming in a series of out of band releases after VC11 RTM (but sooner than the next major release of VC). That slide also lists the stdlib and language features that are included in VC11 Beta/RTM.

I wonder if Windows 8 will have an emulation layer for x86 on the ARM.

Nope.

Programmers back then knew how to right optimized and reliable code that took full advantage of the hardware. Also many programmers knew assembly language for extra optimization. If the programmers from back then were writing for the hardware we have now software would be much more efficient.

Not quite true.

In fact, "clever" optimizations done back then can often come to bite you back in the ass.years later. Heavily optimized code can also be a pain to maintain - it's great back then when we usually threw away programs after a year or two but stuff like Y2K illustrated that a lot of software is starting to be used far longer than ever imagined (decades, or half a century).

And the mess of certain optimizations can restrict maintainability in the future. Hell you still run into minor Y2K bugs now and again (Years reading out as 19112 for example).

Heck, here's an optimization done way back in the Windows 3.1 days that persisted until Vista. It's clever and it optimized memory use (back when you had 4MB of RAM, using 64K of RAM for an API call was gratuitious), but really pointless now as it's much faster ot just always take 64K of RAM rather than try to save it. (And 64K out of 4MB was much bigger than 64K is out of 4+GB)

http://blogs.msdn.com/b/oldnewthing/archive/2012/02/10/10266256.aspx

These days, the goal is to write maintainable code first, then optimize that. Otherwise you'll end up having to refactor and rewrite chunks later as performance tweak after undocumented performance tweak leads to a huge mess of spaghetti code that's indecipherable.

Or writing huge chunks of code in assembly that aren't performance critical (i.e., non-kernel codec/dsp stuff). ("kernel" in the codec/dsp world is the chunk of code that's doing the actual processing - e.g., the multiply-accumulate of FIR/IIR filters, completely unrelated to the OS kernel).

Tuning for performance is fine, but trying to do all the nasty tricks you had to do a decade and a half ago leads to an awful mess of code that some poor schmuck has to maintain later. And general trends indicate that the optimizations work then, but then become irrelevant and possible even slower than the straightforward implementation.

While you appear to have a solid technical knowledge base, it is clear you have little to no practical knowledge or experience with SSDs other than off the cuff comments you've read here or there.

Let's go through some of your misconceptions shall we...

Price. Yes they are more expensive than mechanical hard drives. But the speed boost is substantial and worth it. I remember paying $200 for a 30GB HDD a long time ago. Now I can get a 128GB SSD for $160. My 128GB Crucial M4 is limited by my 3Gbs SATA 2 connection. It maxes out at ~280MB/sec for reads due to the pipe. It is actually much faster than that (over 400MB/sec fast). Pretty amazing difference for the otherwise slowest piece of hardware in any computer. Plus with TLC NAND arriving drives are going to start getting cheaper. Pair the cheaper flash with more mature controllers and within the next year or so SSDs will be in their prime.

Yes they are not tolerant of vast amount of write cycles. That is what wear levelling and TRIM are for. Even if new 25nm MLC flash could *only* handle 3000 write cycles, do you think you will ever use it that much? Highly unlikely. New Intel drives in the worst case scenarios running MySQL databases are still expected to last for a few years. Are home users ever going to continuously do 1TB of writes per day on an SSD? Most enterprise systems won't even touch that.

Mostly wrong about the swap file. Microsoft recommends putting the pagefile onto an SSD. See: http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

Take a look at SSD caching. In particular Intel Smart Response. It's a great way to get the speed benefit of SSDs much of the time with a lower cost.

You are dead wrong about SSD speed. Where did you even come up with those numbers? My USB 3.0 32GB flash drive reads at over 120MB/sec. As already stated my SSD totally maxes out 3gb/sec SATA: something mechanical HDDs can only do in RAID. And that's only talking about sequential reads/writes. I dare you to open up firefox, photoshop, and start a 1080p movie off of a mechanical HDD, and then off of an SSD. Access times on SSDs are near instant. See http://www.anandtech.com/show/2829/20

Yes SSDs are still relatively young and immature in some areas. That doesn't change the fact that support for them is substancial and they are above and beyond mechanical drives in anything related to performance.

They wanted to account for any kind of lag, so by having it all in house and disconnected from even their internal network, they have control over all variables so everything is equal.

They did this post on their blog yesterday http://blogs.msdn.com/b/b8/

They care about it so they created a genuine imitation of the real thing.

Honestly, I'd go at some of the pages I have to each day, which are ludicrous in their use of content and scripting - web developers just pick up and drop widgets all over the place, never a look toward what impact it has on the page being interpreted or used on the receiving end. I know I've got a bad one when I hear the processor fan kick in for a stinkin' web page!!!

They wanted to account for any kind of lag, so by having it all in house and disconnected from even their internal network, they have control over all variables so everything is equal.

They did this post on their blog yesterday http://blogs.msdn.com/b/b8/

You didn't dismiss a damn thing.

Windows was an application that ran on the DOS shell, you say. First of all, the DOS shell was COMMAND.COM, which was essentially a command prompt that would dump itself and launch applications in a single-tasking fashion. It doesn't really run anything (except for batch scripts), it's just a launcher. Windows, nor anything else, could run on top of it. If you are talking about the DOS kernel, you again have some serious problems to contend with. For one, Windows was able to multi-task DOS applications, which requires virtual 8086 mode and a protected mode controller component (see the Intel manuals for more details). So Windows had to provide some sort of kernel to manage those DOS boxes. Additionally, Windows and Windows apps clearly ran in protected mode, which DOS doesn't run in. As such, Windows would, again, need some sort of kernel to manage the protected mode memory manager that DOS didn't have. So even if your oft-stated but always wrong idea that Windows was just a pretty shell on DOS, it was a pretty shell that had to do a lot of things that OS kernels usually do, severely weakening your point.

I'll also leave this here: http://blogs.msdn.com/b/oldnewthing/archive/2007/12/24/6849530.aspx

Now onto the next piece of bullshit. You say that no Windows OS is preemptive. I'm not even sure where you get this one from and I remain stumped after reading your statement several times. I don't see what the log clock has to do with whether the OS is preemptive or not (I should also mention that "log clock" isn't a thing and you really don't explain what your algorithm prints and how it's able to measure anything, really; also, running in a VM is a bad idea because the VM is multitasked by the host OS and most VM implementations use fuzzy timers since routing the timer interrupt to the guest is not a good idea). Then you say that Windows is time-sliced. Well, time-slicing IS preemptive multitasking. Otherwise, you have cooperative multitasking, because there's no guarantee that a program will ever give up control. Even the earliest Windows had to do a context switch to the kernel for interrupts, as did DOS, so that's not a relevant factor in cooperative vs. preemptive. Windows behaves the same as Linux in this regard, and every other modern OS. Since this is EXTREMELY well-documented, even in, e.g., academic OS textbooks, I'd like you to find me some sources that indicate that your definition of preemptive multitasking is real (actually, it'd be nice if you could explain what you actually mean, since I'm not clear what the distinction is that you think you're trying to make) and that Windows doesn't fit it.

Your link about DR-DOS does nothing to explain your point, at all. Nobody denies that DOS was booted first and from there, Windows was launched and was able to take over the system. Nobody denies that Windows used DOS functionality for some hardware access (more so in Win3.1 than in Win95). So what point are you trying to make here? Also, I mentioned HAL not to claim that DOS was NT HAL (it clearly isn't), but that it rather acted like one in a limited sense.

So, your post, which does nothing but parrot myths, proved nothing except your ignorance of some very basic concepts, such as how multitasking works, the difference between the DOS kernel and the DOS shell, and what print statements in a loop tell you about preemption. You ready to drop your delusions now that you've been thoroughly schooled?

Time to get your hopes up again? http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx

its not that clear if they will be fully supported however.

From Herb Sutter's recent "Why C++" presentation (here's a transcript), he mentions that mobile development moves towards native... with the implication that native mobile code will be much more predominant with Windows and phone 8.

I should imagine there will be native (winRT) APIs but not sure if they will create wrappers for the old .NET phone APIs. Certainly Silverlight is no longer even listed under the technologies available for mobile development! I think you'll be ok to redevelop apps for windows phone 8, but they won't work without a little modification.

• Support for up to four Kinect sensors plugged into the same computer
• Significantly improved skeletal tracking, including the ability for developers to control which user is being tracked by the sensor
• Near Mode for the new Kinect for Windows hardware, which enables the depth camera to see objects as close as 40 centimeters in front of the device
• Many API updates and enhancements in the managed and unmanaged runtimes
• The latest Microsoft Speech components (V11) are now included as part of the SDK and runtime installer
• Improved “far-talk” acoustic model that increases speech recognition accuracy
• New and updated samples, such as Kinect Explorer, which enables developers to explore the full capabilities of the sensor and SDK, including audio beam and sound source angles, color modes, depth modes, skeletal tracking, and motor controls
• A commercial-ready installer which can be included in an application’s set-up program, making it easy to install the Kinect for Windows runtime and driver components for end-user deployments.
• Robustness improvements including driver stability, runtime fixes, and audio fixes

Oh, absolutely. I just meant that it shows engagement, so it could be construed as positive in that way. But overall it fits the negative theme.

There's a great blog entry on 40-hour work weeks for programmers from, amazingly enough all considered, someone at Microsoft: http://blogs.msdn.com/b/jmeier/archive/2010/10/21/40-hour-work-week-at-microsoft.aspx

So it's not like they dont' get this.

That's just assumptions on your part, and you're wrong on at least a couple of them. Let's take it one by one:

Since both CoW and ZFS's copy work a lot like RAID0 (as far as I can tell),

Uh... I don't think so, no. I'm not even sure why you'd compare them.
RAID-0 combines two disks into one virtual disk twice the size by interleaving the data on it. It's a fairly low-level technique, where each location on the virtual disk is mapped to a fixed location on one of the underlying disks.
Copy-on-write happens on a different level and does a different thing. Say you have a largish block of data, and a pointer to it. The data block is too large to write atomically to, but the pointer isn't. So instead of overwriting the data, you write the modified data to a new place, and change the pointer when you're sure the data is OK.

No max path length restriction (TFA says there still be one for ReFS)

Right, at 32K characters. OTOH, that's also the max length for filenames, while ZFS is restricted to 255.

Variable Block sizes and Sparse Files

Spares files granted, the block size I'll reserve judgement until we have more details on the design, but I hardly consider it a killer feature of ZFS.

Allocate on Flush

Maybe. That's in part an implementation detail though, we wouldn't necessarily know it if they (MS) did.

Block Journaling (aka Journaling File System) as opposed to Metadata only Journaling (NTFS and probably ReFS) which is less reliable

Much less of an issue since they have a copy-on-write system.
From http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx:

When this option, known as "integrity streams," is enabled, ReFS always writes the file changes to a location different from the original one. This allocate-on-write technique ensures that pre-existing data is not lost due to the new write. The checksum update is done atomically with the data write, so that if power is lost during the write, we always have a consistently verifiable version of the file available whereby corruptions can be detected authoritatively.

Logical Volume Management

That part is handled by their storage spaces. Note that this isn't just RAID - it does allocation and replication for a pool of fixed-size slabs, so you should be able to throw any collection of disks together into a replicated storage pool.

I'm fairly certain NTFS still doesn't support user metadata, either

I'm fairly certain you're wrong - NTFS has "alternate data streams", which let you attach arbitrary metadata to a file.
It's not used too much in practice, for instance in the form of a tagging system like you mention, but the support is there.

That's just assumptions on your part, and you're wrong on at least a couple of them. Let's take it one by one:

Since both CoW and ZFS's copy work a lot like RAID0 (as far as I can tell),

Uh... I don't think so, no. I'm not even sure why you'd compare them.
RAID-0 combines two disks into one virtual disk twice the size by interleaving the data on it. It's a fairly low-level technique, where each location on the virtual disk is mapped to a fixed location on one of the underlying disks.
Copy-on-write happens on a different level and does a different thing. Say you have a largish block of data, and a pointer to it. The data block is too large to write atomically to, but the pointer isn't. So instead of overwriting the data, you write the modified data to a new place, and change the pointer when you're sure the data is OK.

No max path length restriction (TFA says there still be one for ReFS)

Right, at 32K characters. OTOH, that's also the max length for filenames, while ZFS is restricted to 255.

Variable Block sizes and Sparse Files

Spares files granted, the block size I'll reserve judgement until we have more details on the design, but I hardly consider it a killer feature of ZFS.

Allocate on Flush

Maybe. That's in part an implementation detail though, we wouldn't necessarily know it if they (MS) did.

Block Journaling (aka Journaling File System) as opposed to Metadata only Journaling (NTFS and probably ReFS) which is less reliable

Much less of an issue since they have a copy-on-write system.
From http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx:

When this option, known as "integrity streams," is enabled, ReFS always writes the file changes to a location different from the original one. This allocate-on-write technique ensures that pre-existing data is not lost due to the new write. The checksum update is done atomically with the data write, so that if power is lost during the write, we always have a consistently verifiable version of the file available whereby corruptions can be detected authoritatively.

Logical Volume Management

That part is handled by their storage spaces. Note that this isn't just RAID - it does allocation and replication for a pool of fixed-size slabs, so you should be able to throw any collection of disks together into a replicated storage pool.

I'm fairly certain NTFS still doesn't support user metadata, either

I'm fairly certain you're wrong - NTFS has "alternate data streams", which let you attach arbitrary metadata to a file.
It's not used too much in practice, for instance in the form of a tagging system like you mention, but the support is there.

Since both CoW and ZFS's copy work a lot like RAID0 (as far as I can tell), I'd expect them to be similar in this respect, however ZFS also does checksum tests and NTFS doesn't BUT I don't know if ReFS will or not.

According to the original Building Windows 8 post, checksums are indeed supported:

As mentioned previously, one of our design goals was to detect and correct corruption. This not only ensures data integrity, but also improves system availability and online operation. Thus, all ReFS metadata is check-summed at the level of a B+ tree page, and the checksum is stored independently from the page itself. This allows us to detect all forms of disk corruption, including lost and misdirected writes and bit rot (degradation of data on the media). In addition, we have added an option where the contents of a file are check-summed as well.

This is definitely good news; for too long ZFS has been the only file system to take data integrity seriously, and it's nice to see more options start to become available.

There's a blog post linked from the article.

There's all kinds of promising stuff, like data corruption resilience and dropped/extended limits.

Much more interesting read than the linked ZDNet article.

Indeed very interesting - their approach seems sound and modern. First, they remove the non-essential features from the filesystem to keep it lean. They could be possibly reimplemented on top of the filesystem. And second, they mention using B+trees and allocate-on-write principle, which some modern filesystems use - Reiser4 springs to mind.

Interesting project to follow (and imitate in open source).

The summary links to a blog commenting on the new public release. The most relevant blog is present on the MSDN here.

While Mary-Jo Foley's blog has a link to it, this saves the hassle of hopping a bit to get to the nitty gritty.

There's a blog post linked from the article.

There's all kinds of promising stuff, like data corruption resilience and dropped/extended limits.

Much more interesting read than the linked ZDNet article.

Today, NTFS is the most widely used, advanced, and feature rich file system in broad use.

If this is true...it's a very sad world we live in...

The PC version of Kinect is also a new version of the hardware, and it can be used accurately at 1/2 meter range. See: http://blogs.msdn.com/b/kinectforwindows/archive/2011/11/22/kinect-for-windows-building-the-future.aspx

CSS3 adds multi-column layouts. We just need the browsers to get there.

The bad part is that IE9 (and lower, obviously) does not support it. The good part is that IE10 will.

I found my solution somewhere on this site:

http://blogs.msdn.com/b/astebner/

I believe on one of the pages, there's a tool this user wrote that does a more complete uninstall. I have no idea what post - it's been too long.

For some reason, every bank we deal with (for large business types) is internet explorer only. I guess you'll have to start there.

Do they at least stop you looking at other peoples accounts if you change the account in the address bar? If not, you haven't dealt with Citibank.

You've been influenced by old new thing. It's well written and I enjoy reading it but after a while it becomes clear there is too much rationalizing of poor design decisions and sloppy implementations. A recent example is the recent entry about NTFS file sizes. While recognizing that Unix does it the right way very early in the post, the rest of the post goes on to rationalize the confusing, dumb design decision in NTFS influenced by a perceived performance problem that hasn't been relevant for at least a decade.

Stuxnet took advantage of really sloppy bugs. You can rationalize each and every one of them like you just did, but taken as a whole, there are too many of these rationalized sloppy bugs in Windows constantly creeping up. Where there's smoke, there's fire.

Just look at the greasy finger marks

The question of smudges was addressed by Zach Pace in the Building Windows 8 blog entry on picture passwords. He emphasizes that Microsoft's goal was to design a password mechanism that was easier to use than PINs on touch devices, with equal or better security.

The picture password system is certainly vulnerable to the smudge factor, but it's no worse than existing PIN systems today.

What are some of your ideas for a great computer lab for education?

The Perfect Educational Computer Lab

The math at this MS blog post has a few holes.

Minor: n! / (n-2)! is used instead of the simpler, equivalent n*(n-1). The number of passwords of length 2 in their calculation is actually defined (since 0! = 1 by convention); it should say 1040 instead of n/a. The circle-related calculation (95 - 5 + 1)^2 ... is oversimplified: for instance, a circle of radius 25 cannot have center (5, 5). The necessary modification is tedious, though, and not very significant. Tap reduction calculations are similarly oversimplified.

More serious: I'm unable to determine how the "# of taps" table was generated. The first entry, 270, is approximately 10,000/(3+5+7+7+7+5+3), which makes sense--it uses a 100x100 grid where taps are allowed to be off by a few squares. If subsequent taps are independent, the remaining entries in the table should be approximately 270^n. Instead, the ratio between entries varies between 65 and 101 (non-monotonically, even). The # lines and # circles tables are similarly unclear to me.

The number of unique lines count, 1949, is low, assuming the tap gesture recognition is used independently on each line endpoint. There are about 270 distinct grid positions, leading to about 270^2 = 72900 directed lines (alternatively, (100^2)^2 / 37^2 ~= 73000). Removing lines of length less than 5 is negligible.

I am unable to compute more than the first entry in the "multi-gesture picture password" column. As they say, this should be computed by "summing up the unique gestures for all three gesture types for the specific gesture length n and raise [sic] it to the nth power". The entries should just be 2554^n given the previous data, but they're not--they're significantly smaller.

At least all the holes underestimate the number of distinct gestures in cases I'm able to calculate, though without details on the circle and line recognition systems I can't independently calculate those figures. Everything I didn't mention was correct.

The math used for comparison typically assumes that there are 10 points of interest in an image. Obviously there's a range depending on the image but most have at least 10. Just don't use Japan's flag as your image and you should be okay. Since lines are directional, when you say 6 likely candidates for lines, that works out to three points of interest: A->B, A->C, B->A, B->C, C->A, C->B. So that really isn't true at all.

The meaty bit at the end of their math is this: "Assuming the average image has 10 points of interest, and a gesture sequence length of 3, there are 8 million possible combinations, making the prospect of guessing the correct sequence within 5 tries fairly remote."

The table at the bottom is good to look through.
http://blogs.msdn.com/b/b8/archive/2011/12/16/signing-in-with-a-picture-password.aspx

Bottom line, for 3 gestures on a typical image, 8 million > [10,000 to 1,000,000] (possibilities for a 4 to 6-digit pin, the valid comparison for this)

Here are the links to the relevant Microsoft blog posts:
http://blogs.msdn.com/b/b8/archive/2011/12/16/signing-in-with-a-picture-password.aspx
http://blogs.msdn.com/b/b8/archive/2011/12/19/optimizing-picture-password-security.aspx

Here are the links to the relevant Microsoft blog posts:
http://blogs.msdn.com/b/b8/archive/2011/12/16/signing-in-with-a-picture-password.aspx
http://blogs.msdn.com/b/b8/archive/2011/12/19/optimizing-picture-password-security.aspx

The start menu button/taskbar is on the bottom by default because buggy apps assume 0x0 is the top/left of the screen (workarea), see http://blogs.msdn.com/b/oldnewthing/archive/2003/09/12/54896.aspx

As far as I can tell, all that needs to be done is to implement a system-wide Windows Media Foundation component to render Theora, and IE will pick it up if it sees a Theora video.

For HTML5 video IE9 only allows H.264 and WebM regardless of whatever other codecs are installed. Originally it was H.264 only. Then, after Google's announcement and release of WebM, it became H.264 and WebM. Microsoft cites security, consistency and legal concerns as their primary reasons for restricting the number of codecs available for HTML5 video. Here are some posts from the IE blog which chart the changes:

H.264 announced as the only supported HTML5 video codec: http://blogs.msdn.com/b/ie/archive/2010/04/29/html5-video.aspx
Explanation of exclusion of other codecs: http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
WebM support announced: http://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
Video format support demo published, only interesting as a convenient test page for WebM in IE: http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-ie9.aspx

It's a shame that Microsoft hasn't joined the WebM CCL yet. Dean Hachamovitch (corporate vice president for IE) called for the creation of such a body, it was created, and Microsoft still haven't joined for some reason. As far as I know they haven't yet said why they won't join.

As far as I can tell, all that needs to be done is to implement a system-wide Windows Media Foundation component to render Theora, and IE will pick it up if it sees a Theora video.

For HTML5 video IE9 only allows H.264 and WebM regardless of whatever other codecs are installed. Originally it was H.264 only. Then, after Google's announcement and release of WebM, it became H.264 and WebM. Microsoft cites security, consistency and legal concerns as their primary reasons for restricting the number of codecs available for HTML5 video. Here are some posts from the IE blog which chart the changes:

H.264 announced as the only supported HTML5 video codec: http://blogs.msdn.com/b/ie/archive/2010/04/29/html5-video.aspx
Explanation of exclusion of other codecs: http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
WebM support announced: http://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
Video format support demo published, only interesting as a convenient test page for WebM in IE: http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-ie9.aspx

It's a shame that Microsoft hasn't joined the WebM CCL yet. Dean Hachamovitch (corporate vice president for IE) called for the creation of such a body, it was created, and Microsoft still haven't joined for some reason. As far as I know they haven't yet said why they won't join.

As far as I can tell, all that needs to be done is to implement a system-wide Windows Media Foundation component to render Theora, and IE will pick it up if it sees a Theora video.

For HTML5 video IE9 only allows H.264 and WebM regardless of whatever other codecs are installed. Originally it was H.264 only. Then, after Google's announcement and release of WebM, it became H.264 and WebM. Microsoft cites security, consistency and legal concerns as their primary reasons for restricting the number of codecs available for HTML5 video. Here are some posts from the IE blog which chart the changes:

H.264 announced as the only supported HTML5 video codec: http://blogs.msdn.com/b/ie/archive/2010/04/29/html5-video.aspx
Explanation of exclusion of other codecs: http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
WebM support announced: http://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
Video format support demo published, only interesting as a convenient test page for WebM in IE: http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-ie9.aspx

It's a shame that Microsoft hasn't joined the WebM CCL yet. Dean Hachamovitch (corporate vice president for IE) called for the creation of such a body, it was created, and Microsoft still haven't joined for some reason. As far as I know they haven't yet said why they won't join.

As far as I can tell, all that needs to be done is to implement a system-wide Windows Media Foundation component to render Theora, and IE will pick it up if it sees a Theora video.

For HTML5 video IE9 only allows H.264 and WebM regardless of whatever other codecs are installed. Originally it was H.264 only. Then, after Google's announcement and release of WebM, it became H.264 and WebM. Microsoft cites security, consistency and legal concerns as their primary reasons for restricting the number of codecs available for HTML5 video. Here are some posts from the IE blog which chart the changes:

H.264 announced as the only supported HTML5 video codec: http://blogs.msdn.com/b/ie/archive/2010/04/29/html5-video.aspx
Explanation of exclusion of other codecs: http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
WebM support announced: http://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
Video format support demo published, only interesting as a convenient test page for WebM in IE: http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-ie9.aspx

It's a shame that Microsoft hasn't joined the WebM CCL yet. Dean Hachamovitch (corporate vice president for IE) called for the creation of such a body, it was created, and Microsoft still haven't joined for some reason. As far as I know they haven't yet said why they won't join.

As far as I can tell, all that needs to be done is to implement a system-wide Windows Media Foundation component to render Theora, and IE will pick it up if it sees a Theora video.

For HTML5 video IE9 only allows H.264 and WebM regardless of whatever other codecs are installed. Originally it was H.264 only. Then, after Google's announcement and release of WebM, it became H.264 and WebM. Microsoft cites security, consistency and legal concerns as their primary reasons for restricting the number of codecs available for HTML5 video. Here are some posts from the IE blog which chart the changes:

H.264 announced as the only supported HTML5 video codec: http://blogs.msdn.com/b/ie/archive/2010/04/29/html5-video.aspx
Explanation of exclusion of other codecs: http://blogs.msdn.com/b/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx
WebM support announced: http://blogs.msdn.com/b/ie/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
Video format support demo published, only interesting as a convenient test page for WebM in IE: http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-ie9.aspx

It's a shame that Microsoft hasn't joined the WebM CCL yet. Dean Hachamovitch (corporate vice president for IE) called for the creation of such a body, it was created, and Microsoft still haven't joined for some reason. As far as I know they haven't yet said why they won't join.

Valid point. This does smell a little of "security flaws" which start with "first, get root access"... ("It rather involved being on the other side of this airtight hatchway", as Raymond Chen puts it).

If you have someone's phone or trick them to run code on it that steal their Wallet database, that can be used to obtain some information which you might be able to use to trick them to revealing their credit card details? It's possible, but rather convoluted, and requires the user to make mistakes more than once; I'm sure there are far easier ways to commit fraud.