LOL. Actually ls is an alias for the cmdlet Get-ChildItem. That's the canonical name. Other aliases are, surprise, dir and gci (no points for figuring that one out). Unlike *nix aliases PowerShell aliases are strictly aliases, i.e. they are merely alternative names for the same cmdlet. The shortcut functionality of *nix aliases are covered by PowerShell functions or filters.
The fact that the cmdlets canonical name is Get-ChildItem hints of another concept in PS: The same cmdlets can be used against multiple types of targets. The "current directory" has been extended to "current location". A location can be in anything for which there exists a PowerShell provider. It comes with (no suprise) a provider for filesystem in which "child items" will be files and/or directories. However, also the registry is exposes as a "file system", so you can set the current location to a node in a registry hive and use the exact same commands: ls, rm, cp. Other providers are certificate store, active directory, exchange, credentials store etc.
The % is actually an alias for the Foreach-Object. That cmdlet takes up to 3 script blocks: begin block, process block and end block. It starts by executing the begin block once, then executes the process block for each object in the pipeline and finally executes the end block once. If only a single block is defined (as in the above examples) it is assumed to be the "process" block. As PowerShell script is an expression language it will feed the pipeline with whatever the expressions in the block returns. During execution $_ (like in perl) is a reference to the current object being handled.
I have no points to give you, but this is *the* most insightful post I have seen on the topic of shells on slashdot. Ever.
I still think that PowerShell can do something for Windows that is not currently possible on *nix. Until a unified object concept materializes, that is.
1) list all items recursively from the current location
2) filter only those items where ls returns an empty set.
Btw, the objects returned from that command are *still* DirectoryInfo objects, allowing even further operations or property accesses.
Also, this command will work the same even if the "current location" is a node in the registry, the certificate store, the credentials store, a group in active directory etc etc.
In other words if you change the location to an organisational unit in AD, the exact same command will find empty sub-containers.
PowerShell ideas are more relevant to Windows than they are to *nix. PowerShell is object-oriented: The pipes are objects, not text. That saves a lot of parsing and allows interaction (like calling methods) with the objects flowing through.
PowerShell also unifies the object-oriented models on Windows: COM,.NET and WMI. Most of Windows APIs are now either fully object-oriented (e.g. DirextX, Speech) or have been wrapped in by object-oriented models such as.NET or WMI.
*nix generally does not expose API in object-oriented fashions. Hence, most of the advantages that PS may have from being OO are not really relevant on *nix.
That said, some of the other less prominent features of PS could conceivably be relevant for *nix shells, such as unified scripting, better type system and integrated regular expressions.
Available from Microsoft for XP, 2003; included in Server 2008 and Windows 7.
The name is really lame, but it *is* damn powerful. At least for Windows which has most of it API exposed through object-oriented technologies (COM,.NET and WMI) which are easily used in a unified way by PowerShell.
Just a few quick samples:
List all.exe files in current dir and below: ls -r . *.exe
Calculate their combined size: ls -r . *.exe | measure -sum Length
Find the latest version of all.exe files below the current directory: ls -r . *.exe | sort -des LastWriteTime | group Name | %{$_.Group[0]}
Instead of finding the latest, delete those with a more recent version somewhere: ls -r . *.exe | sort -des LastWriteTime | group Name | %{$_.Group|select -skip 1} | rm
Read files and directories from current directory out loud through the speakers: $sam=new-object -com SAPI.SPVoice; ls | %{$sam.Speak($_)}
List processes consuming (the "working set") more than 100MB: ps|?{$_.WS -gt 100MB}
-Kill them instead: ps|?{$_.WS -gt 100MB}|kill
Wait for the "import" process to exit: (ps "powershell_ise").WaitForExit()
Only their website doesn't even mention Microsoft as a partner. IBM, Borland, Sun and Oracle are mentioned as partners, though, with contact details.
What was the intention of mentioning Microsoft and leaving out those partners? Is Microsoft a business partner at all?
I hate software patents. But summaries like this blatantly trying to skew facts to weasel in hints of a grand Microsoft conspiracy does the fight against software patents disservice.
What a crook. Bad! I had to look twice because I fully expected this to be a "kdawson". Not this time, though.
Nope, not the same. The CLR/JVM are comparatively very small cores and offers intrinsic protections against memory corruption, dangling pointers, buffer overflows etc. The extension mechanisms in CLR/JVM are based on that intrinsic level. With PHP practically all useful functionality (unless you write "extensions" in PHP) such as regex, xml serialization, net/socket communication, certificate parsing etc etc are all written on top of C. Which is not a language known for it intrinsic protections against memory corruptions and buffer overflows. To put it mildly.
Well, you are wrong. PowerShell objects are not xml based at all. PowerShell can expose COM,.NET and WMI objects as PowerShell objects.
The ls command (actually an alias for Get-ChildItem) returns a mix of DirectoryInfo and FileInfo objects. Each with a number of properties and methods. A formatting rule for a collection of FileInfo and DirectoryInfo items defines what appears to be the "usual" ls format. But you can actually do something like:
ls c:\ | ?{ $_.Length -gt 100KB} | ft FullName,Length
(get child-items of c:\; select only those with a length greater then 100KB and output them formatted in a table with two columns: The full path name and length).
Culture. For a long time the mysqli library did not allow the use of parameterized queries leading to the unhealthy culture of concatenating or interpolating sql queries and even "require" arguments.
Easy entry with little architectural guidance which leads beginners down the dangerous paths.
Poor design decisions such as (just examples)
the ability to "require" scripts from foreign servers.
stupid type coercion such as 1 == "1more" is actually true.
super-weak type system, meaning that you can never trust what you expect to be an integer to be just that.
stupid attempts to accomodate developers and save LOCs by introducing "magic quotes", superglobals and the ability to "automagically" map query parameters to global variables.
The fact that PHP is merely a glue layer, relying on binary extensions written in C with the usual buffer overflows, memory corruptions etc.
Thirty years of success for us Unix users doesn't feel like a waste of time...
It's through C APIs I have access to thousands of libraries for various
tasks. I have them in Python, Perl and all other major scripting languages
too -- but only because those C APIs exist.
They are still pairs of which C is always one. What's more, using those objects from C is a pain as they all have different object models and name resolution principles.
True interoperability comes when you can use Python objects directly from Ruby or PHP as if they were native objects. The C API doesn't give you that.
You may heralt the 30 years of Unix C API. Meanwhile Windows has almost completely moved to an object-oriented model (COM) for many APIs. COM is a binary object model with absolutely minimal overhead. Cue DirectX. The APIs which have not moved to COM are generally wrapped in object-oriented.NET APIs.
The upshot is that Windows is becoming a object oriented OS. That's what enabled PowerShell - and why PowerShell really is at it best at Windows despite PASH (PowerShell for *nix). Leaving the text-based pipes behind, PowerShell now features an object-based pipeline. You will only realize the true value of this development once you try it.
So I would say that we have come to a point where the lack of more sophisticated object models in *nix will be holding it back. At one point I believed that Java could be it (Java views everything as objects), but Sun blew it with the OS community at that point, only releasing it under a true OS license only last year.
You can view the VM as nothing more than a glorified assembler. In that case you would focus on bytecode. And sure, as bytecode is really just a portable assembly language you can pass around (simple) objects.
What I'm talking about is the ability to pass around higher level objects, such as e.g. dynamic objects or classes or even generics.
The.NET CLR actually has define-site generics with variance, compatible like Scala. On the.NET platform a language like Scala would be able to interop with generics with the upcoming C# 4, VB and other generics-aware languages. The Java platform stops short of specifying how generics should look. Hence, JVM based languages cannot interop on generics. You cannot inherently take a Scala generic and realize it (create a concrete type) using another language, not even Java.
The same goes for dynamic objects, i.e. objects for which their "host language" defines the name resolution for members. These rules are different for most languages. As you point out Jython objects are merely hashtables. Anyone else must know the Jython rules for member resolution to use those objects.
Compare that to the situation on the DLR/CLR. The IDynamicObject lets anyone else invoke methods dynamically on any object and defer the member resolution to code provided by the "host language". IronPython objects can be used from IronRuby, C# or VB as if they were native objects. Whenever a member is referenced the IronPython name resolution will spring into effect and look the name of in whatever internal hashtables are relevant.
The JavaVM was originally only designed to execute Java code. Hence, it is only slowly adopting constructs needed to accommodate other languages. This means that lacking the infrastructure those languages will merely use the byte code as an assembly language, not the type system as it carries over all of the Java limitations.
So no, the JVM spec is very different from the CLR/CTS. CTS was a generalized type system from the get-go and was always designed to be more general than any of the languages.
You are right that the integration will never be "perfect". That would require the languages to become effectively just different syntax for the same constructs, sort of the relationship between C# and VB.NET.
C# and VB.NET exist and are supported because of historical reasons, not because one of the languages supports or excels in a particular paradigm.
However, it will be possible to consume a C# class (a static.NET class) in Ruby and use it as base for the Ruby class construction. I.e. you can take a C# class and mix in more members. This will yield a dynamic class, however. If you went back to C# with this, C# doesn't support specializing dynamic classes, but it will (4.0) support creating instances of dynamic classes. It will know that these objects are dynamic and that member resolution should be done by the object at runtime. To C# the object will be statically typed to be dynamic.
The point is exactly to raise the common denominator and ease interop. Provisions also exists for language developers to support drastic optimizations, such as member lookup caching etc. The goal is not to have all languages converge; rather it is to allow full specification compliant languages to interop and to remove the pain of doing so.
And I think you are still focused on a single language pair. The really compelling upshot of IDynamicObject is that you can interop with, say, C#, F# and Ruby.
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance?
The dynamic classes of Ruby, JavaScript, PHP etc. are accomodated by using the IDynamicObject interface. Basically each object are allowed to define its own member resolution. Ruby mixins can still just update a symbol table somewhere up the hierarchy. During execution the object will be asked to resolve any member access itself. This means that Ruby objects can resolve using the Ruby way which will respect mixins. JavaScript can resolve member access according to prototypes etc.
You do not need to map dynamic classes to static classes. You would only need that if you wanted to be able to specialize classes from other languages. Most interoperability between languages will not require class interop. The most important interop needed is object interop, where you pass object instances between languages, not classes. Indeed some languages (notable JavaScript) don't even *have* classes.
What good are multiple languages if all inter-language integration have to be funneled through some narrow C-like basic model?
The problem is not with the languages but rather with the platform on which they are based. As long as the common denominator is C memory blocks or opaque text-serialized objects, integration is always going to be a pain.
Sometimes language pairs are supported by an asymmetric relationship (one of the languages often being C). Using objects/features from one language is usually easier in one direction than in the other. Often there are severe restrictions on the layout of objects/functions. Examples of this is how PHP can use some C based functions/objects, provided they adhere to the "PHP way" of laying out objects. Using PHP functions from C is considerably more involved and certainly does not qualify as minimalistic.
The problem is that these bindings are often just pairs, excluding other languages from richer integration. Sure, you can integrate other languages with C as well, but rarely will the object layout of one language align with the layout of another language. This makes multi-language integration a pain. Going (down) to C level loses a lot of meta information and complicates going up the abstraction chain to another language. Essentially this is a hub-and-spoke problem with the hub being too weak.
Another example is Java/JavaFX. It's quite easy to use existing Java classes from JavaFX, but going in the other direction requires a number of ceremonies. And this is still just a pair. Even though the Java platform has been used to implement a rich set of languages, the basic problem is still there: The "hub" (Java) is too weak to describe objects/functions on a the level which would let you pass objects from Jython to JRuby to Groovy to JavaFX to Scala. Java's generics are incompatible with the generics used in Scala. Java (and also the VM) does not support unsigned integers.
Java was always designed to be an abstraction over the underlying platform not to integrate with it. This philosophical difference was actually at the center of Microsofts dispute with Sun over the direction of Java. Microsoft wanted the language to evolve in the direction of facilitating integration with the platforms (one in particular) while Sun wanted to abstract away the world outside Java and have everything remodeled in Java. Microsoft enhanced their Java implementation with the "lacking" features, Sun sued and won and Microsoft completely left Java and went on to design.NET.
Your example illustrates that at least in the area of multiple programming languages, the.NET platform is much more evolved. Unlike Java, Microsoft designed.NET as a multi-language platform from the get-go (although initially for multiple statically typed languages).
The.NET Common Type System (CTS) and common language runtime (CLR) were always (and still is) more advanced and feature rich than the primary driving language, C#. The CTS already supports generics variance (C# and VB don't yet) as part of the platform. (aside: Scala generics while being define-site with variance are merely an internal Scala thing and not compatible with anything else; Java generics based on type erasure are merely a compile-time only and as such doesn't exist for anything else).
The latest development in.NET is to incorporate support for dynamic languages into.NET. C# 4.0 and the CTS will lay out a common principle (a "dynamic" interface) which theoretically can accommodate most known static languages, hybrid languages and dynamic languages on a very high level.
This will enable any language which adhere to this specification to participate in a high fidelity hub-and-spoke architecture. You will essentially be able to pass a IronRuby object to IronPython, C#, VB, F#, Eiffel etc. and interact with it there while still relying on the Ruby
on what exactly the flaw is. If the bug is that you can hijack JavaScript and leverage the built-in bindings/API (for saving documents, for example) NX will not be effective.
This is because interpreted JavaScript is regarded as data (to be read by the interpreter); NX is only effective against binary executable code.
Incidentally, this is a big difference between Java and.NET. Because Java typically uses hotspot VMs it will regard Java as data (byte code). Only if the hotspot compiler decides to compile the bytecode all the way to machine instructions will Java execute as binary code. Consequently Java will inherently be able to execute byte code. This means that for the processor the byte code is just data. If a buffer overflow can overwrite the bytecode or the Java stack, the interpreter is quite happy to keep on interpreting the bytecode.
.NET OTOH always compiles the IL (.NET bytecode) code to machine code before executing it. This means that the NX protection can actually protect.NET code but not Java code.
Google Chrome leverages this Vista feature.
http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ
The sandboxing feature in Vista is implemented with process integrity levels. A process with "low integrity" is severely restricted in what it can do on the system.
Adobe could use this feature for Acrobat. They actually do use it (they have to) for Flash, as the Flash plugin in IE runs inside the sandbox.
The crux is that a sandbox is often so severely restricted that you need a helper (called "broker") process to do the privileged stuff such as downloading/uploading files etc. Flash actually made their own broker process for Flash and left a stupid bug in there. That was the flaw which allowed Vista to be compromised in last years' pwn2own contest.
While all of the factors considered by CVSS are important, what CVSS scores
fail to capture is the economic opportunity that a vulnerability presents to
an attacker. The days of amateurs, college students, or hackers taking joy
rides on corporate information systems are largely over. Todayâ(TM)s attackers are
economically motivated. They are international criminal organizations who
make a living stealing financial information and identities. Todayâ(TM)s threat
is far more sophisticated and far more dangerous than the security threats
of yore, but in some ways it is more predictable.
The result of this new reality is that there have been several vulnerabilities
this year that received very high CVSS scores and raised widespread alarm
within the security industry. However, they were not widely exploited in the
wild. In most cases, these vulnerabilities did not fit well into the current
business models of computer criminals
Vulnerabilities that fit into existing processes and
which can leverage existing automation are easy for criminals to monetize.
Vulnerabilities that require the development of new processes or software are
much less likely to present an attractive opportunity to criminals, particularly
if they represent a one-of-a-kind set of circumstances that is unlikely to be
repeated in the future. Even when it does make sense for criminals to develop
a new attack methodology to exploit a new class of vulnerabilities, widespread
attacks will usually take longer to emerge than for vulnerabilities that fit
directly into an existing process.
To put all of these issues into perspective, letâ(TM)s consider them together. Figure 7
plots each issue into one of four quadrants based on the opportunity they present
to a criminal and the cost of realizing that opportunity. Only issues that make it
to the top right [cheap exploit, many targets] resulted in widespread exploitation. The others did not present
enough of a financial opportunity or they were too expensive to monetize.
Basically both OS X and - especially - Linux fails the "many targets" test for desktop-style drive-by exploits. You could argue that Linux, which is used with Apache on most internet servers, presents a formidable number of targets. Yes, but we haven't seen a "cheap" exploit which were remotely exploitable against any of the OSes in the latter years.
It wasn't my intent to troll. The IBM report is an interesting read. Not just about operating system vulnerabilities, but also because it precisely addresses the "economics" of vulnerabilities - why some are exploited and others are not.
BTW, I noticed that I claimed the GP was talking about suing. I was mistaken (that was another thread) he talked about when Microsoft used some of their bright brains to improve the quality of their code (alluding that it is bad). I stand by my comments about the report, though. The IBM report shows that Microsoft has actually improved *a lot* since the sasser, nimda, code red disasters.
The GP I replied to suggested suing Microsoft because of all of the vulnerabilities.
I then pointed out that according to a normally respected organization (IBM) who did their homework, other OSes have far more vulnerabilities, alas we could sue Apple 3 times over and, well, Linus? 2 times over.
But then you jump in and once again equates vulnerabilities with exploits. And on top of that calls me a troll?
Get a clue will you? There is a difference between a vulnerability and an exploit. In case you don't know the difference is exploits are created by attackers taking advantage of vulnerabilities.
If you want to sue some company on the basis of something they did or failed to do, you may try to sue on the basis of vulnerabilities.
Your reference to exploits created by attackers is totally and utterly out of context here.
Or are you again trying to use the number of exploits that exist for Windows as "proof" of the perceived vulnerability of that OS when we actually have much better real data (vulnerabilities).
Or is your problem that some other OSes appear to have more vulnerabilities?
That IBM report does not state anything about MS patch time, and it was not what I wrote about.
The GP was talking about "writing secure code". By that I assume he meant writing it secure in the first place.
And in that area - contrary to popular myth - Microsoft seems to lead the pack. If you don't consider those who didn't even make the list, like the BSDs.
Why don't you read the report? There is more in there than mere operating system security, although that is probably the part that will ruffle feathers on/.
Microsoft comes out as the vendor with most vulnerabilities (across all products) overall. No surprise there, as their product portfolio is quite large. That IBM and Oracle are also on the list is also no surprise. They also have huge software portfolios.
But Apple makes it to 2nd spot, that was a bit surprising. They produce much fewer software products than the others.
But perhaps most alarmingly is the fact that several PHP based single-product vendors made it on to the top-10 list by virtue of their single products.
Apparently it works. Microsofts operating systems have less vulnerabilities than any of the other mainstream operating systems, OS X and Linux.
This is not a troll post. I know the general consensus on/. is that Microsoft operating systems and software have more holes than any other. However, IBM (X-Force team) draws regular statistics based on disclosed vulnerabilities.
Linux kernel has roughly 2x the vulnerabilities of Vista,
OS X has 3x the vulnerabilities of Vista.
Windows XP is not doing to bad either. It still has far fewer vulnerabilities than Linux and OS X.
Now, in a (probably futile) attempt at preempting some of the popular myths as well:
The IBM research team did count Linux kernel vulnerabilities, i.e. they did not add vulnerabilities from multiple distributions, neither did they count vulnerabilities from distros' bundled software as kernel vulnerabilities.
Microsoft does disclose all of their vulnerabilities when patched. They may keep vulnerabilities secret until then. The delay in disclosure may create an temporary undercounting but as the vulnerability must eventually be patched this will even out over time.
Microsoft does not "slip patches" secretly through. Any Windows admin will tell you that all patches are followed by very detailed information about what is being patched and why.
If undercounting is going on, it is far more likely to be a trait of Linux kernel, as the kernel teams policy is to fix a bug when they see it and not go out of their way to formally "disclose" the bug as an official vulnerability. At least Linus has said as much.
With the risk of being modded into obscurity and burning all my karma:
Simply don't venture into the trap that OS is inherently more secure than closed source. It is unfortunately easily refuted. PHP, WordPress, Typo3, Drupal are all open source projects with very challenged security track records.
Security and open source - despite popular belief - seems to be orthogonal concepts. It seems to have more to do with the QA/QC processes in place than with the actual development model.
It actually show that through 2008 Linux kernel experienced 2x the vulnerabilities of Vista/Server 2008, Apple OS X was hit by 3x the vulnerabilities.
The IBM X-Force team went through the disclosed CVEs and attributed them to the operating systems. This way they didn't multi-count Linux because of multiple distributions, and also they didn't count vulnerabilities from the bundled apps from the distributions.
You may claim (as many surely will) that MS somehow "hides" vulnerabilities. However, that doesn't seem to be the case when you look at the information (the "bulletins") which is supplied with each patch.
Simply put, security seems to be an orthogonal issue. Open source does not seem to automatically or inherently guarantee fewer vulnerabilities or better in-depth protections. It doesn't seems to make it worse, though.
Claiming so will only make you vulnerable to counter-examples (of which there are many) and will allow the MS lackeys to paint you as an ideology-driven zealot.
Chunk it down. Point to the security track record of the products you recommend. Leave out the claim that they are more secure because they are OS, just claim that the products are produced by vendors that are accountable, dependable and transparent with proven security records.
1) the prompt does not elevate to administrator, it elevates from "low integrity" to "normal integrity". UAC has more levels than sudo, you know.
2) The prompt comes from the Internet Explorer broker process. It is not under control of IE. IE can request (send a message) to the broker process requesting it to "marshal out". The broker process is not under control of the low integrity IE process running the rendering.
I didn't believe this was a marketing ploy. But, I have noticed that "news" about Windows 7 seems to hit the press almost every week, almost like clockwork. I myself have wondered whether there is a new marketing regime in Redmond who knows how to play the "open" game.
Slashdot Mirror
LOL. Actually ls is an alias for the cmdlet Get-ChildItem. That's the canonical name. Other aliases are, surprise, dir and gci (no points for figuring that one out). Unlike *nix aliases PowerShell aliases are strictly aliases, i.e. they are merely alternative names for the same cmdlet. The shortcut functionality of *nix aliases are covered by PowerShell functions or filters.
The fact that the cmdlets canonical name is Get-ChildItem hints of another concept in PS: The same cmdlets can be used against multiple types of targets. The "current directory" has been extended to "current location". A location can be in anything for which there exists a PowerShell provider. It comes with (no suprise) a provider for filesystem in which "child items" will be files and/or directories. However, also the registry is exposes as a "file system", so you can set the current location to a node in a registry hive and use the exact same commands: ls, rm, cp. Other providers are certificate store, active directory, exchange, credentials store etc.
The % is actually an alias for the Foreach-Object. That cmdlet takes up to 3 script blocks: begin block, process block and end block. It starts by executing the begin block once, then executes the process block for each object in the pipeline and finally executes the end block once. If only a single block is defined (as in the above examples) it is assumed to be the "process" block. As PowerShell script is an expression language it will feed the pipeline with whatever the expressions in the block returns. During execution $_ (like in perl) is a reference to the current object being handled.
I have no points to give you, but this is *the* most insightful post I have seen on the topic of shells on slashdot. Ever.
I still think that PowerShell can do something for Windows that is not currently possible on *nix. Until a unified object concept materializes, that is.
when
ls -r | ?{-not($_|ls)}
would suffice?
Explanation:
1) list all items recursively from the current location
2) filter only those items where ls returns an empty set.
Btw, the objects returned from that command are *still* DirectoryInfo objects, allowing even further operations or property accesses.
Also, this command will work the same even if the "current location" is a node in the registry, the certificate store, the credentials store, a group in active directory etc etc.
In other words if you change the location to an organisational unit in AD, the exact same command will find empty sub-containers.
PowerShell ideas are more relevant to Windows than they are to *nix. PowerShell is object-oriented: The pipes are objects, not text. That saves a lot of parsing and allows interaction (like calling methods) with the objects flowing through.
PowerShell also unifies the object-oriented models on Windows: COM, .NET and WMI. Most of Windows APIs are now either fully object-oriented (e.g. DirextX, Speech) or have been wrapped in by object-oriented models such as .NET or WMI.
*nix generally does not expose API in object-oriented fashions. Hence, most of the advantages that PS may have from being OO are not really relevant on *nix.
That said, some of the other less prominent features of PS could conceivably be relevant for *nix shells, such as unified scripting, better type system and integrated regular expressions.
Available from Microsoft for XP, 2003; included in Server 2008 and Windows 7.
The name is really lame, but it *is* damn powerful. At least for Windows which has most of it API exposed through object-oriented technologies (COM, .NET and WMI) which are easily used in a unified way by PowerShell.
Just a few quick samples:
Only their website doesn't even mention Microsoft as a partner. IBM, Borland, Sun and Oracle are mentioned as partners, though, with contact details.
What was the intention of mentioning Microsoft and leaving out those partners? Is Microsoft a business partner at all?
I hate software patents. But summaries like this blatantly trying to skew facts to weasel in hints of a grand Microsoft conspiracy does the fight against software patents disservice.
What a crook. Bad! I had to look twice because I fully expected this to be a "kdawson". Not this time, though.
Nope, not the same. The CLR/JVM are comparatively very small cores and offers intrinsic protections against memory corruption, dangling pointers, buffer overflows etc. The extension mechanisms in CLR/JVM are based on that intrinsic level. With PHP practically all useful functionality (unless you write "extensions" in PHP) such as regex, xml serialization, net/socket communication, certificate parsing etc etc are all written on top of C. Which is not a language known for it intrinsic protections against memory corruptions and buffer overflows. To put it mildly.
Well, you are wrong. PowerShell objects are not xml based at all. PowerShell can expose COM, .NET and WMI objects as PowerShell objects.
The ls command (actually an alias for Get-ChildItem) returns a mix of DirectoryInfo and FileInfo objects. Each with a number of properties and methods. A formatting rule for a collection of FileInfo and DirectoryInfo items defines what appears to be the "usual" ls format. But you can actually do something like:
ls c:\ | ?{ $_.Length -gt 100KB} | ft FullName,Length
(get child-items of c:\; select only those with a length greater then 100KB and output them formatted in a table with two columns: The full path name and length).
Thirty years of success for us Unix users doesn't feel like a waste of time ...
It's through C APIs I have access to thousands of libraries for various tasks. I have them in Python, Perl and all other major scripting languages too -- but only because those C APIs exist.
They are still pairs of which C is always one. What's more, using those objects from C is a pain as they all have different object models and name resolution principles.
True interoperability comes when you can use Python objects directly from Ruby or PHP as if they were native objects. The C API doesn't give you that.
You may heralt the 30 years of Unix C API. Meanwhile Windows has almost completely moved to an object-oriented model (COM) for many APIs. COM is a binary object model with absolutely minimal overhead. Cue DirectX. The APIs which have not moved to COM are generally wrapped in object-oriented .NET APIs.
The upshot is that Windows is becoming a object oriented OS. That's what enabled PowerShell - and why PowerShell really is at it best at Windows despite PASH (PowerShell for *nix). Leaving the text-based pipes behind, PowerShell now features an object-based pipeline. You will only realize the true value of this development once you try it.
So I would say that we have come to a point where the lack of more sophisticated object models in *nix will be holding it back. At one point I believed that Java could be it (Java views everything as objects), but Sun blew it with the OS community at that point, only releasing it under a true OS license only last year.
You can view the VM as nothing more than a glorified assembler. In that case you would focus on bytecode. And sure, as bytecode is really just a portable assembly language you can pass around (simple) objects.
What I'm talking about is the ability to pass around higher level objects, such as e.g. dynamic objects or classes or even generics.
The .NET CLR actually has define-site generics with variance, compatible like Scala. On the .NET platform a language like Scala would be able to interop with generics with the upcoming C# 4, VB and other generics-aware languages. The Java platform stops short of specifying how generics should look. Hence, JVM based languages cannot interop on generics. You cannot inherently take a Scala generic and realize it (create a concrete type) using another language, not even Java.
The same goes for dynamic objects, i.e. objects for which their "host language" defines the name resolution for members. These rules are different for most languages. As you point out Jython objects are merely hashtables. Anyone else must know the Jython rules for member resolution to use those objects.
Compare that to the situation on the DLR/CLR. The IDynamicObject lets anyone else invoke methods dynamically on any object and defer the member resolution to code provided by the "host language". IronPython objects can be used from IronRuby, C# or VB as if they were native objects. Whenever a member is referenced the IronPython name resolution will spring into effect and look the name of in whatever internal hashtables are relevant.
The JavaVM was originally only designed to execute Java code. Hence, it is only slowly adopting constructs needed to accommodate other languages. This means that lacking the infrastructure those languages will merely use the byte code as an assembly language, not the type system as it carries over all of the Java limitations.
So no, the JVM spec is very different from the CLR/CTS. CTS was a generalized type system from the get-go and was always designed to be more general than any of the languages.
You are right that the integration will never be "perfect". That would require the languages to become effectively just different syntax for the same constructs, sort of the relationship between C# and VB.NET.
C# and VB.NET exist and are supported because of historical reasons, not because one of the languages supports or excels in a particular paradigm.
However, it will be possible to consume a C# class (a static .NET class) in Ruby and use it as base for the Ruby class construction. I.e. you can take a C# class and mix in more members. This will yield a dynamic class, however. If you went back to C# with this, C# doesn't support specializing dynamic classes, but it will (4.0) support creating instances of dynamic classes. It will know that these objects are dynamic and that member resolution should be done by the object at runtime. To C# the object will be statically typed to be dynamic.
The point is exactly to raise the common denominator and ease interop. Provisions also exists for language developers to support drastic optimizations, such as member lookup caching etc. The goal is not to have all languages converge; rather it is to allow full specification compliant languages to interop and to remove the pain of doing so.
And I think you are still focused on a single language pair. The really compelling upshot of IDynamicObject is that you can interop with, say, C#, F# and Ruby.
Really. So how are you going to represent classes with multiple or "mixin" inheritance in a language that only has static single inheritance?
The dynamic classes of Ruby, JavaScript, PHP etc. are accomodated by using the IDynamicObject interface. Basically each object are allowed to define its own member resolution. Ruby mixins can still just update a symbol table somewhere up the hierarchy. During execution the object will be asked to resolve any member access itself. This means that Ruby objects can resolve using the Ruby way which will respect mixins. JavaScript can resolve member access according to prototypes etc.
You do not need to map dynamic classes to static classes. You would only need that if you wanted to be able to specialize classes from other languages. Most interoperability between languages will not require class interop. The most important interop needed is object interop, where you pass object instances between languages, not classes. Indeed some languages (notable JavaScript) don't even *have* classes.
What good are multiple languages if all inter-language integration have to be funneled through some narrow C-like basic model?
The problem is not with the languages but rather with the platform on which they are based. As long as the common denominator is C memory blocks or opaque text-serialized objects, integration is always going to be a pain.
Sometimes language pairs are supported by an asymmetric relationship (one of the languages often being C). Using objects/features from one language is usually easier in one direction than in the other. Often there are severe restrictions on the layout of objects/functions. Examples of this is how PHP can use some C based functions/objects, provided they adhere to the "PHP way" of laying out objects. Using PHP functions from C is considerably more involved and certainly does not qualify as minimalistic.
The problem is that these bindings are often just pairs, excluding other languages from richer integration. Sure, you can integrate other languages with C as well, but rarely will the object layout of one language align with the layout of another language. This makes multi-language integration a pain. Going (down) to C level loses a lot of meta information and complicates going up the abstraction chain to another language. Essentially this is a hub-and-spoke problem with the hub being too weak. Another example is Java/JavaFX. It's quite easy to use existing Java classes from JavaFX, but going in the other direction requires a number of ceremonies. And this is still just a pair. Even though the Java platform has been used to implement a rich set of languages, the basic problem is still there: The "hub" (Java) is too weak to describe objects/functions on a the level which would let you pass objects from Jython to JRuby to Groovy to JavaFX to Scala. Java's generics are incompatible with the generics used in Scala. Java (and also the VM) does not support unsigned integers.
Java was always designed to be an abstraction over the underlying platform not to integrate with it. This philosophical difference was actually at the center of Microsofts dispute with Sun over the direction of Java. Microsoft wanted the language to evolve in the direction of facilitating integration with the platforms (one in particular) while Sun wanted to abstract away the world outside Java and have everything remodeled in Java. Microsoft enhanced their Java implementation with the "lacking" features, Sun sued and won and Microsoft completely left Java and went on to design .NET.
Your example illustrates that at least in the area of multiple programming languages, the .NET platform is much more evolved. Unlike Java, Microsoft designed .NET as a multi-language platform from the get-go (although initially for multiple statically typed languages).
The .NET Common Type System (CTS) and common language runtime (CLR) were always (and still is) more advanced and feature rich than the primary driving language, C#. The CTS already supports generics variance (C# and VB don't yet) as part of the platform. (aside: Scala generics while being define-site with variance are merely an internal Scala thing and not compatible with anything else; Java generics based on type erasure are merely a compile-time only and as such doesn't exist for anything else).
The latest development in .NET is to incorporate support for dynamic languages into .NET. C# 4.0 and the CTS will lay out a common principle (a "dynamic" interface) which theoretically can accommodate most known static languages, hybrid languages and dynamic languages on a very high level.
This will enable any language which adhere to this specification to participate in a high fidelity hub-and-spoke architecture. You will essentially be able to pass a IronRuby object to IronPython, C#, VB, F#, Eiffel etc. and interact with it there while still relying on the Ruby
This is because interpreted JavaScript is regarded as data (to be read by the interpreter); NX is only effective against binary executable code.
Incidentally, this is a big difference between Java and .NET. Because Java typically uses hotspot VMs it will regard Java as data (byte code). Only if the hotspot compiler decides to compile the bytecode all the way to machine instructions will Java execute as binary code. Consequently Java will inherently be able to execute byte code. This means that for the processor the byte code is just data. If a buffer overflow can overwrite the bytecode or the Java stack, the interpreter is quite happy to keep on interpreting the bytecode.
.NET OTOH always compiles the IL (.NET bytecode) code to machine code before executing it. This means that the NX protection can actually protect .NET code but not Java code.
Google Chrome leverages this Vista feature. http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ The sandboxing feature in Vista is implemented with process integrity levels. A process with "low integrity" is severely restricted in what it can do on the system. Adobe could use this feature for Acrobat. They actually do use it (they have to) for Flash, as the Flash plugin in IE runs inside the sandbox. The crux is that a sandbox is often so severely restricted that you need a helper (called "broker") process to do the privileged stuff such as downloading/uploading files etc. Flash actually made their own broker process for Flash and left a stupid bug in there. That was the flaw which allowed Vista to be compromised in last years' pwn2own contest.
Just read the report, will you? Your question has already been answered pretty convincingly by the IBM researchers.
Here, I'll give you the link again: http://www-935.ibm.com/services/us/iss/xforce/trendreports/xforce-2008-annual-report.pdf
And I'll even quote:
While all of the factors considered by CVSS are important, what CVSS scores fail to capture is the economic opportunity that a vulnerability presents to an attacker. The days of amateurs, college students, or hackers taking joy rides on corporate information systems are largely over. Todayâ(TM)s attackers are economically motivated. They are international criminal organizations who make a living stealing financial information and identities. Todayâ(TM)s threat is far more sophisticated and far more dangerous than the security threats of yore, but in some ways it is more predictable.
The result of this new reality is that there have been several vulnerabilities this year that received very high CVSS scores and raised widespread alarm within the security industry. However, they were not widely exploited in the wild. In most cases, these vulnerabilities did not fit well into the current business models of computer criminals
Vulnerabilities that fit into existing processes and which can leverage existing automation are easy for criminals to monetize. Vulnerabilities that require the development of new processes or software are much less likely to present an attractive opportunity to criminals, particularly if they represent a one-of-a-kind set of circumstances that is unlikely to be repeated in the future. Even when it does make sense for criminals to develop a new attack methodology to exploit a new class of vulnerabilities, widespread attacks will usually take longer to emerge than for vulnerabilities that fit directly into an existing process.
To put all of these issues into perspective, letâ(TM)s consider them together. Figure 7 plots each issue into one of four quadrants based on the opportunity they present to a criminal and the cost of realizing that opportunity. Only issues that make it to the top right [cheap exploit, many targets] resulted in widespread exploitation. The others did not present enough of a financial opportunity or they were too expensive to monetize.
Basically both OS X and - especially - Linux fails the "many targets" test for desktop-style drive-by exploits. You could argue that Linux, which is used with Apache on most internet servers, presents a formidable number of targets. Yes, but we haven't seen a "cheap" exploit which were remotely exploitable against any of the OSes in the latter years.
It wasn't my intent to troll. The IBM report is an interesting read. Not just about operating system vulnerabilities, but also because it precisely addresses the "economics" of vulnerabilities - why some are exploited and others are not.
BTW, I noticed that I claimed the GP was talking about suing. I was mistaken (that was another thread) he talked about when Microsoft used some of their bright brains to improve the quality of their code (alluding that it is bad). I stand by my comments about the report, though. The IBM report shows that Microsoft has actually improved *a lot* since the sasser, nimda, code red disasters.
Someone forgot to put a where clause on that delete.
The GP I replied to suggested suing Microsoft because of all of the vulnerabilities.
I then pointed out that according to a normally respected organization (IBM) who did their homework, other OSes have far more vulnerabilities, alas we could sue Apple 3 times over and, well, Linus? 2 times over.
But then you jump in and once again equates vulnerabilities with exploits. And on top of that calls me a troll?
Get a clue will you? There is a difference between a vulnerability and an exploit. In case you don't know the difference is exploits are created by attackers taking advantage of vulnerabilities.
If you want to sue some company on the basis of something they did or failed to do, you may try to sue on the basis of vulnerabilities.
Your reference to exploits created by attackers is totally and utterly out of context here.
Or are you again trying to use the number of exploits that exist for Windows as "proof" of the perceived vulnerability of that OS when we actually have much better real data (vulnerabilities).
Or is your problem that some other OSes appear to have more vulnerabilities?
That IBM report does not state anything about MS patch time, and it was not what I wrote about.
The GP was talking about "writing secure code". By that I assume he meant writing it secure in the first place.
And in that area - contrary to popular myth - Microsoft seems to lead the pack. If you don't consider those who didn't even make the list, like the BSDs.
Why don't you read the report? There is more in there than mere operating system security, although that is probably the part that will ruffle feathers on /.
Microsoft comes out as the vendor with most vulnerabilities (across all products) overall. No surprise there, as their product portfolio is quite large. That IBM and Oracle are also on the list is also no surprise. They also have huge software portfolios.
But Apple makes it to 2nd spot, that was a bit surprising. They produce much fewer software products than the others.
But perhaps most alarmingly is the fact that several PHP based single-product vendors made it on to the top-10 list by virtue of their single products.
Apparently it works. Microsofts operating systems have less vulnerabilities than any of the other mainstream operating systems, OS X and Linux.
This is not a troll post. I know the general consensus on /. is that Microsoft operating systems and software have more holes than any other. However, IBM (X-Force team) draws regular statistics based on disclosed vulnerabilities.
http://www-935.ibm.com/services/us/iss/xforce/trendreports/xforce-2008-annual-report.pdf
Now, in a (probably futile) attempt at preempting some of the popular myths as well:
With the risk of being modded into obscurity and burning all my karma:
Simply don't venture into the trap that OS is inherently more secure than closed source. It is unfortunately easily refuted. PHP, WordPress, Typo3, Drupal are all open source projects with very challenged security track records.
Security and open source - despite popular belief - seems to be orthogonal concepts. It seems to have more to do with the QA/QC processes in place than with the actual development model.
IBM just released a report which shows that Vista and Windows Server are actually hit by fewer vulnerabilities than "Linux kernel", although suffering from more malware. http://www-935.ibm.com/services/us/iss/xforce/trendreports/xforce-2008-annual-report.pdf
It actually show that through 2008 Linux kernel experienced 2x the vulnerabilities of Vista/Server 2008, Apple OS X was hit by 3x the vulnerabilities.
The IBM X-Force team went through the disclosed CVEs and attributed them to the operating systems. This way they didn't multi-count Linux because of multiple distributions, and also they didn't count vulnerabilities from the bundled apps from the distributions.
You may claim (as many surely will) that MS somehow "hides" vulnerabilities. However, that doesn't seem to be the case when you look at the information (the "bulletins") which is supplied with each patch.
Simply put, security seems to be an orthogonal issue. Open source does not seem to automatically or inherently guarantee fewer vulnerabilities or better in-depth protections. It doesn't seems to make it worse, though.
Claiming so will only make you vulnerable to counter-examples (of which there are many) and will allow the MS lackeys to paint you as an ideology-driven zealot.
Chunk it down. Point to the security track record of the products you recommend. Leave out the claim that they are more secure because they are OS, just claim that the products are produced by vendors that are accountable, dependable and transparent with proven security records.
2 mistakes:
1) the prompt does not elevate to administrator, it elevates from "low integrity" to "normal integrity". UAC has more levels than sudo, you know.
2) The prompt comes from the Internet Explorer broker process. It is not under control of IE. IE can request (send a message) to the broker process requesting it to "marshal out". The broker process is not under control of the low integrity IE process running the rendering.
I didn't believe this was a marketing ploy. But, I have noticed that "news" about Windows 7 seems to hit the press almost every week, almost like clockwork. I myself have wondered whether there is a new marketing regime in Redmond who knows how to play the "open" game.