For server functionality pure bullshit. I have a decade's experience running Windows and *nix servers, often in the same networks and while Windows has AD and GPOs to its benefit, in other respects it is horribly backwards and painful to use. Just backing up the system config in Windows is appallingly difficult compared to *nix.
So, how does Linux handle online backups of running server workloads? Does Linux have a way to signal to running services (like RDBMSs, hypervisors, file servers) that a backup is about to happen, negotiate which files are to be included in the backup and then in a fragment of a second work with the running service to synchronize disk content so that the backup will be consistent?
A running database server will almost invariably hold some state in memory. If the power is lost it will be able to rebuild from the disk state, but that can be a time consuming task. If the backup system is simplistic it will just back up the disk state of any file. Upon restoring it will appear as if the power was lost and the roll-forward log will have to be played.
A more advanced backup system will integrate with the services to ensure that for a very brief time (just enough to take a snapshot) the disk state is consistent and thus will not require a rebuild/roll forward if it is ever restored.
Windows comes with Volume Shadow Copy Service (VSS) and a file system which supports block level snapshots. VSS works with VSS aware applications (VSS writers) such as Microsoft SQL Server, Oracle Database Server, Exchange Server, Active Directory, NTFS and Hyper-V server. When a service is a VSS writer it participates in VSS coordination/synchronization to create consistent disk state.
It even works through Hyper-V: When you back up the Hyper-V host, Hyper-V itself is a VSS writer which recursively invokes the VSS running inside guest OSes (if Windows) to ensure that any service inside the Hyper-V guest OS is also disk consistent exactly when a snapshot of the virtual hard disk image is created.
To my knowledge, Linux doesn't have anything like VSS. Which means that each application/service must be handled separately. Typically you will stop the service during the backup. Some services such as PostgreSQL can recover from a non-consistent disk image; others can not. Individual applications may have commands/services which allow admins to "dump" state to a file to be backed up separately. All in all reliably backing up a running Linux server is more complicated compared to backing up a running Windows server with VSS aware services.
So what exactly does it do that similarly equipped Linux machines/vps' can't do that justify the cost?
* New resilient file system ReFS (think BtrFS when completed) * Storage Spaces (think ZFS storage pools) * SMB 3.0 - higher performance network transfer, transparent failover, SMB scaleout (multiple servers serve same shares and aggregates bandwidth), SMB Direct (efficient remote direct memory access), SMB Multichannel, Volume Shadow Service (VSS) for SMB file shares, SMB encryption, SMB Directory Leasing (negotiates and updates local caches of metadata over slow networks) * Dynamic access control (claims and policy based access control). Think SELinux, grsecurity. Access control based on what application the user is running (sandboxing), from what type of device the user is accessing the resource, on other user attributes than security groups (e.g. who is the manager, what department does the user belong to etc), access control based on attributes of the file (e.g. classification, select words of a Word document) * RemoteFX improvements, e.g. virtualized GPUs (can use local or remote shared GPUs during RDP sessions), remote low-latency multitouch. * Direct Access over IPv4. Think hassle-free VPN. * Hyper-V 3: ethernet cable live migration (neat trick) lets you migrate VMs off one server onto another server over the network without the servers sharing anything. Many Hyper-V manageability improvements. Crazy scalability, e.g. a 63-node Hyper-V cluster runs 4000 concurrent VMs simultaneously. Hyper-V replica. * Server manager: Yes, a Metro (oops - "Modern") style management app for multiple servers. Integrates with response files and powershell workflow scripts to manage multiple computers (servers/workstations) at once - e.g. install new software, perform configure actions. * PowerShell 3 with new features such as resilient remote connections (you can detach from a remote session and pick it up later/from another device), workflow scripts which can perform actions with suspend/restart/repeat semantics. No, not just "suspend process" - but actually persisting the state of a script to be continued later, e.g. after a computer restart (or from another machine). * Thousands of new PowerShell cmdlets (many/most automatically derived from WMI providers) to control virtually anything on local or remote computers. * Block sized data de-duplication
These are features I could find by googling. I'm sure there are more. Obviously not all of them will appeal to Linux enthusiasts. But still...
COM is a poor way of doing client/server and dynamic link libraries rolled into one.
Opinion.
There are only a few problems solved by COM objects which already have proven solutions in Unix/Linux like systems:
1) having one COM object offering services to several applications to reduce duplication. It's a client/server design, but with nonstandard communication betwen the client and the server in the form of an API instead of a socket connection.
It may not be *your* standard, or a Unix standard, but COM is a windows standard which is very well documented. You also conflate sockets with higher level communications. Sockets are the channels over which 2 processes communicate. But sockets does not specify how to send a datetime, a floating point number or an interface which allow remote control of an application. This is what COM is for.
You also completely ignore the fact that COM is a way to build software, where sockets are still a way to make software pieces communicate. In Word, for instance, the document model is built from a number of COM classes (paragraphs, sections, headings etc). Word itself internally uses COM - which it can do because COM itself is a binary standard for organization of virtual method tables with extremely little overhead. Thus, COM objects can be used in-process, using references, passing pointers. Not so with sockets. This just goes to show how little you understand when you compare COM to sockets.
When the connection breaks because the COM object or the application crashes, you get failures that aren't as clean to recover from as a proper socket connection.
BS. COM/DCOM has a very mature failure model. Under DCOM objects has leases which ensures that objects are released if connection is lost. If you use a remote COM/DCOM object and the communication fails you are immediately notified. Are you just making things up as you go?
When you use dynamic link libraries, you get more graceful handling of versioning (note: versioning of DLLs in Windows is hell).
Again BS. COM has a very simple and remarkably robust versioning scheme: Interfaces are suffixed with a version. If a server extends an interface in a non-breaking way (e.g. only adding methods) the same interface can be passed to a client which asks for the "older" version. If the change is breaking the server can still relatively simple accomodate both interfaces. As for DLL hell, where have you been living? Windows solved that with side-by-side assemblies. You havent has anything resembling DLL hell since Windows XP (SxS was introduced with Windows XP). It is Linux that is stuck in the past with dependency hell. Software repositories is only a superficial solution to the problem: All software using the same libraries must still agree on the same versions. Step outside the repository and you are immediately in dependency hell.
2) The Unix pipeline/scripting approach is a cleaner way to combine common functionality available on the system than combining COM objects. At the core the issue is that COM object interfaces are too diverse to be mixed and matched as easily as a collection of scripts with command line switches.
What are you going on about? Now you are comparing COM to the CLI? COM is a way to *build* software so that the pieces can be exposed to external parties. Command line interfaces with "switches" is nothing of the sort.
In particular, it's a pain to shunt an extra middle man object between some program calling a COM object's API member function, and the API function being called, because member function signatures are too diverse. With the command line paradigm this is much easier.
You do not build applications by combining processes through sockets. Is that how you would build Writer? Sockets are used to making applications talk to eachother, not for building the internals of
So your complaint is that you don't know x11 messaging and dbus?
I'm fairly certain that was not what GP meant. But you already knew that.
However, it is indeed ironic how you illustrate GPs point very well by suggesting that x11 messaging and dbus are at all comparable to COM/DCOM. The problems solved by having a OS defined common object model are very real, and versioning/backwards compatibility is just one such problem.
if a site choose to ignore the DNT setting of IE10:
How can the site reliably determine whether the user behind the browser has actually explicitly taken the decision? If an online ad agency decides to ignore the DNT preferences of *all* IE10 users, they will invariably violate the right to not be tracked of a *number* of users.
This could easily land the advertiser in a serious conflict with the EU commision, and if found guilty of ignoring users' wishes they could end up with a *hefty* penalty - and face accumulating penalties until they change their behavior to respect the users.
In the US i guess that it could open up the advertiser to a class-action lawsuit - potentially even bigger then the EU fine.
No, some site on the Bahamas will probably give a damn. But Google - being the company that tracks most users and serves up ads - has *a lot* to loose on this.
This is for Windows only and it does not test applications for security problems, it looks at the entire system and how it is affected by the installation.
Hence, attack surface analyzer.
The tool looks at the surface of a system (not an application) and analyzes how observable changes to that surface could impact security. For instance it will report that a new port is listening after an application has been installed, or it reports that a certain application phones home, or that the application relies on configuration files/installation/registry keys which may not have proper permissions set.
I thought the requirement to run Windows 8 was to have a BIOS option to disable secure boot, or rather, enable legacy (BIOS) booting.
There is no such requirement to run Windows 8. There is a UEFI secure boot requirement if you want to put a sticker on the system saying "designed for Windows 8". There is also a requirement that the user must be able to switch off the secure boot.
Of course, if you want to boot back into Windows requires flipping the option back (the files are signed and verified before loading, so it's not like running another OS will break the security - the UEFI verifies the loader, the loader verifies the kernel, the kernel verifies the drivers and Windows binaries, etc.).
No, you do not need to flip the option back to boot Windows 8. If you don't flip it back you will not have the security that comes from the knowledge that the boot loader and kernel has not been tampered with, but Windows 8 will boot.
Of course, if you want to boot back into Windows requires flipping the option back (the files are signed and verified before loading, so it's not like running another OS will break the security - the UEFI verifies the loader, the loader verifies the kernel, the kernel verifies the drivers and Windows binaries, etc.).
That is correct. But while the signed Windows 8 boot loader may allow for another OS to be booted (as opposed to that OS being booted directly from UEFI firmware), you can expect Microsoft to impose certain restrictions on what that other OS does after receiving control of the system.
Specifically Microsoft will want to avoid a situation where the alternative OS performs a silent minimal boot, installs a hypervisor and then boots Windows in a managed VM. This would effectively be a rootkit. So while canonical and others may be able to obtain keys which allow their OS to be booted from Windows boot loader, those keys may very well come with restrictions/requirements that the OS must itself be signed and it must be visibly different from Windows.
I know RedHat and Canonical were worried that the option would be well, optional, but I thought it was now required. And it will be for a little while because Windows 7 isn't ready for secure boot - it can be EFI-booted in 64-bit mode but that's experimental.
That was basically a publicity stunt from RedHat. They knew all along that Microsoft would want an "off" switch (to run Windows 7, Server 2008, Server 2008R2 etc). But they also knew that it is a difficult topic to explain and so they knowingly created controversy.
Then there is well, Apple. Whose EFI-based firmware probably doesn't have secure boot in it and thus unable to boot Windows 8
Again, Windows 8 will accept to boot on any system. The "secure boot requirement" is a logo requirement. It is not a technical requirement of Windows 8. All it means for Windows 8 - on the technical side - is that its binaries, modules and central configuration resides in signed cabinet files which can be verified by the UEFI firmware. Secure boot is a feature of UEFI - not of Windows 8. Windows 8 supports secure boot by being signed using a key known to the UEFI firmware.
* Unix or *nix are built around the concept of getting work done _away_ from superuser privileges.
So is Windows. And it is actually only partly true for Unix. Unix is too much dependent on UID 0 for too many things. And when you need to perform those actions you need to elevate to root - and break least privilege principle. Windows doesn't have that problem, it has a much more granular security model and "power user" privileges can be delegated - you don't need to elevate root/administrator to be able to back up a system, for instance.
So is Windows. And it is actually only partly true for Unix. Unix is too much dependent on UID 0 for too many things. And when you need to perform those actions you need to elevate to root - and break least privilege principle. Windows doesn't have that problem, it has a much more granular security model and "power user" privileges can be delegated - you don't need to elevate root/administrator to be able to back up a system, for instance.So is Windows. And it is actually only partly true for Unix. Unix is too much dependent on UID 0 for too many things. And when you need to perform those actions you need to elevate to root - and break least privilege principle. Windows doesn't have that problem, it has a much more granular security model and "power user" privileges can be delegated - you don't need to elevate root/administrator to be able to back up a system, for instance.
* The points of distributing software for *nix platforms tend to be few and secured.
That is not a Unix component - and certainly not an OS X component until Mountain Lion. You can argue that Linux repositories comes with added trust because the packages are signed. But Sites like download.com, tucows etc. also allow Windows users to download malware-free software. Have there been cases of malware found in these repositories. Yes, both in Linux repositories and in Windows repositories. You are just blowing hot air. It doesn't really matter if software in repositories is signed or not - what matters is the vetting process. And nothing suggests that Linux repositories are any better at that.
Even a Mac user tends to understand that the prospect of downloading small utilities and games from sources that don't start from Apple.com
No they don't. 10% of mac users caught the flashback infection. That's worse than anything on any operating system, ever!
* Different implementations, so binary compatibility is iffy or nonexistent (compatibility is more at the API level)
Good point. Security through voluntary obscurity and incompatibility. Is this part of Unix architecture?
* My theory: The inner workings of most *nix systems are easier to lookup and are better understood by the power users and admins who run and service them -- It is more difficult to hide malware in such an environment.
BS. kernel.org and linuxfoundation.org were compromised for (at least) the better part of a month by and old and known rootkit. And nobody noticed until they started receiving error logs from components which should only be installed on desktops. All OSes in use today are so complicated that there is tons of ways to hide malware. Even if the malware doesn't try to activelt hide itself, do you think regular users have any idea of which daemons and/or network ports should be running/open on their systems?
To me, the level of cleanliness of a Windows system seems like a big, ongoing guessing game: This is particularly true given that the norm for operating Windows, even in a malware emergency, is to depend on the services of the installed, running, _infected_ system and users are often encouraged to download antivirus tools using the infected system to get rid of the existing malware (so the success rates of removal are lowered and the user ends up with a bogged-down or broken system).
Skype used to have a pretty impressive peer to peer encryption design. No longer, I guess.
Yes it does. Nothing has changed with the peer-to-peer encryption. You have been fed rumors, speculation. Here is what Skype says (but if you *want* to make it into a conspiracy you can of course assume that they are lying):
Skype software autonomously applies encryption to Skype to Skype calls between computers, smartphones and other mobile devices with the capacity to carry a full version of Skype software as it always has done. This has not changed.
This is once again someone irresponsibly reading license terms and trying to twist every phrase and condition into something sinister. Like Skype making sure that you understand that instant messages may be stored on the servers because they need to be synchronized with multiple devices which are not all on-line. Like Skype saving voice-messages - because they are (d-oh!) *voice* *messages* (as opposed to peer to peer communication).
Skype has gone under a number of updates and upgrades since it was bought by Microsoft last year, mostly in a bid to improve reliability. But according to a killer report by the Washington Post, Skype has also changed its system to make chat transcripts, as well as users’ addresses and credit card numbers, more easily shared with authorities.
The " to make chat transcripts, as well as users’ addresses and credit card numbers, more easily shared with authorities" is pure speculation.
And the alleged updates "since it was bought by Microsoft last year" (supernodes hosted in central data centers) was actually started in 2010, well before the Microsoft acquisition:
GDI has been hw accelerated since Windows 3.1. There was a time they even benchmarked graphics card on how quickly they accelerated windows drawing calls.
I stand corrected then. However, the software rendering was done because of the introduction of the composition engine (applications writing into a memory buffer representing the Windows which is then composed by the driver rather than each app being asked to redraw itself in reverse Z-order) - not because hw acceleration was making it unstable.
Many Windows crashes was caused by hardware acceleration. As a result Vista supported less hardware acceleration than XP.
What? Vista came with Aero which is entirely *dependent* on HW acceleration. If your graphics card does not support HW acceleration, you could not run with aero.
Also, Vista changed the graphics model from a redraw model to a composition model. The composition model is again mandatory hardware accelerated. If your card doesn't support graphics composition Windows falls back to the redraw model.
What happened with Vista was that Microsoft split the graphics drivers so that the drivers had to come in two parts: a core part running in kernel mode and a user mode part which does most of the computations.
So while you are somewhat correct that many Windows crashes was due to HW acceleration (actually, more generally dure to bad cards or drivers - not necessarily acceleration), the new driver model did not support *less* acceleration. It supported *more* acceleration (composing, aero glass etc) - only it moved it from kernel mode to user mode to increase reliability.
applications don't get direct access.. drivers do. if the drivers clobber things they shouldn't, they can crash the kernel..
Actually, Windows (since Vista) has a more fault-tolerant hybrid driver model for graphics drivers: A "core" part runs in kernel space and the bigger more complicated part runs in user space. If the part of the driver which runs in user mode causes memory corruption, only the user process is affected. This is the major reason why Vista and 7 systems seems more reliable than XP. Microsofts telemetry indicated that poor graphics drivers and overheating and misbehaving graphics cards were *the* major reason for instability of Windows systems.
Windows also can allow the graphics card to re-initialize if it determines that it has faulted or freezes. For a period I was really annoyed about Internet Explorer 9 when I tried it out. It seemed smooth, especially so when I were scrolling up and down (GPU accelerated). But every 5 seconds or so it would pause for just a fraction of a second. Not much, but definitively enough to being annoying. Little did I know that it was actually the nVidia driver that faulted and the Windows graphics system was actually resetting and re-initializing. When I realized that and updated to the latest nVidia driver the problem went away (I still use Chrome; there still is this "feel" to IE9 that isn't quite right - cannot put my finger on it, though).
they can crash the kernel.. just like the unix derivatives in service today.
I don't think that OS X has a similar model - but then again on OS X Apple can tightly control and regression test the limited number of cards and drivers. I have definitively had X crash on me and taking all the apps down with it on more than one occasion - not so much after running Linux mainly under VMWare and Hyper-V.
How long was kernel.org compromised? Without anyone knowing?
We don't know. At least 17 days was the initial assessment, but kernel.org has - despite claims about openness - never got around to write up a post mortem.
Many of us would like to know what the attack vector was. How a compromised *user* account could lead to the kernel being rooted. How a relatively amateurish infection (phalanx is a old, known and pretty trivial rootkit) could penetrate so deeply into infrastructure run by the people most knowledgeable on Linux *in the world*.
Was the actual attack which resulted in the infection a walk-over or was it more sophisticated than what the use of phalanx rootkit suggests?
Now think back to the debut of mandatory driver signing with Windows Vista - where individual components in your computer would cease to function after an upgrade for no reason other than Microsoft wanted your manufacturer to pay extra for the privilege. Even worse, there really was no way to know before the upgrade if your system would function entirely.
This is so much BS that it could have made a Peter Gutmann "research" report.
1) There was no driver signing requirement for 32 bit Vista. To this day there is no driver signing requirement for *any* 32 bit Windows - including Windows 7. If you upgraded from Windows XP (a 32 bit OS) there would *not* be any issue with driver signing. Microsoft has clearly stated that 32bit Windows are exempt from driver signing *exactly* because of potential backwards compatibility issues.
2) 64 bit Vista *did* introduce driver signing for *kernel mode* drivers. If you upgraded from 32bit XP to 64bit (if your hardware was capable) Vista you would need to obtain signed drivers for the the devices which had *kernel mode* drivers. Part of the graphics drivers execute in kernel mode so you would need signed drivers for that. However most drivers for non-bus devices (a bus device include very generic devices such as IDE, SATA or USB hubs), i.e. most consumer electronics do not need signing.
3) There was an upgrade assistant which would produce a comprehensive report on what hardware and software you could expect to be able to run on Vista. Petty you never found it.
4) Microsoft *never* sees any money you pay for a code signing certificate. Microsoft simply trusts Verisign and a few other CAs to issue authenticode certificates. All the signed driver ensures is that 1) they can find the identity of a publisher of a driver - they assume that Verisign has performed a deeper verification than simply a credit card and 2) publishers or individual certificates can be revoked and thus cause systems to refuse to load malicious or exploited drivers.
As for your "clear path" - MS has stated for Windows 7 that if your system worked with Vista - it will work with Windows 7. They have now stated that if your system works with Windows 7 - it will work with Windows 8. Does it get any more clear than that?
Yes, they're taking a proactive approach to push upgrades from XP.
Yeah, if only they would provide a download link for Windows XP and Server 2003 in a knowledge base article so that we could find it if we bothered to look for it!
So, to protect users from potentially trusting a fake Windows Update server, Microsoft is releasing this update through a Windows Update server, which potentially could be fake? I suppose that if your computer already trusts a fake server, it is too late
This is not a fix for machines already pwned. It is a precautionary step to foil copycats (or the original attacker returning with a new kit). If a machine gets this update it will be immunized to attacks using these certs. You are correct that if a machine is already pwned or on a net with a fake WU server, that WU server could block this update to remain in the loop. This was never billed as a solution for that problem, however. If you suspect that your machine is pwned though a sophisticated attack like the Flame you really need to nuke it from orbit.
However, I wish Microsoft would go back to providing downloadable updates that didn't depend on Windows Update.
Ahem. Microsoft releases all updates as separately downloadable packages. Windows Update / Microsoft Update is merely a delivery mechanism. The knowledge base article (with download links) for this particular one is found here: http://support.microsoft.com/kb/2728973
If the key holder is smart, they'll generate the key on a smart card and arrange matters such that it never leaves the smart card, and then lock it in a safe when they aren't signing binaries.
Actually, keys like this are generated within certified hardware security modules (HSMs) which guarantee that the key will *never* leave the unit, not even if an administrator says it's ok. The HSM simply hasn't got the functionality. The HSM will be able to backup the keys in *encrypted* form to an external unit (possibly another HSM) or media. HSMs typically also has an array of anti-tamper protections such as embedding the chips in solid blocks of epoxy, vibration sensors, temperature sensors, accelerometers, power outage sensors, gyroscopes, x-ray/light sensors etc. HSMs will only sign messages or hashes with a private key if a number of users are each presenting a hardware token and PINs at the same time.
... and on up-to-date systems there won't be any known privilege escalation exploits.
Think again. An attacker following the kernel source tree will be able to figure out when exploitable bugs are being patched. While such bugs/fixes are generally not called out as security fixes at that time, they are nevertheless identifiable given a small investment.
And for many distros it takes weeks (sometimes months) for the fixes to come through to the "consumer". During that time (dubbed "high-risk days" by some researchers) the vulnerability information is in the open but systems have not yet been patched. Precisely because some patches are *not* called out as having security implications it has happened that some of the more stable distros have delayed the patch because they didn't see the urgency.
Someone determined to take down Linux desktop systems has recurring windows of opportunity because of the open nature of the kernel and the distro system.
How does this compare with DBUS (or DCOP previously)? It sounds similar --one would have the program internals receive signals (e.g. GoToNextTab or PopUpMenu or other more program-specific jobs involving calculations or files etc.) or send signals (e.g. what is the name of the file currently being operated on?) but I am not familiar with the Microsoft way of doing things.
Several important differences:
* The cmdlets defined by an application would represent domain actions, i.e. New-Teacher, Add-Teacher, Get-Student, Add-Course. The cmdlets are thus functionality (GoF command pattern) which would be used in an UI anyway. So you don't "remote control" a user interface by simulating UI actions such as GoToNextTab - that's brittle and error prone. Rather you expose the actions of the applications in a library (module) to be invoked in multiple contexts - of which UI and CLI are just two. Those cmdlets would be defined in a PowerShell module which could be used by *other* applications (or the PowerShell CLI) without starting the application. I.e. it is not "signals" controlling an application (although that is also possible) - it is exposing the domain model and common actions to be consumed in multiple applications.
* The UI application can host the shell engine, not just interact with a bus. So, while a command such as Add-Teacher may require a Teacher object as well as a Course object (command "adding" a teacher to a class), the UI will let the user focus on a course (displaying a details screen) and have "assign teacher" in a context menu. The course will thus be implicitly given in the UI. The UI can use the PowerShell engine to actually perform the actions to operate on in-memory objects like the course in focus. But because the UI application can *host* the engine, PowerShell pipelines can also be used to extend the functionality of the UI app, for instance the Where-Object can be used to filter collections, ConvertTo-Csv can be used to export in delimited formats etc. A more sophisticated UI can allow more complex command pipelines to be built - without requiring the that the user knows anything about pipelines etc.
* The COM,.NET and WMI object models are system wide - not just for desktop applications and not in the realm of a specific language (like e.g. Python objects). COM (a binary object standard) is typically used by system services and legacy applications..NET objects are typically used by applications, especially 3rd party and custom applications. WMI exposes virtually everything about the hardware, firmware, operating system and drivers.
With PowerShell Microsoft put in place a number of conventions and mechanisms to encourage consistency:
* Cmdlets should be named using a verb-nouns pattern (Get-ChildItem, Remove-Item, Convert-... etc).
* All cmdlets are named this way. MS has even created a list of preferred verbs and guidelines on how and when to use them. If you create a module, the shell will warn the user at load-time if non-standard naming is used (i.e. failing the verb-noun pattern or using a verb not on the preferred list), thus encouraging the author to comply with the naming standard
* The "shortcut" commands are exclusively aliases to properly named cmdlets, i.e. "ls" is an alias for Get-ChildItem - not an actual command by itself. Aliases btw are true aliases - getting help on an alias will display help for the original command.
* A number of common parameters have consistent names and a number of them are actually implemented by the shell on behalf of the cmdlets. For example, the risk-management parameters such as -WhatIf, -Confirm, -Force are implicitly defined for a cmdlet whenever it declares that it supports "should-process" semantics. Likewise the error/warning handling switches -ErrorAction and -WarningAction are implicitly defined for *all* cmdlets.
* PowerShell is strongly typed. This improves consistency on a number of levels, not least it removes the need to define how dates, times and numbers are formatted (and potentially parsed incorrectly)
* Help and introspection are metadata driven and will look into the actual cmdlet/function/alias definition instead of relying on external (and potentially faulty out-of-sync) documentation. Documentation can be inlined with commands/functions, even per-parameter documentation.
These are just some of the features which ensures a higher level of consistency experienced with PowerShell.
Of course, PowerShell also threw out everything and started over defining commands anew (cmdlets as opposed to stdin/stdout tools). That means that there's a whole lot of getting used to - and a long transition period where some application-specific tools will not be in the form of cmdlets but rather in the form of "unix-way" stdin/stdout tools.
I did not start off thinking of Powershell. What triggered me was you responding to this, "If anything, more applications should have command lines.", and when I started considering it, Powershell came to mind.
This.
This is a tremendous strength of PowerShell that you will only realize once you dive into it: PowerShell is much more than a CLI. It is an automation framework where the CLI is merely *one* application using it.
A fundamental difference between PowerShell and other (traditional) shells is that PowerShells execution model for cmdlets is in-process. Combined with the fact that PowerShell is object-oriented (passing objects through the pipelines) one can build combined/aggregated pipelines which can *still* be used as in-process commands of a hosting process, e.g. a GUI administration tool. The commands (cmdlets or entire pipelines) can then be used to manipulate in-memory objects.
This is exactly what Exchange and VMWare (and others) do with their GUI: The do not have to create dual tools; they create the commands (as cmdlets) and they can be used from both a GUI as well as from a CLI or some other automation tool.
Even without creating actual cmdlets, an application may still allow itself to be automated through PowerShell simply because the application object model is exposed. PowerShell can consume objects created with/defined through.NET, COM and WMI.
Rather than being monoliths, applications created with COM or.NET expose the components on which they are built. Those components can be used in other settings, such as PowerShell.
Slashdot Mirror
For server functionality pure bullshit. I have a decade's experience running Windows and *nix servers, often in the same networks and while Windows has AD and GPOs to its benefit, in other respects it is horribly backwards and painful to use. Just backing up the system config in Windows is appallingly difficult compared to *nix.
So, how does Linux handle online backups of running server workloads? Does Linux have a way to signal to running services (like RDBMSs, hypervisors, file servers) that a backup is about to happen, negotiate which files are to be included in the backup and then in a fragment of a second work with the running service to synchronize disk content so that the backup will be consistent?
A running database server will almost invariably hold some state in memory. If the power is lost it will be able to rebuild from the disk state, but that can be a time consuming task. If the backup system is simplistic it will just back up the disk state of any file. Upon restoring it will appear as if the power was lost and the roll-forward log will have to be played.
A more advanced backup system will integrate with the services to ensure that for a very brief time (just enough to take a snapshot) the disk state is consistent and thus will not require a rebuild/roll forward if it is ever restored.
Windows comes with Volume Shadow Copy Service (VSS) and a file system which supports block level snapshots. VSS works with VSS aware applications (VSS writers) such as Microsoft SQL Server, Oracle Database Server, Exchange Server, Active Directory, NTFS and Hyper-V server. When a service is a VSS writer it participates in VSS coordination/synchronization to create consistent disk state.
It even works through Hyper-V: When you back up the Hyper-V host, Hyper-V itself is a VSS writer which recursively invokes the VSS running inside guest OSes (if Windows) to ensure that any service inside the Hyper-V guest OS is also disk consistent exactly when a snapshot of the virtual hard disk image is created.
To my knowledge, Linux doesn't have anything like VSS. Which means that each application/service must be handled separately. Typically you will stop the service during the backup. Some services such as PostgreSQL can recover from a non-consistent disk image; others can not. Individual applications may have commands/services which allow admins to "dump" state to a file to be backed up separately. All in all reliably backing up a running Linux server is more complicated compared to backing up a running Windows server with VSS aware services.
So what exactly does it do that similarly equipped Linux machines/vps' can't do that justify the cost?
* New resilient file system ReFS (think BtrFS when completed)
* Storage Spaces (think ZFS storage pools)
* SMB 3.0 - higher performance network transfer, transparent failover, SMB scaleout (multiple servers serve same shares and aggregates bandwidth), SMB Direct (efficient remote direct memory access), SMB Multichannel, Volume Shadow Service (VSS) for SMB file shares, SMB encryption, SMB Directory Leasing (negotiates and updates local caches of metadata over slow networks)
* Dynamic access control (claims and policy based access control). Think SELinux, grsecurity. Access control based on what application the user is running (sandboxing), from what type of device the user is accessing the resource, on other user attributes than security groups (e.g. who is the manager, what department does the user belong to etc), access control based on attributes of the file (e.g. classification, select words of a Word document)
* RemoteFX improvements, e.g. virtualized GPUs (can use local or remote shared GPUs during RDP sessions), remote low-latency multitouch.
* Direct Access over IPv4. Think hassle-free VPN.
* Hyper-V 3: ethernet cable live migration (neat trick) lets you migrate VMs off one server onto another server over the network without the servers sharing anything. Many Hyper-V manageability improvements. Crazy scalability, e.g. a 63-node Hyper-V cluster runs 4000 concurrent VMs simultaneously. Hyper-V replica.
* Server manager: Yes, a Metro (oops - "Modern") style management app for multiple servers. Integrates with response files and powershell workflow scripts to manage multiple computers (servers/workstations) at once - e.g. install new software, perform configure actions.
* PowerShell 3 with new features such as resilient remote connections (you can detach from a remote session and pick it up later/from another device), workflow scripts which can perform actions with suspend/restart/repeat semantics. No, not just "suspend process" - but actually persisting the state of a script to be continued later, e.g. after a computer restart (or from another machine).
* Thousands of new PowerShell cmdlets (many/most automatically derived from WMI providers) to control virtually anything on local or remote computers.
* Block sized data de-duplication
These are features I could find by googling. I'm sure there are more. Obviously not all of them will appeal to Linux enthusiasts. But still...
COM is a poor way of doing client/server and dynamic link libraries rolled into one.
Opinion.
There are only a few problems solved by COM objects which already have proven solutions in Unix/Linux like systems:
1) having one COM object offering services to several applications to reduce duplication. It's a client/server design, but with nonstandard communication betwen the client and the server in the form of an API instead of a socket connection.
It may not be *your* standard, or a Unix standard, but COM is a windows standard which is very well documented. You also conflate sockets with higher level communications. Sockets are the channels over which 2 processes communicate. But sockets does not specify how to send a datetime, a floating point number or an interface which allow remote control of an application. This is what COM is for.
You also completely ignore the fact that COM is a way to build software, where sockets are still a way to make software pieces communicate. In Word, for instance, the document model is built from a number of COM classes (paragraphs, sections, headings etc). Word itself internally uses COM - which it can do because COM itself is a binary standard for organization of virtual method tables with extremely little overhead. Thus, COM objects can be used in-process, using references, passing pointers. Not so with sockets. This just goes to show how little you understand when you compare COM to sockets.
When the connection breaks because the COM object or the application crashes,
you get failures that aren't as clean to recover from as a proper socket connection.
BS. COM/DCOM has a very mature failure model. Under DCOM objects has leases which ensures that objects are released if connection is lost. If you use a remote COM/DCOM object and the communication fails you are immediately notified. Are you just making things up as you go?
When you use dynamic link libraries, you get more graceful handling of versioning (note: versioning of DLLs in Windows is hell).
Again BS. COM has a very simple and remarkably robust versioning scheme: Interfaces are suffixed with a version. If a server extends an interface in a non-breaking way (e.g. only adding methods) the same interface can be passed to a client which asks for the "older" version. If the change is breaking the server can still relatively simple accomodate both interfaces. As for DLL hell, where have you been living? Windows solved that with side-by-side assemblies. You havent has anything resembling DLL hell since Windows XP (SxS was introduced with Windows XP). It is Linux that is stuck in the past with dependency hell. Software repositories is only a superficial solution to the problem: All software using the same libraries must still agree on the same versions. Step outside the repository and you are immediately in dependency hell.
2) The Unix pipeline/scripting approach is a cleaner way to combine common functionality available on the system than combining COM objects. At the core the issue is that COM object interfaces are too diverse to be mixed and matched as easily as a collection of scripts with command line switches.
What are you going on about? Now you are comparing COM to the CLI? COM is a way to *build* software so that the pieces can be exposed to external parties. Command line interfaces with "switches" is nothing of the sort.
In particular, it's a pain to shunt an extra middle man object between some program calling a COM object's API member function, and the API function being called, because member function signatures are too diverse. With the command line paradigm this is much easier.
You do not build applications by combining processes through sockets. Is that how you would build Writer? Sockets are used to making applications talk to eachother, not for building the internals of
So your complaint is that you don't know x11 messaging and dbus?
I'm fairly certain that was not what GP meant. But you already knew that.
However, it is indeed ironic how you illustrate GPs point very well by suggesting that x11 messaging and dbus are at all comparable to COM/DCOM. The problems solved by having a OS defined common object model are very real, and versioning/backwards compatibility is just one such problem.
To use Metro apps, you need a Microsoft signon.
BS. You do not need to be logged in with a MS account to run Metro style apps.
if a site choose to ignore the DNT setting of IE10:
How can the site reliably determine whether the user behind the browser has actually explicitly taken the decision? If an online ad agency decides to ignore the DNT preferences of *all* IE10 users, they will invariably violate the right to not be tracked of a *number* of users.
This could easily land the advertiser in a serious conflict with the EU commision, and if found guilty of ignoring users' wishes they could end up with a *hefty* penalty - and face accumulating penalties until they change their behavior to respect the users.
In the US i guess that it could open up the advertiser to a class-action lawsuit - potentially even bigger then the EU fine.
No, some site on the Bahamas will probably give a damn. But Google - being the company that tracks most users and serves up ads - has *a lot* to loose on this.
This is for Windows only and it does not test applications for security problems, it looks at the entire system and how it is affected by the installation.
Hence, attack surface analyzer.
The tool looks at the surface of a system (not an application) and analyzes how observable changes to that surface could impact security. For instance it will report that a new port is listening after an application has been installed, or it reports that a certain application phones home, or that the application relies on configuration files/installation/registry keys which may not have proper permissions set.
I thought the requirement to run Windows 8 was to have a BIOS option to disable secure boot, or rather, enable legacy (BIOS) booting.
There is no such requirement to run Windows 8. There is a UEFI secure boot requirement if you want to put a sticker on the system saying "designed for Windows 8". There is also a requirement that the user must be able to switch off the secure boot.
Of course, if you want to boot back into Windows requires flipping the option back (the files are signed and verified before loading, so it's not like running another OS will break the security - the UEFI verifies the loader, the loader verifies the kernel, the kernel verifies the drivers and Windows binaries, etc.).
No, you do not need to flip the option back to boot Windows 8. If you don't flip it back you will not have the security that comes from the knowledge that the boot loader and kernel has not been tampered with, but Windows 8 will boot.
Of course, if you want to boot back into Windows requires flipping the option back (the files are signed and verified before loading, so it's not like running another OS will break the security - the UEFI verifies the loader, the loader verifies the kernel, the kernel verifies the drivers and Windows binaries, etc.).
That is correct. But while the signed Windows 8 boot loader may allow for another OS to be booted (as opposed to that OS being booted directly from UEFI firmware), you can expect Microsoft to impose certain restrictions on what that other OS does after receiving control of the system.
Specifically Microsoft will want to avoid a situation where the alternative OS performs a silent minimal boot, installs a hypervisor and then boots Windows in a managed VM. This would effectively be a rootkit. So while canonical and others may be able to obtain keys which allow their OS to be booted from Windows boot loader, those keys may very well come with restrictions/requirements that the OS must itself be signed and it must be visibly different from Windows.
I know RedHat and Canonical were worried that the option would be well, optional, but I thought it was now required. And it will be for a little while because Windows 7 isn't ready for secure boot - it can be EFI-booted in 64-bit mode but that's experimental.
That was basically a publicity stunt from RedHat. They knew all along that Microsoft would want an "off" switch (to run Windows 7, Server 2008, Server 2008R2 etc). But they also knew that it is a difficult topic to explain and so they knowingly created controversy.
Then there is well, Apple. Whose EFI-based firmware probably doesn't have secure boot in it and thus unable to boot Windows 8
Again, Windows 8 will accept to boot on any system. The "secure boot requirement" is a logo requirement. It is not a technical requirement of Windows 8. All it means for Windows 8 - on the technical side - is that its binaries, modules and central configuration resides in signed cabinet files which can be verified by the UEFI firmware. Secure boot is a feature of UEFI - not of Windows 8. Windows 8 supports secure boot by being signed using a key known to the UEFI firmware.
* Unix or *nix are built around the concept of getting work done _away_ from superuser privileges.
So is Windows. And it is actually only partly true for Unix. Unix is too much dependent on UID 0 for too many things. And when you need to perform those actions you need to elevate to root - and break least privilege principle. Windows doesn't have that problem, it has a much more granular security model and "power user" privileges can be delegated - you don't need to elevate root/administrator to be able to back up a system, for instance.
So is Windows. And it is actually only partly true for Unix. Unix is too much dependent on UID 0 for too many things. And when you need to perform those actions you need to elevate to root - and break least privilege principle. Windows doesn't have that problem, it has a much more granular security model and "power user" privileges can be delegated - you don't need to elevate root/administrator to be able to back up a system, for instance.So is Windows. And it is actually only partly true for Unix. Unix is too much dependent on UID 0 for too many things. And when you need to perform those actions you need to elevate to root - and break least privilege principle. Windows doesn't have that problem, it has a much more granular security model and "power user" privileges can be delegated - you don't need to elevate root/administrator to be able to back up a system, for instance.
* The points of distributing software for *nix platforms tend to be few and secured.
That is not a Unix component - and certainly not an OS X component until Mountain Lion. You can argue that Linux repositories comes with added trust because the packages are signed. But Sites like download.com, tucows etc. also allow Windows users to download malware-free software. Have there been cases of malware found in these repositories. Yes, both in Linux repositories and in Windows repositories. You are just blowing hot air. It doesn't really matter if software in repositories is signed or not - what matters is the vetting process. And nothing suggests that Linux repositories are any better at that.
Even a Mac user tends to understand that the prospect of downloading small utilities and games from sources that don't start from Apple.com
No they don't. 10% of mac users caught the flashback infection. That's worse than anything on any operating system, ever!
* Different implementations, so binary compatibility is iffy or nonexistent (compatibility is more at the API level)
Good point. Security through voluntary obscurity and incompatibility. Is this part of Unix architecture?
* My theory: The inner workings of most *nix systems are easier to lookup and are better understood by the power users and admins who run and service them -- It is more difficult to hide malware in such an environment.
BS. kernel.org and linuxfoundation.org were compromised for (at least) the better part of a month by and old and known rootkit. And nobody noticed until they started receiving error logs from components which should only be installed on desktops. All OSes in use today are so complicated that there is tons of ways to hide malware. Even if the malware doesn't try to activelt hide itself, do you think regular users have any idea of which daemons and/or network ports should be running/open on their systems?
To me, the level of cleanliness of a Windows system seems like a big, ongoing guessing game: This is particularly true given that the norm for operating Windows, even in a malware emergency, is to depend on the services of the installed, running, _infected_ system and users are often encouraged to download antivirus tools using the infected system to get rid of the existing malware (so the success rates of removal are lowered and the user ends up with a bogged-down or broken system).
Actually 64 bit Windows
Skype used to have a pretty impressive peer to peer encryption design. No longer, I guess.
Yes it does. Nothing has changed with the peer-to-peer encryption. You have been fed rumors, speculation. Here is what Skype says (but if you *want* to make it into a conspiracy you can of course assume that they are lying):
Skype software autonomously applies encryption to Skype to Skype calls between computers, smartphones and other mobile devices with the capacity to carry a full version of Skype software as it always has done. This has not changed.
(from http://blogs.skype.com/en/2012/07/what_does_skypes_architecture_do.html)
This is once again someone irresponsibly reading license terms and trying to twist every phrase and condition into something sinister. Like Skype making sure that you understand that instant messages may be stored on the servers because they need to be synchronized with multiple devices which are not all on-line. Like Skype saving voice-messages - because they are (d-oh!) *voice* *messages* (as opposed to peer to peer communication).
For a real take on this read: http://www.zdnet.com/skype-talks-back-to-critics-on-security-and-privacy-7000001682/
This from the TFA:
Skype has gone under a number of updates and upgrades since it was bought by Microsoft last year, mostly in a bid to improve reliability. But according to a killer report by the Washington Post, Skype has also changed its system to make chat transcripts, as well as users’ addresses and credit card numbers, more easily shared with authorities.
The " to make chat transcripts, as well as users’ addresses and credit card numbers, more easily shared with authorities" is pure speculation.
And the alleged updates "since it was bought by Microsoft last year" (supernodes hosted in central data centers) was actually started in 2010, well before the Microsoft acquisition:
http://www.zdnet.com/skype-talks-back-to-critics-on-security-and-privacy-7000001682/
But this is slashdot. Why let facts get in the way of a good rumor-fueled speculation when it promises for a good Microsoft bashing?
Unix is not magic, but it raises the bar significantly for malware authors.
How?
What is it that Unix does that you claim Windows doesn't? What is the secret sauce that is so elusive that you can only speak of it in general terms?
GDI has been hw accelerated since Windows 3.1. There was a time they even benchmarked graphics card on how quickly they accelerated windows drawing calls.
I stand corrected then. However, the software rendering was done because of the introduction of the composition engine (applications writing into a memory buffer representing the Windows which is then composed by the driver rather than each app being asked to redraw itself in reverse Z-order) - not because hw acceleration was making it unstable.
I was thinking on the GDI part of Windows, it is software rendered on Vista. Some applications ran quite badly because of this.
But GDI was never hw accelerated on XP. So there was no hw acceleration removed in Vista, as you claimed:
As a result Vista supported less hardware acceleration than XP
Indeed, Vista did come with GDI+ which *introduced* some hw acceleration into the old GDI.
Many Windows crashes was caused by hardware acceleration. As a result Vista supported less hardware acceleration than XP.
What? Vista came with Aero which is entirely *dependent* on HW acceleration. If your graphics card does not support HW acceleration, you could not run with aero.
Also, Vista changed the graphics model from a redraw model to a composition model. The composition model is again mandatory hardware accelerated. If your card doesn't support graphics composition Windows falls back to the redraw model.
What happened with Vista was that Microsoft split the graphics drivers so that the drivers had to come in two parts: a core part running in kernel mode and a user mode part which does most of the computations.
So while you are somewhat correct that many Windows crashes was due to HW acceleration (actually, more generally dure to bad cards or drivers - not necessarily acceleration), the new driver model did not support *less* acceleration. It supported *more* acceleration (composing, aero glass etc) - only it moved it from kernel mode to user mode to increase reliability.
applications don't get direct access.. drivers do. if the drivers clobber things they shouldn't, they can crash the kernel..
Actually, Windows (since Vista) has a more fault-tolerant hybrid driver model for graphics drivers: A "core" part runs in kernel space and the bigger more complicated part runs in user space. If the part of the driver which runs in user mode causes memory corruption, only the user process is affected. This is the major reason why Vista and 7 systems seems more reliable than XP. Microsofts telemetry indicated that poor graphics drivers and overheating and misbehaving graphics cards were *the* major reason for instability of Windows systems.
http://msdn.microsoft.com/en-us/library/bb188739.aspx
http://msdn.microsoft.com/en-us/library/aa480220.aspx
Windows also can allow the graphics card to re-initialize if it determines that it has faulted or freezes. For a period I was really annoyed about Internet Explorer 9 when I tried it out. It seemed smooth, especially so when I were scrolling up and down (GPU accelerated). But every 5 seconds or so it would pause for just a fraction of a second. Not much, but definitively enough to being annoying. Little did I know that it was actually the nVidia driver that faulted and the Windows graphics system was actually resetting and re-initializing. When I realized that and updated to the latest nVidia driver the problem went away (I still use Chrome; there still is this "feel" to IE9 that isn't quite right - cannot put my finger on it, though).
they can crash the kernel.. just like the unix derivatives in service today.
I don't think that OS X has a similar model - but then again on OS X Apple can tightly control and regression test the limited number of cards and drivers. I have definitively had X crash on me and taking all the apps down with it on more than one occasion - not so much after running Linux mainly under VMWare and Hyper-V.
How long was kernel.org compromised? Without anyone knowing?
We don't know. At least 17 days was the initial assessment, but kernel.org has - despite claims about openness - never got around to write up a post mortem.
Many of us would like to know what the attack vector was. How a compromised *user* account could lead to the kernel being rooted. How a relatively amateurish infection (phalanx is a old, known and pretty trivial rootkit) could penetrate so deeply into infrastructure run by the people most knowledgeable on Linux *in the world*.
Was the actual attack which resulted in the infection a walk-over or was it more sophisticated than what the use of phalanx rootkit suggests?
Now think back to the debut of mandatory driver signing with Windows Vista - where individual components in your computer would cease to function after an upgrade for no reason other than Microsoft wanted your manufacturer to pay extra for the privilege. Even worse, there really was no way to know before the upgrade if your system would function entirely.
This is so much BS that it could have made a Peter Gutmann "research" report.
1) There was no driver signing requirement for 32 bit Vista. To this day there is no driver signing requirement for *any* 32 bit Windows - including Windows 7. If you upgraded from Windows XP (a 32 bit OS) there would *not* be any issue with driver signing. Microsoft has clearly stated that 32bit Windows are exempt from driver signing *exactly* because of potential backwards compatibility issues.
2) 64 bit Vista *did* introduce driver signing for *kernel mode* drivers. If you upgraded from 32bit XP to 64bit (if your hardware was capable) Vista you would need to obtain signed drivers for the the devices which had *kernel mode* drivers. Part of the graphics drivers execute in kernel mode so you would need signed drivers for that. However most drivers for non-bus devices (a bus device include very generic devices such as IDE, SATA or USB hubs), i.e. most consumer electronics do not need signing.
3) There was an upgrade assistant which would produce a comprehensive report on what hardware and software you could expect to be able to run on Vista. Petty you never found it.
4) Microsoft *never* sees any money you pay for a code signing certificate. Microsoft simply trusts Verisign and a few other CAs to issue authenticode certificates. All the signed driver ensures is that 1) they can find the identity of a publisher of a driver - they assume that Verisign has performed a deeper verification than simply a credit card and 2) publishers or individual certificates can be revoked and thus cause systems to refuse to load malicious or exploited drivers.
As for your "clear path" - MS has stated for Windows 7 that if your system worked with Vista - it will work with Windows 7. They have now stated that if your system works with Windows 7 - it will work with Windows 8. Does it get any more clear than that?
Yes, they're taking a proactive approach to push upgrades from XP.
Yeah, if only they would provide a download link for Windows XP and Server 2003 in a knowledge base article so that we could find it if we bothered to look for it!
So, to protect users from potentially trusting a fake Windows Update server, Microsoft is releasing this update through a Windows Update server, which potentially could be fake? I suppose that if your computer already trusts a fake server, it is too late
This is not a fix for machines already pwned. It is a precautionary step to foil copycats (or the original attacker returning with a new kit). If a machine gets this update it will be immunized to attacks using these certs. You are correct that if a machine is already pwned or on a net with a fake WU server, that WU server could block this update to remain in the loop. This was never billed as a solution for that problem, however. If you suspect that your machine is pwned though a sophisticated attack like the Flame you really need to nuke it from orbit.
However, I wish Microsoft would go back to providing downloadable updates that didn't depend on Windows Update.
Ahem. Microsoft releases all updates as separately downloadable packages. Windows Update / Microsoft Update is merely a delivery mechanism. The knowledge base article (with download links) for this particular one is found here: http://support.microsoft.com/kb/2728973
If the key holder is smart, they'll generate the key on a smart card and arrange matters such that it never leaves the smart card, and then lock it in a safe when they aren't signing binaries.
Actually, keys like this are generated within certified hardware security modules (HSMs) which guarantee that the key will *never* leave the unit, not even if an administrator says it's ok. The HSM simply hasn't got the functionality. The HSM will be able to backup the keys in *encrypted* form to an external unit (possibly another HSM) or media. HSMs typically also has an array of anti-tamper protections such as embedding the chips in solid blocks of epoxy, vibration sensors, temperature sensors, accelerometers, power outage sensors, gyroscopes, x-ray/light sensors etc. HSMs will only sign messages or hashes with a private key if a number of users are each presenting a hardware token and PINs at the same time.
... and on up-to-date systems there won't be any known privilege escalation exploits.
Think again. An attacker following the kernel source tree will be able to figure out when exploitable bugs are being patched. While such bugs/fixes are generally not called out as security fixes at that time, they are nevertheless identifiable given a small investment.
And for many distros it takes weeks (sometimes months) for the fixes to come through to the "consumer". During that time (dubbed "high-risk days" by some researchers) the vulnerability information is in the open but systems have not yet been patched. Precisely because some patches are *not* called out as having security implications it has happened that some of the more stable distros have delayed the patch because they didn't see the urgency.
Someone determined to take down Linux desktop systems has recurring windows of opportunity because of the open nature of the kernel and the distro system.
How does this compare with DBUS (or DCOP previously)? It sounds similar --one would have the program internals receive signals (e.g. GoToNextTab or PopUpMenu or other more program-specific jobs involving calculations or files etc.) or send signals (e.g. what is the name of the file currently being operated on?) but I am not familiar with the Microsoft way of doing things.
Several important differences:
* The cmdlets defined by an application would represent domain actions, i.e. New-Teacher, Add-Teacher, Get-Student, Add-Course. The cmdlets are thus functionality (GoF command pattern) which would be used in an UI anyway. So you don't "remote control" a user interface by simulating UI actions such as GoToNextTab - that's brittle and error prone. Rather you expose the actions of the applications in a library (module) to be invoked in multiple contexts - of which UI and CLI are just two. Those cmdlets would be defined in a PowerShell module which could be used by *other* applications (or the PowerShell CLI) without starting the application. I.e. it is not "signals" controlling an application (although that is also possible) - it is exposing the domain model and common actions to be consumed in multiple applications.
* The UI application can host the shell engine, not just interact with a bus. So, while a command such as Add-Teacher may require a Teacher object as well as a Course object (command "adding" a teacher to a class), the UI will let the user focus on a course (displaying a details screen) and have "assign teacher" in a context menu. The course will thus be implicitly given in the UI. The UI can use the PowerShell engine to actually perform the actions to operate on in-memory objects like the course in focus. But because the UI application can *host* the engine, PowerShell pipelines can also be used to extend the functionality of the UI app, for instance the Where-Object can be used to filter collections, ConvertTo-Csv can be used to export in delimited formats etc. A more sophisticated UI can allow more complex command pipelines to be built - without requiring the that the user knows anything about pipelines etc.
* The COM, .NET and WMI object models are system wide - not just for desktop applications and not in the realm of a specific language (like e.g. Python objects). COM (a binary object standard) is typically used by system services and legacy applications. .NET objects are typically used by applications, especially 3rd party and custom applications. WMI exposes virtually everything about the hardware, firmware, operating system and drivers.
With PowerShell Microsoft put in place a number of conventions and mechanisms to encourage consistency:
* Cmdlets should be named using a verb-nouns pattern (Get-ChildItem, Remove-Item, Convert-... etc).
* All cmdlets are named this way. MS has even created a list of preferred verbs and guidelines on how and when to use them. If you create a module, the shell will warn the user at load-time if non-standard naming is used (i.e. failing the verb-noun pattern or using a verb not on the preferred list), thus encouraging the author to comply with the naming standard
* The "shortcut" commands are exclusively aliases to properly named cmdlets, i.e. "ls" is an alias for Get-ChildItem - not an actual command by itself. Aliases btw are true aliases - getting help on an alias will display help for the original command.
* A number of common parameters have consistent names and a number of them are actually implemented by the shell on behalf of the cmdlets. For example, the risk-management parameters such as -WhatIf, -Confirm, -Force are implicitly defined for a cmdlet whenever it declares that it supports "should-process" semantics. Likewise the error/warning handling switches -ErrorAction and -WarningAction are implicitly defined for *all* cmdlets.
* PowerShell is strongly typed. This improves consistency on a number of levels, not least it removes the need to define how dates, times and numbers are formatted (and potentially parsed incorrectly)
* Help and introspection are metadata driven and will look into the actual cmdlet/function/alias definition instead of relying on external (and potentially faulty out-of-sync) documentation. Documentation can be inlined with commands/functions, even per-parameter documentation.
These are just some of the features which ensures a higher level of consistency experienced with PowerShell.
Of course, PowerShell also threw out everything and started over defining commands anew (cmdlets as opposed to stdin/stdout tools). That means that there's a whole lot of getting used to - and a long transition period where some application-specific tools will not be in the form of cmdlets but rather in the form of "unix-way"
stdin/stdout tools.
I did not start off thinking of Powershell. What triggered me was you responding to this, "If anything, more applications should have command lines.", and when I started considering it, Powershell came to mind.
This.
This is a tremendous strength of PowerShell that you will only realize once you dive into it: PowerShell is much more than a CLI. It is an automation framework where the CLI is merely *one* application using it.
A fundamental difference between PowerShell and other (traditional) shells is that PowerShells execution model for cmdlets is in-process. Combined with the fact that PowerShell is object-oriented (passing objects through the pipelines) one can build combined/aggregated pipelines which can *still* be used as in-process commands of a hosting process, e.g. a GUI administration tool. The commands (cmdlets or entire pipelines) can then be used to manipulate in-memory objects.
This is exactly what Exchange and VMWare (and others) do with their GUI: The do not have to create dual tools; they create the commands (as cmdlets) and they can be used from both a GUI as well as from a CLI or some other automation tool.
Even without creating actual cmdlets, an application may still allow itself to be automated through PowerShell simply because the application object model is exposed. PowerShell can consume objects created with/defined through .NET, COM and WMI.
Rather than being monoliths, applications created with COM or .NET expose the components on which they are built. Those components can be used in other settings, such as PowerShell.