[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Neil Stone wrote: > Mark Thurston wrote: >>> With reference to windows, the only problem that I have with it as >>> software is that it seems to have a requirement to reinstall every 6 >>> months if you want to maintain a decent speed. It just seems to get >>> slower and slower after you first install. As linux can do everything I >>> need, I choose that instead. >>> >>> I've never had this problem with linux (at least not noticed it). > > I get that complaint a lot at work.. It's been a while since I did any serious delving into Windows problems but the more I get involved in GNU/Linux packaging, the more it appears to be a package management issue. Windows apps (certainly on Win9x) have a scattergun approach to configuration settings, registry entries, menu entries, mime-types and user settings. Apps are installed and uninstalled but a lot of crud can be left behind. This would be fine if these settings were in some quiet part of the filesystem (/etc/foo/conf) but when these settings are in a single monolithic binary registry, there is a noticeable amount of junk being loaded into memory every time - there should be some mandatory ruling by M$ that every application sticks to a strict policy of registry use. Every time a Windows user installs and uninstalls an app, that amount of crud can only increase. When you follow that line of logic, you'll come back to an earlier thread: In GNU/Linux, packages work best from standard repositories - principally because these have been checked to comply with agreed policies. Debian probably goes further with policy than other distributions and has a reputation of good package management. In Windows, the idea of an M$ central, authoritative, repository would cause absolute terror and paranoia in many computer users! (M$ applications themselves don't necessarily behave in a idempotent manner.) > i then offer to rebuild the machine > and people don't want me to.. perhaps it's because they have installed > lots and configured "just so".. And those configuration settings are often obfuscated in CLS_ID hexadecimal mysteries. It is one thing to remove registry settings that clearly identify the application involved, it's quite another to start going hacking around in the hexadecimal ID strings. Windows applications need better package management - a strict adherence to an *open* and *mutually agreed* policy. A system to which M$ themselves submit and where compliance is clearly identifiable whenever a user wants to download or install new software. (And not just as a blind-click-through dialogue box.) Oh, and backwards-compatibility would have to be consigned to history. Can't see that happening somehow. Yet in Debian, that is what you have. There is no guarantee of backwards compatibility - a Debian Potato box will continue running but upgrade that to woody and nearly all packages will have to be upgraded, some will have to be removed too. If a package is unmaintained in Debian, it will eventually be dropped. On Windows, M$ are shackled by compatibility with applications that are unmaintained. The version of gnucash in woody may not run in etch. It almost certainly will not run in the version after etch without a building a LOT of old libraries manually. There's trouble when this happens in Windows because users have to pay for a new version of Windows AND a new version of ALL their applications. It's not uncommon to find someone wanting to run software released in 1998 on an XP box because they resent paying for a new version when they are quite happy with the old version. If that upgrade was painless and free of cost, more people would run packages that were released for the same version of the OS itself. A simple idea but it's all but impossible for M$ to now adopt. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: OpenPGP digital signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html