Even if such a platform exists, how does that preclude Microsoft from suing? Remember that the thesis here is that Microsoft would disregard the licenses already granted for C#, .NET Framework, compilers etc and just sue to exhaust your funds. Why couldn't they claim that you infringed an algorithm (or whatever) even if you were using Java or Python? After all, they have no legal standing but are considered *so* malicious that they will sue even when they have no legal standing.

The whole "Microsoft will sue!" is nothing but FUD.

In reality - because of the promissory estoppel of the community promise - users of .NET and any other technology under the community promise is much better protected than when using alternatives. This is because the promissory estoppel can be used to dismiss a lawsuit outright.

None. Zero. Zilch.

This does not make sense to me at all. While I agree that's the way they should have taken (IMHO using MVVM instead of MVC), it is almost exactly the way they took. They didn't have all the ducks in row at the first iteration, but it was the plan all the way. They said so at the time.

You did not belive the FUD about Microsoft abandoning .NET did you? .NET is very, very much in the game. At /Build// Microsoft just announced Universal Apps.

MSDN has documentation

With universal apps you build one app for phone, tablets and laptops/desktops. The same app can share views and viewmodels (MVVM) across the form factors, or they can have completely different view/viewmodels. A view/viewmodel can also "adapt" to the formfactor - showing only primary and essential information on phones, more on tablets and include secondary/tertiary information on desktops.

When deployed, the universal apps are deployed as IL/CLR code. When a device installs an app, the cloud service will perform the compilation and serve a native app to the device, compiled for the architecture, memory requirements and core count. The delivery system will only serve resources used by the specific device, i.e. even if the universal app is distributed with extensive resources for desktop users, the package that is downloaded to a phone will strip those resources.

Metro was never mutually exclusive with .NET. Microsoft made plenty of blunders both with their messaging on Metro as well as the initial Dr. Jekyll-and-Hyde two-personality Windows 8. But they have been consistent on their messaging on .NET and apps.

No they haven't. You just do not want slashdot readers to read them, because they do not say what you claim.

http://www.internetnews.com/de...

Quote from that article:

GP is correct, those who took a look at it indeed came away with the impression that it was quite pristine.

You, OTOH, are just lying.

ASLR was invented as a mitigation of "return oriented programming" which was itself a way to get around DEP/NX. As such, ASLR targets executable memory, making the memory addresses of candidate executable code fragments hard to guess. ASLR does not randomize data segments - there's no need since the original intent was to make executable locations hard to guess. Non-executable locations was not the problem ASLR tried to solve.

And in the case it would not matter at all if the location was randomized, since this bug is an unbounded offset to a memory location. The attacker does not need to know the actual memory location, he just needs to specify a too large or too small offset to read adjacent memory. Yes, going too far could trigger a segfault, but the attacker will have dumped all memory until then. So what? The attacker can just continue the attack once the service restarts.

The point is: The attacker does not need to know anything about the memory layout. The server already allows him to offset from a pointer to a known valid location.

clearly demonstrates the intent to create an appearance of an animated continuous movement. The technology at the time did not allow for the same smoothness as today. But even today you can argue that the movement is *still* not continuous - it is just that Apple has "invented" smaller and more steps.

Let it go: The video is clearly prior art for state change. It is presented as a general way to change state on an electronic device with a touchscreen.

What Apple has is
      1) Apple "re-invented" the state change for an handheld device
      2) The Apple state change is "unlock" - a specific example of a state change

For 1: it is trivial to demonstrate that such a state change on a handheld device would derive automatically from the technological advances that shrink devices to the point where the touch screen can be handheld.

For 2: It is interesting if the *specific* (unlock) state change is not covered by the broader state change mechanism demonstrated in the video.

Compare (original)

with

The latter accurately describes what happens in the Microsoft video demonstration. All I did was to substitute (state) for "unlock", (change state of) for "unlocking". I also removed "handheld".

So what we have is that Apple is using the general application of switches with graphical representation to perform a specific function (unlock) rather than the general (changing state) and Apple applying it to handheld devices.

Everyone can recognize unlocking as a specific example of a state change. Your "invention" does not become more original because you narrow the scope to which it is applied.

Same goes for handheld. It was done on a electronic device with a touch screen. When the technology advances and allows the electronic device to be carried around it does not make the same idea new again.

During runtime, a.NET already runs compiled. This saves on the JIT compiler.

However, they also announced (later session at /Build//) that the new compilers (including the JITs) will take advantage of SIMD. For some application types this can allegedly lead to serious (like in 60%) performance gains. Games were mentioned.

MS announced that developers still need to pass hints to the compiler on what architecture, CPU core count, available memory etch, to compile for. You can (cross) compile to multiple architectures.

This technology is already at work when deploying apps for Windows Phone 8: Developers pass IL code to the store, native compilation is performed per device type in the cloud (CPU architecture, OS version, memory, ...) and the binary is passed to the device.

That is precisely what they announced. No correction needed. They use that C++ backend to emit code for specific processor architectures (and core counts) and do global optimizations.

Martian feel threatened by PowerShell. So he is spreading CUD.

PowerShell is an amazing shell. As a shell, its core is even simpler and more consistent than any of the *sh shells. Yet, it is based object models and is designed to be hosted by applications, not just a command line. The commands (cmdlets) are self-discoverable through metadata, meaning that parameter help etch can all be generated from the actual command itself rather than rely on authored text.

From Steve Gibson and Leo Laporte:

Windows SteadyState from Microsoft is available for Windows XP.

SteadyState virtualizes the OS directories transparently on the disk. File writes/updates are directed to a secluded area. You can set it to simply delete those journaled updates upon restart/signoff. Any malware will be effectively gone. Windows Update would still be possible when signing in as the SteadyState administrator (creating an updated image), but that's kind of moot at this point.

Citation needed.

Yes, Windows servers are compromised less because it is far easier to set those up securely. Especially IIS+ASP.NET is way more secure than Apache+PHP in almost any way; not least the programming model where PHP almost encourages SQL injections and XSS where with .NET/MVC it is hard to create SQL injections and XSS vulnerabilities.

ACLs are available with most distros nowadays. However, the point is they are bolted on. They represent a MAC model which competes with simplistic linux file system permissions. You do not switch to ACLs, you turn them on and have to manage them in parallel with regular file system permissions. Thus they complicate the security model rather than refine it (and they still support inheritance pretty poorly). Now throw in SELinux, SUID root utilities and *nobody* stand any realistic chance of performing a reliable security assesment of a Linux system.

Coming from someone who cannot remember the "project" with (and obviously does not use) ACLs. Nice.

The biggest threat to Linux security is the number smug, amateurish Linux admins who believe they are all safe because their tribal platform is blessed with magic fairy dust that makes vulnerabilities un-possible.

On the architectural level, the biggest threat to Linux is the outdated security model inherited from the 1970 where saving a few bytes at the expense of better layered security was all the rage. This is exemplified by:
* The woefully outdated permission model where proper ACLs had to be bolted on, and to this day competes with and confuses security planning and auditing (Windows NT had ACLs from the start).
* The fact that only the file system objects were considered for access control. (In Windows the security model extends to all objects: Threads, processes, synchronization objects (locks, semaphores), sockets/ports etc)
* Security tokens do not exist. Instead of granular tokens you have to use "effective users" - breaking the Least Privilege Pinciple (Windows NT was designed with granular process tokens from the start).

When creating a new IIS in Windows, the site is automatically set up with the most restrictive isolation. You do not even have to create a user for the site to run under - the security model already knows about identities and each site gets it own identity which must be explicitly granted permissions to read the file system.

That's rich. The absolutely most security-ignorant ecosystem is the LAMP community. PHP with it's abysmal security record is the worst language *ever*.