[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Lawrence wrote: > On Sat, 2003-02-01 at 18:13, psutton wrote: > >> Microsoft issued a patch six months ago which could have stopped the worm, but its networks >>were quagmired too because the company failed to install it. > > > However, one of our customers did have the patch installed in his only > sql server. How come he got slammed - perhaps cos the patch didn't > f*****g work. I'm sure if the patch didn't work Microsoft would have changed it by now. The SQL SP3 fixed the problem in July, however if you had MSDE based stuff you weren't covered due to Microsoft's failings. A lot of people seemed to think SP3 for the OS covers it - which it didn't - you also have to reinstall service packs after changes. I had warned the big BG about configuration management issues with Windows (and MS Software) before although he never replied. <RANT status="fundamentals of modern computing"> Microsoft OSes lack a comprehensive strategy for patching. Typically in the *nix world you have a clear modular hierarchy - "PackageX" needs "libcrypto" for some features, and admin think nothing of installing a libcrypto patch, even if they have never heard of it before. The update tools automatically say "libcrypto is out of date". libcrypto is typically more than just "/lib/libcrypto.so" but other files required, plus dependency information on other modules. Microsoft believe they use file level configuration management. Microsoft could hardly deliver updates at subfile level (well I suppose they could technically if they were particularly keen, but that would require them to have a very sophisticated plan indeed). It is possible to do file based configuration control, but it is also possible to default to thinking you are doing it through lack of clue, and I believe MS falls into the second category. If you did file level configuration management, each file would indicate what files (and revisions) it depends on, and the update would indicate which files are out of date. Since there are common files to MSDE and MS SQL, and the patching was "out of sync", Microsoft clearly do not manage configurations at the file level. It is barely conceivable they have some clever configuration management at the file level in Redmund, and the system was saying that critical patches for MSDE had not been released, which is worse than not having such a system (except in terms of possibly fixing things in the future) - being willful negligence. In this sense I use "Configuration Management" as distinct from mere "version control". Microsoft clearly use file based version control as right clicking on any DLL will readily confirm. For terminology clarification - CVS provide file based (and project based) version control - Debian dpkg provides configuration management (or release management) type functionality (which Apt and friends build on -- think rpm for Redhat derivatives). Of course the problem with File based configuration management is that it needlessly multiplies entities and so in unduely expensive to do properly as a result. From a management perspective it is far better to group components together and label it metacomponents - at least where these components are closely related - coming from the same CVS cut is a good basis for grouping components as you are already managing them as one entity at source level - at least in some sense. Curiously MS VSS does project level management, but I believe some MS projects use other software control tools. This grouping of related components is the only way manage the complexity of modern software components, and also why Oracle products say things like "Requires Redhat 7.3" and not "requires kernel 2.4.7+", "libc 6+"..... the exceptions to which are documented where known. Such grouping of software will inevitably lead to simplifications, especially where "code" (or objects<sic> smaller than a configurable item) rather than "configurable items" are shared between projects. However I don't know of anyone who has attempted to tracks "lines of code" cut and pasted between different projects (files yes, but not lines of code). Such relationships where they exist are probably between expressed as configuration management data (i.e. if configurable item X is buggy also check for same bug in configurable item Y. Although for simple coding issues the bad practice is often generic and can be examined for across all relevant configurable items, and processes which spot said issue across multiple CI's should be used. Since unlike MS the Free Software community can not easily dictate such inspection practices, or extract metadata on cpying code, the burden for automated audit, MUST fall to the packagers such as the Debian Package Owners (or at least it is beyond the remit of developers - although putting checks in GCC is a good back up). Certainly Debian and more so some BSD groups have long recognised this fact. Microsoft could mandate such practices to all internal development teams, but they still use a substantial amount of "free" code, which must also be managed. Typically software houses mandate these roles to QA groups (if they have them - many don't). </RANT> Sorry for the rant, but these concepts are not sophisticated, the average primary school kid could grasp them quickly enough. But remember the Debian Linux group support far more diverse architectures that most Microsoft products, and manage these issues better than Microsoft (even though they are the kind of boring and mundane things you'd expect paid employees to do better than volunteers). The reasons for this difference are equally obvious, but that is another rant - for those struggling to do the reasoning - in the immortal lesson learnt from Watergate "Follow the money". Simon, not particularly meaning to slam Microsoft, although this is an area they do particularly badly at. Microsoft do seem to do file based version control better than most, in that most files are tagged with version ID's, although even here some others do better. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+PkU4GFXfHI9FVgYRAgsJAJ9plg1UmwCcxsony0zOJaTukF278wCfRfiz wsi7tQzjzRBuMQetkFHMIlc= =htJg -----END PGP SIGNATURE----- -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.