Why is windows vista so late? On backwards compatibility and web based operation system
Saturday, May 27, 2006
I have recently upgraded my Fedora 4 installation to Fedora 5, while admiring Fedora's ability to produce a new version every 6 months, while Microsoft is struggling with its new operation system for what seems like a decade.
When my beloved Linux box restarted following the upgrade, and for the following two days - it became apparent what makes Vista so late, and what makes Fedora so quick to release new versions.
Backwards compatibility.
Following my fedora upgrade many components were broken on my system. My Ruby On Rails applications broke down - their dependency libraries, such as rmagick and bdb stopped working. some of my KDE components did not upgrade due to package conflicts - in short - I had to spend about a day to resolve all the issues, and I'm still getting some very weired behavior from my KDE desktop and a couple of system services.
When Microsoft releases a new operation system to the market, it must check it is compatible with hundreds of thousand software packages, thousands of hardware devices and infinite array of configurations, languages, time zones - you name it. Microsoft can't allow its upgrade to ever fail. It can't relay on its user to download and compile the new kernel.
The nature of desktop software is that once you have shipped it - fixing glitches and bugs is a costly and a highly complex feat. Web based services, on the other hand - are much simpler to manage.
Imagine a world where your operation system, windows, is managed on an Internet server. Imagine how easy it would be for Microsoft to upgrade their operation system for all its world-wide users. It, too, will transform is deployment model into "a continuous release of upgrades and features" replacing the "one version every 10 years" approach currently dictated by its distribution model. It could compete with Google and Yahoo's rate of software release cycles.
That's why I like projects like YouOS the idea behind it is exciting. But what kind of technologies such an idea needs in order to bemore reality? what kind of hardware should be standard practice for it to work?
On the software side, a dynamic, easily extensible language is needed. Javascript, which is YouOs choice, just won't cut it. It lacks the "power" of defining meta languages and high-level models of its world. This task is a perfect match for languages such as Lisp or the more popular, and almost as powerful Ruby. These dynamic languages, who has no distinction between "run-time" and "design-time" will allow software vendors to write OS extensions. Software components made by different vendors could communicate without needing the OS "manufacturer" to extend the "API". Such an operation system and its facilities could be "grown" and developed by the application writers and make it more powerful and feature-rich with every new application that is added. In a way, every applications' libraries and "procedures" will be available to all other applications with minimum effort. They must all conform to some basic "behavior" protocol which can be self-moderated by the community. Security will be a hell to deal with - but current state is not much better.
The network IS the operation system. and if it's not - there's a powerful, living software environment operation system that is easily extendible.
technorati tags: ruby, lisp, operation system, guy tavor, web, vista
I have recently upgraded my Fedora 4 installation to Fedora 5, while admiring Fedora's ability to produce a new version every 6 months, while Microsoft is struggling with its new operation system for what seems like a decade.
When my beloved Linux box restarted following the upgrade, and for the following two days - it became apparent what makes Vista so late, and what makes Fedora so quick to release new versions.
Backwards compatibility.
Following my fedora upgrade many components were broken on my system. My Ruby On Rails applications broke down - their dependency libraries, such as rmagick and bdb stopped working. some of my KDE components did not upgrade due to package conflicts - in short - I had to spend about a day to resolve all the issues, and I'm still getting some very weired behavior from my KDE desktop and a couple of system services.
When Microsoft releases a new operation system to the market, it must check it is compatible with hundreds of thousand software packages, thousands of hardware devices and infinite array of configurations, languages, time zones - you name it. Microsoft can't allow its upgrade to ever fail. It can't relay on its user to download and compile the new kernel.
The nature of desktop software is that once you have shipped it - fixing glitches and bugs is a costly and a highly complex feat. Web based services, on the other hand - are much simpler to manage.
Imagine a world where your operation system, windows, is managed on an Internet server. Imagine how easy it would be for Microsoft to upgrade their operation system for all its world-wide users. It, too, will transform is deployment model into "a continuous release of upgrades and features" replacing the "one version every 10 years" approach currently dictated by its distribution model. It could compete with Google and Yahoo's rate of software release cycles.
That's why I like projects like YouOS the idea behind it is exciting. But what kind of technologies such an idea needs in order to bemore reality? what kind of hardware should be standard practice for it to work?
On the software side, a dynamic, easily extensible language is needed. Javascript, which is YouOs choice, just won't cut it. It lacks the "power" of defining meta languages and high-level models of its world. This task is a perfect match for languages such as Lisp or the more popular, and almost as powerful Ruby. These dynamic languages, who has no distinction between "run-time" and "design-time" will allow software vendors to write OS extensions. Software components made by different vendors could communicate without needing the OS "manufacturer" to extend the "API". Such an operation system and its facilities could be "grown" and developed by the application writers and make it more powerful and feature-rich with every new application that is added. In a way, every applications' libraries and "procedures" will be available to all other applications with minimum effort. They must all conform to some basic "behavior" protocol which can be self-moderated by the community. Security will be a hell to deal with - but current state is not much better.
The network IS the operation system. and if it's not - there's a powerful, living software environment operation system that is easily extendible.
technorati tags: ruby, lisp, operation system, guy tavor, web, vista
