Re:The ABCs of Google Complete
on
Google Suggest
·
· Score: 1
People are clearly incompetent. The pages you want for amazon, bestbuy, cnn, ebay, firefox, hotmail, ikea, kazaa, mapquest, ups, verizon, yahoo, and xbox are all http://www.(name).com. Reasonable pages for dictionary and weather are the same.
There's something especially funny about people searching for yahoo on google.
Re:I call foul: CENSORSHIP
on
Google Suggest
·
· Score: 1
Millions of people do type "sex" with one hand. Even people with both hands on the keyboard or typing with only their index fingers tends to use the same hand for 'e', 's', and 'x'.
Now, in addition to the rumored flash-based iPod, they can have a Flash-based iPod and a flash-based Flash-based iPod. Then you can listen to it in your car while you look at your HDD-based HD-HUD using CSS-protected CSS to generate CSS for the pages.
I think it would be helpful to have it record when you talk to yourself, so that, instead of retyping it the way you settle on, you can just rearrange the text that's already available. I think a system where you would generate text from speech in a temporary buffer while you control the program and edit the text with the keyboard would be good. Also, it would be nice to be able to speak while offline and then edit the text into your document while sitting at the computer. This would be really nice for taking notes on papers in a cafe.
The entity conspicuously absent in the press release is the OpenOffice.org team. The real news is that a Swahili translation of the software was created without taking any resources away from the development of the project. This was a separate effort, done by a group of consultants and academics and funded by an organization that funds this sort of thing. OpenOffice.org software development couldn't have gotten that funding, nor would the people who worked on this been particularly useful working on the project.
As for the importance of this, there are 70 million native speakers of Swahili, and Swahili is the trade language of East Africa, meaning that the 25 million most-regionally-connected people talk to each other in a language that Microsoft doesn't support, but OO.o does.
A good engineer actually does relatively little production of code; the real work is in arranging the problem such that the correct solution is intuitively obvious. Once you can explain exactly how it works, you can write good code. The real role of a technical writer is to be a novice to the code and ask about all the things that experienced people take for granted.
As for communication, there's a big difference between having errors such as "as log as", "thier", and "mis-communication" and making the text unclear. In the example:
"hI KATHY i am sending u the assignmnet again," one student wrote to her recently. "i had sent you the assignment earlier but i didnt get a respond. If u get this assgnment could u please respond . thanking u for ur cooperation."
I cringed at the writing, but the only thing that is at all ambiguous is the original punctuation of the first sentence, where the author of the article, following many style manuals[1], puts a comma inside the quotes which was (probably) not in the source. The same is true of:
"i need help," said the message, which was devoid of punctuation. "i am writing a essay on writing i work for this company and my boss want me to help improve the workers writing skills can yall help me with some information thank you".
except that the author of the article helpfully mentions that the source didn't contain that comma.
In the other examples, on the other hand, it is hard to tell what the author meant, which is really the problem. What does "(they in Barry file)" mean? This is a message that is likely to be misleading to anyone who actually needed the information from it. The issue is not so much the grammatical errors but the vagueness; "I updated the status report for the four discrepancies Lennie forwarded us via e-mail, which are in Barry's file" would not actually improve the email substantially, because we still don't know whether Barry's file contains the problematic portion of the status report or the reports of the problems, and Barry probably has more than one file. Having the language error-free just makes it harder to tell that you didn't actually understand the point.
The point is really effective communication and not grammar compliance. Most writing could be corrected, but if all recipients read it the way the author intended (I read over every e-mail I write before I click send and ask "Do I sound lucid and professional, and do I actually communicate my idea well?"), there's no need to actually do it.
[1] The latest versions of many style manuals actually support putting the surrounding sentence's punctuation outside in cases where the punctuation is important to the quoted material.
As far as I know, the idea that that comma is not necessary comes from misreading Strunk & White's unclear explanation ("In a series of three or more terms with a single conjunction, use a comma after each term except the last"), where "the last" is the one after the "and", not the last one before it. The comma is omitted if there are no commas ("this and that") and in certain idioms ("Foo, Bar and Company"); proper names get whatever punctuation they want. In general, follow the principle that it is better to make a supposed grammatical error than produce something which could be misinterpreted; including the comma is much less likely to cause confusion than omitting it.
If you get a physical copy, try to get a German edition. The tiles in the American edition are less brightly colored, less distinctive, and don't look as much like the things they produce. Of course, the rules and cards are in German, but you already know how to play, so that shouldn't be an issue.
I prefer the interpretation that Einstein had actually forgotten how to do the sort of math that shows up on high school assignments, because it wasn't practical for his needs. As such, it's a statement about how math isn't a single track with progressively more difficult things, but a collection of skills, and someone who has problems with some of the nominally basic parts of it might be the leading expert in some more abstract part. Anyone who's tried to split a restaurant check with math majors can attest that this is true. A CS-focused math prof may very well only be able to tell you how to get Mathematica to solve your problem, not how to do it in a way that will get you homework credit.
The next step is to prohibit putting content over other content, and putting a little banner at the top of the window that tells you that the site tried to put something over something else, and to click on a browser button to let it if you want to. Then advertizers will find that Firefox users don't click on their ads, because their ads are stuck somewhere out of the way, due to not fitting anywhere in the layout of the page.
I have yet to see a case in which the user and the page author actually want content to appear over other content. I can imagine an exception, where there's stuff covering hints on a page, and you can uncover each hint if you decide you need it. But I don't think CSS is quite reliable enough to make that technique a good idea, at least so far (I think black-on-black text that you can highlight is the most reliable and common currently).
Back in the Napster days, when the RIAA's target was a company getting rich on file-sharing and not individual fans, Don Henley was against it. He's gotten less sympathetic towards the RIAA as their activities have gotten less defensible.
In the programming environment I use, the close brace is highlighted in bright pink to indicate that something's probably wrong. Also, the ", i}" is in blue to indicate that it is still part of a string constant. If I actually try to compile the code despite the editor telling me exactly what the compiler will think of the code, I get 'temp.c:6:38: missing terminating " character', which is quite explanitory and is undoubtedly true (unlike your message; I often put single quotes around things inside double-quoted strings to mark the edges of a value).
I only get an uninformative message on the next line, when the compiler determines that it is completely lost, but I know to resolve the clear error messages before working on the ones I don't understand.
(This is with emacs and gcc; I don't know if less mature IDEs still give bad feedback).
In fact, giving helpful error messages is a highly tricky art. You need a good understanding of what people will actually try to write and of what mistakes people make. For the first five years or so, meaningful compiler error messages are generally misleading more often than helpful, because they reflect a misunderstanding of the user's intent. Sun's javac is just recently getting to the point where it tells you useful things about mistakes in using the original language.
The point of this is not actually to have a single sign-on everywhere, like Passport tried to do. The point of this is to have a transitive sign-on, where you can sign-on to a starting web site, and have that web site provide the information you gave it to other sites of your choice. If you're a slashdot user, you could post to groklaw as a slashdot user when you follow a link from slashdot, whether or not you have a groklaw account, and groklaw could verify that you are the slashdot user you claim to be.
Their example has a person having a session with an airline company (not Microsoft or Sun or some identity company) and using that session to make reservations at other sites for the same trip.
The argument is that (1) software which is not tested under actual conditions is going to be buggier than software tested under actual conditions, and (2) voting software is never tested under actual conditions, because a complete and full-scale mock election is too expensive to run and people are unwilling to do full recounts everywhere after a real election to try to identify bugs.
The same arguments apply to any software which is only used in unusal circumstances, and such software is generally unreliable. It's possible that voting software is actually worse than, say, power grid emergency response software due to liability on the latter, but probably not by much, because if you can't test something, it doesn't matter how liable you are for failures; you do the best you can, but, by definition, no better.
Of course, in the case of voting software, there's a easy solution: have the official result come from a tally of paper ballots which the voters check for accuracy before depositing, and only the quick result come from the software. The first year, the software will probably still be buggy, and the result may be corrected, but the software will get fixed and future elections will be unlikely to get reversed after the election-night tally.
I'm not sure why he thinks that objects fabricated by consumers will be flimsy and low-quality. Most likely, a process which actually placed atoms individually would default to making everything out of diamond, just because it's simple. Laser-cutters work nicely on hard plastics, and don't really work on the flimsy stuff just because you're actually carving the thing out of a solid block that has to not wobble while you cut it. It's only easier to make wimpy items than strong ones if you're using a melting technque (vacuum=forming or injection-molding), while then requires that you have a physical mold that you're using, which isn't going to be a "download-and-fabricate" process. It'll actually probably be much more difficult to make soft items than hard ones.
It's only "next" because, while the RIAA was always worried about copying, and the MPAA was worried about bandwidth going up, the TVA has just been thinking about the same dam thing they always did. The owners of shows sell content to stations; stations sell time to advertizers, and send the combination to viewers whether or not they're watching. The fact that anyone can get a copy of a show for their own viewing doesn't make it harder for the owner to sell to stations, and the stations only care whether you're watching them or not, not what else you might be doing if you're not watching them.
In fact, assuming that people are downloading TV shows over the internet a lot, it is in the interests of the owners of shows to cover this fact up rather than publicizing it and doing something about it, because they don't want to send the message to stations and advertizers that people don't watch shows.
There are two results of working on projects: understanding of the project and the project itself. Understanding of the project is only generated while not consciously working on anything. If you're working too long hours, you lose this part. You can only write good code with understanding of what you're doing. So working long hours is fine at the end of a project, when you already understand it, and can work on it until it's done with just what you already know (and forgetting how you debugged stuff doesn't matter too much), but it will kill your productivity if you do it earlier in the project or for anything involving design.
If you work 14 hour days all the time (as opposed to just during crunch time), you're only spending about 2 hours a day on improving your insight into the project. You're probably writing good code for half an hour each day and writing junk for 13 and a half hours.
Yesterday, I worked for 3 hours trying to fix a bug, and didn't get anywhere. Then I gave up and went home. During my half-hour commute, I realized what must be happening and solved it in 5 minutes upon getting home. I'd probably have solved it in another 3 hours had I stayed at work, but I actually was done sooner because I didn't work too late.
According to your link, it is used to indicate that a non-standard spelling (or other error) is intended, but it is not an acronym and it comes from the Latin word (in the sense that the editor intends the text to read "just so"). In fact, the slashdot article which misspells "sic" is using it when quoting an error in grammar, not spelling.
And the basic principle of the internet is "be strict in what you generate and lenient in what you accept". IE does what is, in some ways, a better job of this (of course, it also tends to fail to prohibit a lot of the things it should process and then deny). A browser should not obscure any text on the page unless the specification specifically requires that the text be obscured. Any page which is not standard html should be forced by the browser to render so it's readable, not allowed to be unreadable.
As far as I can tell, slashdot is not using standard html that IE doesn't support to make a page that is supposed to render badly. It's failing to obey the standards, and firefox is showing something mangled. (Or so I hear; I read slashdot in "lite" mode, which removes most of the badly broken stuff along with the space-wasting stuff)
Really, the W3C ought to provide a guide for what to do with non-compliant HTML, not as a specification of how you handle HTML, but as a specification of how web browsers should behave towards users. Having buffer overflows parsing malformed HTML should not be compliant behavior on the browser's part (but this shouldn't need the W3C's input); similarly, the browser shouldn't place text outside the window, under images, under other text, etc., and the W3C should define this sort of constraint.
I have nothing against IDEs with special (e.g., graphical) support for specialized source formats; the issue is when the IDE generates code in some other language directly without a step involving a non-generated format you can version control. (Personally, I mainly avoid IDEs because they always seem to have keyboard shortcuts that are malicious to people accustomed to using Emacs the way I do, which involves moving text around with C-k/C-y; but this means that I insist on only using things that can be done outside of the IDE).
When you save your guis as.ui files and turn them into.cpp files, you don't then start editing the.cpp file and consider it the source of your project. So you just have another stage in your compile, and it doesn't actually matter that the intermediate step in also code that you could have written.
If Linus gets hit by a bus, probably Alan Cox would take over, because he's pretty easy to get to agree to do things. Alternatively, Marcelo could take over 2.6 and work with Andrew Morton on it.
What happens today when large factions of kernel developers disagree with Linus is that they share their patches with each other. The offical development series (-mm), where most debugging gets done, has included kgdb for ages. Especially with things that aren't important to end users, there's no need to convince Linus in order to have something in common use.
The thing that really makes Linux development work is that it's not done by committee, and it's not really done with a single authority. Everybody who's working on it really does have their own version, and they're just close enough together that they can trade their work back and forth. In fact, the point of the new development process (i.e., trying not to fork 2.7) is to have all of the trees with current development stay close enough that stuff is shared throughout, rather than splitting into 2.6 and 2.8 regions with slow transit between them.
I can't think of any project which is run as effectively as Linux in terms of getting changes from concept to patch to testing to official while simultaneously keeping out things which are not ready for general use and making them available to people who want them anyway. For example, the process of making Linux suitable for audio editting (which requires some processes to have predictably low latency) is still in progress, because the current versions mess up performance on other systems, have maintainability issues, etc. But people who want to actually do audio editting with Linux just use a tree that has the current version of these changes, rather than Linus's kernel. As the changes get reworked to be suitable for general inclusion, the patches get smaller, and the mainline will eventually have the necessary characteristics.
The thing is that, previously, each increase in abstraction was either done by writing in a higher-level language or by using a nicer library in the same language. IDEs, on the other hand, move from writing code in any language to carrying out an IDE-specific process which generates a chunk of code which is then part of the project without anyone having written it.
The real solution isn't IDEs. It's adding language features that let you write the code more simply without a lot of boilerplate, and APIs which are easier to use. Really, the standard compiler should deal with the plumbing and there should never be any blanks which need to be filled in with information an IDE could supply. Doing these tasks with an IDE just hurts repeatability.
On the other hand, the rest of the things on your list are good: having a system which processes the project such that your tools are acting with a complete understanding of the code helps a whole lot.
Have you reported the crashes? There will never be a kernel version that fixes bugs that haven't been reported. If each kernel version you tried was broken in some entirely different way, then having the developers working on a different branch might actually improve your stability. But chances are that you're seeing something that nobody's known to fix. If you test the latest kernel for a little while, and report to the linux kernel mailing list what it does when it crashes, your.config, and your boot messages, someone will probably personally resolve your problem.
Slashdot Mirror
People are clearly incompetent. The pages you want for amazon, bestbuy, cnn, ebay, firefox, hotmail, ikea, kazaa, mapquest, ups, verizon, yahoo, and xbox are all http://www.(name).com. Reasonable pages for dictionary and weather are the same.
There's something especially funny about people searching for yahoo on google.
Millions of people do type "sex" with one hand. Even people with both hands on the keyboard or typing with only their index fingers tends to use the same hand for 'e', 's', and 'x'.
Now, in addition to the rumored flash-based iPod, they can have a Flash-based iPod and a flash-based Flash-based iPod. Then you can listen to it in your car while you look at your HDD-based HD-HUD using CSS-protected CSS to generate CSS for the pages.
I think it would be helpful to have it record when you talk to yourself, so that, instead of retyping it the way you settle on, you can just rearrange the text that's already available. I think a system where you would generate text from speech in a temporary buffer while you control the program and edit the text with the keyboard would be good. Also, it would be nice to be able to speak while offline and then edit the text into your document while sitting at the computer. This would be really nice for taking notes on papers in a cafe.
The entity conspicuously absent in the press release is the OpenOffice.org team. The real news is that a Swahili translation of the software was created without taking any resources away from the development of the project. This was a separate effort, done by a group of consultants and academics and funded by an organization that funds this sort of thing. OpenOffice.org software development couldn't have gotten that funding, nor would the people who worked on this been particularly useful working on the project.
As for the importance of this, there are 70 million native speakers of Swahili, and Swahili is the trade language of East Africa, meaning that the 25 million most-regionally-connected people talk to each other in a language that Microsoft doesn't support, but OO.o does.
As for communication, there's a big difference between having errors such as "as log as", "thier", and "mis-communication" and making the text unclear. In the example:
I cringed at the writing, but the only thing that is at all ambiguous is the original punctuation of the first sentence, where the author of the article, following many style manuals[1], puts a comma inside the quotes which was (probably) not in the source. The same is true of:
except that the author of the article helpfully mentions that the source didn't contain that comma.
In the other examples, on the other hand, it is hard to tell what the author meant, which is really the problem. What does "(they in Barry file)" mean? This is a message that is likely to be misleading to anyone who actually needed the information from it. The issue is not so much the grammatical errors but the vagueness; "I updated the status report for the four discrepancies Lennie forwarded us via e-mail, which are in Barry's file" would not actually improve the email substantially, because we still don't know whether Barry's file contains the problematic portion of the status report or the reports of the problems, and Barry probably has more than one file. Having the language error-free just makes it harder to tell that you didn't actually understand the point.
The point is really effective communication and not grammar compliance. Most writing could be corrected, but if all recipients read it the way the author intended (I read over every e-mail I write before I click send and ask "Do I sound lucid and professional, and do I actually communicate my idea well?"), there's no need to actually do it.
[1] The latest versions of many style manuals actually support putting the surrounding sentence's punctuation outside in cases where the punctuation is important to the quoted material.
If your math's Czech, you're probably better off...
As far as I know, the idea that that comma is not necessary comes from misreading Strunk & White's unclear explanation ("In a series of three or more terms with a single conjunction, use a comma after each term except the last"), where "the last" is the one after the "and", not the last one before it. The comma is omitted if there are no commas ("this and that") and in certain idioms ("Foo, Bar and Company"); proper names get whatever punctuation they want. In general, follow the principle that it is better to make a supposed grammatical error than produce something which could be misinterpreted; including the comma is much less likely to cause confusion than omitting it.
"I'd like to thank my parents, Ayn Rand and God."
If you get a physical copy, try to get a German edition. The tiles in the American edition are less brightly colored, less distinctive, and don't look as much like the things they produce. Of course, the rules and cards are in German, but you already know how to play, so that shouldn't be an issue.
I prefer the interpretation that Einstein had actually forgotten how to do the sort of math that shows up on high school assignments, because it wasn't practical for his needs. As such, it's a statement about how math isn't a single track with progressively more difficult things, but a collection of skills, and someone who has problems with some of the nominally basic parts of it might be the leading expert in some more abstract part. Anyone who's tried to split a restaurant check with math majors can attest that this is true. A CS-focused math prof may very well only be able to tell you how to get Mathematica to solve your problem, not how to do it in a way that will get you homework credit.
The next step is to prohibit putting content over other content, and putting a little banner at the top of the window that tells you that the site tried to put something over something else, and to click on a browser button to let it if you want to. Then advertizers will find that Firefox users don't click on their ads, because their ads are stuck somewhere out of the way, due to not fitting anywhere in the layout of the page.
I have yet to see a case in which the user and the page author actually want content to appear over other content. I can imagine an exception, where there's stuff covering hints on a page, and you can uncover each hint if you decide you need it. But I don't think CSS is quite reliable enough to make that technique a good idea, at least so far (I think black-on-black text that you can highlight is the most reliable and common currently).
Back in the Napster days, when the RIAA's target was a company getting rich on file-sharing and not individual fans, Don Henley was against it. He's gotten less sympathetic towards the RIAA as their activities have gotten less defensible.
In the programming environment I use, the close brace is highlighted in bright pink to indicate that something's probably wrong. Also, the ", i}" is in blue to indicate that it is still part of a string constant. If I actually try to compile the code despite the editor telling me exactly what the compiler will think of the code, I get 'temp.c:6:38: missing terminating " character', which is quite explanitory and is undoubtedly true (unlike your message; I often put single quotes around things inside double-quoted strings to mark the edges of a value).
I only get an uninformative message on the next line, when the compiler determines that it is completely lost, but I know to resolve the clear error messages before working on the ones I don't understand.
(This is with emacs and gcc; I don't know if less mature IDEs still give bad feedback).
In fact, giving helpful error messages is a highly tricky art. You need a good understanding of what people will actually try to write and of what mistakes people make. For the first five years or so, meaningful compiler error messages are generally misleading more often than helpful, because they reflect a misunderstanding of the user's intent. Sun's javac is just recently getting to the point where it tells you useful things about mistakes in using the original language.
The point of this is not actually to have a single sign-on everywhere, like Passport tried to do. The point of this is to have a transitive sign-on, where you can sign-on to a starting web site, and have that web site provide the information you gave it to other sites of your choice. If you're a slashdot user, you could post to groklaw as a slashdot user when you follow a link from slashdot, whether or not you have a groklaw account, and groklaw could verify that you are the slashdot user you claim to be.
Their example has a person having a session with an airline company (not Microsoft or Sun or some identity company) and using that session to make reservations at other sites for the same trip.
The argument is that (1) software which is not tested under actual conditions is going to be buggier than software tested under actual conditions, and (2) voting software is never tested under actual conditions, because a complete and full-scale mock election is too expensive to run and people are unwilling to do full recounts everywhere after a real election to try to identify bugs.
The same arguments apply to any software which is only used in unusal circumstances, and such software is generally unreliable. It's possible that voting software is actually worse than, say, power grid emergency response software due to liability on the latter, but probably not by much, because if you can't test something, it doesn't matter how liable you are for failures; you do the best you can, but, by definition, no better.
Of course, in the case of voting software, there's a easy solution: have the official result come from a tally of paper ballots which the voters check for accuracy before depositing, and only the quick result come from the software. The first year, the software will probably still be buggy, and the result may be corrected, but the software will get fixed and future elections will be unlikely to get reversed after the election-night tally.
I'm not sure why he thinks that objects fabricated by consumers will be flimsy and low-quality. Most likely, a process which actually placed atoms individually would default to making everything out of diamond, just because it's simple. Laser-cutters work nicely on hard plastics, and don't really work on the flimsy stuff just because you're actually carving the thing out of a solid block that has to not wobble while you cut it. It's only easier to make wimpy items than strong ones if you're using a melting technque (vacuum=forming or injection-molding), while then requires that you have a physical mold that you're using, which isn't going to be a "download-and-fabricate" process. It'll actually probably be much more difficult to make soft items than hard ones.
It's only "next" because, while the RIAA was always worried about copying, and the MPAA was worried about bandwidth going up, the TVA has just been thinking about the same dam thing they always did. The owners of shows sell content to stations; stations sell time to advertizers, and send the combination to viewers whether or not they're watching. The fact that anyone can get a copy of a show for their own viewing doesn't make it harder for the owner to sell to stations, and the stations only care whether you're watching them or not, not what else you might be doing if you're not watching them.
In fact, assuming that people are downloading TV shows over the internet a lot, it is in the interests of the owners of shows to cover this fact up rather than publicizing it and doing something about it, because they don't want to send the message to stations and advertizers that people don't watch shows.
There are two results of working on projects: understanding of the project and the project itself. Understanding of the project is only generated while not consciously working on anything. If you're working too long hours, you lose this part. You can only write good code with understanding of what you're doing. So working long hours is fine at the end of a project, when you already understand it, and can work on it until it's done with just what you already know (and forgetting how you debugged stuff doesn't matter too much), but it will kill your productivity if you do it earlier in the project or for anything involving design.
If you work 14 hour days all the time (as opposed to just during crunch time), you're only spending about 2 hours a day on improving your insight into the project. You're probably writing good code for half an hour each day and writing junk for 13 and a half hours.
Yesterday, I worked for 3 hours trying to fix a bug, and didn't get anywhere. Then I gave up and went home. During my half-hour commute, I realized what must be happening and solved it in 5 minutes upon getting home. I'd probably have solved it in another 3 hours had I stayed at work, but I actually was done sooner because I didn't work too late.
According to your link, it is used to indicate that a non-standard spelling (or other error) is intended, but it is not an acronym and it comes from the Latin word (in the sense that the editor intends the text to read "just so"). In fact, the slashdot article which misspells "sic" is using it when quoting an error in grammar, not spelling.
And the basic principle of the internet is "be strict in what you generate and lenient in what you accept". IE does what is, in some ways, a better job of this (of course, it also tends to fail to prohibit a lot of the things it should process and then deny). A browser should not obscure any text on the page unless the specification specifically requires that the text be obscured. Any page which is not standard html should be forced by the browser to render so it's readable, not allowed to be unreadable.
As far as I can tell, slashdot is not using standard html that IE doesn't support to make a page that is supposed to render badly. It's failing to obey the standards, and firefox is showing something mangled. (Or so I hear; I read slashdot in "lite" mode, which removes most of the badly broken stuff along with the space-wasting stuff)
Really, the W3C ought to provide a guide for what to do with non-compliant HTML, not as a specification of how you handle HTML, but as a specification of how web browsers should behave towards users. Having buffer overflows parsing malformed HTML should not be compliant behavior on the browser's part (but this shouldn't need the W3C's input); similarly, the browser shouldn't place text outside the window, under images, under other text, etc., and the W3C should define this sort of constraint.
I have nothing against IDEs with special (e.g., graphical) support for specialized source formats; the issue is when the IDE generates code in some other language directly without a step involving a non-generated format you can version control. (Personally, I mainly avoid IDEs because they always seem to have keyboard shortcuts that are malicious to people accustomed to using Emacs the way I do, which involves moving text around with C-k/C-y; but this means that I insist on only using things that can be done outside of the IDE).
.ui files and turn them into .cpp files, you don't then start editing the .cpp file and consider it the source of your project. So you just have another stage in your compile, and it doesn't actually matter that the intermediate step in also code that you could have written.
When you save your guis as
If Linus gets hit by a bus, probably Alan Cox would take over, because he's pretty easy to get to agree to do things. Alternatively, Marcelo could take over 2.6 and work with Andrew Morton on it.
What happens today when large factions of kernel developers disagree with Linus is that they share their patches with each other. The offical development series (-mm), where most debugging gets done, has included kgdb for ages. Especially with things that aren't important to end users, there's no need to convince Linus in order to have something in common use.
The thing that really makes Linux development work is that it's not done by committee, and it's not really done with a single authority. Everybody who's working on it really does have their own version, and they're just close enough together that they can trade their work back and forth. In fact, the point of the new development process (i.e., trying not to fork 2.7) is to have all of the trees with current development stay close enough that stuff is shared throughout, rather than splitting into 2.6 and 2.8 regions with slow transit between them.
I can't think of any project which is run as effectively as Linux in terms of getting changes from concept to patch to testing to official while simultaneously keeping out things which are not ready for general use and making them available to people who want them anyway. For example, the process of making Linux suitable for audio editting (which requires some processes to have predictably low latency) is still in progress, because the current versions mess up performance on other systems, have maintainability issues, etc. But people who want to actually do audio editting with Linux just use a tree that has the current version of these changes, rather than Linus's kernel. As the changes get reworked to be suitable for general inclusion, the patches get smaller, and the mainline will eventually have the necessary characteristics.
The thing is that, previously, each increase in abstraction was either done by writing in a higher-level language or by using a nicer library in the same language. IDEs, on the other hand, move from writing code in any language to carrying out an IDE-specific process which generates a chunk of code which is then part of the project without anyone having written it.
The real solution isn't IDEs. It's adding language features that let you write the code more simply without a lot of boilerplate, and APIs which are easier to use. Really, the standard compiler should deal with the plumbing and there should never be any blanks which need to be filled in with information an IDE could supply. Doing these tasks with an IDE just hurts repeatability.
On the other hand, the rest of the things on your list are good: having a system which processes the project such that your tools are acting with a complete understanding of the code helps a whole lot.
Have you reported the crashes? There will never be a kernel version that fixes bugs that haven't been reported. If each kernel version you tried was broken in some entirely different way, then having the developers working on a different branch might actually improve your stability. But chances are that you're seeing something that nobody's known to fix. If you test the latest kernel for a little while, and report to the linux kernel mailing list what it does when it crashes, your .config, and your boot messages, someone will probably personally resolve your problem.
91: 1 to screw in the outer package, and 90 to screw in the individual LEDs inside.