Typical Slashdot... they post a snarky anti-Microsoft comment with a pretentious air of superiority but get the details wrong.
Photosynth is not Deep Zoomm. Photosynth reconstructs 3D models from collections of 2D photos of the scene acquired from different positions and angles. And as far as I know, Photosynth wasn't an acquisition - it was produced by Microsoft Research.
Deep Zoom was an acquisition, but it was the technology formerly known as Seadragon. It's completely unrelated - Deep Zoom/Seadragon is a 2D thing.
And it's an acquisition, but so what? Ooh, naughty Microsoft - how dare they take exciting technology developed by a startup and put it in the hands of millions of users? Shocking! Clearly it they should have left it to sink in obscurity.
I don't think Microsoft are asking. I wrote the blog entry the question refers to, and I don't work for Microsoft, nor was I acting on their behalf. (And I don't imagine I've made myself any friends in Microsoft with that blog entry.) I know the guy who submitted the question to Ask/. (MythMoth) - he doesn't work for Microsoft either. In fact as far as I know he mainly runs Ubuntu these days, and he's been a Java developer for years.
My motivation is pretty simple: I think it sucks that lots of apps have problems if you run as a non-admin user. As an application developer myself, I know that if applications are broken in this way, there is basically nothing Windows can do to fix that. (The same would be true of Linux - it would be trivial to write an application that refuses to run properly unless it's running as root. It wouldn't be Linux's job to fix that apps problems would it?) Yes, the fact that the culture grew up this way is Microsoft's fault. But I want the culture to get better. So my goal was to encourage developers write apps that work properly for non-admin users.
On another note, you've said something that doesn't seem to apply to any version of Windows I'm familiar with:
"The fundamental problem with Windows Security architecture is that the Operating System thinks it is better, wiser and more powerful than the user. In Unix, the user is the boss.
The user is boss in Windows. If you're the admin of a Windows box, it'll let you do anything, including shooting yourself repeatedly in the foot if you so choose. To give an example that's relevant to the point at hand: an admin can choose to turn off UAC. (A bad choice, IMO, but Windows certainly won't stop you making that choice.) That's just one tiny example of course - one amongst thousands. The admin is in complete control of his or her machine.
(Of course, if the admin doesn't know what he or she is doing, then this 'control' will be purely hypothetical. Being an admin merely makes it possible to control everything, but to achieve that in practice does require you to know how to achieve what you're trying to achieve. And Windows does put up the odd road block to discourage you from doing certain particularly egregious forms of damage to your machine, so if you're not an expert user, you might mistakenly conclude that you're not in control. But the bottom line is: if you're the admin, you can circumvent any of these because you are, ultimately, in complete control of your machine.)
Can you point to a single concrete example of where Windows "thinks it is better, wiser and more powerful than the user"? I've been using Windows for almost as long as I've been using Linux. (12 years and 15 years respectively.) I can't think what you might be referring to - could you be specific please?
One could make a case that Windows should behave as you're suggesting it does. (I personally don't think it should, but I can see there's an argument.) After all, the vast majority of home users are entirely unqualified to "examine every single running process themselves". But for better or worse, if someone walks into a shop and buys a PC they are the de facto administrator of that box, whatever OS it might be running, and regardless of how well qualified they might be for that task. You could argue that if Windows was as authoritarian as you are suggesting that we might have fewer zombie Windows boxes out there, because end users wouldn't be empowered to hand over control of their machines to botnets. (It's pretty well documented that enterprise that don't let end users run as admin just don't have the security problems Windows is famed for.)
I wouldn't actually want it to work that way though. While I don't run as root most of the time, it's important to me to be able to control my box. Which is exactly how it is. So I'm surprised by what you've written.
Actually, passing NULL as the first parameter of CreateEvent is almost always the right thing to do.
Of course the vast majority of developers don't actually know that - they just pass NULL out of laziness. But it turns out that if you spend the time it takes to learn the intricacies of the Win32 security model, you'll still end up passing NULL once you understand what's happening.
What happens if you have an engine file in a modern car though?
Either:
you don't have a fire extinguisher, your car's engine bay burns out, the bulkhead stops the fire from spreading
You have a fire extinguisher which is plumbed in to the engine bar, so the fire is extinguished, or...
You have a free standing fire extinguisher, you attempt to put out the fire with it, you discover why it's important to have the extinguisher plumbed into the engine bay, your car's engine bay burns out, the bulkhead stops the fire from spreading
You get the same results in all three cases with or without the engine bay being welded shut.
I think you just conformed very neatly to the picture that the BBC reporter painted of a typical Linux zealot didn't you? It seemed to me that his basic point was "Some Linux users are such zealots that they think it's OK to launch illegal attacks on SCO." If you go around saying that SCO were "asking for it" when someone launches an illegal attack on their systems, then you just confirm that reporter's views.
I think that SCO deserves to crash and burn. But the way I want it to happen is for them to be exposed as frauds through legal process. I think the illegal DDoS attacks work to SCOs benefit because they hand the moral high ground SCO. (As does claiming that SCO were "asking for it".)
This is no different from the existing system though - London Underground has tracked tickets across London for years. The fact that the physical token that carries the ID they track is now a smartcard rather than a ticket with a magnetic stripe doesn't change anything. We were being tracked before, and we're still being tracked now.
The main reason they do this is because they have to in order for the ticket barriers to enforce the fares - there journeys you can make on a single ticket which actually require you to leave the system and re-enter it. (E.g. changing from the Hammersmith & City line to the Bakerloo line at Paddington Station.) So the ticket machines need to know where the ticket has already been to work out if you're allowed to pass through the barrier according to the rules of the fare. (Or, when you're leaving the system, whether it should swallow the ticket or give it back to you.)
Those of us with season tickets have always had our movements tracked every single day we travel on the underground.
The ID used to do this tracking now comes in a new package. Big deal... It's no less intrusive than it ever was.
Maybe the retention of data is a new thing. But that was something they could have introduced without needing smartcards.
Re:Conclusion
on
Hijacking .NET
·
· Score: 2, Informative
This is of course also true in Java - there are a variety of ways you can get to private members there too.
And of course in C++ you can always get at whatever you like by using pointers..NET does at least improve upon traditional C++ in that your code can only get at private members if the security policy permits it. Code downloaded from the Internet for example (e.g. a.NET component running in a web browser like a Java applet would) is not, able to access private members in this way.
I think the main problem with what you suggest is that nothing would ever work!
Look at the hardware world - here we have geniune reuse of components - you really can go out and buy a black box (or grey in the case of chips in ceramic cases), read the documentation on how it works and integrate it successfully into a system. But the amount of work you have to do to accommodate the particular component you chose is huge.
From a high-level point of view, a PowerPC processor does the same thing that a Pentium 4 does. But the details are so different that you have to completely redesign the system if you want to migrate from one to the other. The same problems would plague any attempt to make such low level software pieces as a scheduler 'pluggable'.
Even components that are designed to be plug compatible suffer from problems. Not all PCI devices work properly in all systems. Even consumer electronics doesn't get it right - I've had to help lots of people get VCRs working properly. The advent of digital TV has made it really hard to get everything working properly. (I'm British - most people here can receive one of 3 competing digital TV services, either cable, satellite or terrestrial. So this is a big issue here now.) It took me about an hour to grok my parents system and wire it up so that it worked, and I've spent 2 years designing MPEG2 broadcast systems! Did you know that over 90% of people don't use their VCRs to do anything other than play rented videos because they can't work out how to connect the things up? And yet the interconnects between such components are some of the best-standardised component interfaces in the world! The real problem here is that the conceptual model is overcomplex - unless you understand the various paths down which information flows in this system (which parts are digital, which are analogue, how they are multiplexed etc.) you're never going to get it working reliably.
So the liklihood of getting a complete computer system to work where everything has been componentised is extremely slim. It would mean that every user suddenly had to be a systems integrator. Anyone who has worked professional in systems integration will tell you how long-winded and complex the integration process is.
FWIW I've taught 3 courses on C# in the last month. I also teach Java courses, but demand has tailed right off for those at the moment.
I guess it depends on the advertising focus of the company you teach for. If all the C# instructors in your company are unenthusiastic about the technology then it's no surprise these courses aren't selling - courses delivered by someone who dislikes what their teaching about aren't going to be worth attending. But where I work there's a great deal of enthusiasm for this technology (and also for Java), which is presumably part of the reason why we're selling a lot of these courses right now.
Just because a system is written in C doesn't mean that it isn't reusable. GNOME was written in C, and it is reusable
But surely the point being made was that code wasn't reused in practice. It's all very well pointing out that in theory one can write reusable code in technology X, but if the reality is that nobody does, then something must be wrong..NET seems to attempt to address some of the pragmatic reasons why people don't reuse code in practice, and it tries to solve those problems.
A well-crafted compiler in C will always be faster than one written in a garbage collected language, no matter how good the JIT is.
Bzzt! Not actually true - there are some performance optimisations which are available for a JIT compiler which a static compiler cannot realistically do. For example, the hotspot JVM is able to do something called 'monomorphic inlining'. This is a technique which, based on runtime analysis of the code, converts virtual function calls into non-virtual ones, which opens up a whole raft of extra optmisations.
In reality, the reverse of what you state is true - a traditional static compilation is at best no better than JIT compilation can get. There is no information available to a traditional compiler that is not also available to a JIT compiler, so why would a JIT compiler ever do a worse job? However the JIT compiler has the added bonus of being able to bring runtime analysis to bear.
Garbage collection is not really the issue - it's orthogonal to JIT compilation: (1) you can build statically compiled systems with GC, (2) for some purposes GC actually turns out to be faster. (Quick question: which takes longer, allocating from a GC heap, or allocating from a non-GC heap?) GC has different characteristics, but it's just not right to say it is simply slower - for some applications it's faster, for some it isn't.
Read Jeff Kesselman's book 'Java Platform Performance' makes very interesting reading, and debunks many of the performance myths about GC and VMs that abound.
Actually the CLR doesn't interpret code, at least not in the current implementations - they always JIT compile down to native code. (And MS's CIL was designed to be used thus - intpretive execution was an explicit non-goal.)
As for the advantages, well several spring to mind, and these all apply to Java just as much as.NET:
Platform independence - this might seem a Java-only concern, but remember that 64 bit processors are lurking on Microsoft's horizon. MS are still living with the pain of the 16 bit -> 32 bit transition, so they would like to avoid a repeat performance. Compiling to IL is a crucial part of.NET's strategy for providing a smooth upgrade path from 32 bit to 64 bit processors. Sure, the 64 bit processors will run 32 bit code happily, but that's not really a viable long-term solution: 16 bit code still runs today, but that doesn't mean you would want to run it if you could possible avoid it.
Security and integrity - both Java and.NET perform extensive validity checking of binaries before they run them. In particular they make sure that the code never does the moral equivalent of void* p = (void*) someInt;. Both Java and.NET go out of their way to try and make it impossible to write code which would allow a buffer overflow exploit. Type safety is an important part of the way they do this, and the IL representations in both systems have been carefully designed to be susceptible to such validity analysis. Raw Intel machine code cannot reasonably be analysed thus. Also, both environments rely on being able to walk the stack frame reliably in order to perform security checks. Running native code would allow such code to mess about with the stack to subvert such validation checks.
Performance - yes, believe it or not there are actually performance advantages to using an intermediate representation in your binaries rather than native compiled code. The hotspot JVMs from Sun monitor the behaviour of code at runtime and base their optimizations on this analysis. This enables a whole class of optimizations which are infeasible with compile-time analysis: compilers are just not smart enough to be able to deduce from first principals many of the things that can be determined empirically by examining a running system. Plenty of work has been published showing that this technique can provide superior average performance than static compile-time optimization. (The downside is that the transient performance is worse - code is slower at the start, but becomes quicker over time. It's great for server-side code, but less good for, say, command line utils.) Note that the JVMs currently seem to be ahead in this area - the current CLR implementations don't appear to exploit this technique yet. Doubtless this will happen.
"Say due to some "bug" in the software, you get locked out of your mission critical system. How do you get back in? "
As others have already pointed out, such a backdoor should only be of any use to someone who has physical access to the machine. The implication of this article is that it is available to remote users which is highly dangerous.
NT already can be unlocked if you've managed to lock yourself out, so long as you have physical access. Go to http://www.sysinternals.com/ and check out their NT utilities page, looking for a thing called 'Locksmith'. This lets you create a boot floppy which will reset the password on the account of your choice.
It caused a stir at the time, but of course if you can boot the machine from a floppy, then you can reset passwords. If the OS on the hard disk can change a password then so can any other OS that can get access to the hard disk. Just like I can come along with a Linux boot disk, mount your hard disk and edit your password file to get root access...
"With WinDriver, your device driver is developed in the User Mode (as part of your application or as a separate DLL)."
Um, so in other words you're just writing normal user mode code. So how on earth do you deal with things like actually accessing the device and fielding IRQs? Well, it goes on:
"The performance critical sections of your code (Interrupt handlers, I/O handlers, etc.) are handled in the Kernel PlugIn (YourDriver.VXD / SYS) and executed in the Kernel Mode, thereby eliminating overhead."
You have to wonder exactly what they were putting into their device drivers that meant it had anything but IRQ and IO handling... However the interesting bit is:
"This architecture enables you to develop and debug all of your driver code in the user mode, using the WinDriver functions, and to migrate only the performance critical sections of the code to the Kernel Mode, via the simple Kernel PlugIn mechanism - without any changes in the code."
So in other words, they seem to be implying that you can do everything - handling IRQs, touching the hardware - from user mode, it just might run like a dog. But that's OK because having ironed out the bugs, you can then migrate these bits into kernel mode for an instant performance increase without changing the code. (IMHO any code in your 'driver' which didn't end up in kernel mode has no business being in a device driver anyway, and its rightful place is in the user mode support libraries you ship with your driver. But I digress.)
Sounds great, but two problems spring to mind.
How do they deal with SMP? The semantics of user mode synchronisation primitives are totally different from the ones you have to use at the lowest level in kernel mode. There is no such thing as a user-mode spin lock, and there's no way to emulate it because there's no way to raise the interrupt level of a thread in user mode. And since it claims to be multi-platform, how do they deal with the differences in SMP techniques across OSs?
What about those timing-dependent problems? Lots of problems in drivers don't actually emerge until you're running at something like full speed. (It often requires a lot of care with debug log output to recreate a problem afflicting a release build in a debug version of the driver, without losing the information you require to diagnose the problem.) Eventually you end up wanting to analyse problems in a release driver with no debug info in it. And if you needed a wizard to build the driver for you, there's no way you're going to be able to diagnose this kind of thing.
To answer one of the questions ("why isn't everyone using this?") I think the answer is: this is only any good for people needing a quick and dirty solution to access some hardware. This is not an industrial strength solution. This is because the final problem is that to get good performance out of a driver tends to require matching that driver very closely both to the characteristics of the device and also to the operating system.
For example, when writing NT drivers there is a no-brainer approach for accessing user mode buffers to transfer data to and fro between the device and the application. This is fine for getting you going, but it sucks as far as speed goes. If you want good performance you end up interacting at a more grungy level with NT's memory management APIs to make sure that you lock down precisely the pages you want when you want them. It's harder work, but it sure pays off. Now will the code I wrote to do that map naturally onto Linux's mechanisms? I doubt it. (I haven't looked at Linux kernel mode hacking since 1.1.x days, so I have no idea how it all works now.)
To put it another way, I've developed high performance device drivers that ran on multiple platforms. Looking at this product I don't believe it would have been any use to me.
Of course there is nothing magically significant about 1GHz in any technical sense. Clearly it's only because it sounds cool to quote your processor speed in GHz rather than MHz - unless you really have a need to get the fastest processor you can buy (and who really needs that?) it's just about showing off...
The thing is that people gagging to get faster and faster clocks, freezing their CPUs to overclock them etc. are probably running distinctly suboptimal systems anyway, because there are usually a whole load of things you can do to a machine to get the best performance out of it beyond bumping up clock speeds.
A while back when the processor and memory clocks were more closely related, you used to run more slowly with a higher processor clock under certain conditions! A lot of P120 systems ran slower than P100 systems for most applications because they ran the system bus slightly slower. Does anyone know if this is still an issue - is there still any kind of relationship between headline processor speed and the bus speed? If not, when did that get decoupled?
According to this article on the BBC News web site there's a problem with the mast supporting the radar equipment: a stabilising thruster has stopped working.
They've already mapped 17 million square miles, but may have to stop short at 70% because of the failure of this thruster. They've been able to keep making measurements, compensating for the thruster's failure by firing the shuttle's own boosters. But it doesn't have enough fuel on board to carry on doing this for the rest of the mission.
1.6ms to search 16M entries? Surely not that hard - we have O(log(N)) search algorithms don't we? A binary chop search through a 16M entry table takes 24 steps, absolute worst case. That gives you 0.0667ms, i.e. 66.7us. That's a lot of time - you don't even need hardware for that. Heck, I have hardware 10 years old that can do that in software.
Not sure I agree with your maths though. Maybe you meant us not ms? OK, so that's harder, but it doesn't require wildly fast memory. (It's over an order of magnitude slower than typical 1st level processor cache memory.) I'm guessing that you have to pay a lot of money for a router big enough and ugly enough to be in a MAE, and that this particular aspect of it isn't that big a deal?
Where does the 1GB figure come from by the way? Looking at www.mae.net they talk about "multiple 155Mbps circuits". Mostly they don't talk about anything faster than 100Mbps on their site as far as I can see. So I think even accounting for your units error, I think you're an order of magnitude out there - we have more like 16us per packet, which doesn't sound that ambitious.
But does it? The definition of 'well enough' for apparently mundane multimedia applications is often surprisingly hard to measure up to. Stick any half-decent DVD player wired via RGB into a TV next to a PC playing a copy of the same DVD out onto its screen, and the consumer electronics setup wins hands down. (This is especially true when the DVD is of a video source (i.e. 50fps, or 60fps for NTSC sources) instead of a film source - temporal aliasing (visual artifacts typically at the beat frequency of the DVD's frame rate and the monitor's refresh frame rate) is perhaps the most obvious problem, but there are many more.)
Apparently the broadcast and consumer electronics industries have a much higher standard of doing 'well enough' than most of the PC world.
Whether or not Linux can play 3 mp3's while animating a spinning cube with each facet it's own running video mpeg is about as relevant...
That specific example may well be irrelevant, but this isn't so different: what about the ability to play 6 audio streams and a single video stream and (crucially, and this is something which is far easier to get wrong than a lot of people realise) keep them all in sync? Is that important to people? Well it's important to me - I like to watch movies with surround sound, and it requires you to do precisely this. It annoys the hell out of me when the sound and video get out of step.
Lots of people are trying to bring the Internet to an audience used to consumer electronics. Whilst this will need some PC-like features (e.g. everything required to be a web browser), this audience will not tolerate shabby AV performance. (And frankly, the vast majority of PC setups deliver very shabby AV.)
This is the motivation behind the technology Be have been developing. Don't dismiss it just because the demos seem overly flashy - try to understand what it is they are showing you. (Or alternatively, try and work out how you would go about demonstrating that a system can deliver the level of real-time media support that would be required by any Internet-enabled high quality piece of consumer electronics.)
Just think of what happens to a packet that arrives in MAE East. It came in one one pipe. Presumably it doesn't go back out on that one. But on which one of the other pipes does it go? Surely those super routers cannot keep and search 2^32 entries.
Well searching 2^32 entries would be possible of course, if expensive. However we know that it only has to search all possible network numbers, which reduces the problem substantially. (Can't remember exactly how many networks there are, but it must be fewer than 16M.) And block allocation of IP networks helps a lot too.
But at the end of the day, the way I understand it's done these days is that you do end up with machines with massive routing tables. (Someone told me that circa 1996, the typical routing table of a router in LINX in London had about 40MB of routing information!)
Actually I think you've stumbled across an interesting point here. You (reasonably) pulled someone up for misidentifying a technical feature as some kind of deliberate privacy invasion. But having corrected them, you then went on to make exactly the same mistake yourself! (See the second half of this email for a precise description of the error in question; the details are kind of beside the point.)
I think what's interesting here is that technologies are now being developed for initially benign purposes which turn out to have powerful applications when it comes to invading people's privacy. The MS office tracability thing I take issue with here is a case in point - tracability was never a design goal, it was an accident of implementation (an accident which has since been fixed).
I happen to think the MS case is relatively mild. What's perhaps more frightening is the scale of information collection going on over the Internet. I find some of this benign - I like the fact that when Amazon send me some junk mail, every single book they suggest is one I'm interested . However I sometimes get the creeps when I think about how much these kinds of places know about me...
It's kind of like doing scientific research because you hope to provide some benefit to the world such as a cheap clean energy source, only to inadvertently invent the most deadly weapon of destruction yet. (Well OK, maybe not quite that bad, but you know what I mean.)
My take on this though is that the cost of progress is worth paying, it just means everyone has a duty to be vigilant. And wouldn't it be nice if people didn't instantly leap to the conclusion that those making the progress had evil in their hearts from the very beginning...
----------------
What was wrong in that previous message
I've tacked this on the end because it's not the main point I was making, it merely supports it. The problem is that unobservant folks skim reading this might get the impression that I was just spouting pro-MS propaganda. I'm not, I'm just fighting a crusade against technical innaccuracy wherever I see it.:-) Please take what follows on its technical merits; don't just take a political stance - THINK!
some nasties in this direction (eg MS record you MAC address in Office documents in order to trace you),
Actually that's not entirely accurate. This much is true: MS put a unique number in every new Office document. This is emphatically not to trace you. How can I say that for sure? Because the number it embeds is one returned from the OS's "give me a unique number" API, (CoCreateGuid). This API's documentation doesn't mention MAC addresses anywhere. There is nothing in the documentation to suggest that the number you will get back will identify the machine on which it was generated (and indeed on many machines it won't exhibit such behaviour).
So the intent is simply to make each document uniquely identifiable. This does not make the document intrinsically traceable back to you. It so happens that in certain versions of Windows this API uses your unmodified MAC address (in conjunction with some other stuff) to generate a unique number. This wasn't even MS's idea - they lifted the algorithm in question lock, stock & barrel from the OSF DCE specification.
Any examples you may have heard about documents being traced back to an individual would have been someone who was running such a version of Windows. I am convinced that this is not by design - never attribute to malice that which can easily be explained by incompetence, and the incompetence theory holds up well under scrutiny here:
On more recent releases of Windows (e.g. Windows 2000, and later service packs for NT 4) this API no longer embeds your MAC address in the unique number. (It still uses the MAC address as input to the algorithm, but it then runs the whole result through a 1 way hash algorithm, which should make it impossible to retrieve the original MAC address.) So if you run Office on such OSs you don't get your MAC address embedded in your files.
So while your statement bears some relation to the truth, it's inaccurate in both spirit and actual detail: if MS had meant to use your MAC address, that's exactly what they would have done. As it is they wanted a unique number, and that's what they put in. (If you don't believe me try installing what you consider to be an offending copy of Office on a machine running Windows 2000 and see if the behaviour persists.)
If you really believe that MS are that interested in tracking down your every move through Office then your arrogance and paranoia are out of control...
All this Service Pack 6, Option Pack 2 stuff drives me crazy with MS products
Actually you've overcomplicated it a little. The 'Option Pack' for NT 4 is a collection of programs you can add to NT which are not installed as standard. (Stuff like the distributed transaction coordinator, the transaction server, IIS, that sort of thing.) This has nothing to do with the version - that's a bit like complaining that Linux 2.3.4 with Apache is a different version number from Linux 2.3.4. In fact with Linux you have the potentially more confusing situation where the versions of the kernel and the distribution you're running are different.
The scheme they use is actually pretty simple - a product name, and a service pack number. They stopped putting version numbers into the main name of the product because their research indicated that this confused people - separating the product name from the release seemed to go down better.
And hey, it discourages them from charging for the bug fixes, which they used to do with carefree abandon.
Does this mean I just have to wait until I can afford something with the power of Deep Blue and then I'll have a compiler that can generate better code than a person? Given current exponential rates of improvement I guess that's not too bad.
Problem is, I'm not sure it's true. If you consider chess to be an optimisation problem, I have my suspicions that it's actually a good deal more complex than chess. Chess is relatively narrowly-defined. It feels like the space that code optimisation has to work in could be far broader?
It certainly feels like a different problem - one simple way of doing better than the compiler is to look at what the compiler produces and then remove all the stupid mistakes it's made. (Modern compilers tend to make 3 or 4 on every page of code. And I mean really stupid - completely failing to notice that values were already available in a register and reloading/recalculating them, that sort of thing.) This is not likely to be a successful approach with a chess game...
Slashdot Mirror
Typical Slashdot... they post a snarky anti-Microsoft comment with a pretentious air of superiority but get the details wrong.
Photosynth is not Deep Zoomm. Photosynth reconstructs 3D models from collections of 2D photos of the scene acquired from different positions and angles. And as far as I know, Photosynth wasn't an acquisition - it was produced by Microsoft Research.
Deep Zoom was an acquisition, but it was the technology formerly known as Seadragon. It's completely unrelated - Deep Zoom/Seadragon is a 2D thing.
And it's an acquisition, but so what? Ooh, naughty Microsoft - how dare they take exciting technology developed by a startup and put it in the hands of millions of users? Shocking! Clearly it they should have left it to sink in obscurity.
I don't think Microsoft are asking. I wrote the blog entry the question refers to, and I don't work for Microsoft, nor was I acting on their behalf. (And I don't imagine I've made myself any friends in Microsoft with that blog entry.) I know the guy who submitted the question to Ask /. (MythMoth) - he doesn't work for Microsoft either. In fact as far as I know he mainly runs Ubuntu these days, and he's been a Java developer for years.
My motivation is pretty simple: I think it sucks that lots of apps have problems if you run as a non-admin user. As an application developer myself, I know that if applications are broken in this way, there is basically nothing Windows can do to fix that. (The same would be true of Linux - it would be trivial to write an application that refuses to run properly unless it's running as root. It wouldn't be Linux's job to fix that apps problems would it?) Yes, the fact that the culture grew up this way is Microsoft's fault. But I want the culture to get better. So my goal was to encourage developers write apps that work properly for non-admin users.
On another note, you've said something that doesn't seem to apply to any version of Windows I'm familiar with:
The user is boss in Windows. If you're the admin of a Windows box, it'll let you do anything, including shooting yourself repeatedly in the foot if you so choose. To give an example that's relevant to the point at hand: an admin can choose to turn off UAC. (A bad choice, IMO, but Windows certainly won't stop you making that choice.) That's just one tiny example of course - one amongst thousands. The admin is in complete control of his or her machine.
(Of course, if the admin doesn't know what he or she is doing, then this 'control' will be purely hypothetical. Being an admin merely makes it possible to control everything, but to achieve that in practice does require you to know how to achieve what you're trying to achieve. And Windows does put up the odd road block to discourage you from doing certain particularly egregious forms of damage to your machine, so if you're not an expert user, you might mistakenly conclude that you're not in control. But the bottom line is: if you're the admin, you can circumvent any of these because you are, ultimately, in complete control of your machine.)
Can you point to a single concrete example of where Windows "thinks it is better, wiser and more powerful than the user"? I've been using Windows for almost as long as I've been using Linux. (12 years and 15 years respectively.) I can't think what you might be referring to - could you be specific please?
One could make a case that Windows should behave as you're suggesting it does. (I personally don't think it should, but I can see there's an argument.) After all, the vast majority of home users are entirely unqualified to "examine every single running process themselves". But for better or worse, if someone walks into a shop and buys a PC they are the de facto administrator of that box, whatever OS it might be running, and regardless of how well qualified they might be for that task. You could argue that if Windows was as authoritarian as you are suggesting that we might have fewer zombie Windows boxes out there, because end users wouldn't be empowered to hand over control of their machines to botnets. (It's pretty well documented that enterprise that don't let end users run as admin just don't have the security problems Windows is famed for.)
I wouldn't actually want it to work that way though. While I don't run as root most of the time, it's important to me to be able to control my box. Which is exactly how it is. So I'm surprised by what you've written.
Actually, passing NULL as the first parameter of CreateEvent is almost always the right thing to do.
Of course the vast majority of developers don't actually know that - they just pass NULL out of laziness. But it turns out that if you spend the time it takes to learn the intricacies of the Win32 security model, you'll still end up passing NULL once you understand what's happening.
You just get to feel smug about it.
What happens if you have an engine file in a modern car though?
Either:
You get the same results in all three cases with or without the engine bay being welded shut.
"Microsoft is asking for it, as is SCO."
I think you just conformed very neatly to the picture that the BBC reporter painted of a typical Linux zealot didn't you? It seemed to me that his basic point was "Some Linux users are such zealots that they think it's OK to launch illegal attacks on SCO." If you go around saying that SCO were "asking for it" when someone launches an illegal attack on their systems, then you just confirm that reporter's views.
I think that SCO deserves to crash and burn. But the way I want it to happen is for them to be exposed as frauds through legal process. I think the illegal DDoS attacks work to SCOs benefit because they hand the moral high ground SCO. (As does claiming that SCO were "asking for it".)
This is no different from the existing system though - London Underground has tracked tickets across London for years. The fact that the physical token that carries the ID they track is now a smartcard rather than a ticket with a magnetic stripe doesn't change anything. We were being tracked before, and we're still being tracked now.
The main reason they do this is because they have to in order for the ticket barriers to enforce the fares - there journeys you can make on a single ticket which actually require you to leave the system and re-enter it. (E.g. changing from the Hammersmith & City line to the Bakerloo line at Paddington Station.) So the ticket machines need to know where the ticket has already been to work out if you're allowed to pass through the barrier according to the rules of the fare. (Or, when you're leaving the system, whether it should swallow the ticket or give it back to you.)
Those of us with season tickets have always had our movements tracked every single day we travel on the underground.
The ID used to do this tracking now comes in a new package. Big deal... It's no less intrusive than it ever was.
Maybe the retention of data is a new thing. But that was something they could have introduced without needing smartcards.
This is of course also true in Java - there are a variety of ways you can get to private members there too. And of course in C++ you can always get at whatever you like by using pointers. .NET does at least improve upon traditional C++ in that your code can only get at private members if the security policy permits it. Code downloaded from the Internet for example (e.g. a .NET component running in a web browser like a Java applet would) is not, able to access private members in this way.
I think the main problem with what you suggest is that nothing would ever work!
Look at the hardware world - here we have geniune reuse of components - you really can go out and buy a black box (or grey in the case of chips in ceramic cases), read the documentation on how it works and integrate it successfully into a system. But the amount of work you have to do to accommodate the particular component you chose is huge.
From a high-level point of view, a PowerPC processor does the same thing that a Pentium 4 does. But the details are so different that you have to completely redesign the system if you want to migrate from one to the other. The same problems would plague any attempt to make such low level software pieces as a scheduler 'pluggable'.
Even components that are designed to be plug compatible suffer from problems. Not all PCI devices work properly in all systems. Even consumer electronics doesn't get it right - I've had to help lots of people get VCRs working properly. The advent of digital TV has made it really hard to get everything working properly. (I'm British - most people here can receive one of 3 competing digital TV services, either cable, satellite or terrestrial. So this is a big issue here now.) It took me about an hour to grok my parents system and wire it up so that it worked, and I've spent 2 years designing MPEG2 broadcast systems! Did you know that over 90% of people don't use their VCRs to do anything other than play rented videos because they can't work out how to connect the things up? And yet the interconnects between such components are some of the best-standardised component interfaces in the world! The real problem here is that the conceptual model is overcomplex - unless you understand the various paths down which information flows in this system (which parts are digital, which are analogue, how they are multiplexed etc.) you're never going to get it working reliably.
So the liklihood of getting a complete computer system to work where everything has been componentised is extremely slim. It would mean that every user suddenly had to be a systems integrator. Anyone who has worked professional in systems integration will tell you how long-winded and complex the integration process is.
FWIW I've taught 3 courses on C# in the last month. I also teach Java courses, but demand has tailed right off for those at the moment.
I guess it depends on the advertising focus of the company you teach for. If all the C# instructors in your company are unenthusiastic about the technology then it's no surprise these courses aren't selling - courses delivered by someone who dislikes what their teaching about aren't going to be worth attending. But where I work there's a great deal of enthusiasm for this technology (and also for Java), which is presumably part of the reason why we're selling a lot of these courses right now.
In reality, the reverse of what you state is true - a traditional static compilation is at best no better than JIT compilation can get. There is no information available to a traditional compiler that is not also available to a JIT compiler, so why would a JIT compiler ever do a worse job? However the JIT compiler has the added bonus of being able to bring runtime analysis to bear.
Garbage collection is not really the issue - it's orthogonal to JIT compilation: (1) you can build statically compiled systems with GC, (2) for some purposes GC actually turns out to be faster. (Quick question: which takes longer, allocating from a GC heap, or allocating from a non-GC heap?) GC has different characteristics, but it's just not right to say it is simply slower - for some applications it's faster, for some it isn't.
Read Jeff Kesselman's book 'Java Platform Performance' makes very interesting reading, and debunks many of the performance myths about GC and VMs that abound.
As for the advantages, well several spring to mind, and these all apply to Java just as much as .NET:
As others have already pointed out, such a backdoor should only be of any use to someone who has physical access to the machine. The implication of this article is that it is available to remote users which is highly dangerous.
NT already can be unlocked if you've managed to lock yourself out, so long as you have physical access. Go to http://www.sysinternals.com/ and check out their NT utilities page, looking for a thing called 'Locksmith'. This lets you create a boot floppy which will reset the password on the account of your choice.
It caused a stir at the time, but of course if you can boot the machine from a floppy, then you can reset passwords. If the OS on the hard disk can change a password then so can any other OS that can get access to the hard disk. Just like I can come along with a Linux boot disk, mount your hard disk and edit your password file to get root access...
Um, so in other words you're just writing normal user mode code. So how on earth do you deal with things like actually accessing the device and fielding IRQs? Well, it goes on:
You have to wonder exactly what they were putting into their device drivers that meant it had anything but IRQ and IO handling... However the interesting bit is:
So in other words, they seem to be implying that you can do everything - handling IRQs, touching the hardware - from user mode, it just might run like a dog. But that's OK because having ironed out the bugs, you can then migrate these bits into kernel mode for an instant performance increase without changing the code. (IMHO any code in your 'driver' which didn't end up in kernel mode has no business being in a device driver anyway, and its rightful place is in the user mode support libraries you ship with your driver. But I digress.)
Sounds great, but two problems spring to mind.
To answer one of the questions ("why isn't everyone using this?") I think the answer is: this is only any good for people needing a quick and dirty solution to access some hardware. This is not an industrial strength solution. This is because the final problem is that to get good performance out of a driver tends to require matching that driver very closely both to the characteristics of the device and also to the operating system.
For example, when writing NT drivers there is a no-brainer approach for accessing user mode buffers to transfer data to and fro between the device and the application. This is fine for getting you going, but it sucks as far as speed goes. If you want good performance you end up interacting at a more grungy level with NT's memory management APIs to make sure that you lock down precisely the pages you want when you want them. It's harder work, but it sure pays off. Now will the code I wrote to do that map naturally onto Linux's mechanisms? I doubt it. (I haven't looked at Linux kernel mode hacking since 1.1.x days, so I have no idea how it all works now.)
To put it another way, I've developed high performance device drivers that ran on multiple platforms. Looking at this product I don't believe it would have been any use to me.
The thing is that people gagging to get faster and faster clocks, freezing their CPUs to overclock them etc. are probably running distinctly suboptimal systems anyway, because there are usually a whole load of things you can do to a machine to get the best performance out of it beyond bumping up clock speeds.
A while back when the processor and memory clocks were more closely related, you used to run more slowly with a higher processor clock under certain conditions! A lot of P120 systems ran slower than P100 systems for most applications because they ran the system bus slightly slower. Does anyone know if this is still an issue - is there still any kind of relationship between headline processor speed and the bus speed? If not, when did that get decoupled?
They've already mapped 17 million square miles, but may have to stop short at 70% because of the failure of this thruster. They've been able to keep making measurements, compensating for the thruster's failure by firing the shuttle's own boosters. But it doesn't have enough fuel on board to carry on doing this for the rest of the mission.
Not sure I agree with your maths though. Maybe you meant us not ms? OK, so that's harder, but it doesn't require wildly fast memory. (It's over an order of magnitude slower than typical 1st level processor cache memory.) I'm guessing that you have to pay a lot of money for a router big enough and ugly enough to be in a MAE, and that this particular aspect of it isn't that big a deal?
Where does the 1GB figure come from by the way? Looking at www.mae.net they talk about "multiple 155Mbps circuits". Mostly they don't talk about anything faster than 100Mbps on their site as far as I can see. So I think even accounting for your units error, I think you're an order of magnitude out there - we have more like 16us per packet, which doesn't sound that ambitious.
But does it? The definition of 'well enough' for apparently mundane multimedia applications is often surprisingly hard to measure up to. Stick any half-decent DVD player wired via RGB into a TV next to a PC playing a copy of the same DVD out onto its screen, and the consumer electronics setup wins hands down. (This is especially true when the DVD is of a video source (i.e. 50fps, or 60fps for NTSC sources) instead of a film source - temporal aliasing (visual artifacts typically at the beat frequency of the DVD's frame rate and the monitor's refresh frame rate) is perhaps the most obvious problem, but there are many more.)
Apparently the broadcast and consumer electronics industries have a much higher standard of doing 'well enough' than most of the PC world.
Whether or not Linux can play 3 mp3's while animating a spinning cube with each facet it's own running video mpeg is about as relevant...
That specific example may well be irrelevant, but this isn't so different: what about the ability to play 6 audio streams and a single video stream and (crucially, and this is something which is far easier to get wrong than a lot of people realise) keep them all in sync? Is that important to people? Well it's important to me - I like to watch movies with surround sound, and it requires you to do precisely this. It annoys the hell out of me when the sound and video get out of step.
Lots of people are trying to bring the Internet to an audience used to consumer electronics. Whilst this will need some PC-like features (e.g. everything required to be a web browser), this audience will not tolerate shabby AV performance. (And frankly, the vast majority of PC setups deliver very shabby AV.)
This is the motivation behind the technology Be have been developing. Don't dismiss it just because the demos seem overly flashy - try to understand what it is they are showing you. (Or alternatively, try and work out how you would go about demonstrating that a system can deliver the level of real-time media support that would be required by any Internet-enabled high quality piece of consumer electronics.)
Well searching 2^32 entries would be possible of course, if expensive. However we know that it only has to search all possible network numbers, which reduces the problem substantially. (Can't remember exactly how many networks there are, but it must be fewer than 16M.) And block allocation of IP networks helps a lot too.
But at the end of the day, the way I understand it's done these days is that you do end up with machines with massive routing tables. (Someone told me that circa 1996, the typical routing table of a router in LINX in London had about 40MB of routing information!)
Actually I think you've stumbled across an interesting point here. You (reasonably) pulled someone up for misidentifying a technical feature as some kind of deliberate privacy invasion. But having corrected them, you then went on to make exactly the same mistake yourself! (See the second half of this email for a precise description of the error in question; the details are kind of beside the point.)
I think what's interesting here is that technologies are now being developed for initially benign purposes which turn out to have powerful applications when it comes to invading people's privacy. The MS office tracability thing I take issue with here is a case in point - tracability was never a design goal, it was an accident of implementation (an accident which has since been fixed).
I happen to think the MS case is relatively mild. What's perhaps more frightening is the scale of information collection going on over the Internet. I find some of this benign - I like the fact that when Amazon send me some junk mail, every single book they suggest is one I'm interested . However I sometimes get the creeps when I think about how much these kinds of places know about me...
It's kind of like doing scientific research because you hope to provide some benefit to the world such as a cheap clean energy source, only to inadvertently invent the most deadly weapon of destruction yet. (Well OK, maybe not quite that bad, but you know what I mean.)
My take on this though is that the cost of progress is worth paying, it just means everyone has a duty to be vigilant. And wouldn't it be nice if people didn't instantly leap to the conclusion that those making the progress had evil in their hearts from the very beginning...
----------------
What was wrong in that previous message
I've tacked this on the end because it's not the main point I was making, it merely supports it. The problem is that unobservant folks skim reading this might get the impression that I was just spouting pro-MS propaganda. I'm not, I'm just fighting a crusade against technical innaccuracy wherever I see it. :-) Please take what follows on its technical merits; don't just take a political stance - THINK!
some nasties in this direction (eg MS record you MAC address in Office documents in order to trace you),
Actually that's not entirely accurate. This much is true: MS put a unique number in every new Office document. This is emphatically not to trace you. How can I say that for sure? Because the number it embeds is one returned from the OS's "give me a unique number" API, (CoCreateGuid). This API's documentation doesn't mention MAC addresses anywhere. There is nothing in the documentation to suggest that the number you will get back will identify the machine on which it was generated (and indeed on many machines it won't exhibit such behaviour).
So the intent is simply to make each document uniquely identifiable. This does not make the document intrinsically traceable back to you. It so happens that in certain versions of Windows this API uses your unmodified MAC address (in conjunction with some other stuff) to generate a unique number. This wasn't even MS's idea - they lifted the algorithm in question lock, stock & barrel from the OSF DCE specification.
Any examples you may have heard about documents being traced back to an individual would have been someone who was running such a version of Windows. I am convinced that this is not by design - never attribute to malice that which can easily be explained by incompetence, and the incompetence theory holds up well under scrutiny here:
On more recent releases of Windows (e.g. Windows 2000, and later service packs for NT 4) this API no longer embeds your MAC address in the unique number. (It still uses the MAC address as input to the algorithm, but it then runs the whole result through a 1 way hash algorithm, which should make it impossible to retrieve the original MAC address.) So if you run Office on such OSs you don't get your MAC address embedded in your files.
So while your statement bears some relation to the truth, it's inaccurate in both spirit and actual detail: if MS had meant to use your MAC address, that's exactly what they would have done. As it is they wanted a unique number, and that's what they put in. (If you don't believe me try installing what you consider to be an offending copy of Office on a machine running Windows 2000 and see if the behaviour persists.)
If you really believe that MS are that interested in tracking down your every move through Office then your arrogance and paranoia are out of control...
Actually you've overcomplicated it a little. The 'Option Pack' for NT 4 is a collection of programs you can add to NT which are not installed as standard. (Stuff like the distributed transaction coordinator, the transaction server, IIS, that sort of thing.) This has nothing to do with the version - that's a bit like complaining that Linux 2.3.4 with Apache is a different version number from Linux 2.3.4. In fact with Linux you have the potentially more confusing situation where the versions of the kernel and the distribution you're running are different.
The scheme they use is actually pretty simple - a product name, and a service pack number. They stopped putting version numbers into the main name of the product because their research indicated that this confused people - separating the product name from the release seemed to go down better.
And hey, it discourages them from charging for the bug fixes, which they used to do with carefree abandon.
Does this mean I just have to wait until I can afford something with the power of Deep Blue and then I'll have a compiler that can generate better code than a person? Given current exponential rates of improvement I guess that's not too bad.
Problem is, I'm not sure it's true. If you consider chess to be an optimisation problem, I have my suspicions that it's actually a good deal more complex than chess. Chess is relatively narrowly-defined. It feels like the space that code optimisation has to work in could be far broader?
It certainly feels like a different problem - one simple way of doing better than the compiler is to look at what the compiler produces and then remove all the stupid mistakes it's made. (Modern compilers tend to make 3 or 4 on every page of code. And I mean really stupid - completely failing to notice that values were already available in a register and reloading/recalculating them, that sort of thing.) This is not likely to be a successful approach with a chess game...