You've clearly not watched Windows users use Windows. There's a lot of fumbling that even people who know what they're doing go through, just because a lot of the interactions are difficult to do.
What he seems to me to be saying is that Microsoft formats have, at least traditionally, been tied to the behavior of the application, rather than being defined in terms of what the document is supposed to be about. This means that, if you're trying to do something very much unlike what the original application was supposed to do, the Microsoft format may be problematic, in terms of lacking information you want or requiring information you don't have. I have no idea if OpenDocument actually has any particular benefits due to this focus, but that's at least what he's talking about.
The xforms integration is a good idea in this direction, in any case; it means that you can have a document which is simultaneously a word processing document (that can be printed out like normal) and a machine-readable form (that can be reliably imported into a database, because it's actually storing the form structure and information about each field's value explicitly, rather than just storing a word processing document which looks like a filled-out form. This means that it's really easy to handle forms (verify that the form in the document is the form you sent out; read and validate the field values), rather than needing to try to understand the layout of the document and figure out how to parse the thing the way that the person expected it to be interpreted.
I block Flash (actually, I keep the plugin not installed) and only let animations run once. As much as possible, I block anything that creates new windows or changes window size or decorations. If I could, I'd block anything that places anything over text. I'd also like to block mouseover.
In all of these cases, the worst abuses I've seen aren't ads, but the most common violations of my rules for web site behavior are ads.
Who said anything about copyright infringement? These were trade secrets, which lose their value if other people obtain them. (Because cell phone providers would be unable to maintain control of their networks with the current design if people knew how to write OS software for phones.)
You probably really want to chat with the program director about what the class is supposed to be about; it could be anything from "how to use OSS for regular computing" to "how to start a successful OSS project".
I think it would be good to have a class on how to get involved with an OSS project. There are a number of things that are a bit unexpected if you're coming from an industry development background, such as:
People are really blunt. If you do something wrong, your work will be trashed in public by someone famous. If you do something right, you'll be thanked and credited. This isn't a reflection of their opinion of you or your skills; it's directed entirely at the particular patch. The same person on the same day may praise one of your patches and insult another. You'll even get people praising your idea, insulting your implementation, and applying their own version. Don't take any of it too seriously, and judge your value to the project only over a large amount of work.
People will ask you for stuff. It's okay to not do what they want. If you'd rather do something else, do it. Doing what they want is a good way of getting nice emails, though, and it's easy to feel guilty about not doing things.
You have to figure stuff out yourself. There probably won't be instructions on how to get up to speed on the project. You have to pick something you want to do, and figure out how to do it with a lot of reading code and trial and error. Projects generally don't know what to do with people who want to be helpful without a specific goal.
You don't need permission for anything. If you want to write something, just do it, and tell people you're doing it. If you think it's going to be controversial, announce it before you get very far, in case somebody has a good fundamental objection.
The biggest need is always documentation. The best documentation comes from people who try to use the program, have a problem, get it explained, and write up the solution. The second biggest need is always testing. The best testing comes from people who try to use the program and find that it's doing something definitely wrong. Developers almost always instinctively avoid doing things that don't work, and rarely hit those cases. There's often plenty of low-hanging fruit if you want to get involved just by running the program and fixing what comes up.
I think the main factor is likely to be that people are coming to expect that the little restaurant down the street will have their hours and phone number up on the web, and getting someone to put up a site with this info and enough matching design elements that people will know they're in the right place is becoming easy enough that people are doing it.
I've certainly noticed an increase in my ability to find purely informational web sites owned by and about small brick-and-morter businesses, and it makes sense, as more people start to prefer the web over the phone, that this would give an advantage in terms of customers tending to show up when the business is open and feeling confident when leaving the house that the business will be open.
Punting costs £14-16 per hour, which is a lot less than a database. Of course, I've got no idea what you'd use a database for while poling a boat around the river Cam.
Since this work was done in 1963, we can say with confidence that it led to great advances in communications and storage, and we're using them already. The Nobel Prize, especially in Physics, is entirely at the other end of the spectrum from a lot of the speculative stories on slashdot; it's often given in recognition of the lasting significance of work that's already made a difference.
Thinking of light as ambiguous between a wave and a particle is a bit misguided; it's neither a wave nor a particle, but something different which has properties in common with each, like how an SUV isn't exactly a car or a truck, but similar to each in some ways. You can think of the wave/particle duality experiments as proving that light is not an ordinary wave (because it can only be detected going through one gap), nor an ordinary particle (because it shows interference patterns). It is therefore a different type of thing, that we'd never seen before, whose rules had to be worked out. It's not that light sometimes acts like a wave and sometimes like a particle; light always acts in a consistent fashion, which has some features like waves, some like particles, and some unlike anything else.
He's not complaining about specs as a way of getting things to behave the same. He's talking about using hardware specs to base your software on. If you try to talk to your PCI hardware by following the PCI spec, chances are that it won't work, because a huge portion of PCI hardware doesn't quite work right. Someone had been saying that, in order to write a good SCSI driver, you should follow the guidelines in the SCSI spec, and Linus was saying that, if you did that, your results wouldn't work with a lot of real hardware that people use, and you won't be able to deal with these quirks, because you won't have designed your system to handle them.
It's not about the development model at all. The situation is that Linux has to work with third party devices, where the spec is like a contract that the other party hasn't signed. You can do your part to be perfectly compatible, but when the computer's BIOS tells you impossible things, you can't go yell at them, because they don't really care, and the user still wants the computer to work.
I personally wouldn't go on an airplane where the people designing it just trusted that parts perform the way the contracts specify. The most common area in engineering failures is to assume that, just because you say that something has to be done a certain way, it'll actually get done that way. I want my airplane designed such that, if a couple of the engines aren't aren't doing what the manufacturer claimed they'd do, the plane doesn't just crash. You have to expect that a certain amount of the stuff will misbehave, and the safety of your system really depends on just how much of it can misbehave before something terrible happens.
In short, if you're producing SCSI adaptors, you should understand the SCSI spec completely. But if you're writing a SCSI driver, you should have a copy of the spec, but also a big database of how particular hardware violates it, and notes on what parts are unreliable in practice, because there are certain to be a lot of these.
Copyright gives the owner the right to control distribution of the works, not just the right to benefit financially from it. There are a number of legitimate reasons that they might want to insist that someone get permission to distribute subway maps, even if they're not making any money on them anyway. For example, if they change the schedule or the routes, they'd want to know who distributes the maps, so that they can make sure old versions aren't being distributed. Of course, it leads to better PR if they actually give their reasons in the C&D letter, but legal departments tend not to be sufficiently savvy to bother.
It would be trivial. It wouldn't even have to be done by Microsoft; someone else could probably spend a weekend extracting the MS Office conversion support from OpenOffice.org and setting up a VB script to call it. Really, somebody ought to do that, just to mock Microsoft's claims. It would really mess up Microsoft's PR at this point if Massachusetts solicited a bid for an unmodified Office deployment for the contracts that Microsoft is claiming to be unfairly excluded from (with the Massachusetts handling the OpenDocument requirement itself).
The real problem is that the good guys play too fair. If the big media lobbies can get provisions into bills for things like the broadcast flag, why can't the other side get things in with the opposite effect? Just slip in an amendment requiring any station that uses a technological measure to restrict the use of content transmitted over the public airwaves to lose its license to the spectrum. Outlaw the sale of anything which includes technology that would block the recipient's right of first sale. There are plenty of measures which would effectively stop the **AA's ability to cause trouble, and it evidentally doesn't take much to get bills passed without general support.
The thread actually went in the other order. Linus said he was worried about Andrew burning out, and asked him how he was doing. Andrew said he's fine with his job, but that getting patches that don't work slows him down a lot. Then he said that there doesn't seem to be much queued for 2.6.15.
The reason for 2.6.15 being light isn't that everyone's using 2.4; 2.6.13 got so many changes that the changelog (since 2.6.12) was too big to send to the mailing list. My theory is that the latest change to the process (everything for 2.6.14 had to be ready two weeks after 2.6.13 came out) meant that everything close to ready got done in a hurry to meet that deadline, instead of slipping towards 2.6.15. There's also been focus on streamlining the process, which means that stuff goes through it faster, so the volume he's dealing with for a given throughput is lower.
Most likely, the process would change, because I don't think anyone else's style is quite the same. There's nothing that says patches have to go through -mm or any other particular catch-all development tree; it's just that, since -mm exists, it is expected that patches will go through it. Most likely, were Andrew to get hit by a bus, subsystem maintainers would solicit more testing of their trees and would send patches directly to Linus. Most likely, Linus would take over Andrew's role, and the maintainers of the -stable ("2.6.x.y") series would take over more of Linus's current role. But really, the informality of the process is important, because it allows people to respond to whatever actually happens, rather than trying to plan everything in advance. All of the people working on the kernel have particular roles that would need to be filled if they weren't doing them, and figuring out in advance who would fill all of them would take a lot of effort. And for most of them, it's impossible to tell what they're doing that's vital, and what's merely nice.
The real issue is that ordinary users of computers are expected to understand a lot of computer jargon, while ordinary citizens, humans, drivers, residents, and so forth can use plain language to get by. People are having trouble understanding that 10 gigabytes is really large, and 10 kilobytes is pretty small, but they don't try to buy a $10B car instead of a $10K car. They don't consider disabling their amygdala, while they do consider disabling their firewall. You don't have to know which color wire is hot and which is neutral to turn on a light switch. If I'm writing a book, I don't need to know what "widows" and "orphans" are to have my book come out nicely; but I'm using Word, my documents are hard to read if I don't know this jargon.
I think the main ugly thing about it is that the banner image with the slashdot logo appears now. (Rather than a version that isn't trying to match a different background, or something of the sort)
On the other hand, if you tell Firefox (at least some versions) to use the colors you've configured, you get an interesting look. I think the main weird thing then is that it puts black boxes around everything.
You clearly haven't read the "CxO" portion of the MAINTAINERS file. Around 2.5.70, half of the patches getting applied were around there. Linux has a huge advantage over Microsoft here, because Sarbanes-Oxley doesn't apply, and Jeff Garzik and Greg Kroah-Hartman can, between them, hold most of the titles.
He's not whining that it's hard. He's whining that it's impossible, because the tests don't match the either the standards or common practice. He's whining that distros must be somehow faking compliance, because they ship *his software* which doesn't "pass" the buggy tests.
His argument is: no set of Linux software could pass the LSB suite by actually consistantly giving the desired results, because there's no libc that consistantly gives those results (when run on sufficiently fast hardware to expose the bugs in the tests, for example); yet distros do claim to pass the suite; therefore, the LSB is not ensuring compatibility, because it certifies things that don't work by their rules.
Furthermore, he argues that programs that don't work tend not to work because they rely on undefined behavior. Certifying that the environment behaves in accordance with the standard doesn't help, because the software developer's environment and the user's environment may do different things in some cases, while both comply with the standard. Unless the programs are tested for doing non-standard things, they won't necessarily work. And the undefined behavior is undefined for a reason: you can't improve the system without changing it (especially when the thing not defined is which takes longer: executing a certain function or waiting.001 seconds). And the same cases are particularly hard to test programs' assumptions about.
The sections that you dismiss as whining are actually providing examples, which is important in engineering (or science). There are theoretical flaws in any process; it is always important to know whether those situations ever actually occur. If he didn't have an example of a program relying on undefined behavior which should vary between systems, one could say that nobody would actually write code like that and think that it worked; but it turns out that people actually do write such code, and these people happen to include the people writing LSB tests, which is why they're flawed tests.
GIMP isn't a clone of anything; the developers pretty firmly do their own thing and work on improving the application. This story is actually an endorsement of this approach. The GIMP developers didn't waste any effort on chasing Photoshop, and then some random TV producer takes care of the Photoshop UI. From this example, you could guess that, if you've got any developers working on the UI, you're wasting effort; that job should be done by a user with limited programming experience. (For that matter, he was probably better situated to do the redesign than any of the developers, who aren't likely to be heavy users of Photoshop.)
For that matter, Linspire seems to me like a bunch of non-programmers who configure Linux to match Windows. It's unlikely that they'd be helpful working on applications.
Also note that Scott and Asa talk back and forth in the comments on that page. I look forward to Scott getting fed up with trying to describe how things should be and just writing an extension, and then joining the project. He claims he doesn't have enough time, but I bet this is going to bother him until he actually does it...
I haven't looked at the details yet, but I think you're supposed to be able to affect compilation using annotations, and you can certainly have tools post-process class files using annotations. What that means is that you can have a "production build" which strips out everything annotated with the JUnit annotations, and have your tests actually in the class they're testing, but have them not end up in the final application. Then it's easy to find the tests for a class (they're in the same class) and the tests can even peek at private fields, which is really nice, because sometimes you don't want subclasses messing with some of the fields you want to test.
You've got a weird pencil if it's 1.1 cm thick. Pencils are generally about.7 cm thick surface-to-surface (which is what they're talking about) and.8 cm thick edge-to-edge. Also, I'm a bit suspicious of your half-ounce quarters; they're supposed to be.2 oz.
Well, he's in the process of getting it into the kernel; looks moderately unlikely for 2.6.14 (which has closed already for some purposes), but likely for 2.6.15, as there seems to be agreement on what will be suitable at that stage. Reaching the necessary agreement on what should go in, however, has taken a while due to all of the flaming and lack of communication.
There are a number of cases where a trivial disagreement and misunderstanding prevented progress for a while, until the thread died out and the issue got brought up in a different way. E.g., Reiser4 is full of asserts that weren't considered suitable for inclusion; Hans fought long and hard for having asserts, but having them is a standard kernel practice. The issues were just that the code used messages that weren't meaningful to anybody else, didn't use the kernel's standard assert mechanism, rebooted the computer when there were problems with only one filesystem, and duplicated checks for conditions automatically caught (such as dereferencing a NULL pointer). Getting this clear to everybody took a while, involving a digression about Christoph Hellwig's haircut and much delay.
MA isn't going to switch to OpenOffice unless Microsoft forces them to. If MA goes forward with their plans, MS will almost certainly add support to MS Office for OpenDocument. It's not like it's difficult; multiple people have already written MS/OpenDocument converters even without MS's internal documentation. They're only making it sound like MS Office can't support other formats now because they'd rather it didn't. Faced with people actually defecting, they'd change their story.
As for filing taxes online, you've never been able to read a MA tax form in a Microsoft format; it's all PDF, which MA intends to keep using. Filing forms online is done through one of a number of commercial services, which will deal with whatever format MA wants them in. Forms you can fill out on your computer, print out, and mail in are exclusively in PDF (because that makes the form part reliably identical regardless of where it gets printed out).
By the time the army moves in, whoever they're fighting doesn't have any runways for a jet to take off from, and probably no aircraft either (because the US isn't going to try to move ground troops under enemy aircraft; air-to-ground is just too effective these days). The bigger danger is surface-to-air. But really, this is likely to mostly replace moving stuff in by helicopter, and helicopters aren't that tough or fast either, and have the habit of crashing even when they haven't been shot, so it's a win all around.
Slashdot Mirror
You've clearly not watched Windows users use Windows. There's a lot of fumbling that even people who know what they're doing go through, just because a lot of the interactions are difficult to do.
What he seems to me to be saying is that Microsoft formats have, at least traditionally, been tied to the behavior of the application, rather than being defined in terms of what the document is supposed to be about. This means that, if you're trying to do something very much unlike what the original application was supposed to do, the Microsoft format may be problematic, in terms of lacking information you want or requiring information you don't have. I have no idea if OpenDocument actually has any particular benefits due to this focus, but that's at least what he's talking about.
The xforms integration is a good idea in this direction, in any case; it means that you can have a document which is simultaneously a word processing document (that can be printed out like normal) and a machine-readable form (that can be reliably imported into a database, because it's actually storing the form structure and information about each field's value explicitly, rather than just storing a word processing document which looks like a filled-out form. This means that it's really easy to handle forms (verify that the form in the document is the form you sent out; read and validate the field values), rather than needing to try to understand the layout of the document and figure out how to parse the thing the way that the person expected it to be interpreted.
I block Flash (actually, I keep the plugin not installed) and only let animations run once. As much as possible, I block anything that creates new windows or changes window size or decorations. If I could, I'd block anything that places anything over text. I'd also like to block mouseover.
In all of these cases, the worst abuses I've seen aren't ads, but the most common violations of my rules for web site behavior are ads.
Who said anything about copyright infringement? These were trade secrets, which lose their value if other people obtain them. (Because cell phone providers would be unable to maintain control of their networks with the current design if people knew how to write OS software for phones.)
You probably really want to chat with the program director about what the class is supposed to be about; it could be anything from "how to use OSS for regular computing" to "how to start a successful OSS project".
I think it would be good to have a class on how to get involved with an OSS project. There are a number of things that are a bit unexpected if you're coming from an industry development background, such as:
People are really blunt. If you do something wrong, your work will be trashed in public by someone famous. If you do something right, you'll be thanked and credited. This isn't a reflection of their opinion of you or your skills; it's directed entirely at the particular patch. The same person on the same day may praise one of your patches and insult another. You'll even get people praising your idea, insulting your implementation, and applying their own version. Don't take any of it too seriously, and judge your value to the project only over a large amount of work.
People will ask you for stuff. It's okay to not do what they want. If you'd rather do something else, do it. Doing what they want is a good way of getting nice emails, though, and it's easy to feel guilty about not doing things.
You have to figure stuff out yourself. There probably won't be instructions on how to get up to speed on the project. You have to pick something you want to do, and figure out how to do it with a lot of reading code and trial and error. Projects generally don't know what to do with people who want to be helpful without a specific goal.
You don't need permission for anything. If you want to write something, just do it, and tell people you're doing it. If you think it's going to be controversial, announce it before you get very far, in case somebody has a good fundamental objection.
The biggest need is always documentation. The best documentation comes from people who try to use the program, have a problem, get it explained, and write up the solution. The second biggest need is always testing. The best testing comes from people who try to use the program and find that it's doing something definitely wrong. Developers almost always instinctively avoid doing things that don't work, and rarely hit those cases. There's often plenty of low-hanging fruit if you want to get involved just by running the program and fixing what comes up.
I think the main factor is likely to be that people are coming to expect that the little restaurant down the street will have their hours and phone number up on the web, and getting someone to put up a site with this info and enough matching design elements that people will know they're in the right place is becoming easy enough that people are doing it.
I've certainly noticed an increase in my ability to find purely informational web sites owned by and about small brick-and-morter businesses, and it makes sense, as more people start to prefer the web over the phone, that this would give an advantage in terms of customers tending to show up when the business is open and feeling confident when leaving the house that the business will be open.
Punting costs £14-16 per hour, which is a lot less than a database. Of course, I've got no idea what you'd use a database for while poling a boat around the river Cam.
Since this work was done in 1963, we can say with confidence that it led to great advances in communications and storage, and we're using them already. The Nobel Prize, especially in Physics, is entirely at the other end of the spectrum from a lot of the speculative stories on slashdot; it's often given in recognition of the lasting significance of work that's already made a difference.
Thinking of light as ambiguous between a wave and a particle is a bit misguided; it's neither a wave nor a particle, but something different which has properties in common with each, like how an SUV isn't exactly a car or a truck, but similar to each in some ways. You can think of the wave/particle duality experiments as proving that light is not an ordinary wave (because it can only be detected going through one gap), nor an ordinary particle (because it shows interference patterns). It is therefore a different type of thing, that we'd never seen before, whose rules had to be worked out. It's not that light sometimes acts like a wave and sometimes like a particle; light always acts in a consistent fashion, which has some features like waves, some like particles, and some unlike anything else.
He's not complaining about specs as a way of getting things to behave the same. He's talking about using hardware specs to base your software on. If you try to talk to your PCI hardware by following the PCI spec, chances are that it won't work, because a huge portion of PCI hardware doesn't quite work right. Someone had been saying that, in order to write a good SCSI driver, you should follow the guidelines in the SCSI spec, and Linus was saying that, if you did that, your results wouldn't work with a lot of real hardware that people use, and you won't be able to deal with these quirks, because you won't have designed your system to handle them.
It's not about the development model at all. The situation is that Linux has to work with third party devices, where the spec is like a contract that the other party hasn't signed. You can do your part to be perfectly compatible, but when the computer's BIOS tells you impossible things, you can't go yell at them, because they don't really care, and the user still wants the computer to work.
I personally wouldn't go on an airplane where the people designing it just trusted that parts perform the way the contracts specify. The most common area in engineering failures is to assume that, just because you say that something has to be done a certain way, it'll actually get done that way. I want my airplane designed such that, if a couple of the engines aren't aren't doing what the manufacturer claimed they'd do, the plane doesn't just crash. You have to expect that a certain amount of the stuff will misbehave, and the safety of your system really depends on just how much of it can misbehave before something terrible happens.
In short, if you're producing SCSI adaptors, you should understand the SCSI spec completely. But if you're writing a SCSI driver, you should have a copy of the spec, but also a big database of how particular hardware violates it, and notes on what parts are unreliable in practice, because there are certain to be a lot of these.
Copyright gives the owner the right to control distribution of the works, not just the right to benefit financially from it. There are a number of legitimate reasons that they might want to insist that someone get permission to distribute subway maps, even if they're not making any money on them anyway. For example, if they change the schedule or the routes, they'd want to know who distributes the maps, so that they can make sure old versions aren't being distributed. Of course, it leads to better PR if they actually give their reasons in the C&D letter, but legal departments tend not to be sufficiently savvy to bother.
It would be trivial. It wouldn't even have to be done by Microsoft; someone else could probably spend a weekend extracting the MS Office conversion support from OpenOffice.org and setting up a VB script to call it. Really, somebody ought to do that, just to mock Microsoft's claims. It would really mess up Microsoft's PR at this point if Massachusetts solicited a bid for an unmodified Office deployment for the contracts that Microsoft is claiming to be unfairly excluded from (with the Massachusetts handling the OpenDocument requirement itself).
The real problem is that the good guys play too fair. If the big media lobbies can get provisions into bills for things like the broadcast flag, why can't the other side get things in with the opposite effect? Just slip in an amendment requiring any station that uses a technological measure to restrict the use of content transmitted over the public airwaves to lose its license to the spectrum. Outlaw the sale of anything which includes technology that would block the recipient's right of first sale. There are plenty of measures which would effectively stop the **AA's ability to cause trouble, and it evidentally doesn't take much to get bills passed without general support.
The thread actually went in the other order. Linus said he was worried about Andrew burning out, and asked him how he was doing. Andrew said he's fine with his job, but that getting patches that don't work slows him down a lot. Then he said that there doesn't seem to be much queued for 2.6.15.
The reason for 2.6.15 being light isn't that everyone's using 2.4; 2.6.13 got so many changes that the changelog (since 2.6.12) was too big to send to the mailing list. My theory is that the latest change to the process (everything for 2.6.14 had to be ready two weeks after 2.6.13 came out) meant that everything close to ready got done in a hurry to meet that deadline, instead of slipping towards 2.6.15. There's also been focus on streamlining the process, which means that stuff goes through it faster, so the volume he's dealing with for a given throughput is lower.
Most likely, the process would change, because I don't think anyone else's style is quite the same. There's nothing that says patches have to go through -mm or any other particular catch-all development tree; it's just that, since -mm exists, it is expected that patches will go through it. Most likely, were Andrew to get hit by a bus, subsystem maintainers would solicit more testing of their trees and would send patches directly to Linus. Most likely, Linus would take over Andrew's role, and the maintainers of the -stable ("2.6.x.y") series would take over more of Linus's current role. But really, the informality of the process is important, because it allows people to respond to whatever actually happens, rather than trying to plan everything in advance. All of the people working on the kernel have particular roles that would need to be filled if they weren't doing them, and figuring out in advance who would fill all of them would take a lot of effort. And for most of them, it's impossible to tell what they're doing that's vital, and what's merely nice.
The real issue is that ordinary users of computers are expected to understand a lot of computer jargon, while ordinary citizens, humans, drivers, residents, and so forth can use plain language to get by. People are having trouble understanding that 10 gigabytes is really large, and 10 kilobytes is pretty small, but they don't try to buy a $10B car instead of a $10K car. They don't consider disabling their amygdala, while they do consider disabling their firewall. You don't have to know which color wire is hot and which is neutral to turn on a light switch. If I'm writing a book, I don't need to know what "widows" and "orphans" are to have my book come out nicely; but I'm using Word, my documents are hard to read if I don't know this jargon.
I think the main ugly thing about it is that the banner image with the slashdot logo appears now. (Rather than a version that isn't trying to match a different background, or something of the sort)
On the other hand, if you tell Firefox (at least some versions) to use the colors you've configured, you get an interesting look. I think the main weird thing then is that it puts black boxes around everything.
You clearly haven't read the "CxO" portion of the MAINTAINERS file. Around 2.5.70, half of the patches getting applied were around there. Linux has a huge advantage over Microsoft here, because Sarbanes-Oxley doesn't apply, and Jeff Garzik and Greg Kroah-Hartman can, between them, hold most of the titles.
He's not whining that it's hard. He's whining that it's impossible, because the tests don't match the either the standards or common practice. He's whining that distros must be somehow faking compliance, because they ship *his software* which doesn't "pass" the buggy tests.
.001 seconds). And the same cases are particularly hard to test programs' assumptions about.
His argument is: no set of Linux software could pass the LSB suite by actually consistantly giving the desired results, because there's no libc that consistantly gives those results (when run on sufficiently fast hardware to expose the bugs in the tests, for example); yet distros do claim to pass the suite; therefore, the LSB is not ensuring compatibility, because it certifies things that don't work by their rules.
Furthermore, he argues that programs that don't work tend not to work because they rely on undefined behavior. Certifying that the environment behaves in accordance with the standard doesn't help, because the software developer's environment and the user's environment may do different things in some cases, while both comply with the standard. Unless the programs are tested for doing non-standard things, they won't necessarily work. And the undefined behavior is undefined for a reason: you can't improve the system without changing it (especially when the thing not defined is which takes longer: executing a certain function or waiting
The sections that you dismiss as whining are actually providing examples, which is important in engineering (or science). There are theoretical flaws in any process; it is always important to know whether those situations ever actually occur. If he didn't have an example of a program relying on undefined behavior which should vary between systems, one could say that nobody would actually write code like that and think that it worked; but it turns out that people actually do write such code, and these people happen to include the people writing LSB tests, which is why they're flawed tests.
GIMP isn't a clone of anything; the developers pretty firmly do their own thing and work on improving the application. This story is actually an endorsement of this approach. The GIMP developers didn't waste any effort on chasing Photoshop, and then some random TV producer takes care of the Photoshop UI. From this example, you could guess that, if you've got any developers working on the UI, you're wasting effort; that job should be done by a user with limited programming experience. (For that matter, he was probably better situated to do the redesign than any of the developers, who aren't likely to be heavy users of Photoshop.)
For that matter, Linspire seems to me like a bunch of non-programmers who configure Linux to match Windows. It's unlikely that they'd be helpful working on applications.
Also note that Scott and Asa talk back and forth in the comments on that page. I look forward to Scott getting fed up with trying to describe how things should be and just writing an extension, and then joining the project. He claims he doesn't have enough time, but I bet this is going to bother him until he actually does it...
I haven't looked at the details yet, but I think you're supposed to be able to affect compilation using annotations, and you can certainly have tools post-process class files using annotations. What that means is that you can have a "production build" which strips out everything annotated with the JUnit annotations, and have your tests actually in the class they're testing, but have them not end up in the final application. Then it's easy to find the tests for a class (they're in the same class) and the tests can even peek at private fields, which is really nice, because sometimes you don't want subclasses messing with some of the fields you want to test.
You've got a weird pencil if it's 1.1 cm thick. Pencils are generally about .7 cm thick surface-to-surface (which is what they're talking about) and .8 cm thick edge-to-edge. .2 oz.
Also, I'm a bit suspicious of your half-ounce quarters; they're supposed to be
Well, he's in the process of getting it into the kernel; looks moderately unlikely for 2.6.14 (which has closed already for some purposes), but likely for 2.6.15, as there seems to be agreement on what will be suitable at that stage. Reaching the necessary agreement on what should go in, however, has taken a while due to all of the flaming and lack of communication.
There are a number of cases where a trivial disagreement and misunderstanding prevented progress for a while, until the thread died out and the issue got brought up in a different way. E.g., Reiser4 is full of asserts that weren't considered suitable for inclusion; Hans fought long and hard for having asserts, but having them is a standard kernel practice. The issues were just that the code used messages that weren't meaningful to anybody else, didn't use the kernel's standard assert mechanism, rebooted the computer when there were problems with only one filesystem, and duplicated checks for conditions automatically caught (such as dereferencing a NULL pointer). Getting this clear to everybody took a while, involving a digression about Christoph Hellwig's haircut and much delay.
MA isn't going to switch to OpenOffice unless Microsoft forces them to. If MA goes forward with their plans, MS will almost certainly add support to MS Office for OpenDocument. It's not like it's difficult; multiple people have already written MS/OpenDocument converters even without MS's internal documentation. They're only making it sound like MS Office can't support other formats now because they'd rather it didn't. Faced with people actually defecting, they'd change their story.
As for filing taxes online, you've never been able to read a MA tax form in a Microsoft format; it's all PDF, which MA intends to keep using. Filing forms online is done through one of a number of commercial services, which will deal with whatever format MA wants them in. Forms you can fill out on your computer, print out, and mail in are exclusively in PDF (because that makes the form part reliably identical regardless of where it gets printed out).
By the time the army moves in, whoever they're fighting doesn't have any runways for a jet to take off from, and probably no aircraft either (because the US isn't going to try to move ground troops under enemy aircraft; air-to-ground is just too effective these days). The bigger danger is surface-to-air. But really, this is likely to mostly replace moving stuff in by helicopter, and helicopters aren't that tough or fast either, and have the habit of crashing even when they haven't been shot, so it's a win all around.