"A not insignificant amount of the code is a mess, yes, but it's not low-quality"
Maintainability is an extremely important aspect of development. If the code is a mess, then it is not high-quality code.
"Being a mess never implies low quality, it just means that a decade or so of cruft has built up."
Being a mess implies that it is difficult to maintain, which implies that it is of poor quality. The proper way to develop is to refactor during development, so that you don't accumulate cruft or messiness. I'd say that cruft by definition implies low-quality code. A very important aspect of development is design. A proper design phase for new features/code will also include looking at the existing design and how the new stuff can fit into it. You don't just go and tack your new feature on the end of what you already have, or you end up with unmaintainable, messy, cruft. You look at what you want to do, and you evolve the existing design to make the new code integrate into it, rather than be tacked on with sticky tape.
Why, does Mozilla have a policy of allowing anyone to commit patches without approval?
If the patches received are crap, then the people who are in charge of receiving the patches and committing them should reject them, or pass them on to a 'de-crappifying' team who can look at the patch and rework it in a non-crappy manner.
If crap patches get automatically committed and added to the code base, and no-one at Mozilla thinks this is a bad idea, then I'd agree... Firefox is most definitely losing its way.
Don't you think that by the time Vista is available to the average user, the software would have been fixed? Vista isn't even on MSDN yet - for all intents and purposes, it is an unreleased operating system. Why is it funny that software currently available doesn't run on an operating system that is not yet available?
Mr Chen has also addressed that issue at length as well. There are many problems with simply including an emulator with the new OS that can host the old OS, for example supporting copy/paste between apps in the native OS and apps in the emulated OS. Simply providing an emulated solution for backwards compatibility with the old OS was considered but rejected because it provided a crappy user experience.
Another example - you have a network share mapped on your native OS. You double-click a file in the network share which is associated with a program written for a previous version of the OS, so it needs to be launched in the emulator. Emulator lauches, and launches the old application. How does the emulator know that this drive needs to be network mapped?
Not to mention the fact that you'd have two task bars, two system trays, two start menus, etc.
There's nothing stopping major improvements to the kernel. As I understand it, the problem is that the kernel maintainers seem to have a specific desire to *not* maintain a stable interface against which drivers can be written, the reasoning being that if the drivers are open source, then the changes required by the new interface will be trivial to implement. So, the kernel maintainers make a point of not bothering to maintain a stable interface for driver developers over the long term to discourage binary-only drivers.
Guess what - those hardware manufacturers who are releasing binary-only drivers aren't going to suddenly decide to release open-source drivers. They have a lot of intellectual property in there that they either cannot afford to be disclosed to their competitors, or cannot disclose due to licensing requirements from 3rd parties.
If the kernel wasnt such a moving target, it would be easier for hardware vendors to release one set of drivers that will work on a large range of kernel versions. I'd imagine having to maintain multiple releases of the same driver for different point releases of kernel contributes a lot to the perceived apathy of hardware vendors towards linux. Before this gets marked as a troll, think about the number of 'i upgraded my kernel from x.y.z to x.y.z+1 and ABC stopped working' comments that accompany so many kernel release announcements
I think you dont understand the difference between adware and spyware. Adware is advertising-supported software. How does trying to support your software via ads make you an asshole?
Er, Microsoft does not issue driver-signing certs. They require that you have a valid cert from a 3rd-party CA (Verisign IIRC), who charges the $500 fee. MS then uses this existing cert to sign your driver. MS makes no money from driver signing.
Please provide a link or some sort of evidence for that? It is actively in Microsoft's best interests NOT to forcefully require DRM-capable monitors. Why would it be? Microsoft does not sell monitors. They sell software. People will not buy their software if they also had to go and buy DRM-capable monitors for no reason. Despite what people on this site may think, Microsoft is not really made up of a bunch of idiots. So, could you please provide some sort of official hardware requirements list from Microsoft that states that a DRM-capable monitor is required for ANY type of Vista use?
Plus considering that Vista will have monitor DRM, early adopters (aside from hardcore gamers) may not find having to buy a whole new monitor acceptable
Why why why does this rubbish keep on getting repeated over and over again? Just because Vista supports monitor DRM doesnt mean that you HAVE to have a DRM-capable monitor. All it means is that if you choose to watch DRM'd content that specifically requests a DRM'd monitor, you will need to have one, or the display will be fuzzy. This has absolutely NOTHING to do with Vista at all. Do you think that by sticking to XP or MacOS or Linux you'd magically avoid the monitor DRM? Not a chance. The content dictates the levels of "security" required. Vista is going to support these levels of security. If you will never have the need to watch content that requires a DRM'd monitor, then you will still be able to use Vista quite happily with whatever old monitor you wish.
The FUD around Vista and DRM on slashdot is disgusting. Just because Vista supports DRM does not mean that everyhing to do with Vista revolves around DRM. If anyone thinks that, then they're deliberately remaining ignorant about it. MS has nothing to gain by requiring people to buy DRM monitors. That would be insane. Nobody is going to upgrade to their new OS if that were the case. Content providers want this support and MS is providing the capabilities. Stay away from those content providers or that type of content, and you can live your life being blissfully unaffected by monitor DRM.
There is a difference though. If your car was taken in to the shop for a factory defect (windows bugs) then fixing it (applying security patches) should not affect the warranty. Windows service packs are not just security updates, as most of the commenters here seem to be missing - they are also feature enhancements. If the submitter just wants the security patches, then as far as i can recall (from the last time I used the web-based windows-update) the individual patches just require confirmation for installation, not acceptance of an EULA. However, because a SP is not just patches, but feature enhancements and additions as well (my memory is fading, but I seem to recall SP4 introducing or improving a native bluetooth stack for example), it is more like an overhaul of your car's engine, rather than just a tune-up. And I'm sure that an engine overhaul could justify a warranty adjustment, because the product has been voluntarily enhanced by yourself.
Do you actually have any proof to support your "DOS ain't done till Lotus wont run" claim? That's just about as widespread, and just as unproven as the " who would ever need more than 640KB of ram" crap that gets repeated here over and over again.
But you don't need to leave your pc running 24/7 to contribute to distributed computing projects - typically during normal use you're not fully utilizing your cpu... if that's the case, then you can still make a small contribution towards some sort of research, and still not waste electricity by leaving your pc on all the time.
You're obviously not a programmer, are you? Every time I have to fix a bug in some code I myself have written more than a few months ago, I scratch my head and say to myself 'why the fuck did you even think of doing that, you idiot'. That's why they're bugs. It may have made sense at the time. Now it doesn't. Maybe the 'if (length == 1)' was part of a switch statement, and the other entries were removed. Maybe the source code actually looks different, but the optimizing compiler had a bug which 'helpfully' reduced the check to the seemingly suspect length==1 check. I know I came across a bug in VS2003's compiler (to which alas I've lost the code that reproduces it) in which a switch statement worked perfectly in debug mode, but was 'optimized' into a hideous mess of incorrect assembly in release mode. There are dozens of plausible explanations for the length==1 statement in the code. Only one of them requires a tinfoil hat.
"I honestly get sick of people - including many of my co-workers - saying how they'll put up with all the problems of WinXP just so they can "play games." If I were that interested in these types of games, I'd buy a console - either an XBox or PSP or GameCube."
The reasons why I wont buy a console is because 1. I already have a computer capable of playing these games 2. PC versions of the games are usually *much* cheaper than PS2/XBox versions (at least here in South Africa) 3. Say I already had an PS2. Now fast forward a few months to when the PS3 is out. If i want to play the newest games, I need to buy an PS3 because the newest games are written for the newer platform. So I must buy another console. With my pc, once it gets too old to play current games, I can either upgrade it, or buy a new PC, BUT, I can still use the old pc for doing any number of things. What would you do with a PS2 once you've bought a PS3?
I agree. If they really want to have their input devices provide feedback based on new mail, IM's etc, then surely a better device would be the keyboard?
Almost every new keyboard I've seen already has a row of about 10 buttons at the top as shortcuts to email, etc. I would think an LED behind each shortcut button would make more sense - if you have new mail, the email shortcut would light up, and so on. Especially since the keyboard is generally directly below the monitor, and so is usually within your peripheral vision, even if you dont look at the keyboard as you type. My mouse is usually completely out of sight, and hardly used.
If you've never been involved in working with Visual Sourcesafe, how can you assert with great authority that it 'has been pretty crap for ages'? Were you just hoping for a karma-boost by making an MS-bashing post?
from tfa: One function of the new mouse, however, is its ability to sense if there is wireless interference from other devices, an increasingly common problem with today's numerous wireless devices, and to change channels to establish the most secure connection.
Other features include the ability to sense the power status of the PC. For example, the mouse can sense when the PC has gone into sleep mode or is shut down. The mouse powers down accordingly. This gives the mouse an expected battery life of three months.
I'd imagine you'd need two-way communication to achieve that
I can't speak as to why the AARD code was obfuscated, I have no explanation for that, it seems totally stupid to me. But I've got to say that I totally agree with the basic concept of Windows checking for an alternative version of MS-DOS and refusing to run on it.
The thing is that the Windows team had a problem to solve, and they didn't care how they solved it. Windows decided that it owned every part of the system, including the internal data structures of the operating system. It knew where those structures were located, it knew what the size of those data structures was, and it had no compunction against replacing those internal structures with its own version. Needless to say, from a DOS developer's standpoint, keeping Windows working was an absolute nightmare.
As a simple example, when Windows started up, it increased the size of MS-DOS's internal file table (the SFT, that's the table that was created by the FILES= line in config.sys). It did that to allow more than 20 files to be opened on the windows system (a highly desirable goal for a multi-tasking operating system). But it did that by using an undocumented API call, which returned a pointer to a set of "interesting" pointers in MS-DOS. It then indexed a known offset relative to that pointer, and replaced the value of the master SFT table with its own version of the SFT. When I was working on MS-DOS 4.0, we needed to support Windows. Well, it was relatively easy to guarantee that our SFT was at the location that Windows was expecting. But the problem was that the MS-DOS 4.0 SFT was 2 bytes larger than the MS-DOS 3.1 SFT. In order to get Windows to work, I had to change the DOS loader to detect when win.com was being loaded, and if it was being loaded, I looked at the code at an offset relative to the base code segment, and if it was a "MOV" instruction, and the amount being moved was the old size of the SFT, I patched the instruction in memory to reflect the new size of the SFT! Yup, MS-DOS 4.0 patched the running windows binary to make sure Windows would still continue to work.
Now then, considering how sleazy Windows was about MS-DOS, think about what would happen if Windows ran on a clone of MS-DOS. It's already groveling internal MS-DOS data structures. It's making assumptions about how our internal functions work, when it's safe to call them (and which ones are reentrant and which are not). It's assuming all SORTS of things about the way that MS-DOS's code works.
And now we're going to run it on a clone operating system. Which is different code. It's a totally unrelated code base.
If the clone operating system isn't a PERFECT clone of MS-DOS (not a good clone, a perfect clone), then Windows is going to fail in mysterious and magical ways. Your app might lose data. Windows might corrupt the hard disk.
Given the degree with which Windows performed extreme brain surgery on the innards of MS-DOS, it's not unreasonable for Windows to check that it was operating on the correct patient.
Wanna know why they didnt just remove the code from the final release? Chris Pratley explains that too:
A last anecdote to leave you with. Even re-linking your code (not even recompile) can introduce a crashing bug. A few years ago, we were working on the release candidate for an Asian-language version of Word97. We thought we were done, and ran our last optimization on the build. We have some technology at Microsoft that profiles code usage and arranges the code modules so that they are in the executable in the optimal order to produce the best possible boot speed. Afte
Its probably worthwhile to note that the Ubuntu foundation was also started up by Mark Shuttleworth. The man is really doing everything he can to get linux to as many people as possible.
Slashdot Mirror
"A not insignificant amount of the code is a mess, yes, but it's not low-quality"
Maintainability is an extremely important aspect of development. If the code is a mess, then it is not high-quality code.
"Being a mess never implies low quality, it just means that a decade or so of cruft has built up."
Being a mess implies that it is difficult to maintain, which implies that it is of poor quality. The proper way to develop is to refactor during development, so that you don't accumulate cruft or messiness. I'd say that cruft by definition implies low-quality code.
A very important aspect of development is design. A proper design phase for new features/code will also include looking at the existing design and how the new stuff can fit into it. You don't just go and tack your new feature on the end of what you already have, or you end up with unmaintainable, messy, cruft. You look at what you want to do, and you evolve the existing design to make the new code integrate into it, rather than be tacked on with sticky tape.
Why, does Mozilla have a policy of allowing anyone to commit patches without approval?
If the patches received are crap, then the people who are in charge of receiving the patches and committing them should reject them, or pass them on to a 'de-crappifying' team who can look at the patch and rework it in a non-crappy manner.
If crap patches get automatically committed and added to the code base, and no-one at Mozilla thinks this is a bad idea, then I'd agree... Firefox is most definitely losing its way.
Actually no, different teams in microsoft do not have access to source code other than the product they are working on.
Don't you think that by the time Vista is available to the average user, the software would have been fixed?
Vista isn't even on MSDN yet - for all intents and purposes, it is an unreleased operating system. Why is it funny that software currently available doesn't run on an operating system that is not yet available?
Mr Chen has also addressed that issue at length as well. There are many problems with simply including an emulator with the new OS that can host the old OS, for example supporting copy/paste between apps in the native OS and apps in the emulated OS. Simply providing an emulated solution for backwards compatibility with the old OS was considered but rejected because it provided a crappy user experience.
Another example - you have a network share mapped on your native OS. You double-click a file in the network share which is associated with a program written for a previous version of the OS, so it needs to be launched in the emulator. Emulator lauches, and launches the old application. How does the emulator know that this drive needs to be network mapped?
Not to mention the fact that you'd have two task bars, two system trays, two start menus, etc.
There's nothing stopping major improvements to the kernel. As I understand it, the problem is that the kernel maintainers seem to have a specific desire to *not* maintain a stable interface against which drivers can be written, the reasoning being that if the drivers are open source, then the changes required by the new interface will be trivial to implement. So, the kernel maintainers make a point of not bothering to maintain a stable interface for driver developers over the long term to discourage binary-only drivers.
Guess what - those hardware manufacturers who are releasing binary-only drivers aren't going to suddenly decide to release open-source drivers. They have a lot of intellectual property in there that they either cannot afford to be disclosed to their competitors, or cannot disclose due to licensing requirements from 3rd parties.
If the kernel wasnt such a moving target, it would be easier for hardware vendors to release one set of drivers that will work on a large range of kernel versions. I'd imagine having to maintain multiple releases of the same driver for different point releases of kernel contributes a lot to the perceived apathy of hardware vendors towards linux. Before this gets marked as a troll, think about the number of 'i upgraded my kernel from x.y.z to x.y.z+1 and ABC stopped working' comments that accompany so many kernel release announcements
I think you dont understand the difference between adware and spyware. Adware is advertising-supported software. How does trying to support your software via ads make you an asshole?
Er, Microsoft does not issue driver-signing certs. They require that you have a valid cert from a 3rd-party CA (Verisign IIRC), who charges the $500 fee. MS then uses this existing cert to sign your driver. MS makes no money from driver signing.
Please provide a link or some sort of evidence for that? It is actively in Microsoft's best interests NOT to forcefully require DRM-capable monitors. Why would it be? Microsoft does not sell monitors. They sell software. People will not buy their software if they also had to go and buy DRM-capable monitors for no reason. Despite what people on this site may think, Microsoft is not really made up of a bunch of idiots. So, could you please provide some sort of official hardware requirements list from Microsoft that states that a DRM-capable monitor is required for ANY type of Vista use?
Why why why does this rubbish keep on getting repeated over and over again? Just because Vista supports monitor DRM doesnt mean that you HAVE to have a DRM-capable monitor. All it means is that if you choose to watch DRM'd content that specifically requests a DRM'd monitor, you will need to have one, or the display will be fuzzy. This has absolutely NOTHING to do with Vista at all. Do you think that by sticking to XP or MacOS or Linux you'd magically avoid the monitor DRM? Not a chance. The content dictates the levels of "security" required. Vista is going to support these levels of security. If you will never have the need to watch content that requires a DRM'd monitor, then you will still be able to use Vista quite happily with whatever old monitor you wish.
The FUD around Vista and DRM on slashdot is disgusting. Just because Vista supports DRM does not mean that everyhing to do with Vista revolves around DRM. If anyone thinks that, then they're deliberately remaining ignorant about it. MS has nothing to gain by requiring people to buy DRM monitors. That would be insane. Nobody is going to upgrade to their new OS if that were the case. Content providers want this support and MS is providing the capabilities. Stay away from those content providers or that type of content, and you can live your life being blissfully unaffected by monitor DRM.
There is a difference though. If your car was taken in to the shop for a factory defect (windows bugs) then fixing it (applying security patches) should not affect the warranty. Windows service packs are not just security updates, as most of the commenters here seem to be missing - they are also feature enhancements. If the submitter just wants the security patches, then as far as i can recall (from the last time I used the web-based windows-update) the individual patches just require confirmation for installation, not acceptance of an EULA. However, because a SP is not just patches, but feature enhancements and additions as well (my memory is fading, but I seem to recall SP4 introducing or improving a native bluetooth stack for example), it is more like an overhaul of your car's engine, rather than just a tune-up. And I'm sure that an engine overhaul could justify a warranty adjustment, because the product has been voluntarily enhanced by yourself.
Do you actually have any proof to support your "DOS ain't done till Lotus wont run" claim? That's just about as widespread, and just as unproven as the " who would ever need more than 640KB of ram" crap that gets repeated here over and over again.
s _aint_done_t.html which has quotes from both microsoft and lotus dispelling that myth, and http://blogs.msdn.com/larryosterman/archive/2004/0 8/12/213681.aspx explaining why windows 3 did the check for incompatible DOS installations.
/.
If you bothered to google your quote, you'd come up with http://www.proudlyserving.com/archives/2005/08/do
As someone has already pointed out above, the "DOS aint done" myth was already exposed right here on
Slashdot needs a -1, Factually incorrect mod.
The latest version of MSN, version 8, supports offline messaging.
But you don't need to leave your pc running 24/7 to contribute to distributed computing projects - typically during normal use you're not fully utilizing your cpu... if that's the case, then you can still make a small contribution towards some sort of research, and still not waste electricity by leaving your pc on all the time.
dude, i'd think the bicep would be one of the best developed muscles on the average slashdotter's body :p
You're obviously not a programmer, are you?
Every time I have to fix a bug in some code I myself have written more than a few months ago, I scratch my head and say to myself 'why the fuck did you even think of doing that, you idiot'. That's why they're bugs. It may have made sense at the time. Now it doesn't. Maybe the 'if (length == 1)' was part of a switch statement, and the other entries were removed. Maybe the source code actually looks different, but the optimizing compiler had a bug which 'helpfully' reduced the check to the seemingly suspect length==1 check. I know I came across a bug in VS2003's compiler (to which alas I've lost the code that reproduces it) in which a switch statement worked perfectly in debug mode, but was 'optimized' into a hideous mess of incorrect assembly in release mode. There are dozens of plausible explanations for the length==1 statement in the code. Only one of them requires a tinfoil hat.
"I honestly get sick of people - including many of my co-workers - saying how they'll put up with all the problems of WinXP just so they can "play games." If I were that interested in these types of games, I'd buy a console - either an XBox or PSP or GameCube."
The reasons why I wont buy a console is because
1. I already have a computer capable of playing these games
2. PC versions of the games are usually *much* cheaper than PS2/XBox versions (at least here in South Africa)
3. Say I already had an PS2. Now fast forward a few months to when the PS3 is out. If i want to play the newest games, I need to buy an PS3 because the newest games are written for the newer platform. So I must buy another console. With my pc, once it gets too old to play current games, I can either upgrade it, or buy a new PC, BUT, I can still use the old pc for doing any number of things. What would you do with a PS2 once you've bought a PS3?
Like this eye?
/ releases/2003/11/image/a
http://hubblesite.org/newscenter/newsdesk/archive
The problem seemed to be the Radeon video card
So what exactly does that have to do with this:
So much for Windows running on old hardware...
Install broken hardware or a broken driver on your linux machine and then tell us how well that works
You mean like this?
Search for "Baltimore" on the page - only one article between the original and the dupe.
I agree. If they really want to have their input devices provide feedback based on new mail, IM's etc, then surely a better device would be the keyboard?
Almost every new keyboard I've seen already has a row of about 10 buttons at the top as shortcuts to email, etc. I would think an LED behind each shortcut button would make more sense - if you have new mail, the email shortcut would light up, and so on. Especially since the keyboard is generally directly below the monitor, and so is usually within your peripheral vision, even if you dont look at the keyboard as you type. My mouse is usually completely out of sight, and hardly used.
If you've never been involved in working with Visual Sourcesafe, how can you assert with great authority that it 'has been pretty crap for ages'? Were you just hoping for a karma-boost by making an MS-bashing post?
from tfa:
One function of the new mouse, however, is its ability to sense if there is wireless interference from other devices, an increasingly common problem with today's numerous wireless devices, and to change channels to establish the most secure connection. Other features include the ability to sense the power status of the PC. For example, the mouse can sense when the PC has gone into sleep mode or is shut down. The mouse powers down accordingly. This gives the mouse an expected battery life of three months.
I'd imagine you'd need two-way communication to achieve that
Larry Osterman, who's been at MS for over 20 years now, clears that up for you:
http://blogs.msdn.com/larryosterman/archive/2004/0 8/12/213681.aspx
I can't speak as to why the AARD code was obfuscated, I have no explanation for that, it seems totally stupid to me. But I've got to say that I totally agree with the basic concept of Windows checking for an alternative version of MS-DOS and refusing to run on it.
The thing is that the Windows team had a problem to solve, and they didn't care how they solved it. Windows decided that it owned every part of the system, including the internal data structures of the operating system. It knew where those structures were located, it knew what the size of those data structures was, and it had no compunction against replacing those internal structures with its own version. Needless to say, from a DOS developer's standpoint, keeping Windows working was an absolute nightmare.
As a simple example, when Windows started up, it increased the size of MS-DOS's internal file table (the SFT, that's the table that was created by the FILES= line in config.sys). It did that to allow more than 20 files to be opened on the windows system (a highly desirable goal for a multi-tasking operating system). But it did that by using an undocumented API call, which returned a pointer to a set of "interesting" pointers in MS-DOS. It then indexed a known offset relative to that pointer, and replaced the value of the master SFT table with its own version of the SFT. When I was working on MS-DOS 4.0, we needed to support Windows. Well, it was relatively easy to guarantee that our SFT was at the location that Windows was expecting. But the problem was that the MS-DOS 4.0 SFT was 2 bytes larger than the MS-DOS 3.1 SFT. In order to get Windows to work, I had to change the DOS loader to detect when win.com was being loaded, and if it was being loaded, I looked at the code at an offset relative to the base code segment, and if it was a "MOV" instruction, and the amount being moved was the old size of the SFT, I patched the instruction in memory to reflect the new size of the SFT! Yup, MS-DOS 4.0 patched the running windows binary to make sure Windows would still continue to work.
Now then, considering how sleazy Windows was about MS-DOS, think about what would happen if Windows ran on a clone of MS-DOS. It's already groveling internal MS-DOS data structures. It's making assumptions about how our internal functions work, when it's safe to call them (and which ones are reentrant and which are not). It's assuming all SORTS of things about the way that MS-DOS's code works.
And now we're going to run it on a clone operating system. Which is different code. It's a totally unrelated code base.
If the clone operating system isn't a PERFECT clone of MS-DOS (not a good clone, a perfect clone), then Windows is going to fail in mysterious and magical ways. Your app might lose data. Windows might corrupt the hard disk.
Given the degree with which Windows performed extreme brain surgery on the innards of MS-DOS, it's not unreasonable for Windows to check that it was operating on the correct patient.
Wanna know why they didnt just remove the code from the final release? Chris Pratley explains that too:
http://blogs.msdn.com/chris_pratley/archive/2004/0 2/05/67871.aspx
A last anecdote to leave you with. Even re-linking your code (not even recompile) can introduce a crashing bug. A few years ago, we were working on the release candidate for an Asian-language version of Word97. We thought we were done, and ran our last optimization on the build. We have some technology at Microsoft that profiles code usage and arranges the code modules so that they are in the executable in the optimal order to produce the best possible boot speed. Afte
Its probably worthwhile to note that the Ubuntu foundation was also started up by Mark Shuttleworth. The man is really doing everything he can to get linux to as many people as possible.