Slashdot Mirror
Windows 7 Likely Going Modular, Subscription-based
Microsoft CRM writes "When Windows 7 launches sometime after the start of 2010, the desktop OS will be Microsoft's most 'modular' operating system to date. That's not necessarily a good thing, of course; Windows Vista is a sprawling, complex OS. From Microsoft's perspective, though, there are many possible benefits. The OS's developers can add/remove functionality module by module. New modules could be sold post-launch, keeping revenue streams strong. A modular approach could also allow the company to make functionality available on a time-limited basis, potentially allowing users to 'rent' a feature if it's needed on a one-off basis. Microsoft is already testing 'pay as you go' consumer subscriptions in developing countries."
The problem will be in the dependancies. Want MSN Messenger, that relies on IE, because it can display HTML content. So to install messenger, you have to install IE. Same goes for Linux. You want GIMP, well you have to install GTK, because you can't have one without the other.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Does this mean we might see drivers for most devices that aren't part of the kernel itself? A stock Windows XP install is surprisingly robust, but add even one crappy driver to the mix (Yeah, ATI, I'm looking at you!) and soon the computer's gone on a one-way vacation to Reboot City.
- Installation of Windows 7: the OS communicates with the TPM and 'takes ownership' of the TPM. (The tech docs can't spell it out any clearer: the programmer controls the computer, not the user.) When taking ownership of the TPM, Windows provides the public key of Microsoft to the TPM.
- Booting the computer: During installation, Windows installs a hash of the bootloader code and the OS code into the TPM. The bootloader performs a sanity check using the TPM to ensure that it has not been compromised. The bootloader then verifies the OS against the TPM and only loads 'genuine' copies of Windows. Note that the definition of genuine is entirely up to MS; at any time the TPM can be instructed, only by its owner, to invalidate any credentials. It's perfectly possible, and in fact designed into the specs, for the TPM owner to completely disable TPM protected software at any time. Irreversibly, because the binaries are encrypted and require the TPM's cooperation to run.
- Updating Windows: Before updating, the OS instructs the TPM to provide a guarantee that it is a genuine TPM (using information manufactured into the chip), and the TPM signs MS's public key. This cryptographically proves that the computer has a TPM and that Microsoft owns the TPM. Microsoft then transmits the update to the computer, encrypting it with the TPM's key to prevent the native code from being revealed to the user or installed on a non-authenticated machine.
- Installing a module: Similar to updating, but more insidious. The user purchases a certificate to run a module, then the module is securely transferred to the machine. The certificate is stored by the TPM itself to prevent it from being read from disk or RAM by a third party. This is done for all the TPM's information. The module is then installed if and only if it is authenticated by Microsoft. This may seem to have some flaws, but that's taken care of with the following...
- Running a binary executable: The OS can require that every single binary be signed by a person who is authenticated by the owner. The TPM verifies this, and then either provides the OS with the decrypted binary or a failure notice. 'Configuration states' are a key principle here; at any time the state of the system (all programs that are running) can be saved into the TPM. This can be used for example by Windows update. The updater saves a configuration where only the core OS and the updater are running, and then can ensure that it will not update if not in this configuration. This keeps any on-the-fly memory editors out.
A lot of very smart people put a lot of effort into this system; it works. It's just been waiting for that 'killer app' to use it...IBM didn't sell you anything back then. You leased the machine, rather than buy it. IBM would charge you a low price but ship and install a bigger machine with extra processors and memory modules installed. The lease terms limited you, rather than physical limitations. This was actually a very good thing. First, whenever something broke, IBM could switch it out over the phone, which made those late night calls much more tolerable. Second, if you needed more power, they could switch on more processors and bill you. Then, when you no longer needed the extra, they could switch them off again and save you money. It was really a win-win situation for everyone.
The big difference here is that we are talking about software, not hardware. If MS really does this, it will either be a wild success or a dismal failure. Personally, I will stick with my Mac or move back to Linux.
This is especially true for Windows, in which long-term heavy usage of COM (which was explicitly designed to promote modularity) has meant that you can do things like swap out the IE rendering engine for Firefox, and it'll work.
Well... in a way. COM is now pretty dated, and it required a lot of extra programming to make sure that things were properly supported. Programs that bundle with Microsoft Windows are extremely integrated, regardless of whatever libraries and APIs are made available. There is no "cd %notepad_dir%; make" command for the Windows system, literally, there is no way to know for sure if something needs to be rebuilt without literally recompiling the whole source code.
You make a change to some random library, that changes the publics for that library, and that disseminates out and touches potentially tons of binaries. The reason Vista started using componentization is exactly for this reason, so that you could trust that updating a certain library only hit a limited number of binaries. However, even this isn't ideal, as many of the changes to library don't propagate changes out to binaries, but since they're all in the same component, you have to bundle all of them together, even if most of the component is just updating version numbers.
For quite awhile the Service Pack for Vista was looking at being a ton of GiBs big... once they made some changes to be able to again only patch at the binary level *gasp* the SP size went down. Oddly enough it was called "small SP", even though it is still larger than other SPs before. (There's just data to "touch" the version number of all the binaries that didn't change despite being in a component that was serviced.)
(it's only done at compile time for most programs).
As noted above, most of the internal modularity of Windows the OS is done at compile time as well. As for updating things, I've updated on the fly the Linux kernel, X-Windows, WINE, and Mozilla/Gecko before on the ol' Red Hat systems. Honestly, I don't know where you're getting your troubles from, but I've never experienced any of them myself. Most notably tough, I don't have to recompile everything from scratch each time a new version of Gentoo is released... rather, I just compile what was updated. Windows Vista still isn't uncomplicated enough in compiling to be able to do this. No less, its dependence upon the Microsoft Corporate network.
And you're actually wrong. Mach is a microkernel. But just because the kernel is a microkernel doesn't mean that the stuff built upon it actually make use of that microkernel. Windows has also been based on a microkernel since Windows NT. The difference between a microkernel and a macrokernel are pretty irrelevant once you get to the layer of stuff on top of the OS.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
I hope you're not too serious, but I'll try to explain.
Ubuntu uses Debian's apt package management system. It's a great thing, fast as hell (especially when one's coming from Gentoo or source-y relatives), easy through Synaptic and so on. It does, however, have one major difference to Gentoo's way of handling new releases: Only security fixes are applied to packages after a release.
That's a great advantage to admin staff. Never touch a running system's config unless upgrading to a new release. It's also a (rather large) disadvantage to people favouring the bleeding edge. A seperate "backports" repository will contain some new releases but it's not as extensive or current as gentoo's. The actual updating process itself, though, is typically orders of magnitude faster because packages are distributed binary (source optional) instead of as source and compiled locally.
Updating Ubuntu's embraced and extended* edition of Firefox to it's newest version is as easy as "apt-get upgrade" (emerge -u world) or "apt-get install ubufox" (emerge firefox) after an "apt-get update" (emerge --sync). Updating to vanilla Firefox from mozilla.org is, as GP stated, another beast.
* I'm seriously hoping for that third "e" there -- all those annoying Fx banners and buttons and other nuisances are enough to ruin an already mediocre product completely. Freedom in software should mean letting people use whatever browser they like. Be it Opera, Safari, ELinks, Lynx or even a properly secured instance of MSIE.
The Linux kernel is monolithic, even if you compile everything as a module, it's basically stitched back together as a big monolith. Linux modules are just excised chunks of the kernel that you can load on demand, but you still need something specifically compiled into the kernel for each specific module to hook into.
With XNU, kernel extensions are more self-contained, and insert themselves into the kernel using more generic/universal interfaces.
That's why OS X device drivers don't have strict requirements for kernel version while binary Linux device drivers require a specific kernel version with specific compile-time options, and source drivers need the kernel to be compiled with support for them.