Windows 8.1 does away with the fixed split when you run two modern apps in split view. It used to be that you had two "modes" - one for when your app was the main app and one for when your app had the narrow strip at the left or right.
That last mode is now gone. Your app may now have both more and less space. As an app developer you'll have do content with this more fluent split. It has actually broken several apps. Not that they will not run - they just look like s*** when they don't take advantage of the assigned space.
Yes - as an app developer I can test this on the preview version of 8.1 - but it would be nice if I could actually test on the real RTM version.
What irks me is that I have seen no really good explanation from MS as to *why* we will not get the RTM bits. Which makes you start guessing. Is it perhaps that it is not quite ready, and they want be able to push last-minute updates to a known and controllable crowd (OEMs). Maybe they are afraid that if a broader community (without NDAs?) got to see the unfinished bits they would risk a bad rep even before launch?
If that is the case, those in charge are really, really stupid. The OEM bits *will* leak to the Internet at some point.
Yes it is. Since Windows 7 and Server 2008 PowerShell is considered part of the operating system. Several OS features such as the troubleshooting packs rely on PowerShell. The OS comes with PowerShell and you cannot even uninstall it (you can uninstall the ISE but the console remains).
Mark Russinovich (practically reverse engineered the Windows kernel and wrote books about it even before joining MS) Scott Guthrie (a techie succeeding in a management position, apparently winning a lot of respect by his employees), Scott Hanselmann, Anders Hejlsberg (created C# and still oversees it's development, latest with true async continuation support) Jeffrey Snower (created the vision driving PowerShell with his Monad Manifesto and actually saw it through, completing with Desired State Configuration in PowerShell 4) Don Symes (F# fame), Don Box, Neal Gafter (previously of Java fame) Dave Cutler (yes, he apparently still works for MS)
I was really, really sad to see Erik Meier go. That was a colossal loss. But Microsoft is not short of outstanding engineers.
The only sane thing to do is use a POSIX OS: Those who do not understand POSIX will re-implement it poorly. See BASH vs Power Shell, oh look a command line interface... like you get when you start typing on the interface formally known as Metro...
POSIX is based on 1970 era ideas of operating systems. While you can argue that it is time tested, there are also many areas where the designs are showing the age. Todays hardware is radically different from what could even be imagined just 20 years ago.
The Windows stack is much better positioned to make efficient use of resources in an increasingly parallel and (not least) asynchronous world. Asynchronicity in POSIX is a meager story, so much so that Linux had to go invent epoll to avoid inefficient busy polling*. Meanwhile Windows NT always had callback/event based asynchronous/overlapped IO built in.
But perhaps more importantly, Microsoft is quietly transitioning the APIs and guiding developers use to asynchronous programming patterns. Traditionally only select types of applications would use asynchronous programming patterns. Think database servers and other server-type of applications where the added complexity was justified by the need to scalability and performance. But asynchronous programming techniques was frequently deemed too complex for ordinary applications, web applications and the like, even though they could benefit from it. The problem was the balance between complexity and effect.
Witness Windows Runtime where any operation that may take more than 50ms is offered as an asynchronous operation exclusively, i.e. developers are guided to use asynchronicity. That would be bad if it wasn't for Microsofts innovations in bringing asynchronicity up from to the application developers. Programming languages like C#, VB.NET and F# now allows application developers to take direct advantage of inherently asynchronous APIs.
Asynchronicity is not multi-threading. Traditionally developers has solved asynchronous requirements by spinning up a thread (or use one from a pool) and have the thread do the waiting. While it seemingly worked ok (for a while), it is a waste of resources when all the thread does it is block waiting for an IO request to complete. As more and more applications need to interact more and more with external resources, this waste of resources become massive.
Unlike the Linux kernel, the Windows kernel implement overlapped/asynchronous IO (disk/network/...) using the reactive pattern (IO completion ports). Think DMA: As a developer you instruct the OS to fill a buffer with bytes received from a network stream. You *offload* the operation to the OS (which will quite possibly use DMA internally) and you don't hear from the OS again until the operation completes (or fails), i.e. no context switches back and forth. The POSIX doesn't even specify anything like that. Linix has epoll which is the proactive pattern: The OS will tell you when there are bytes ready to be read, but it cannot take responsibility for the entire logical operation. This creates more context switches.
POSIX is hopelessly outdated, and transitioning to POSIX in an age where every POSI" OS has had to implement extra mechanisms just to compete and take advantage of modern hardware, would be stupid. Windows kernel and development stack is much better positioned to meet the challenges of massively asynchronous applications.
Go admin an IIS server and your opinion will change rapidly!
I play with some php scripts on some VMS on my home machine but the admins I have talked too love the CLI and the non registry of Unix. There are some things were the only option is to do a reformat and install because of something you did with Windows 6 installations ago. Changing an XML file wont fix it as it is event driven and the registry is a black box of cryptic hex decimal keys!
You may be good at playing Unix. But your ignorance of Windows does not mean a Windows admin would be equally clueless. Clue: IIS does not rely on the registry for website or server administration. The registry contains very, very basic configuration parameters. You may have experience with (or talked to someone who used) IIS6 and the metabase. That was still not the registry, though.
Apache httpd's config files are one of the best examples of how convoluted file based configuration can get. It is a pseudo-xml line-oriented format where every module use it's own way to refer to the same concepts, such as headers and cookies.
And yes, IIS sites are now fully configurable through XML config files, which are built using an extensible model (config sections and config groups).If you do not like XML files there is also a full configuration API exposed as.NET as well as PowerShell cmdlets.
You can now type IIS: which will change your PowerShell "working location" to IIS. Yes, the IIS management model (sites, application pools, bindings etc) is exposed as locations. You can now even cd to your site: cd Sites/MyCompanySite From there you can list the content using ls. From the Sites node you can create, remove, rename and copy websites as if they were files, using the same cmdlets you would use for files. What could be easier than that?
Oh, how would an Windows admin figure out what he could do with the webserver? He lists the commands of the webadministration module: get-command -module webadministration.
IIS can be administered through text (xml) files,.NET/COM API, PowerShell, the management console plugin and graphically through the IIS administration tool. How again did you administer an Apache? through cpanel? (yikes)
Yep, installed packages are available through the Windows Management Instrumentation - where you'll find rich information about everything related to system management, from system board, network adapters, performance counters, drivers over printers, volumes, disks to installed software, updates, running services etc.
Yes, this model offers much more information that you'll ever get from a Linux system unless you have dip into some serious log file archeology. The WMI classes are not part of PowerShell, but PowerShell will seamlessly integrate with the WMI/CIM model. Consequently, the WMI classes are not documented as part of PowerShell. However, they are very well documented. To get a little feel for what type of information can be obtained for a Windows system, look at the documentation for WMI. There are also CIM classes which should work cross platform with any system that adheres to DMTFs WBEM protocol and CIM model. Yes, they are available for Unix/Linux as well.
Your example is actually very interesting. You managed to figure out that Win32_Product was *probably* the WMI class you wanted. Great! here is how you will progress from there: run the command and pipe the result through the Get-Member cmdlet to get an overview of the available information (properties, methods).
Get-WmiObject win32_product | Get-Member
From the answer (cannot be shown here due to./ junk character filter) you can see that Win32_Products has (among other properties) a caption and a version. Hence, you type (or press up-arrow and edits the prev line):
And voila you have your installed products with versions, nicely formatted in a table. This workflow is actually very, very common with PowerShell: 1) locate the command, 2) pipe the results through get-member (which has the standard alias gm because it is used so frequently), 3) chose properties, 4) re-run the command but pipe the results to one of the export-, out- or format- cmdlets.
Yes, you can export the list as comma- or tab-separated values instead by piping the results through Export-Csv: Get-WmiObject win32_product | select caption,version | Export-Csv myproducts.csv
The GPs point was exactly about the discoverability and consistency of PowerShell. There is no overloaded use of -e options. All options has meaningful names, but can be abbreviated as long as there is no ambiguity. Output from cmdlets are self-describing and you can discover both properties and methods.
And PowerShell works with objects. If you inspected the output from the Get-WmiObject win32_product | Get-Member, you would notice that the returned objects each expose an Uninstall method. See if you can figure out what Get-WmiObject win32_product | where name -like "*Java*" | foreach Uninstall will do.
I can't think of anything Powershell could bring to the *nix table that hasn't already been around one way or another for decades.
PowerShell is not a good fit for *nix.
Most Windows APIs (and indeed the Windows kernel with it's concept of handles) are already object-oriented. The low level stuff is typically exposed through native COM APIs. The manageability of kernel, devices etc is exposed through WMI. Applications typically through COM or.NET. PowerShell unifies all these object models.
Not so on *nix. That is not to say that some of the ideas from PowerShell could not be beneficial to *nix shells. But if you ported PowerShell to *nix you would still need some object-oriented view of the system to reap the benefits.
It's just two models with advantages and disadvantages for each OS. *nix use a lot of text files and the traditional tools consume and produce text. Hence, a text oriented shell makes sense, and especially a powerful tool like awk.
Windows does not use a lot of text files. XML files are becoming more prevalent, but mainly configuration is done through object-oriented APIs. Hence, a shell that allows access to those APIs, that speaks objects and makes XML grokking easy makes a lot of sense.
Which is also why a text oriented shell like bash would be inferior (on Windows) to something like PowerShell.
Just different ecosystems. But the days where Windows was lagging *nix on scripting capabilities are definitely over.
will invoke a web request and get this slashdot page and use the COM API to get the title element (getElementById is exposed as an IDispatch method) and print the title.
FWIW, I think the work-around was calling powershell with my script as the parameter instead of calling my script directly.
Yes - you can always invoke powershell.exe with a -command parameter. Given that it can take a script block and/or multiple statements separated by semicolon you can invoke a "script" like that.
Script signing is not designed to be a permission mechanism. Rather it is an integrity mechanism, one that ensures that the script has not been tampered with at rest or in transit. You do not authorize anyone to run a script by signing it, instead you guarantee them that it has not been changed by anyone since it was signed.
As a sysadmin you may receive a script from a developer who instructs you to "run it on the production server". You may (rightfully) be suspicious towards such requests, especially if it is a highly secured server or a server in a regulated domain. But if the script is signed by an auditor/supervisor authority and you have ok through change management, you are in the clear. Script signing supports such a scenario.
The default setting to disallow *all* script file execution is just Microsoft erring on the side of caution. They want you to explicitly and knowingly set the execution policy to something else. The same reason that ps1 files are associated with notepad and *not* with powershell. If you doubleclick a ps1 file, the file doesn't run. Instead notepad pops up.:-)
I've also read that Microsoft planned adding an optional view pane to every control panel and administrator tool in Server 2012 that would output the PowerShell equivalent command to anything you did in the GUI. That strikes me as a brilliant way to turn your slow click-monkeys into fast shell admins.
Maybe they planned it that way, and the server manager certainly offers to quote the powershell script it will execute when you install features and/or roles on a server. However, it does not seem to have penetrated all features, as of Server 2012, and the control panels for the individual roles (IIS, AD etc) typically do not offer such a feature. So if that's their grand plan, they are not there yet.
You *can* however often "export" the setting that you have chosen using the server manager. This is not export as a powershell script, rather the chosen setup is exported as XML which can be *used* by a PowerShell install script at some later point in time or on some other server to repeat the installation.
With Server 2012R2, PowerShell will be bumped up to version 4. Version 4 includes desired state configuration which extends PowerShell with recipe-like declarative functionality. I suspect that this is going to form the backbone of the integration of Server Manager and PowerShell in the future, i.e. rather than generating an imperative script, the Server Manager GUI can generate a PowerShell recipe (formally also a script, albeit a declarative one) which can be readily executed by PowerShell (v4).
The desired state configuration include ways to describe dependencies, package manager style.
I'd like to see Red Hat or Canonical (Ubuntu) do something similar for Unix, but I don't think even Red Hat has the engineering resources for a project like that.
Like a GUI frontend to puppet or chef?
The problem I had with powershell, which I assume is commonplace, is that I fired it up expecting it to be a backwards-compatible superset of cmd.exe. It isn't, lots of the syntax that works fine in cmd.exe gives errors in Powershell or works but does something different from the cmd.exe equivalent.
Yes, PowerShell is significantly different from cmd. Bash also broke some backwards compatibility with the earliest shells. cmd to PowerShell is a much bigger leap compared to the leap from the first sh to bash. For one, the commands of cmd are (somewhat) unix style in the way they use text/stream stdin and stdout. PowerShell does away with that and streams objects. All PowerShell cmdlets stream objects (COM objects,.NET objects, WMI objects wrapped in PS extended type system). Backwards compatability with older utilities is achieved by regarding old utilities as commands that consume and produce sequences of strings - where string is an object type.
It has arcane syntax and plenty of warts, but an investment in bash will probably still be useful in another twenty years. Will Microsoft be using Powershell in ten years, in a form that's compatible with current syntax?
Who knows? Will you still be using bash if something vastly better comes along? One problem with bash (and an obvious difference between PowerShell and bash) is how bash is still created to run on a single machine. Yes, you can use SSH and other tools to fan out and run on multiple machines, but each script is still understood in the context of a single machine. PowerShell is designed with remoting in mind, and many of the commands - and all of the workflows - support multiple remote machines by default. This is not merely the capability to launch remote commands, it also extends to being able to control remote jobs through local job commands and to how the results are marshalled back with a reference back to the computer, thus the command consolidates results from multiple computers into a single result
Unfortunately, I have no graphs I can share with you due to confidentiality reasons. You can get Apache to outperform Nginx by configuring Apache to use prefork, then increasing Linux's file descriptors to a much larger setting than default to coincide with the forked processes and the connection limits you wish to handle.
Using processes to serve individual requests seems like a massive waste of resources, and I have a hard time believing this will run faster than a standard threaded worker. Do you have any theory behind why Apache would process requests faster with preform as opposed to worker?
I have searched for optimization guidelines for Apache and I cannot find anyone recommending this setup, except for when compatibility is required.
I suppose that if Apache is used to serve non-static content using a foreign/3rd party module, there could be local lock contention issues if the module is poorly written. If the lock contention is intra-process (process local locks) I suppose that you could get around that by running multiple processes. But that would merely mean that the server is not being slowed down waiting for locks, not that it will run faster than Nginx.
But in this case no such modules are involved, and lock contentions are clearly not at issue for any browser in the bandwidth saturation tests.
Multiple processes is what nginx would need to get the maximum performance out of a the Quad-core machine.
1. It is mentioned that default configuration was used, but the tester was willing to adjust parameters if the server was not taking advantage of the machine.
2. The CPU utilization at bandwidth saturation test should not be impacted, even if Nginx was running on a single core - unless it showed that bandwidth could not be saturated. But bandwidth was saturated with Nginx and cpu utilization was more than double that of lighttpd and IIS.
And he used a different harddisks for Windows than Linux are they of the same type ?
That could be an issue. But the test used a "real, minimalistic page with a variety of resource sizes and types". The content was static so it will quickly be served from the disk cache negating any performance difference between drives. And again, that should not have a bearing on the bandwidth saturation/cpu utolization test.
I'd say its a bit misleading. Sure, Windows is easier to make work, but to actually secure and keep maintained is a pain in the arse.
Can you elaborate on this, please? As far as I know, Windows Server and IIS comes pretty secure out of the box.
For instance, when you create a new website you automatically also get a specific (virtual) identity for the website/app pool. By default the app pool identity does not have any permissions outside the website directory, effectively preventing the cross-contamination that is so common on Apache setups (yes, because the admins did not bother to create accounts per website, or because such a setup decreases the website density on a shared server).
On IIS, the "account per website" is automatic and implied. The default permissions are restricted and applications are isolated.
If you let the Windows server auto update you are also pretty secure at the OS level. Install headless if you want to decrease the attack surface. Even if you choose to manage the patching yourself, Windows still receives fewer patches (fewer vulns) compared to Linux and they are batched in monthly updates which means you only has to manage patches once per month.
Apparently you are wrong, IIS beats up the competition; only lighttpd comes close.
In the tests, * IIS used only half the CPU compared to Nginx at bandwidth saturation. * IIS delivered more than double peak throughput * IIS had about half the response time compared to Nginx, under medium load.
In short, IIS appears to be twice as fast compared to Nginx.
What benchmarks are you thinking of when you claim "Nginx is faster than both"? Do you have a link?
There are *a lot* of little things in PowerShell that makes you go "aw, that's a good idea". Things you will not find in other shells and neither in Pytho, Ruby or Perl.
Off the top of my head:
* Consistent common parameters for "impact management": You can pass a parameter called -WhatIf to every built-in command that may change persistent state. The -WhatIf parameter runs the command in simulated mode, only echoing on the console what it *would have* done. Similarly a common -Confirm parameter which asks *before* changing persistent state. It even works for scripts and functions: If you declare that your script (in a.ps1 file) "supports shouldprocess" you can pass the -WhatIf parameter to your script and PowerShell will set the whatif preference for the duration of the entire script - as if each command of the script had been passed a -whatif parameter as well.
* Commands, functions, script blocks and script files declare parameters with (optional) static types. This information is used by PowerShell to coerce values to the correct types before invocation. But the declarations can also contain declarative validation attributes, allowing the *shell* to validate parameters before invocation. Declarative validation can validate required parameters, string lengths, number/date ranges, regular expressions, value sets. The kicker here is that the script author does not need to *implement* validations, merely declare them, the information is available to the shell which can use it to both validate parameters before invocation, but *also* to report the validations through the help system. That's right, when you set up validation, help text that describes the acceptable values is automatically generated from this meta information.
And yes, even the tab completion (or intellisense in the integrated scripting environment) will pick up on the parameter type and validation. If you restrict a parameter to a certain value set, tab completion will cycle through those values when the shell determines that you request tab completion for the parameter.
* The PowerShell help system allow for in-script help text through special code comments. No need to author external help files. You can write the documentation right there in the script (using special "dot" comments), and when you do man myscript.ps1, the help system will report the documentation.
* PowerShell workflows allow scripts to suspend and resume at a later time. No, this is not the process suspend of sh shells. PowerShell actually saves the state of script execution to persistent storage and you can resume execution later, even after system restart - or on another computer. This is incredibly useful for the type of scripts that manages farms of servers and that may be running for a long time. If the script is somehow interrupted (power failure, hardware failure) it can later automatically pick up its execution from the latest savepoint. I.e. you can restart it and have it run to completion.
PowerShell is not simply a programming language. It has many features which are directly aimed at being used in a scripting setting and which are not found in general purpose language like Python or Ruby.
And for God's sake, the whole signing scripts business with Powershell is a tragedy. I can understand the value of being a little bit more tight with scripts that can do harmful things, but it should only matter for scripts that need to run as admin or do system management tasks. I shouldn't need to cryptographically sign a script to extract tags from music files, for example. The process to do the signing is itself unnecessarily complex.
Just set the execution policy for the scope that you want. Type man set-executionpolicy -para scope. You will notice that scope can be set for the process, the current user account or for the local machine. So if you want to then simple set a less restrictive execution policy (like RemoteSigned) for your current user. That will still prevent scripts downloaded through a browser or received through a mail to be executed.
There are a lot of legitimate uses for script signing. For instance, for a tightly managed system you could put in place a regime where an auditor/reviewer must sign a script only after review, and the farm of machines will only execute scripts that have been signed by the reviewer. Thus you can have devops develop scripts and test at their test systems, but to deploy the scripts they must follow the review process.
What is the gain for this pain? From a business standpoint, I would want to know what R2 delivers that would necessitate a price increase. If there isn't much then this makes it hard sell for businesses: "We get to pay more for no reason!"
A number of important improvements to Hyper-V allowing higher VM density and (if you run 2012R2 guests) improved performance because of more direct access to hardware. Also, Hyper-V replica
Storage Spaces with tiered storage (what is usually only available with SANs). You can fit a server with regular disks, fast disks and/or SSDs and set up tiered storage spaces, e.g. with parity (think ZFS). Server 2012R2 will then move "hot blocks" to faster disks and move them back to slower disks when they are not accessed as often anymore, letting other hot blocks utilize the faster tier.
A number of manageability improvements, among those PowerShell with Desired State Configuration (think puppet/chef on steroids for what is not already covered by group policies).
Whether it is value enough to justify the price increase is probably subjective. However, it could steal away some SAN business as you now basically can set it up to provide the same features as (at least) entry level SANs. Also the higher VM density could be worth money.
The only thing slightly unreasonable to me is the "Are you willing to have your company name and URL displayed on our MAPP website?" question, but only because it has nothing to do with security and it probably the result of having to please the marketing department.
In the interest of public disclosure of *who* has access to advance information about vulnerabilities before they are patched, I actually find it highly relevant. I can see good coming from giving truly security minded companies a head start. But I would like to know *who* gets this head start.
A few years back a rogue Chinese security company (or just a rogue employee?) leaked proof-of-concept exploit code to Chinese hacker websites. The security company had received the PoC code from Microsoft as part of the MAPP program. The intention was that security companies (AV vendors) could use the PoC code to create heuristics/signatures to scan for exploit attempts.
Of course the spin on slashdot was that Microsoft had "leaked" exploit information. Go figure.
It is also in this light we have to view the "Microsoft shares vulnerability information with the fr***** NSA!!! OMG! Conspiracy!!!" debacle.
Problems with NSA overreaching notwithstanding, I for one believe that NSA should receive vulnerability information at about the same time as it is made public to the other MAPP partners. This news is just that similar agencies of other countries now will receive the information at the same time as NSA and other MAPP partners.
The NT kernel was based on VMS in it's core design, which is what matters, not the APIs. VMS APIs were based on FORTRAN interfaces, while NTs were not, so of course they're not "compatible."
BS. The NT kernel was created based on experience with VMS and a lot of new ideas. For instance, permeating the entire NT kernel is the concept of handles. A handle identifies a kernel object with a jump table. What we today call an object (in the OO sense), as it identifies and encapsulates an piece of memory with data as well as method references.
One of the advantages of this design is that the desired access level (read/write/delete/...) can be expressed when the handle is originally opened. If access is allowed, the kernel object identified by the handle will have the corresponding method pointer reference the actual kernel method that performs the operation. If a given access was not requested the method pointer will simply point to an generic "access denied" method. The upshot is that permissions are checked once when the handle is created. After that the granted access is implicit the the function indirection. If you didn'r request write access, the "write" method is mapped to "access denied". Not having to check permission of the user on each use of the handle yields much better performance than having syscalls check permissions upon each access to a file.
VMS was a much more traditional OS. It didn't have this object-oriented view of its internal structures.
The trouble with GPOs is that many of them are extremely porous and can be bypassed with minimal effort. They are enforced mainly by the programs that they apply to. For example, the GPO to stop people using the command prompt can be easily bypassed simply by having a cmd.exe binary that ignores the setting. Similarly with regedit.
Uhm. Not all GPOs are security policies as you seem to believe. If you do not want users to access resources on the local computer then use permissions to restrict users instead of trying to stop them from going to the command prompt. This is not your stupid sudo. There are other and better ways to secure resources than trying to prevent users from running applications that can access them.
You may hide the command prompt if you don't want your users to strafe out where they don't know how to come back from. But if the intentionally launch an application (or a copy of the shell) they go there themselves.
It should definitively NOT be your security boundary.
You also fail to understand how GPOs are applied. They are *NOT* enforced by the programs they apply to. Policies are a declarative way to configure local state, primarily the registry. Instead of a script trying to run remotely (or on every boot), policies are enforced at boot time (machine policies) *or* at logon time (user policies).
Individual apps do not check up against GPOs. They read config state from the registry (or old style config files). This provides a clean interface where GPOs are not *necessary* (you can use other means to alter the registry) but *available* if you need to enforce a set of configurations consistently across all or subsets of machines and/or users.
You can think of GPOs as declarative scripts. The group policy service reads/interprets policies and performs actions such as setting registry values, changing text/config files or (seldom) running scripts. But because they are declarative they can inherently be applied and re-applied and rolled back.
On Linux/Unix you will need something like puppet or chef to match the declarative power Windows has had with GPOs since the introduction of AD.
http://forums.opensuse.org/english/get-technical-help-here/applications/406017-does-dependency-hell-still-exist-2.html * "The best (worst) way to get dependency hell is to add too many repositories. Eventually one will find the right combination of conflicting repositories to create a situation of dependency hell." * "The problem is the more repositories that are added, the less and less likely that applications are built against the same set. " * "Dependency hell ALWAYS exists. ALWAYS (Yes, Debian users, I'm talking to YOU). The question is whether or not if somebody tries to NOT go to dependency hell, is the system going to take them there anyway."
All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible.
Dependency hell is real. Package managers help mitigate the problem locally, but software repositories are distro and version specific. Once you step outside of the official repository you risk stepping into dependency hell, as many of the above experienced. I fully concede that it *shoudn't* be a problem if every piece of software author did what they were supposed to do. It is the OSs job to provide a service and guidance so that authors do the right thing. Linux is not quite there yet, unfortunately. That's why you see the typical advice to install from the "official" distro and version specific repository. But that model is flawed.
The problem was that a service which typically runs with some form of elevated rights (at least to some resources) could expose those rights/permissions if there was a flaw in the interactive part that communicated with the user.
Your complaint is interesting, because the risk is very much the same posed by sudo (and every other SUID root) utility: The user is allowed to directly interact with a process which has higher privileges than the user.
Windows eliminated it. What about SUID root tools, which have historically *many* vulnerabilities and actual exploits and system compromises on its conscience?
I also remember when Vista moved graphics processing into user mode, so that the usual BSOD from graphics drivers famous in XP would simply be an abnormal termination. Reading suggests this was reversed in 7 because of the slowness this added.
Sorry, but this is BS. You need to cite sources for that "reading" you have done.
WDDM is still very much a split driver model where the driver author has to create a (small) kernel mode part and a user model part. The graphics subsystem is still much more stable on Windows than Linux. And even when the driver or hardware fails (e.g. overheated) it merely resets and comes back up, *without* killing any processes, clipboard or services.
If graphics - fundamentally the way the OS communicates with the user, since the command-line is supposed to be a second resort - has to be so close to the metal it can't be in user space without slowing it down, this is not good.
Wrong on all counts. Windows allow multiple ways to "communicate with the user". Core versions of the servers, for instance, does not use GUIs. And it is your BS claim that it "is slowing it down". All benchmarks I have seen strongly suggests that Linux has a very hard time keeping up with Windows in this area - even when Windows uses a compartmentalized (and more stable) driver model.
But if the intent is to provide a windowing environment, and the method of doing so is not secure, maybe the kernel has exceeded its usefulness.
1998 called. This is not the 9X kernel. The Windows kernel of today runs services in a ''seperate session'' from the users session.
I should also say that a lot of uninformed people parrot the idea that the kernel is well designed, siply because it flies in the face of all the Microsoft hate. The original nerd hipster, who likes something - or believes that something can be good - even if the masses hate it. Or just because the masses hate it.
So far you have offered nothing but speculation and outdated myths. Talk about uninformed.
I have personally used a Shatter attack to expose passwords masked by asterisks. There is a single byte in the window definition that says "replace every character with this one because this is a password box". If it is not filled in, the text box is normal. If it is filled in, it's a password box. Most apps that display a password set the password style (by default filling that byte with an asterisk) and put the password up.
I don't know a single application that pre fills password boxes with the current password. Would you care to elaborate on that?
Since Windows Vista, applications running with medium integrity level *cannot* freely send messages to other processes' windows. UAC integrity levels mandate that in order to send
Slashdot Mirror
Windows 8.1 does away with the fixed split when you run two modern apps in split view. It used to be that you had two "modes" - one for when your app was the main app and one for when your app had the narrow strip at the left or right.
That last mode is now gone. Your app may now have both more and less space. As an app developer you'll have do content with this more fluent split. It has actually broken several apps. Not that they will not run - they just look like s*** when they don't take advantage of the assigned space.
Yes - as an app developer I can test this on the preview version of 8.1 - but it would be nice if I could actually test on the real RTM version.
What irks me is that I have seen no really good explanation from MS as to *why* we will not get the RTM bits. Which makes you start guessing. Is it perhaps that it is not quite ready, and they want be able to push last-minute updates to a known and controllable crowd (OEMs). Maybe they are afraid that if a broader community (without NDAs?) got to see the unfinished bits they would risk a bad rep even before launch?
If that is the case, those in charge are really, really stupid. The OEM bits *will* leak to the Internet at some point.
Powershell isn't built-in....
Yes it is. Since Windows 7 and Server 2008 PowerShell is considered part of the operating system. Several OS features such as the troubleshooting packs rely on PowerShell. The OS comes with PowerShell and you cannot even uninstall it (you can uninstall the ISE but the console remains).
Mark Russinovich (practically reverse engineered the Windows kernel and wrote books about it even before joining MS)
Scott Guthrie (a techie succeeding in a management position, apparently winning a lot of respect by his employees),
Scott Hanselmann,
Anders Hejlsberg (created C# and still oversees it's development, latest with true async continuation support)
Jeffrey Snower (created the vision driving PowerShell with his Monad Manifesto and actually saw it through, completing with Desired State Configuration in PowerShell 4)
Don Symes (F# fame),
Don Box,
Neal Gafter (previously of Java fame)
Dave Cutler (yes, he apparently still works for MS)
I was really, really sad to see Erik Meier go. That was a colossal loss. But Microsoft is not short of outstanding engineers.
The only sane thing to do is use a POSIX OS: Those who do not understand POSIX will re-implement it poorly. See BASH vs Power Shell, oh look a command line interface... like you get when you start typing on the interface formally known as Metro...
POSIX is based on 1970 era ideas of operating systems. While you can argue that it is time tested, there are also many areas where the designs are showing the age. Todays hardware is radically different from what could even be imagined just 20 years ago.
The Windows stack is much better positioned to make efficient use of resources in an increasingly parallel and (not least) asynchronous world. Asynchronicity in POSIX is a meager story, so much so that Linux had to go invent epoll to avoid inefficient busy polling*. Meanwhile Windows NT always had callback/event based asynchronous/overlapped IO built in.
But perhaps more importantly, Microsoft is quietly transitioning the APIs and guiding developers use to asynchronous programming patterns. Traditionally only select types of applications would use asynchronous programming patterns. Think database servers and other server-type of applications where the added complexity was justified by the need to scalability and performance. But asynchronous programming techniques was frequently deemed too complex for ordinary applications, web applications and the like, even though they could benefit from it. The problem was the balance between complexity and effect.
Witness Windows Runtime where any operation that may take more than 50ms is offered as an asynchronous operation exclusively, i.e. developers are guided to use asynchronicity. That would be bad if it wasn't for Microsofts innovations in bringing asynchronicity up from to the application developers. Programming languages like C#, VB.NET and F# now allows application developers to take direct advantage of inherently asynchronous APIs.
Asynchronicity is not multi-threading. Traditionally developers has solved asynchronous requirements by spinning up a thread (or use one from a pool) and have the thread do the waiting. While it seemingly worked ok (for a while), it is a waste of resources when all the thread does it is block waiting for an IO request to complete. As more and more applications need to interact more and more with external resources, this waste of resources become massive.
Unlike the Linux kernel, the Windows kernel implement overlapped/asynchronous IO (disk/network/...) using the reactive pattern (IO completion ports). Think DMA: As a developer you instruct the OS to fill a buffer with bytes received from a network stream. You *offload* the operation to the OS (which will quite possibly use DMA internally) and you don't hear from the OS again until the operation completes (or fails), i.e. no context switches back and forth. The POSIX doesn't even specify anything like that. Linix has epoll which is the proactive pattern: The OS will tell you when there are bytes ready to be read, but it cannot take responsibility for the entire logical operation. This creates more context switches.
POSIX is hopelessly outdated, and transitioning to POSIX in an age where every POSI" OS has had to implement extra mechanisms just to compete and take advantage of modern hardware, would be stupid. Windows kernel and development stack is much better positioned to meet the challenges of massively asynchronous applications.
Go admin an IIS server and your opinion will change rapidly!
I play with some php scripts on some VMS on my home machine but the admins I have talked too love the CLI and the non registry of Unix. There are some things were the only option is to do a reformat and install because of something you did with Windows 6 installations ago. Changing an XML file wont fix it as it is event driven and the registry is a black box of cryptic hex decimal keys!
You may be good at playing Unix. But your ignorance of Windows does not mean a Windows admin would be equally clueless. Clue: IIS does not rely on the registry for website or server administration. The registry contains very, very basic configuration parameters. You may have experience with (or talked to someone who used) IIS6 and the metabase. That was still not the registry, though.
Apache httpd's config files are one of the best examples of how convoluted file based configuration can get. It is a pseudo-xml line-oriented format where every module use it's own way to refer to the same concepts, such as headers and cookies.
And yes, IIS sites are now fully configurable through XML config files, which are built using an extensible model (config sections and config groups).If you do not like XML files there is also a full configuration API exposed as .NET as well as PowerShell cmdlets.
You can now type
IIS:
which will change your PowerShell "working location" to IIS. Yes, the IIS management model (sites, application pools, bindings etc) is exposed as locations. You can now even cd to your site:
cd Sites/MyCompanySite
From there you can list the content using ls. From the Sites node you can create, remove, rename and copy websites as if they were files, using the same cmdlets you would use for files. What could be easier than that?
Oh, how would an Windows admin figure out what he could do with the webserver? He lists the commands of the webadministration module:
get-command -module webadministration.
IIS can be administered through text (xml) files, .NET/COM API, PowerShell, the management console plugin and graphically through the IIS administration tool. How again did you administer an Apache? through cpanel? (yikes)
Yep, installed packages are available through the Windows Management Instrumentation - where you'll find rich information about everything related to system management, from system board, network adapters, performance counters, drivers over printers, volumes, disks to installed software, updates, running services etc.
Yes, this model offers much more information that you'll ever get from a Linux system unless you have dip into some serious log file archeology.
The WMI classes are not part of PowerShell, but PowerShell will seamlessly integrate with the WMI/CIM model. Consequently, the WMI classes are not documented as part of PowerShell. However, they are very well documented. To get a little feel for what type of information can be obtained for a Windows system, look at the documentation for WMI. There are also CIM classes which should work cross platform with any system that adheres to DMTFs WBEM protocol and CIM model. Yes, they are available for Unix/Linux as well.
Your example is actually very interesting. You managed to figure out that Win32_Product was *probably* the WMI class you wanted. Great! here is how you will progress from there: run the command and pipe the result through the Get-Member cmdlet to get an overview of the available information (properties, methods).
Get-WmiObject win32_product | Get-Member
From the answer (cannot be shown here due to ./ junk character filter) you can see that Win32_Products has (among other properties) a caption and a version. Hence, you type (or press up-arrow and edits the prev line):
Get-WmiObject win32_product | Format-Table caption,version
And voila you have your installed products with versions, nicely formatted in a table. This workflow is actually very, very common with PowerShell:
1) locate the command,
2) pipe the results through get-member (which has the standard alias gm because it is used so frequently),
3) chose properties,
4) re-run the command but pipe the results to one of the export-, out- or format- cmdlets.
Yes, you can export the list as comma- or tab-separated values instead by piping the results through Export-Csv:
Get-WmiObject win32_product | select caption,version | Export-Csv myproducts.csv
The GPs point was exactly about the discoverability and consistency of PowerShell. There is no overloaded use of -e options. All options has meaningful names, but can be abbreviated as long as there is no ambiguity. Output from cmdlets are self-describing and you can discover both properties and methods.
And PowerShell works with objects. If you inspected the output from the Get-WmiObject win32_product | Get-Member, you would notice that the returned objects each expose an Uninstall method. See if you can figure out what Get-WmiObject win32_product | where name -like "*Java*" | foreach Uninstall will do.
I can't think of anything Powershell could bring to the *nix table that hasn't already been around one way or another for decades.
PowerShell is not a good fit for *nix.
Most Windows APIs (and indeed the Windows kernel with it's concept of handles) are already object-oriented. The low level stuff is typically exposed through native COM APIs. The manageability of kernel, devices etc is exposed through WMI. Applications typically through COM or .NET. PowerShell unifies all these object models.
Not so on *nix. That is not to say that some of the ideas from PowerShell could not be beneficial to *nix shells. But if you ported PowerShell to *nix you would still need some object-oriented view of the system to reap the benefits.
It's just two models with advantages and disadvantages for each OS. *nix use a lot of text files and the traditional tools consume and produce text. Hence, a text oriented shell makes sense, and especially a powerful tool like awk.
Windows does not use a lot of text files. XML files are becoming more prevalent, but mainly configuration is done through object-oriented APIs. Hence, a shell that allows access to those APIs, that speaks objects and makes XML grokking easy makes a lot of sense.
Which is also why a text oriented shell like bash would be inferior (on Windows) to something like PowerShell.
Just different ecosystems. But the days where Windows was lagging *nix on scripting capabilities are definitely over.
I'd use Invoke-WebRequest - which has a standard alias iwr.
For instance:
(iwr http://apache.slashdot.org/story/13/08/12/2236256/apache-web-server-share-falls-below-50-percent-for-first-time-since-2009).ParsedHtml.getElementById('title-49466063').OuterText
will invoke a web request and get this slashdot page and use the COM API to get the title element (getElementById is exposed as an IDispatch method) and print the title.
FWIW, I think the work-around was calling powershell with my script as the parameter instead of calling my script directly.
Yes - you can always invoke powershell.exe with a -command parameter. Given that it can take a script block and/or multiple statements separated by semicolon you can invoke a "script" like that.
Script signing is not designed to be a permission mechanism. Rather it is an integrity mechanism, one that ensures that the script has not been tampered with at rest or in transit. You do not authorize anyone to run a script by signing it, instead you guarantee them that it has not been changed by anyone since it was signed.
As a sysadmin you may receive a script from a developer who instructs you to "run it on the production server". You may (rightfully) be suspicious towards such requests, especially if it is a highly secured server or a server in a regulated domain. But if the script is signed by an auditor/supervisor authority and you have ok through change management, you are in the clear. Script signing supports such a scenario.
The default setting to disallow *all* script file execution is just Microsoft erring on the side of caution. They want you to explicitly and knowingly set the execution policy to something else. The same reason that ps1 files are associated with notepad and *not* with powershell. If you doubleclick a ps1 file, the file doesn't run. Instead notepad pops up. :-)
I've also read that Microsoft planned adding an optional view pane to every control panel and administrator tool in Server 2012 that would output the PowerShell equivalent command to anything you did in the GUI. That strikes me as a brilliant way to turn your slow click-monkeys into fast shell admins.
Maybe they planned it that way, and the server manager certainly offers to quote the powershell script it will execute when you install features and/or roles on a server. However, it does not seem to have penetrated all features, as of Server 2012, and the control panels for the individual roles (IIS, AD etc) typically do not offer such a feature. So if that's their grand plan, they are not there yet.
You *can* however often "export" the setting that you have chosen using the server manager. This is not export as a powershell script, rather the chosen setup is exported as XML which can be *used* by a PowerShell install script at some later point in time or on some other server to repeat the installation.
With Server 2012R2, PowerShell will be bumped up to version 4. Version 4 includes desired state configuration which extends PowerShell with recipe-like declarative functionality. I suspect that this is going to form the backbone of the integration of Server Manager and PowerShell in the future, i.e. rather than generating an imperative script, the Server Manager GUI can generate a PowerShell recipe (formally also a script, albeit a declarative one) which can be readily executed by PowerShell (v4).
The desired state configuration include ways to describe dependencies, package manager style.
I'd like to see Red Hat or Canonical (Ubuntu) do something similar for Unix, but I don't think even Red Hat has the engineering resources for a project like that.
Like a GUI frontend to puppet or chef?
The problem I had with powershell, which I assume is commonplace, is that I fired it up expecting it to be a backwards-compatible superset of cmd.exe. It isn't, lots of the syntax that works fine in cmd.exe gives errors in Powershell or works but does something different from the cmd.exe equivalent.
Yes, PowerShell is significantly different from cmd. Bash also broke some backwards compatibility with the earliest shells. cmd to PowerShell is a much bigger leap compared to the leap from the first sh to bash. For one, the commands of cmd are (somewhat) unix style in the way they use text/stream stdin and stdout. PowerShell does away with that and streams objects. All PowerShell cmdlets stream objects (COM objects, .NET objects, WMI objects wrapped in PS extended type system). Backwards compatability with older utilities is achieved by regarding old utilities as commands that consume and produce sequences of strings - where string is an object type.
It has arcane syntax and plenty of warts, but an investment in bash will probably still be useful in another twenty years. Will Microsoft be using Powershell in ten years, in a form that's compatible with current syntax?
Who knows? Will you still be using bash if something vastly better comes along? One problem with bash (and an obvious difference between PowerShell and bash) is how bash is still created to run on a single machine. Yes, you can use SSH and other tools to fan out and run on multiple machines, but each script is still understood in the context of a single machine. PowerShell is designed with remoting in mind, and many of the commands - and all of the workflows - support multiple remote machines by default. This is not merely the capability to launch remote commands, it also extends to being able to control remote jobs through local job commands and to how the results are marshalled back with a reference back to the computer, thus the command consolidates results from multiple computers into a single result
Unfortunately, I have no graphs I can share with you due to confidentiality reasons. You can get Apache to outperform Nginx by configuring Apache to use prefork, then increasing Linux's file descriptors to a much larger setting than default to coincide with the forked processes and the connection limits you wish to handle.
Using processes to serve individual requests seems like a massive waste of resources, and I have a hard time believing this will run faster than a standard threaded worker. Do you have any theory behind why Apache would process requests faster with preform as opposed to worker?
I have searched for optimization guidelines for Apache and I cannot find anyone recommending this setup, except for when compatibility is required.
I suppose that if Apache is used to serve non-static content using a foreign/3rd party module, there could be local lock contention issues if the module is poorly written. If the lock contention is intra-process (process local locks) I suppose that you could get around that by running multiple processes. But that would merely mean that the server is not being slowed down waiting for locks, not that it will run faster than Nginx.
But in this case no such modules are involved, and lock contentions are clearly not at issue for any browser in the bandwidth saturation tests.
Multiple processes is what nginx would need to get the maximum performance out of a the Quad-core machine.
1. It is mentioned that default configuration was used, but the tester was willing to adjust parameters if the server was not taking advantage of the machine.
2. The CPU utilization at bandwidth saturation test should not be impacted, even if Nginx was running on a single core - unless it showed that bandwidth could not be saturated. But bandwidth was saturated with Nginx and cpu utilization was more than double that of lighttpd and IIS.
And he used a different harddisks for Windows than Linux are they of the same type ?
That could be an issue. But the test used a "real, minimalistic page with a variety of resource sizes and types". The content was static so it will quickly be served from the disk cache negating any performance difference between drives. And again, that should not have a bearing on the bandwidth saturation/cpu utolization test.
I'd say its a bit misleading. Sure, Windows is easier to make work, but to actually secure and keep maintained is a pain in the arse.
Can you elaborate on this, please? As far as I know, Windows Server and IIS comes pretty secure out of the box.
For instance, when you create a new website you automatically also get a specific (virtual) identity for the website/app pool. By default the app pool identity does not have any permissions outside the website directory, effectively preventing the cross-contamination that is so common on Apache setups (yes, because the admins did not bother to create accounts per website, or because such a setup decreases the website density on a shared server).
On IIS, the "account per website" is automatic and implied. The default permissions are restricted and applications are isolated.
If you let the Windows server auto update you are also pretty secure at the OS level. Install headless if you want to decrease the attack surface. Even if you choose to manage the patching yourself, Windows still receives fewer patches (fewer vulns) compared to Linux and they are batched in monthly updates which means you only has to manage patches once per month.
As said earlier: Nginx is faster than both.
nope.. IIS almost 2x faster than Nginx when serving static content.
Nginx serves static pages faster than Apache or MS. Try again.
http://www.webperformance.com/load-testing/blog/2011/11/what-is-the-fastest-webserver/
IIS outperforming Nginx by a factor two. Your turn to "try again".
As said earlier: Nginx is faster than both.
Citation needed.
I could only find this: http://www.webperformance.com/load-testing/blog/2011/11/what-is-the-fastest-webserver/
Apparently you are wrong, IIS beats up the competition; only lighttpd comes close.
In the tests,
* IIS used only half the CPU compared to Nginx at bandwidth saturation.
* IIS delivered more than double peak throughput
* IIS had about half the response time compared to Nginx, under medium load.
In short, IIS appears to be twice as fast compared to Nginx.
What benchmarks are you thinking of when you claim "Nginx is faster than both"? Do you have a link?
There are *a lot* of little things in PowerShell that makes you go "aw, that's a good idea". Things you will not find in other shells and neither in Pytho, Ruby or Perl.
Off the top of my head:
* Consistent common parameters for "impact management": You can pass a parameter called -WhatIf to every built-in command that may change persistent state. The -WhatIf parameter runs the command in simulated mode, only echoing on the console what it *would have* done. Similarly a common -Confirm parameter which asks *before* changing persistent state. It even works for scripts and functions: If you declare that your script (in a .ps1 file) "supports shouldprocess" you can pass the -WhatIf parameter to your script and PowerShell will set the whatif preference for the duration of the entire script - as if each command of the script had been passed a -whatif parameter as well.
* Commands, functions, script blocks and script files declare parameters with (optional) static types. This information is used by PowerShell to coerce values to the correct types before invocation. But the declarations can also contain declarative validation attributes, allowing the *shell* to validate parameters before invocation. Declarative validation can validate required parameters, string lengths, number/date ranges, regular expressions, value sets. The kicker here is that the script author does not need to *implement* validations, merely declare them, the information is available to the shell which can use it to both validate parameters before invocation, but *also* to report the validations through the help system. That's right, when you set up validation, help text that describes the acceptable values is automatically generated from this meta information.
And yes, even the tab completion (or intellisense in the integrated scripting environment) will pick up on the parameter type and validation. If you restrict a parameter to a certain value set, tab completion will cycle through those values when the shell determines that you request tab completion for the parameter.
* The PowerShell help system allow for in-script help text through special code comments. No need to author external help files. You can write the documentation right there in the script (using special "dot" comments), and when you do man myscript.ps1, the help system will report the documentation.
* PowerShell workflows allow scripts to suspend and resume at a later time. No, this is not the process suspend of sh shells. PowerShell actually saves the state of script execution to persistent storage and you can resume execution later, even after system restart - or on another computer. This is incredibly useful for the type of scripts that manages farms of servers and that may be running for a long time. If the script is somehow interrupted (power failure, hardware failure) it can later automatically pick up its execution from the latest savepoint. I.e. you can restart it and have it run to completion.
PowerShell is not simply a programming language. It has many features which are directly aimed at being used in a scripting setting and which are not found in general purpose language like Python or Ruby.
And for God's sake, the whole signing scripts business with Powershell is a tragedy. I can understand the value of being a little bit more tight with scripts that can do harmful things, but it should only matter for scripts that need to run as admin or do system management tasks. I shouldn't need to cryptographically sign a script to extract tags from music files, for example. The process to do the signing is itself unnecessarily complex.
Just set the execution policy for the scope that you want. Type man set-executionpolicy -para scope. You will notice that scope can be set for the process, the current user account or for the local machine. So if you want to then simple set a less restrictive execution policy (like RemoteSigned) for your current user. That will still prevent scripts downloaded through a browser or received through a mail to be executed.
There are a lot of legitimate uses for script signing. For instance, for a tightly managed system you could put in place a regime where an auditor/reviewer must sign a script only after review, and the farm of machines will only execute scripts that have been signed by the reviewer. Thus you can have devops develop scripts and test at their test systems, but to deploy the scripts they must follow the review process.
What is the gain for this pain? From a business standpoint, I would want to know what R2 delivers that would necessitate a price increase. If there isn't much then this makes it hard sell for businesses: "We get to pay more for no reason!"
A number of important improvements to Hyper-V allowing higher VM density and (if you run 2012R2 guests) improved performance because of more direct access to hardware. Also, Hyper-V replica
Storage Spaces with tiered storage (what is usually only available with SANs). You can fit a server with regular disks, fast disks and/or SSDs and set up tiered storage spaces, e.g. with parity (think ZFS). Server 2012R2 will then move "hot blocks" to faster disks and move them back to slower disks when they are not accessed as often anymore, letting other hot blocks utilize the faster tier.
A number of manageability improvements, among those PowerShell with Desired State Configuration (think puppet/chef on steroids for what is not already covered by group policies).
There's more. You can read some of it here: http://www.zdnet.com/windows-server-2012-r2-a-first-look-7000017675/
Whether it is value enough to justify the price increase is probably subjective. However, it could steal away some SAN business as you now basically can set it up to provide the same features as (at least) entry level SANs. Also the higher VM density could be worth money.
The only thing slightly unreasonable to me is the "Are you willing to have your company name and URL displayed on our MAPP website?" question, but only because it has nothing to do with security and it probably the result of having to please the marketing department.
In the interest of public disclosure of *who* has access to advance information about vulnerabilities before they are patched, I actually find it highly relevant. I can see good coming from giving truly security minded companies a head start. But I would like to know *who* gets this head start.
A few years back a rogue Chinese security company (or just a rogue employee?) leaked proof-of-concept exploit code to Chinese hacker websites. The security company had received the PoC code from Microsoft as part of the MAPP program. The intention was that security companies (AV vendors) could use the PoC code to create heuristics/signatures to scan for exploit attempts.
Of course the spin on slashdot was that Microsoft had "leaked" exploit information. Go figure.
It is also in this light we have to view the "Microsoft shares vulnerability information with the fr***** NSA!!! OMG! Conspiracy!!!" debacle.
Problems with NSA overreaching notwithstanding, I for one believe that NSA should receive vulnerability information at about the same time as it is made public to the other MAPP partners. This news is just that similar agencies of other countries now will receive the information at the same time as NSA and other MAPP partners.
Which is 1-3 days in advance.
The NT kernel was based on VMS in it's core design, which is what matters, not the APIs. VMS APIs were based on FORTRAN interfaces, while NTs were not, so of course they're not "compatible."
BS. The NT kernel was created based on experience with VMS and a lot of new ideas. For instance, permeating the entire NT kernel is the concept of handles. A handle identifies a kernel object with a jump table. What we today call an object (in the OO sense), as it identifies and encapsulates an piece of memory with data as well as method references.
One of the advantages of this design is that the desired access level (read/write/delete/...) can be expressed when the handle is originally opened. If access is allowed, the kernel object identified by the handle will have the corresponding method pointer reference the actual kernel method that performs the operation. If a given access was not requested the method pointer will simply point to an generic "access denied" method. The upshot is that permissions are checked once when the handle is created. After that the granted access is implicit the the function indirection. If you didn'r request write access, the "write" method is mapped to "access denied". Not having to check permission of the user on each use of the handle yields much better performance than having syscalls check permissions upon each access to a file.
VMS was a much more traditional OS. It didn't have this object-oriented view of its internal structures.
The trouble with GPOs is that many of them are extremely porous and can be bypassed with minimal effort. They are enforced mainly by the programs that they apply to. For example, the GPO to stop people using the command prompt can be easily bypassed simply by having a cmd.exe binary that ignores the setting. Similarly with regedit.
Uhm. Not all GPOs are security policies as you seem to believe. If you do not want users to access resources on the local computer then use permissions to restrict users instead of trying to stop them from going to the command prompt. This is not your stupid sudo. There are other and better ways to secure resources than trying to prevent users from running applications that can access them.
You may hide the command prompt if you don't want your users to strafe out where they don't know how to come back from. But if the intentionally launch an application (or a copy of the shell) they go there themselves.
It should definitively NOT be your security boundary.
You also fail to understand how GPOs are applied. They are *NOT* enforced by the programs they apply to. Policies are a declarative way to configure local state, primarily the registry. Instead of a script trying to run remotely (or on every boot), policies are enforced at boot time (machine policies) *or* at logon time (user policies).
Individual apps do not check up against GPOs. They read config state from the registry (or old style config files). This provides a clean interface where GPOs are not *necessary* (you can use other means to alter the registry) but *available* if you need to enforce a set of configurations consistently across all or subsets of machines and/or users.
You can think of GPOs as declarative scripts. The group policy service reads/interprets policies and performs actions such as setting registry values, changing text/config files or (seldom) running scripts. But because they are declarative they can inherently be applied and re-applied and rolled back.
On Linux/Unix you will need something like puppet or chef to match the declarative power Windows has had with GPOs since the introduction of AD.
http://forums.linuxmint.com/viewtopic.php?f=47&t=99890
http://fixunix.com/redhat/489285-rhel-5-1-rhel-5-2-dependency-hell.html
http://www.freelists.org/post/oracle-l/Linux-X86-26-Oracle-9204-and-RPM-Dependency-Hell
http://unix.stackexchange.com/questions/53077/firefox-circular-dependency-hell-on-linux-mint-13
http://linuxgazette.net/issue71/tag/3.html
http://lwn.net/Articles/198455/
http://forums.opensuse.org/english/get-technical-help-here/applications/406017-does-dependency-hell-still-exist-2.html
* "The best (worst) way to get dependency hell is to add too many repositories. Eventually one will find the right combination of conflicting repositories to create a situation of dependency hell."
* "The problem is the more repositories that are added, the less and less likely that applications are built against the same set. "
* "Dependency hell ALWAYS exists. ALWAYS (Yes, Debian users, I'm talking to YOU). The question is whether or not if somebody tries to NOT go to dependency hell, is the system going to take them there anyway."
http://unix.stackexchange.com/questions/32594/fedora-16-dependency-hell
http://www.eonlinegratis.com/2013/dependency-hell-trying-to-install-gcc-on-centos4/
Oh, dependency hell is real alright!
(from http://archive09.linux.com/feature/155922)
We have all been bitten by this. It is not that prevalent on servers (what I use Linux for), but desktop distros definately suffers from this.
also:
http://www.linuxquestions.org/questions/linux-newbie-8/dependency-hell-233892/
http://fixunix.com/suse/265243-dependency-hell.html
http://forums.fedoraforum.org/showthread.php?t=289520&goto=nextnewest
http://www.brighthub.com/computing/linux/articles/52282.aspx
Dependency hell is real. Package managers help mitigate the problem locally, but software repositories are distro and version specific. Once you step outside of the official repository you risk stepping into dependency hell, as many of the above experienced. I fully concede that it *shoudn't* be a problem if every piece of software author did what they were supposed to do. It is the OSs job to provide a service and guidance so that authors do the right thing. Linux is not quite there yet, unfortunately. That's why you see the typical advice to install from the "official" distro and version specific repository. But that model is flawed.
Interactive services can expose system-level access to users - a design flaw shich should not be allowed.
This was deprecated in Windows 2000/XP (and you had to explicitly allow a service to interact with the user) and it was disallowed in Windows Vista and has been ever since.
The problem was that a service which typically runs with some form of elevated rights (at least to some resources) could expose those rights/permissions if there was a flaw in the interactive part that communicated with the user.
Your complaint is interesting, because the risk is very much the same posed by sudo (and every other SUID root) utility: The user is allowed to directly interact with a process which has higher privileges than the user.
Windows eliminated it. What about SUID root tools, which have historically *many* vulnerabilities and actual exploits and system compromises on its conscience?
I also remember when Vista moved graphics processing into user mode, so that the usual BSOD from graphics drivers famous in XP would simply be an abnormal termination. Reading suggests this was reversed in 7 because of the slowness this added.
Sorry, but this is BS. You need to cite sources for that "reading" you have done.
WDDM is still very much a split driver model where the driver author has to create a (small) kernel mode part and a user model part. The graphics subsystem is still much more stable on Windows than Linux. And even when the driver or hardware fails (e.g. overheated) it merely resets and comes back up, *without* killing any processes, clipboard or services.
If graphics - fundamentally the way the OS communicates with the user, since the command-line is supposed to be a second resort - has to be so close to the metal it can't be in user space without slowing it down, this is not good.
Wrong on all counts. Windows allow multiple ways to "communicate with the user". Core versions of the servers, for instance, does not use GUIs. And it is your BS claim that it "is slowing it down". All benchmarks I have seen strongly suggests that Linux has a very hard time keeping up with Windows in this area - even when Windows uses a compartmentalized (and more stable) driver model.
But if the intent is to provide a windowing environment, and the method of doing so is not secure, maybe the kernel has exceeded its usefulness.
1998 called. This is not the 9X kernel. The Windows kernel of today runs services in a ''seperate session'' from the users session.
I should also say that a lot of uninformed people parrot the idea that the kernel is well designed, siply because it flies in the face of all the Microsoft hate. The original nerd hipster, who likes something - or believes that something can be good - even if the masses hate it. Or just because the masses hate it.
So far you have offered nothing but speculation and outdated myths. Talk about uninformed.
I have personally used a Shatter attack to expose passwords masked by asterisks. There is a single byte in the window definition that says "replace every character with this one because this is a password box". If it is not filled in, the text box is normal. If it is filled in, it's a password box. Most apps that display a password set the password style (by default filling that byte with an asterisk) and put the password up.
I don't know a single application that pre fills password boxes with the current password. Would you care to elaborate on that?
Since Windows Vista, applications running with medium integrity level *cannot* freely send messages to other processes' windows. UAC integrity levels mandate that in order to send