I suspect...it runs much faster than win7 on lower end hardware really means it boots faster, since Win8 doesn't routinely boot at all - just reloads a pre-booted memory image. Still, that probably makes it feel like it runs faster, since the main 'slowness' of Windows is that it seems to be ready to work when it really hasn't finished booting.
No, Windows 8 also run faster and uses less memory while doing so. Text rendering has become hw accelerated, more 2d rendering hw accelerated, DirectX and video rendering performance enhanced and general "creative" rendering has vastly improved:
BTW, have we ever seen a satisfying explanation for what happened at kernel.org and linuxfoundation.org? We were initially told that it was something similar (stolen password/compromised user system), but AFAICT they have never explained how that could lead to the servers being root'ed. A rootkit *was* installed. That requires careless use of root privileges or an exploit of a privilege escalation vulnerability. Which was it?
And so, when Microsoft gets raped by a bunch of hackers you think they are going to let the public know? No, they are going to keep it under wraps.
No, they are *not* going to keep it under wraps, at least not if the break-in puts its users or customers at risk.
The reason is simple: Microsoft is required by law to disclose any such breach. The penalties for "keeping it under wraps" are severe and could include paying restitution/punitive damages to each individual customers/user.
But don't let such minor detail stand in the way of spewing your MHD all over slashdot.
Seriously? They put inertial sensors in an add-on instead of in the device itself? I guess in the PC world you never know what hardware configuration people have and they wanted to carry that over.... dumb.
The sensors are so that the Surface device (not the cover) can figure out when you fold the cover back. They also assist the screen orientation logic. For instance, when you attach the cover, the keyboard and trackpad will be active until you fold it back past apx 200 degrees (0 degrees being fully closed). After that the Surface will assume that you are folding the cover back and will disable the keyboard and trackpad so that you do not inadvertently press the keys when holding .
When the keyboard *is* active the Surface will force screen orientation to landscape, regardless of its internal sensors.
Maybe you'll have to experience this to fully understand, but it actually makes a lot of sense.
The Surface has it's own set of sensors. It certainly does not rely on the sensors in the cover to figure out it's orientation etc.
it is bs, because the suggestion is made with the mouth of an user
Not with the mouth of a user. The suggestion was made by a user. Or are you suggesting that Microsoft imposes a user to make such a suggestion?
but it's apparently the reason for why it breaks
That a little premature conclusion, don't you think? I have been using the device extensively like that and my cover has not split (yet). Is it now a concern? Yes, definitively. I can even see how the wires in that place *does* put extra stress on the glued/welded surfaces. But to jump to " it's apparently the reason for why it breaks" is just not supported by any data at this point. Pure speculation.
so I'd wager that MS would tell you just to fuck off after you're back to have it changed the third time.
Yeah, you'd wager. Right. Certainly their actions so far indicate that the users affected by this problem have had no problem getting a replacement. So on what basis do you "wager" that?
One article claims 2 users have reported this. The linked thread mentions three. I'm sure that they're may be more, but three reports of problems doesn't seem like a reason to declare a universal flaw yet.
The position where the cover has been splitting in these instances does seem to be a position under great stress. It is not inconceivable that it is a widespread problem.
I have been using the Surface extensively with the cover folded back behind the unit (the position putting the most stress on that seam) and mine haven't split (yet). But examining the cover I can definitively see how it could happen, if the cover is not perfectly glued/molded. Not looking forward to confirming this problem:-)
That said, it is a wonderful device. The touch cover really *is* nice. Folded back it offers a good non-slipping grip on the device. Having an (almost) real keyboard just by dropping the cover on a table is so much more convenient than using the screen keyboard.
couldn't be stuffed reading all your gobbledygook, but i don't know what you're smoking about the whole "trustedinstaller" user thing.
regardless of who i'm logged into on a windows machine, i can install any program with simple click-through privelige escalation
Of course you can install software when you are admin. But please go ahead and try to delete operating system files, rename or overwrite them. You will soon discover that in Windows even the administrator is not all-powerful. Only TrustedInstaller is allowed to change OS files; and there is no way to log in as TrustedInstaller.
Changing OS files (changing configuration, overwriting drivers or loadable modules/libraries) is a common way for malware to try to insert itself into the OS to ensure that it gets executed again during system startup.
The Windows operating system protects its files through multiple mechanisms. The first is that even Administrators are not allowed to overwrite or change the OS files. The second is that if you succeed in changing OS files (you *can* probably use admin privileges to take ownership of OS files and then change them) then integrity checks during boot will detect the tampering and will restore the files from an encrypted cache.
root in linuxland is simply the highest level of access, which is also required for windows to be able to operate (regardless of whether you call it admin, trustedinstaller, blahblah).
root in linuxland is all-powerful. root can change, delete or overwrite *anything*.
Windows practices separation of duties. Yes, that's an actual security principle. Changing individual operating system files is something even an administrator should not be allowed to do. He should be allowed to change certain configuration and even point to an update package and launch an installation process. But he should not be allowed to tweak individual operating system files. That is both unnecessary and a liability.
Administrator is not equivalent to root. Windows and Linux are designed quite differently, it's just wrong to say these two things are equivalent.
You are correct. One OS have 2 levels of users: regular users and a single all-powerful user. If you want to do anything remotely system oriented you have to run as the all-powerful user - even if it is just to mount a printer. The same OS is designed with extremely coarse-grained file-system permissions where you can only grant access to the owner, a *single* group or to *everyone* in the world. The same OS has *only* file system permissions and thus tries stupidly to map everything else that must be secured to a file - even if it doesn't fit the file metaphor at all - like e.g. processes.
The other OS comes with fine-grained privileges which can be assigned to any user, like for instance the privilege to change system time, to backup files, to take ownership. The other OS has fine-grained permissions on securable objects - allowing for inheritance, separation of read/write file from read/write permissions, multiple owners. Access to objects can even be granted to multiple groups - by design. The other OS also allows many object types (not just file system objects) to be secured: Processes, threads, semaphores, URLs etc. This other OS comes with a group "Administrators" which is just a group to which a number of powerful privileges have been granted. Members of this group are usually designated "Administrators" - but they are not all-powerful. Privileges can be removed from the Administrators group or even outright denied through other memberships.
So you are right. The first OS has a single all-powerful account while the other have just accounts. The first one requires that you elevate to *root* to perform a number of system tasks. While root the process can do *anything* on the system - and multiple exploits have used this to total system pwnage. The other OS does not require that you run as an all-powerful user. A user or group can be granted just the necessary privilege and the risk contained.
Which one do you prefer?
Now go on and tell us about the latest band-aids Microsoft has pasted over the open wounds of Windows security.
Sounds like TrustedInstaller then is more analogous to root, then. No, really, it sounds like Windows has some SELinux role features. Admittedly, Windows had it first but just like with SELinux it didn't obtain any sort of regular adoption because it introduces an extra level of complexity that makes it harder for the average user to manage their own system.
No, TrustedInstaller is not equivalent to root. An administrator is equivalent to root; only in Windows "administrator" is a set of privileges/permissions rather than a single can-do-everything all-or-nothing account in Unix/Linux - a limitation which has led to the incredibly stupid and exploit-prone SUID processes. You cannot log on as TrustedInstaller - it has no password (no it is not blank - it just doesn't exist) and you cannot log on interactively. Only the WindowsUpdate process run as the TrustedInstaller - and it only accepts packages signed by Microsoft. There is *nothing* comparable in Linux. If you are root you can tamper with files and loadable modules (e.g. drivers). There is no equivalent account in Windows that you can use.
And attempts to try to automate around that issue end up invariably just being another place that becomes an attack vector.
There may be bugs in the implementation - but resource protection is a significant barrier to overcome. Along with kernel driver signing it has pushed malware that seeks to take permanent residence to resort to bootkits - a vector now being closed as well.
All of the above would be important if, oh, malicious processes need to be root to auto run or otherwise do 99% of the stuff they want to do. No, the only major thing the above does is make it harder to write a root kit.
It is correct that a process running as the logged on user typically will have access to the user's files. But if the malware wants to *infect* the machine it must ensure that it is somehow in the startup chain. If it can insert itself into the OS it will infect all users. Otherwise it will be gone on the next logoff/logon or system restart. What does Linux/Unix do to prevent a malicious process (e.g. a trojan) from infecting the machine? Is "root" the only barrier?
But malware doesn't have to be a root kit to be a major annoyance to remove.
On Linux/Unix/Mac OS X you may be correct. But on Windows (especially Windows 8) malware cannot intercept the boot process anymore. The kernel is integrity protected and will revert tampering automatically or outright refuse to boot a compromised system.
Right because in Linux land, 99% of drivers are open source and included with the kernel. That is to say, there can be static analysis of the code to much more readily guarantee against kernel tampering.
You really should try to understand what Kernel Patch Protection is. It is *not* static analysis; rather it is dynamic checksumming while the OS runs. It is protection against a malicious process getting foothold in the kernel by patching OS tables.
Beyond that, yes, the more noticeable examples of closed drivers (gfx card and wifi) are a real problem, but something like KPP is at best a hack to the problem. For the rest, trying to prevent local system escalation is generally more important anyways to prevent that vector of attack. But as I noted, it only tends to matter with root kits.
KPP is another layer of protection. A layer absent in Linux/Unix. And it is decidedly *NOT* protection against rootkits (where it is ineffective). KPP protects against rogue or compromised kernel mode drivers making unauthorized changes to running OS tables (such as the page table). Again, I understand that you don't get it: Linux/Unix doesn't have it.
Funny thing about digitally signed code. Even if it were a guarantee that you know where the code came from, it doesn't mean it's secure either by design
Windows has Windows Resource Protection (WRP). Unlike Linux/Unix, even if you run as an administrator (equivalent to root) you *do not* have permission to change operating system files. Only the TrustedInstaller account can change those files. Furthermore, the files are designated system integrity level raising another barrier. Even if a malicious process succeeds in fooling a user into elevating to high integrity level with administrator privileges, it cannot change those files. WRP also performs integrity checks upon system start. If any files have been tampered with they are restored from an encrypted cache before they are accessed. Is guaranteed security? no - but it pretty good protection and it is unlike anything you'll find in Linux/Unix where root access == pwned.
Windows has Kernel Patch Protection (KPP). KPP encrypts and checksums certain OS tables of the running operating system to prevent tampering by rogue processes which somehow have gained kernel access (e.g. through a vulnerable driver). A rogue kernel process will attempt to patch itself in so that it may intercept disk accesses, network access etc. If KPP determines tampering it will halt the system. Is guaranteed security? no - but it is unlike anything you'll find in Linux/Unix.
Windows has a kernel mode signing policy which requires all software (drivers and more) which are to be loaded in kernel space to be digitally signed. If they are not signed they cannot be loaded. If a driver has been tampered with, the signature will be invalid and the kernel will refuse to load it. Ubuntu and Fedora now does have some signing protection, but they are incomplete in comparison, e.g. they only protect executable modules, not configuration files.
Windows 8 introduced secure boot. The Windows 8 boot loader is signed with a key known to the UEFI bios. The boot loader will in turn check the integrity of the OS and configuration (using digital signatures) before the proceeds. This closes the vector where a bootkit takes control of the system and boots the OS in a virtualized environment through which it can patch the OS after boot.
Excuse me, but I thought that NTFS (as opposed to FAT), like HFS+ on Macs, is actually quite good at avoiding fragmentation in the first place.
Yes, it does try to keep blocks belonging to the same files together. However, *no* file system can avoid fragmentation. They can try to be clever and allocate files with space between them to allow for some growth (defeating the original purpose of keeping things together to some extend) or try to delay allocation for as long as possible when a new file is created. However, as files grow they will invariably use up what spare space has been set aside and fragmentation will occur.
All file systems are prone to fragmentation. All of them. Traditionally the defrag tools for Linux file systems have been few and somewhat lagging in functionality (i.e. may need to take the volume off line). The lack of good tools have been spun into a myth that it's because Linux file systems don't fragment. They do. Ext4 does try to combat it using delayed allocation, so maybe it can delay the eventual fragmentation compared to other file systems. But it *will* fragment.
On Windows there's a defrag API which allows both the built-in tool as well as 3rd party tools to run defragmentation on volumes while they are on-line. Furthermore, IO and memory prioritization (in addition to CPU prioritization) allows the defrag process to run "nicely" in the background. You no longer encounter the "lunch syndrome" where your machine seems sluggish after you return from lunch because a defrag or scanning process has caused all cache and memory pages of other processes to be swapped out. With memory prioritization Windows will *not* swap out your word processor or Chrome working memory - simply because the memory requested by the defrag process is requested at a lower priority and is not allowed to offline higher priority memory.
What it amounts to is that defragmentation may improve disk access performance on old-school spinning disks. Regardless of OS, regardless of file system. However, it is not a problem on modern Windows (since Vista) at all since the OS will schedule a non-infringing defrag process for you, running in the background without taking files or volumes offline.
Second, the swap file should have its own partition. In *nix this is pretty much dogma, and it well should be in windows as well. Everyone knows that windows loves to fragment the hell out of its own file system, and the windows swap (paging) file is no exception. If you put it on its own partition you will make defragmentation a lot easier later when you have to do it.
Stupid advice, based on an old Unix/Linux myth.
Consider this: What is the paging file actually for? Yes, for swapping out "dirty memory" when the memory pages are needed for something else. The paging file is *not* used like a large video file. It is being accessed *randomly* (non-sequential) *most* of the time.
What if the primary concern with fragmentation? Answer: Excessive head movements.
And you advice users to place the paging file on another partition, all but *guaranteeing* excessive head movement on *each* access to the paging file? The original recommendation to place the swap file in its own partition was that Linux (and most Unix'es) fails pretty horribly under low-disk space conditions. I.e. the recommendation was for space management - not for controlling fragmentation.
Fragmentation of the paging/swap file is a non issue. The OS rarely need to read more than a few blocks sequentially. Actually, one could argue that the best place for the paging file in a memory-constrained system (where swapping happens a lot) is at ½ disc width - or centered in the partition. If that happens to be interleaved with other files which are also access in a random-access pattern - so be it. It is still more optimal.
The *only* files that really benefit from *not* being fragmented are large files that are access in sequential fashion or which account for a very large share of all disc accesses (such a large video file or a database file in a single-instance database server).
If you are concerned that the paging file may grow and shrink and thus cause fragmentation of *other* files, then simply reserve a minimum size for the paging file. If you keep it on the same disc as the OS, then you should definitively keep it in the same partition as the rest of the OS. Now, if you could move it to another physical disc - that would offer a performance improvement - as long as you reserve that disc for paging.
But suggesting to move the paging file into a location where you are guaranteed to *increase* head movements - that is nonsensical. Unfortunately that is a very hard myth to bust.
microsoft.com honors DNT... Oh wait, they don't, it's just another way for them to screw with Google. Microsoft tracks you anyway, IE has it on by default in violation of the specification, guess only the people who honor it get screwed.
No, it is NOT on by default. The user chooses between express settings and advanced settings. The screen *clearly* states that IF you choose express THEN do-not-track will be set to on.
By choosing express settings the user has made an informed choice. Or would you argue otherwise in a court?
The user is presented with a "setup" screen at which he/she can choose "express" or "advanced" setup.
The screen *clearly* spells out that *if* you choose express settings then DNT will be switched on.
You are confounding default settings (settings which take effect unless you explicitly go through a change) with a *choice* of grouped settings.
Yes, the settings are grouped. Yes, the users may not know what exactly could be the benefits of tracking (or the benefits to Google?).
But, the user actually *do* make a choice. It is not like the screen merely says "express or advanced?". It actually outlines what will be set.
To claims that this is "default" and that the user has not made a choice is simply wrong. It is the *easy* choice, but that is not the same.
Advertisers and their shills like Roy Fielding may not like the fact that the process does stack the deck against tracking as it makes the DNT the easy choice. To me that is just "right back at ya!". Thanks for all your toolbars, btw. But no thanks.
When using IE10 for the first time (per user) you get a screen where you can choose "express settings". The screen clearly spells out what that means, *including* what DNT will be set to. Arguably, the user *has* made a decision by selecting express settings. How does Roy Fieldings patch determine how much of that text the user read before continuing?
And how does the patch determine when a user *explicitly* sets the DNT.
Yes, Microsoft probably does this because it will annoy Google and hurt them more than it will hurt Bing. But at the same time it does help protect users' privacy. What a joke if Apache accepts this patch. What a sell-out. Disgusting.
PowerShell is great for day to day admin of the Windows-based products, but the moment I find myself with a non-Microsoft logfile or similar, PowerShell is no longer the solution.
By comparison, the other day I solved an issue with reporting via a (slightly convoluted) chain of grep->awk->sed->tr. The issue was getting statistics from "XML" report files that a process dumps when it's completed. My other options were to write an actual program using an XML library and VBscript/C#/$whatever.
Bad example. You should have investigated PowerShell a little more. PowerShell has *built-in* support for XML, even to the point that it has it's own data type. Simply casting a string with XML in it to the [xml] PowerShell type allow you navigate down through an XML document with simple dot-notation. Maybe you could have settled for Select-Xml which lets you query xml using xpath.
Using non-xml tools to parse xml is *really* bad behavior. You invariably make assumptions which may not hold over time. Consider how equivalent XML may be serialized in very different forms - and still be essentially the same XML. I'm not just thinking of line breaks and white space (although that can typically also throw off awk), but namespace qualifiers may change, a different default namespace may come into effect globally or locally, CDATA may be used instead of entities etc.
If the tool producing the XML has been made with proper XML tooling (an XML library, typically) you *cannot* rely on the tool to keep producing that specific serialization. You may very well experience that the library when it encounters certain characters it decides to use a CDATA element to encapsulate text content which until then used to be just plain text.
If you worked for me and produced such a solution, I would tell you to redo it, properly. If it is a one-off report where all the XML files are know, it may be ok. But if you want to push such a solution as "scripting" solution to be reused, it is really, really bad design.
There's an upside and downside to marshalling objects.
Uhm. PowerShell does not marshal objects (since you invoke COM/DCOM I assume you know what marshaling means). PowerShell passes objects in-process. This is actually part of a greater idea with PowerShell: To be able to reuse cmdlets and even scripts in applications (e.g. a GUI admin tool) but still work on the applications own in-memory objects, even on objects which cannot be marshaled.
Some of us have been around since DCOM and COM were prevalent, and the additional security and overhead isn't always worth it.
There is no additional security with in-proc objects.
With objects there's a minimum overhead that you can't code around. Text streams, pointers to objects / inodes / etc all have their uses.
Certainly there's an overhead around text streams that you can't code around. When PowerShell passes an object it merely passes a pointer (reference), the object is not serialized/deserialized or marshaled. Even for string objects, PowerShell passes the pointers, thus not even allocating the text strings in a new process like the *nix pipeline does.
There's an overhead associated with the creating and deleting objects, like there an overhead associated with creating and deleting text objects/buffers of text streams. It is probably safe to assume that the latter is smaller, but then again in a *nix pipeline you will have a lot more allocations/deallocations going on. So you are certainly correct that it all depends on the usage scenario.
In the Windows world, until recently, text stream support was extremely weak so they pushed some of these other methods instead. It's still catching up, and a large part of that is because Windows developers were encouraged by Microsoft to throw objects around in memory even when other more simple and scalable approaches existed.
PowerShell still has no equivalent to to awk. And I don't think it will ever be put in there. It simply is not *needed* in a world where you don't handle text streams but rather COM,.NET and WMI objects you soon realize that awk is a solution to a problem which has simply disappeared. However, it is not like PowerShell lacks tools for parsing and handling text. Import-Csv, for instance, can be used to read files with all sorts of delimiters. And PowerShell has a very advanced regular expression engine built-in which can be used to parse even more complicated formats.
... developers were encouraged by Microsoft to throw objects around in memory even when other more simple and scalable approaches existed. The API -- the "objects" -- are part of the lock-in of developers to the Windows model, so Microsoft can't totally be blamed for that.
This does not make sense. What about objects are not scalable. What is the more scalable approach? One could argue that an object-oriented model is superior in many regards (just witness the success this approach has over the traditional approach). Indeed, the handle/object based model of Windows has *many* advantages for instance when it comes to security. For instance, with handle based objects, access control is determined once when an object is created/opened and after that manipulating the objects goes through the objects method table. If you don't have write-access that "write" method is simply mapped directly to an access denied stub.
As it turns out, object orientation is a big boon for software design. It solves *many* problems, not least some pesky backwards compatibility problems, discoverability, security etc. The fact that applications can be built using an extremely low -overhead model such as COM (in-proc COM is really just a vtable binary standard) allows applications to be built using objects which can then be reused externally. Consider how Word exposes its inner objects such as documents, paragraphs, words and (fl
So if I run PostgreSQL on Windows I can be sure VSS executes psql -c "select pg_start_backup(‘hourly’,true);" before creating the snapshot?
No. PostgreSQL is not a VSS Writer. That's a limitation of PostgreSQL - it fails to take advantage of a service provided by one of the OSes on which it runs. A service which makes backups (and recovery) simpler and more robust. Granted, I don't think Windows is the most important platform for PostgreSQL.
However, Oracle, for instance, is a VSS Writer, i.e. it registers with VSS and participates in the protocol that ensures file consistency during backups. So consider that you have an Oracle instance running inside a VM with virtual harddisks in files on the host system. When you backup that host system, the VSS will ask Hyper-V to ensure consistent state of the harddisk image file. Hyper-V does that by asking the VSS service of the guest OS to ensure disk consistency. This VSS service in turn asks the Oracle instance to ensure disk consistency (flush memory state and refrain from polluting it).
At this time the snapshot is created in the host OS and the the VSS service again tells Hyper-V to continue normal operation. Hyper-V tells the VSS of the guest OS to continue normal operation. The VSS of the guest OS tells the Oracle instance to continue normal operation - i.e. it is again allowed to service requests which can pollute the state. IIRC this entire process is guaranteed to complete in less than 1/10th of a second.
I am currently running a number of VMs using CentOS KVM with virtual disks being hosted on volumes being managed by LVM. Granted KVM and LVM are separate entities, but they can be made to work together to achieve the same result you mention above.
No, you still cannot integrate with applications. To my knowledge there is no OS defined way to tell applications to flush to disk, hold their breath, confirm, wait for an "as you were". It is actually a bit more complicated than that, because the application (e.g. a database server) may have state spanning multiple volumes - and snapshots need to be taken in synch on all volumes.
With the set of applications you use (PostgreSQL, for instance, is quite resilient) you may indeed not experience any problems. I would expect, however, that after a restore you will be able to find warnings indicating that the system was not shut down orderly - or something to that effect.
Have you ever heard of LVM and LVM snapshots? A zillion times better than VSS
Yes, I know about LVM. But LVM is a *file system* volume manager. It *cannot* ensure that applications which caches state in memory (such as databases and most other daemons/services) flushes the state to disk en refrain from polluting the state until a snapshot has been taken. LVM ensures that file system buffers are flushed to disk before a snapshot is taken. It does NOT ensure that the application has flushed state not already written to the file system. To tell me, how is LVM snapshots "a zillion times better than VSS"?
So in other words, by your own description, things that you can already get in linux.
BtrFS has not been completed yet. ReFS is shipping. ReFS will not have all the features of the completed BtrFS, but for now ReFS offers features not available in any shipping Linux.
I don't think ZFS is production quality on Linux yet either. Storage Spaces under Windows is nor shipping.
Dynamic Access Control actually ups the ante for SELinux, grsecurity apparmor etc. While it still protects access to resources it does so based on potentially very fine grained policies which can express rules based on a very wide range of properties. And it brings claims based security all the way into the primary access control of an OS. Linux does not sport claims based security.
Ok, things linux doesn't have yet, but are on the way.
Sure. I am not aware of any effort to bring something like VSS to Linux, though. Windows now extends VSS to remote file systems (shares), which means that clients can ensure consistency even if an application/service stores files remotely (e.g. a SQL Server keeping it's data files on a remote server).
I really don't understand what this is. An automagic VPN? Doesn't sound all that special. NetworkManager has been able to do system-wide VPN connections for a while now.
Yes, an automagic always-on, bi-directional VPN on steroids. No calling, no VPN client installations. Just take the laptop outside the perimeter and it is still connected, still secured, still managed.
So the equivalent of what you can already do on linux with a combination of SSH, Puppet/Chef, and Screen. Admittedly an improvement for Windows, but this has always been a strength with linux.
All in all a meh, in my opinion. If you really have a need for the high-end features, perhaps Microsoft is offering at a competitive price. But otherwise doesn't seem to offer much that you can't already get with a linux, bsd, or solaris distribution.
Uhm, not quite. But unless you experience the new Server Manager you are not going to understand. It has this "declarative" feeling - comparable to controlling your network with declarative network policies as opposed to relying on scripts running on each node to set thing up.
So in other words, by your own description, things that you can already get in linux.
Did you miss the "when completed" part? Or are you that idiot admin who runs btrfs on production servers?
To be fair, I don't think ReFS will be on par - feature wise - with a completed BtrFS. ReFS focuses on the resiliency part. IIRC ReFS does not even implement all of NTFS's features.
Slashdot Mirror
I suspect ...it runs much faster than win7 on lower end hardware really means it boots faster, since Win8 doesn't routinely boot at all - just reloads a pre-booted memory image. Still, that probably makes it feel like it runs faster, since the main 'slowness' of Windows is that it seems to be ready to work when it really hasn't finished booting.
No, Windows 8 also run faster and uses less memory while doing so. Text rendering has become hw accelerated, more 2d rendering hw accelerated, DirectX and video rendering performance enhanced and general "creative" rendering has vastly improved:
http://www.zdnet.com/windows-8-vs-windows-7-benchmarked_p2-7000002671/
http://arstechnica.com/information-technology/2012/10/gentlemen-start-your-benches-measuring-windows-8s-performance/
http://www.askvg.com/comparison-between-windows-7-and-windows-8-memory-management-system/
from http://www.dailytech.com/Windows+8+is+Using+Less+Memory+Than+Windows+7/article22986.htm :
[Windows 8]has 124 MB (~20 percent) more "Available Memory" on his 1 GB notebook -- the Windows 7 minimum memory requirement.
would proprietary companies that get broken into so forthcoming? Should they be?
Yes, they are already required to
BTW, have we ever seen a satisfying explanation for what happened at kernel.org and linuxfoundation.org? We were initially told that it was something similar (stolen password/compromised user system), but AFAICT they have never explained how that could lead to the servers being root'ed. A rootkit *was* installed. That requires careless use of root privileges or an exploit of a privilege escalation vulnerability. Which was it?
And so, when Microsoft gets raped by a bunch of hackers you think they are going to let the public know?
No, they are going to keep it under wraps.
No, they are *not* going to keep it under wraps, at least not if the break-in puts its users or customers at risk.
The reason is simple: Microsoft is required by law to disclose any such breach. The penalties for "keeping it under wraps" are severe and could include paying restitution/punitive damages to each individual customers/user.
But don't let such minor detail stand in the way of spewing your MHD all over slashdot.
Seriously? They put inertial sensors in an add-on instead of in the device itself? I guess in the PC world you never know what hardware configuration people have and they wanted to carry that over.... dumb.
The sensors are so that the Surface device (not the cover) can figure out when you fold the cover back. They also assist the screen orientation logic. For instance, when you attach the cover, the keyboard and trackpad will be active until you fold it back past apx 200 degrees (0 degrees being fully closed). After that the Surface will assume that you are folding the cover back and will disable the keyboard and trackpad so that you do not inadvertently press the keys when holding .
When the keyboard *is* active the Surface will force screen orientation to landscape, regardless of its internal sensors.
Maybe you'll have to experience this to fully understand, but it actually makes a lot of sense.
The Surface has it's own set of sensors. It certainly does not rely on the sensors in the cover to figure out it's orientation etc.
it is bs, because the suggestion is made with the mouth of an user
Not with the mouth of a user. The suggestion was made by a user. Or are you suggesting that Microsoft imposes a user to make such a suggestion?
but it's apparently the reason for why it breaks
That a little premature conclusion, don't you think? I have been using the device extensively like that and my cover has not split (yet). Is it now a concern? Yes, definitively. I can even see how the wires in that place *does* put extra stress on the glued/welded surfaces. But to jump to " it's apparently the reason for why it breaks" is just not supported by any data at this point. Pure speculation.
so I'd wager that MS would tell you just to fuck off after you're back to have it changed the third time.
Yeah, you'd wager. Right. Certainly their actions so far indicate that the users affected by this problem have had no problem getting a replacement. So on what basis do you "wager" that?
One article claims 2 users have reported this. The linked thread mentions three. I'm sure that they're may be more, but three reports of problems doesn't seem like a reason to declare a universal flaw yet.
The position where the cover has been splitting in these instances does seem to be a position under great stress. It is not inconceivable that it is a widespread problem.
I have been using the Surface extensively with the cover folded back behind the unit (the position putting the most stress on that seam) and mine haven't split (yet). But examining the cover I can definitively see how it could happen, if the cover is not perfectly glued/molded. Not looking forward to confirming this problem :-)
That said, it is a wonderful device. The touch cover really *is* nice. Folded back it offers a good non-slipping grip on the device. Having an (almost) real keyboard just by dropping the cover on a table is so much more convenient than using the screen keyboard.
That's exactly what they are saying: don't use it the way you see us using it in the adverts and you'll be fine.
Citation needed. Hint: You seem to be confusing one user's suggestion for a Microsoft statement.
and microsoft telling them that they're using it in wrong position that causes wrong stress on the seam.
I call BS. Nowhere in the linked articles is Microsoft cited for any such claim. Citation needed, please.
couldn't be stuffed reading all your gobbledygook, but i don't know what you're smoking about the whole "trustedinstaller" user thing.
regardless of who i'm logged into on a windows machine, i can install any program with simple click-through privelige escalation
Of course you can install software when you are admin. But please go ahead and try to delete operating system files, rename or overwrite them. You will soon discover that in Windows even the administrator is not all-powerful. Only TrustedInstaller is allowed to change OS files; and there is no way to log in as TrustedInstaller.
Changing OS files (changing configuration, overwriting drivers or loadable modules/libraries) is a common way for malware to try to insert itself into the OS to ensure that it gets executed again during system startup.
The Windows operating system protects its files through multiple mechanisms. The first is that even Administrators are not allowed to overwrite or change the OS files. The second is that if you succeed in changing OS files (you *can* probably use admin privileges to take ownership of OS files and then change them) then integrity checks during boot will detect the tampering and will restore the files from an encrypted cache.
root in linuxland is simply the highest level of access, which is also required for windows to be able to operate (regardless of whether you call it admin, trustedinstaller, blahblah).
root in linuxland is all-powerful. root can change, delete or overwrite *anything*.
Windows practices separation of duties. Yes, that's an actual security principle. Changing individual operating system files is something even an administrator should not be allowed to do. He should be allowed to change certain configuration and even point to an update package and launch an installation process. But he should not be allowed to tweak individual operating system files. That is both unnecessary and a liability.
Administrator is not equivalent to root. Windows and Linux are designed quite differently, it's just wrong to say these two things are equivalent.
You are correct. One OS have 2 levels of users: regular users and a single all-powerful user. If you want to do anything remotely system oriented you have to run as the all-powerful user - even if it is just to mount a printer. The same OS is designed with extremely coarse-grained file-system permissions where you can only grant access to the owner, a *single* group or to *everyone* in the world. The same OS has *only* file system permissions and thus tries stupidly to map everything else that must be secured to a file - even if it doesn't fit the file metaphor at all - like e.g. processes.
The other OS comes with fine-grained privileges which can be assigned to any user, like for instance the privilege to change system time, to backup files, to take ownership. The other OS has fine-grained permissions on securable objects - allowing for inheritance, separation of read/write file from read/write permissions, multiple owners. Access to objects can even be granted to multiple groups - by design. The other OS also allows many object types (not just file system objects) to be secured: Processes, threads, semaphores, URLs etc. This other OS comes with a group "Administrators" which is just a group to which a number of powerful privileges have been granted. Members of this group are usually designated "Administrators" - but they are not all-powerful. Privileges can be removed from the Administrators group or even outright denied through other memberships.
So you are right. The first OS has a single all-powerful account while the other have just accounts. The first one requires that you elevate to *root* to perform a number of system tasks. While root the process can do *anything* on the system - and multiple exploits have used this to total system pwnage. The other OS does not require that you run as an all-powerful user. A user or group can be granted just the necessary privilege and the risk contained.
Which one do you prefer?
Now go on and tell us about the latest band-aids Microsoft has pasted over the open wounds of Windows security.
Tell me about the open wounds, then.
Sounds like TrustedInstaller then is more analogous to root, then. No, really, it sounds like Windows has some SELinux role features. Admittedly, Windows had it first but just like with SELinux it didn't obtain any sort of regular adoption because it introduces an extra level of complexity that makes it harder for the average user to manage their own system.
No, TrustedInstaller is not equivalent to root. An administrator is equivalent to root; only in Windows "administrator" is a set of privileges/permissions rather than a single can-do-everything all-or-nothing account in Unix/Linux - a limitation which has led to the incredibly stupid and exploit-prone SUID processes. You cannot log on as TrustedInstaller - it has no password (no it is not blank - it just doesn't exist) and you cannot log on interactively. Only the WindowsUpdate process run as the TrustedInstaller - and it only accepts packages signed by Microsoft. There is *nothing* comparable in Linux. If you are root you can tamper with files and loadable modules (e.g. drivers). There is no equivalent account in Windows that you can use.
And attempts to try to automate around that issue end up invariably just being another place that becomes an attack vector.
There may be bugs in the implementation - but resource protection is a significant barrier to overcome. Along with kernel driver signing it has pushed malware that seeks to take permanent residence to resort to bootkits - a vector now being closed as well.
All of the above would be important if, oh, malicious processes need to be root to auto run or otherwise do 99% of the stuff they want to do. No, the only major thing the above does is make it harder to write a root kit.
It is correct that a process running as the logged on user typically will have access to the user's files. But if the malware wants to *infect* the machine it must ensure that it is somehow in the startup chain. If it can insert itself into the OS it will infect all users. Otherwise it will be gone on the next logoff/logon or system restart. What does Linux/Unix do to prevent a malicious process (e.g. a trojan) from infecting the machine? Is "root" the only barrier?
But malware doesn't have to be a root kit to be a major annoyance to remove.
On Linux/Unix/Mac OS X you may be correct. But on Windows (especially Windows 8) malware cannot intercept the boot process anymore. The kernel is integrity protected and will revert tampering automatically or outright refuse to boot a compromised system.
Right because in Linux land, 99% of drivers are open source and included with the kernel. That is to say, there can be static analysis of the code to much more readily guarantee against kernel tampering.
You really should try to understand what Kernel Patch Protection is. It is *not* static analysis; rather it is dynamic checksumming while the OS runs. It is protection against a malicious process getting foothold in the kernel by patching OS tables.
Beyond that, yes, the more noticeable examples of closed drivers (gfx card and wifi) are a real problem, but something like KPP is at best a hack to the problem. For the rest, trying to prevent local system escalation is generally more important anyways to prevent that vector of attack. But as I noted, it only tends to matter with root kits.
KPP is another layer of protection. A layer absent in Linux/Unix. And it is decidedly *NOT* protection against rootkits (where it is ineffective). KPP protects against rogue or compromised kernel mode drivers making unauthorized changes to running OS tables (such as the page table). Again, I understand that you don't get it: Linux/Unix doesn't have it.
Funny thing about digitally signed code. Even if it were a guarantee that you know where the code came from, it doesn't mean it's secure either by design
I don't know if you've heard, but Linux/Android PC's are moving 1.5 million units per day, with a half-billion unit installed base.
Exactly!
That totally debunks the market share argument since Android has not seen a malware explosion, even with it's huge market share.
Oh wait...
That's why Google has stated that Android does not need any malware scanner like Windows Defender
Oh, wait...
What red flag?
Windows has Windows Resource Protection (WRP). Unlike Linux/Unix, even if you run as an administrator (equivalent to root) you *do not* have permission to change operating system files. Only the TrustedInstaller account can change those files. Furthermore, the files are designated system integrity level raising another barrier. Even if a malicious process succeeds in fooling a user into elevating to high integrity level with administrator privileges, it cannot change those files. WRP also performs integrity checks upon system start. If any files have been tampered with they are restored from an encrypted cache before they are accessed. Is guaranteed security? no - but it pretty good protection and it is unlike anything you'll find in Linux/Unix where root access == pwned.
Windows has Kernel Patch Protection (KPP). KPP encrypts and checksums certain OS tables of the running operating system to prevent tampering by rogue processes which somehow have gained kernel access (e.g. through a vulnerable driver). A rogue kernel process will attempt to patch itself in so that it may intercept disk accesses, network access etc. If KPP determines tampering it will halt the system. Is guaranteed security? no - but it is unlike anything you'll find in Linux/Unix.
Windows has a kernel mode signing policy which requires all software (drivers and more) which are to be loaded in kernel space to be digitally signed. If they are not signed they cannot be loaded. If a driver has been tampered with, the signature will be invalid and the kernel will refuse to load it. Ubuntu and Fedora now does have some signing protection, but they are incomplete in comparison, e.g. they only protect executable modules, not configuration files.
Windows 8 introduced secure boot. The Windows 8 boot loader is signed with a key known to the UEFI bios. The boot loader will in turn check the integrity of the OS and configuration (using digital signatures) before the proceeds. This closes the vector where a bootkit takes control of the system and boots the OS in a virtualized environment through which it can patch the OS after boot.
Excuse me, but I thought that NTFS (as opposed to FAT), like HFS+ on Macs, is actually quite good at avoiding fragmentation in the first place.
Yes, it does try to keep blocks belonging to the same files together. However, *no* file system can avoid fragmentation. They can try to be clever and allocate files with space between them to allow for some growth (defeating the original purpose of keeping things together to some extend) or try to delay allocation for as long as possible when a new file is created. However, as files grow they will invariably use up what spare space has been set aside and fragmentation will occur.
All file systems are prone to fragmentation. All of them. Traditionally the defrag tools for Linux file systems have been few and somewhat lagging in functionality (i.e. may need to take the volume off line). The lack of good tools have been spun into a myth that it's because Linux file systems don't fragment. They do. Ext4 does try to combat it using delayed allocation, so maybe it can delay the eventual fragmentation compared to other file systems. But it *will* fragment.
On Windows there's a defrag API which allows both the built-in tool as well as 3rd party tools to run defragmentation on volumes while they are on-line. Furthermore, IO and memory prioritization (in addition to CPU prioritization) allows the defrag process to run "nicely" in the background. You no longer encounter the "lunch syndrome" where your machine seems sluggish after you return from lunch because a defrag or scanning process has caused all cache and memory pages of other processes to be swapped out. With memory prioritization Windows will *not* swap out your word processor or Chrome working memory - simply because the memory requested by the defrag process is requested at a lower priority and is not allowed to offline higher priority memory.
What it amounts to is that defragmentation may improve disk access performance on old-school spinning disks. Regardless of OS, regardless of file system. However, it is not a problem on modern Windows (since Vista) at all since the OS will schedule a non-infringing defrag process for you, running in the background without taking files or volumes offline.
Second, the swap file should have its own partition. In *nix this is pretty much dogma, and it well should be in windows as well. Everyone knows that windows loves to fragment the hell out of its own file system, and the windows swap (paging) file is no exception. If you put it on its own partition you will make defragmentation a lot easier later when you have to do it.
Stupid advice, based on an old Unix/Linux myth.
Consider this: What is the paging file actually for? Yes, for swapping out "dirty memory" when the memory pages are needed for something else. The paging file is *not* used like a large video file. It is being accessed *randomly* (non-sequential) *most* of the time.
What if the primary concern with fragmentation? Answer: Excessive head movements.
And you advice users to place the paging file on another partition, all but *guaranteeing* excessive head movement on *each* access to the paging file? The original recommendation to place the swap file in its own partition was that Linux (and most Unix'es) fails pretty horribly under low-disk space conditions. I.e. the recommendation was for space management - not for controlling fragmentation.
Fragmentation of the paging/swap file is a non issue. The OS rarely need to read more than a few blocks sequentially. Actually, one could argue that the best place for the paging file in a memory-constrained system (where swapping happens a lot) is at ½ disc width - or centered in the partition. If that happens to be interleaved with other files which are also access in a random-access pattern - so be it. It is still more optimal.
The *only* files that really benefit from *not* being fragmented are large files that are access in sequential fashion or which account for a very large share of all disc accesses (such a large video file or a database file in a single-instance database server).
If you are concerned that the paging file may grow and shrink and thus cause fragmentation of *other* files, then simply reserve a minimum size for the paging file. If you keep it on the same disc as the OS, then you should definitively keep it in the same partition as the rest of the OS. Now, if you could move it to another physical disc - that would offer a performance improvement - as long as you reserve that disc for paging.
But suggesting to move the paging file into a location where you are guaranteed to *increase* head movements - that is nonsensical. Unfortunately that is a very hard myth to bust.
microsoft.com honors DNT ... Oh wait, they don't, it's just another way for them to screw with Google. Microsoft tracks you anyway, IE has it on by default in violation of the specification, guess only the people who honor it get screwed.
No, it is NOT on by default. The user chooses between express settings and advanced settings. The screen *clearly* states that IF you choose express THEN do-not-track will be set to on.
By choosing express settings the user has made an informed choice. Or would you argue otherwise in a court?
The user is presented with a "setup" screen at which he/she can choose "express" or "advanced" setup.
The screen *clearly* spells out that *if* you choose express settings then DNT will be switched on.
You are confounding default settings (settings which take effect unless you explicitly go through a change) with a *choice* of grouped settings.
Yes, the settings are grouped. Yes, the users may not know what exactly could be the benefits of tracking (or the benefits to Google?).
But, the user actually *do* make a choice. It is not like the screen merely says "express or advanced?". It actually outlines what will be set.
To claims that this is "default" and that the user has not made a choice is simply wrong. It is the *easy* choice, but that is not the same.
Advertisers and their shills like Roy Fielding may not like the fact that the process does stack the deck against tracking as it makes the DNT the easy choice. To me that is just "right back at ya!". Thanks for all your toolbars, btw. But no thanks.
When using IE10 for the first time (per user) you get a screen where you can choose "express settings". The screen clearly spells out what that means, *including* what DNT will be set to. Arguably, the user *has* made a decision by selecting express settings. How does Roy Fieldings patch determine how much of that text the user read before continuing?
And how does the patch determine when a user *explicitly* sets the DNT.
Yes, Microsoft probably does this because it will annoy Google and hurt them more than it will hurt Bing. But at the same time it does help protect users' privacy. What a joke if Apache accepts this patch. What a sell-out. Disgusting.
PowerShell is great for day to day admin of the Windows-based products, but the moment I find myself with a non-Microsoft logfile or similar, PowerShell is no longer the solution.
By comparison, the other day I solved an issue with reporting via a (slightly convoluted) chain of grep->awk->sed->tr. The issue was getting statistics from "XML" report files that a process dumps when it's completed. My other options were to write an actual program using an XML library and VBscript/C#/$whatever.
Bad example. You should have investigated PowerShell a little more. PowerShell has *built-in* support for XML, even to the point that it has it's own data type. Simply casting a string with XML in it to the [xml] PowerShell type allow you navigate down through an XML document with simple dot-notation. Maybe you could have settled for Select-Xml which lets you query xml using xpath.
Using non-xml tools to parse xml is *really* bad behavior. You invariably make assumptions which may not hold over time. Consider how equivalent XML may be serialized in very different forms - and still be essentially the same XML. I'm not just thinking of line breaks and white space (although that can typically also throw off awk), but namespace qualifiers may change, a different default namespace may come into effect globally or locally, CDATA may be used instead of entities etc.
If the tool producing the XML has been made with proper XML tooling (an XML library, typically) you *cannot* rely on the tool to keep producing that specific serialization. You may very well experience that the library when it encounters certain characters it decides to use a CDATA element to encapsulate text content which until then used to be just plain text.
If you worked for me and produced such a solution, I would tell you to redo it, properly. If it is a one-off report where all the XML files are know, it may be ok. But if you want to push such a solution as "scripting" solution to be reused, it is really, really bad design.
There's an upside and downside to marshalling objects.
Uhm. PowerShell does not marshal objects (since you invoke COM/DCOM I assume you know what marshaling means). PowerShell passes objects in-process. This is actually part of a greater idea with PowerShell: To be able to reuse cmdlets and even scripts in applications (e.g. a GUI admin tool) but still work on the applications own in-memory objects, even on objects which cannot be marshaled.
Some of us have been around since DCOM and COM were prevalent, and the additional security and overhead isn't always worth it.
There is no additional security with in-proc objects.
With objects there's a minimum overhead that you can't code around. Text streams, pointers to objects / inodes / etc all have their uses.
Certainly there's an overhead around text streams that you can't code around. When PowerShell passes an object it merely passes a pointer (reference), the object is not serialized/deserialized or marshaled. Even for string objects, PowerShell passes the pointers, thus not even allocating the text strings in a new process like the *nix pipeline does.
There's an overhead associated with the creating and deleting objects, like there an overhead associated with creating and deleting text objects/buffers of text streams. It is probably safe to assume that the latter is smaller, but then again in a *nix pipeline you will have a lot more allocations/deallocations going on. So you are certainly correct that it all depends on the usage scenario.
In the Windows world, until recently, text stream support was extremely weak so they pushed some of these other methods instead. It's still catching up, and a large part of that is because Windows developers were encouraged by Microsoft to throw objects around in memory even when other more simple and scalable approaches existed.
PowerShell still has no equivalent to to awk. And I don't think it will ever be put in there. It simply is not *needed* in a world where you don't handle text streams but rather COM, .NET and WMI objects you soon realize that awk is a solution to a problem which has simply disappeared. However, it is not like PowerShell lacks tools for parsing and handling text. Import-Csv, for instance, can be used to read files with all sorts of delimiters. And PowerShell has a very advanced regular expression engine built-in which can be used to parse even more complicated formats.
... developers were encouraged by Microsoft to throw objects around in memory even when other more simple and scalable approaches existed. The API -- the "objects" -- are part of the lock-in of developers to the Windows model, so Microsoft can't totally be blamed for that.
This does not make sense. What about objects are not scalable. What is the more scalable approach? One could argue that an object-oriented model is superior in many regards (just witness the success this approach has over the traditional approach). Indeed, the handle/object based model of Windows has *many* advantages for instance when it comes to security. For instance, with handle based objects, access control is determined once when an object is created/opened and after that manipulating the objects goes through the objects method table. If you don't have write-access that "write" method is simply mapped directly to an access denied stub.
As it turns out, object orientation is a big boon for software design. It solves *many* problems, not least some pesky backwards compatibility problems, discoverability, security etc. The fact that applications can be built using an extremely low -overhead model such as COM (in-proc COM is really just a vtable binary standard) allows applications to be built using objects which can then be reused externally. Consider how Word exposes its inner objects such as documents, paragraphs, words and (fl
So if I run PostgreSQL on Windows I can be sure VSS executes psql -c "select pg_start_backup(‘hourly’,true);" before creating the snapshot?
No. PostgreSQL is not a VSS Writer. That's a limitation of PostgreSQL - it fails to take advantage of a service provided by one of the OSes on which it runs. A service which makes backups (and recovery) simpler and more robust. Granted, I don't think Windows is the most important platform for PostgreSQL.
However, Oracle, for instance, is a VSS Writer, i.e. it registers with VSS and participates in the protocol that ensures file consistency during backups. So consider that you have an Oracle instance running inside a VM with virtual harddisks in files on the host system. When you backup that host system, the VSS will ask Hyper-V to ensure consistent state of the harddisk image file. Hyper-V does that by asking the VSS service of the guest OS to ensure disk consistency. This VSS service in turn asks the Oracle instance to ensure disk consistency (flush memory state and refrain from polluting it).
At this time the snapshot is created in the host OS and the the VSS service again tells Hyper-V to continue normal operation. Hyper-V tells the VSS of the guest OS to continue normal operation. The VSS of the guest OS tells the Oracle instance to continue normal operation - i.e. it is again allowed to service requests which can pollute the state. IIRC this entire process is guaranteed to complete in less than 1/10th of a second.
I am currently running a number of VMs using CentOS KVM with virtual disks being hosted on volumes being managed by LVM. Granted KVM and LVM are separate entities, but they can be made to work together to achieve the same result you mention above.
No, you still cannot integrate with applications. To my knowledge there is no OS defined way to tell applications to flush to disk, hold their breath, confirm, wait for an "as you were". It is actually a bit more complicated than that, because the application (e.g. a database server) may have state spanning multiple volumes - and snapshots need to be taken in synch on all volumes.
With the set of applications you use (PostgreSQL, for instance, is quite resilient) you may indeed not experience any problems. I would expect, however, that after a restore you will be able to find warnings indicating that the system was not shut down orderly - or something to that effect.
Have you ever heard of LVM and LVM snapshots? A zillion times better than VSS
Yes, I know about LVM. But LVM is a *file system* volume manager. It *cannot* ensure that applications which caches state in memory (such as databases and most other daemons/services) flushes the state to disk en refrain from polluting the state until a snapshot has been taken. LVM ensures that file system buffers are flushed to disk before a snapshot is taken. It does NOT ensure that the application has flushed state not already written to the file system. To tell me, how is LVM snapshots "a zillion times better than VSS"?
So in other words, by your own description, things that you can already get in linux.
BtrFS has not been completed yet. ReFS is shipping. ReFS will not have all the features of the completed BtrFS, but for now ReFS offers features not available in any shipping Linux.
I don't think ZFS is production quality on Linux yet either. Storage Spaces under Windows is nor shipping.
Dynamic Access Control actually ups the ante for SELinux, grsecurity apparmor etc. While it still protects access to resources it does so based on potentially very fine grained policies which can express rules based on a very wide range of properties. And it brings claims based security all the way into the primary access control of an OS. Linux does not sport claims based security.
Ok, things linux doesn't have yet, but are on the way.
Sure. I am not aware of any effort to bring something like VSS to Linux, though. Windows now extends VSS to remote file systems (shares), which means that clients can ensure consistency even if an application/service stores files remotely (e.g. a SQL Server keeping it's data files on a remote server).
I really don't understand what this is. An automagic VPN? Doesn't sound all that special. NetworkManager has been able to do system-wide VPN connections for a while now.
Yes, an automagic always-on, bi-directional VPN on steroids. No calling, no VPN client installations. Just take the laptop outside the perimeter and it is still connected, still secured, still managed.
So the equivalent of what you can already do on linux with a combination of SSH, Puppet/Chef, and Screen. Admittedly an improvement for Windows, but this has always been a strength with linux.
All in all a meh, in my opinion. If you really have a need for the high-end features, perhaps Microsoft is offering at a competitive price. But otherwise doesn't seem to offer much that you can't already get with a linux, bsd, or solaris distribution.
Uhm, not quite. But unless you experience the new Server Manager you are not going to understand. It has this "declarative" feeling - comparable to controlling your network with declarative network policies as opposed to relying on scripts running on each node to set thing up.
So in other words, by your own description, things that you can already get in linux.
Did you miss the "when completed" part? Or are you that idiot admin who runs btrfs on production servers?
To be fair, I don't think ReFS will be on par - feature wise - with a completed BtrFS. ReFS focuses on the resiliency part. IIRC ReFS does not even implement all of NTFS's features.