Forgot your password?
typodupeerror

Comment: Re:Trolling? (Score 1) 270

by benjymouse (#46729341) Attached to: The New 'One Microsoft' Is Finally Poised For the Future

Microsoft SHOULD have taken MVC design to its next logical level, and built upon .net instead of throwing it all away in the blighted name of Metro... common model and controller code across all Windows platforms, with different views for desktop, tablet, and maybe mobile devices whose displays are too small to treat like a tablet. They could have compiled the code to CLR, then had the installer itself compile it to native code optimized for the local platform. But no... they just *had* to ruin a good thing, and try to ram touch down everybody's throats.

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.

Comment: I call BS (Score 3, Informative) 270

by benjymouse (#46729165) Attached to: The New 'One Microsoft' Is Finally Poised For the Future

The links have long disappeared due to DCMA takedowns.....

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:

One technology enthusiast at Web site kuro5shin noted many of the hacks (additions) to the code base included some colorful comments and creative use of adjectives in noting programming changes.

In this case, the reviewer concluded the code was generally "excellent." But he also noted the many additions to the Windows code to be almost universally compatible with previous Windows versions. And third-party software has "clearly come at a cost, both in developer-sweat and the elegance (and hence stability and maintainability) of the code."

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.

Comment: Re:ASLR anyone? hype? (Score 2) 303

by benjymouse (#46694517) Attached to: OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks

I've actually wondered about this too. Read overruns will crash a program just as badly as write overruns; Read AV in Windows [NT], Segmentation Fault in *nix (General Protection Fault in legacy Windows), etc. reading memory will tell you enough about the layout of memory to cherry-pick addresses pretty well, and probably to determine the ASLR mask, but you're still going to have the issue of what, within the heap, is allocated. You could probably do OK by starting from the stack (which is in a predictable enough location) and working from there, I guess?

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.

Comment: Re:The Slide-to-Unlock Claim, for reference (Score 1) 408

by benjymouse (#46694009) Attached to: Apple: Dumb As a Patent Trolling Fox On iPhone Prior Art?

As mentioned in a different reply, I see non-continuous movement: slider at the left side; slider in the middle; slider at the right side. Three images, replaced in succession, as I said.

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.

Comment: Re:The Slide-to-Unlock Claim, for reference (Score 1) 408

by benjymouse (#46693825) Attached to: Apple: Dumb As a Patent Trolling Fox On iPhone Prior Art?

Compare (original)

A method of unlocking a hand-held electronic device, the device including a touch-sensitive display, the method comprising:
detecting a contact with the touch-sensitive display at a first predefined location corresponding to an unlock image;
continuously moving the unlock image on the touch-sensitive display in accordance with movement of the contact while continuous contact with the touch screen is maintained, wherein the unlock image is a graphical, interactive user-interface object with which a user interacts in order to unlock the device; and
unlocking the hand-held electronic device if the moving the unlock image on the touch-sensitive display results in movement of the unlock image from the first predefined location to a predefined unlock region on the touch-sensitive display.

with

A method of (changing state of) an () electronic device, the device including a touch-sensitive display, the method comprising:
detecting a contact with the touch-sensitive display at a first predefined location corresponding to a (state) image;
continuously moving the (state) image on the touch-sensitive display in accordance with movement of the contact while continuous contact with the touch screen is maintained, wherein the (state) image is a graphical, interactive user-interface object with which a user interacts in order to (change state of) the device; and
(changing the state of) the () electronic device if the moving the (state) image on the touch-sensitive display results in movement of the (state) image from the first predefined location to a predefined unlock region on the touch-sensitive display.

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.

Comment: Re:What about number-crunching performance? (Score 2) 217

by benjymouse (#46654823) Attached to: .NET Native Compilation Preview Released

I skimmed over the links, but I probably just missed it. So apps take 60% less time to start, and they use 15% less memory. What about run-time performance? How much faster are they when executing?

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.

Comment: Re:Only benefits smaller devices (Score 2) 217

by benjymouse (#46654779) Attached to: .NET Native Compilation Preview Released

The raw speed of the code might actually diminish since the .net runtime could have optimized it better for the specific environment (CPU model, available RAM, phase of the moon, etc).

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.

Comment: Re:Translator? (Score 1) 217

by benjymouse (#46654693) Attached to: .NET Native Compilation Preview Released

Correct me if I am mistaken, but I'm pretty sure that if they are using the backend they are skipping the lexing and parsing steps and going straight to the generation of the intermediate representation. That would mean that there is no generated C++ code to see.

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.

Comment: Re:What about 2012R2??? (Score 1) 387

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.

Comment: Re:Windows SteadyState (Score 1) 423

by benjymouse (#46597065) Attached to: Ask Slashdot: Preparing For Windows XP EOL?

From Steve Gibson and Leo Laporte:

Now, it's not quite as onerous in my experience as Jim's letter indicates because it does not
make an entire copy of your system partition and/or drive. Instead you set aside a block of
hard drive space. And using a feature, basically it's file system filtering, this is able to capture
any changes which are made to the system drive. And essentially it caches the changes. So, for
example, when any application, installer, literally anything you do, I mean, this thing is global.
You cannot turn it off without restarting Windows. So it's not something that just sort of easily
comes and goes. I mean, this is meant to be bulletproof.
And I discovered the hard way that it even protects the partition table, and that first track of
the drive which we were talking about recently could be prone to preboot kernel rootkits. I was
using something else that did deliberately change that first track, very much in a kernel rootkit
fashion. And that'll be the subject of an upcoming podcast because it involves performing whole
drive encryption. And it turns out that SteadyState uninstalled this thing, even though I had
SteadyState sort of in a mode where it was supposed to allow changes to be saved. So, I
mean...

Comment: Windows SteadyState (Score 4, Informative) 423

by benjymouse (#46596493) Attached to: Ask Slashdot: Preparing For Windows XP EOL?

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.

Comment: Re:The big problem with Linux security. (Score 1) 220

by benjymouse (#46525587) Attached to: Malware Attack Infected 25,000 Linux/UNIX Servers

Is that why Windows and IIS got hacked all the time while Linux and Apache/PHP very rarely ?

Citation needed.

Because it had better security ?

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.

There was a project for Linux kernel that gives advanced ACL capabilities to Linux systems. I forgot the name of it now, but basically.. whatever was possible to do, you could do it.

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.

There are hundreds of projects that you can add and use.. (stable, tested projects).

The problem with security is an admin that thinks blocking port 22 is gonna keep him safe... if he uses Linux, and the other problem with security in general... is using Windows.
The other problem with security is management hiring idiots (above mentioned jolly bunch, block port 22 and all ok) and/or outsourcing administration to cheap indian companies that work for peanuts.

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

Comment: Re:The big problem with Linux security. (Score 1, Insightful) 220

by benjymouse (#46522335) Attached to: Malware Attack Infected 25,000 Linux/UNIX Servers

The best locks in world, which Linux does come with, do not help if the door is left unlocked.
Microsoft OTOH has no doors.

The biggest threat to linux in the last five years has not been the architecture of linux

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.

but the willingness of programmers, in particular weak programmers from the WIndows world coming over and applying the same philiosophies to linux development.

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*.

Comment: Then use XML (Score 1) 68

by benjymouse (#46513953) Attached to: OASIS Approves OData 4.0 Standards For an Open, Programmable Web

One project might use "customer" another "client" or "businessname". Each of these may have a "description", "overview", "synopsis" and a "type"/"kind"/"businesstype" field.

So code discovery of data doesn't work unless we have agreed to standardized field names in advance

Why doesn't it work? Have a look at $metadata. You get schemas for your data. OData has full discovery. The only "standardized field name" you need to know in advance is $metadata.

... but now there's always exceptions to look out for and name conflicts.

Now even if we know the names of every field, how do we know exactly what sort of data will be returned? A name alone is nothing unless we can ensure its type, and remove all assumptions about what it can contain.

OData was originally designed for XML. JSON was added later. With XML you can (and should) use namespaces to disambiguate field names between different entities/domains.

Comment: Re:No lowrights mode (not surprised) (Score 2) 207

W3C was something a committee did which was academic. Only Netscape and MS specific CSS and HTML mattered and websites needed to include specific workarounds for one or the other etc. Man, people forget how dark the web was 10 years ago.

This. And everyone seems to have forgotten how Netscape pushed the awful JSSS as an alternative to CSS. Microsoft actually pushed CSS at the time.

At the time, the best browser actually won. It was the neglect by MS in the years following that was/became the big problem, one for which MS has rightfully earned a lot of scorn. MS never wanted the web to evolve too fast as it could undermine the very lucrative desktop business.

But at the time of Netscape/MS rivaly, it was actually Netscape who tried to foist abominations like JSSS and the "layer" tag upon us.

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Working...