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.
Considering Microsoft has, in the past, been accused of artificially bundling components together (IE+Windows, DirectX10+Vista, etc), [...]
Of course, accusations != truth. For your two examples, IE was no more "artificially bundled" into Windows than its equivalents were into contemporary OSes and DirectX10 requires features only present in Vista's new display system.
"Artificial bundling" is as meaningless as "bloat". Stuff that you, personally, aren't interested in != stuff that no-one is interested in.
[...] I'm going to remain skeptical on this plan. It seems like Microsoft can get much higher revenue from a several-hundred-dollars major upgrade than a pick-n-choose bundle of features. The only way I see them breaking it apart is if their monopoly really does begin to be challenged and they have to start selling in a truly competitive market.
Huh ? It was the competitive market that resulted in IE, etc, being "bundled" into Windows in the first place (in response to competitors doing the same). What on Earth makes you think its going to drive them to start removing stuff when their competitors continue to add more and more features as part of their base packages ?
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.
I'm sure that back in the 70's during the gas crunch, the people that said "gas is gonna be $2, 3, 4 a gallon" were told the same thing OMG! Slippery slope! Slippery Slope!
0xB315AA8D852DCD3F3DCA578FD2E0BF88
I think you're right, but I wouldn't agree to "English is one of the hardest languages in the world to learn", seeing the struggle of native English speakers in learning French or Spanish and, to a lesser extent, German, languages that are all related to each other. If you count Chinese and the like, well, we're all equally buggered. On the other hand, Europeans aren't too bad at English if only at a basic level (after all it's taught at school), specially in the Nordic area. And yes, as you've guessed, English is not my native language :)
Your head a splode
And there's versions of MSSQL that only support databases of certain size.
There's ONE version, and it's free.
Hi, you're not funny. Thanks for trying.
- 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.
Not necessarily. I guess that it depends upon the hardware. There are three groups we can be discussing:
a) All 32-bit hardware.
b) 64-bit hardware with limitations on the MMU that ultimately restrict (to various degrees) mapping of high portions of memory.
b) 64-bit hardware with an MMU that does not have the above restriction.
All modern operating systems on hardware platform a are going to have problems seeing 4GB of RAM.
All modern 64-bit operating systems on hardware platform b (including Windows Vista 64) will be able to map the full range of memory, less whatever is mapped or reserved for devices. This is the hardware platform that I was referencing. More on this later.
All modern 64-bit operating systems on hardware platform c should be able to see the full amount of RAM. This seems to be the hardware platform to which you're referring.
The specific issue I had was with a 64-bit, dual-core Athlon processor and a motherboard (I don't remember the brand, much less the model.) The board was advertised as capable of accepting 4 gigabytes of RAM, but when I put four gigabyte sticks in, Linux told me that it was only able to use 3.25. This was 64-bit Linux with a kernel that should have allowed the full amount to be accessed. After I ran into this, I started researching the issue and discovered the cause.
On the other hand, if MS does this, then competitors can come in and offer the same components/services. Open source will do it very quickly, driving the cost to zero. If MS tries to shut out anyone else, the result is antitrust action.
Simple solution to that one: you allow anyone to write the modules, but Windows will not install them unless they're signed by Microsoft. And the signing process costs money.
Obligatory statement... I took 4 years of Japanese at university, forming the minor to my double major degree in Philosophy and Linguistics. English and French are my first languages, Japanese is number 5, after Spanish and German. There's also a smattering of Greek and Latin in there, remnants from a time when I thought that learning those languages would make learning other European languages easier.
I can tell you that spoken Japanese is probably the easiest language to learn on the planet. I can also tell you that it's a language isolate, and is not related to any other language on the planet. The reason it's partly written with Chinese characters (and in fact, the Katakana and Hiragana writing systems are derived from Kanji) has to do with an influx of Chinese in the last two thousand years. The Japanese language itself, and underlying grammar, predates the introduction of the Chinese writing system by thousands of years.
There's two main verb tenses, and you can count the number of irregular verbs on one hand. (There's actually a whole bunch more, but the overwhelming majority of them are formed as noun + the verb "suru" meaning "to do". For example, the verb for driving a car is "untensuru", literally meaning "to do driving"). The grammar is particle delineated... it really doesn't matter what order you get the nouns in when forming a sentence, because their function is indicated by a particle. Finally, there's exactly 5 vowel sounds.
Contrast that to English, which takes vocabulary and grammar from at least 5 major donor languages, and has over 30 vowel sounds. No language has more cases where you "just have to know" than English. *shrugs* One of the hardest languages there is, IMO.
If you believe everything you read, you'd better not read. - Japanese proverb
Umm... substitutability has very little to do with COM. This has to do with the Gecko ActiveX control specifically emulating the Internet Explorer HTML control's API, for the exact purpose of being substitutable in all those applications that depend on the IE control.
.NET basically circumvents the need for COM by replacing it with the CLR and .NET assemblies. .NET defines Microsoft's new interface for a language-independent library, so there's no need for the older COM approach.
The only benefit of COM was that it was supposed to be language-neutral; it doesn't depend on, say, having a specific C++ compiler to be able to use a library. That's it. On Linux, almost all APIs either use plain C (which has a standard ABI), or C++ (which generally means the G++ ABI), or are scripted languages where it doesn't matter, so there's very little need for anything like COM. Actually, there's very little need for COM on Windows, either, for pretty much the same reason as there's no need for it on Linux.
Microsoft still uses COM extensively for historical reasons, but all the hullabaloo about
If an analogy would clear this up: Being surprised you can't replace Gecko with WebKit is like being surprised you can't plug a square peg into a round hole. Being surprised you can replace Internet Explorer with an ActiveX control that uses Gecko is like being surprised you can fit a square peg with the corners cut off into a round hole.
There are, incidentally, plenty of examples of libraries that are substitutable on Linux. (Java's full of them, every browser plug-in is essentially an example, there's the DNS resolver, the list goes on.) It's just that in the world of open source, there's rarely any need to have more than one major implementation of a particular interface; it's better to share the work on a single implementation than to keep re-inventing the wheel. On the flip side, if it's useful to have more than one implementation, it's also generally useful to have more than one API. That other implementation is going to be tuned for a different use, and a different API will likely be optimal because of it.