Are you sure Perl does not just store 8-bit strings?
Transcoding UTF-8 to UTF-32 is a huge WASTE of processing time, not a saving. You are seriously over-estimating the number of times that somebody needs to get to the N'th code point without looking at the N-1 code points before it. Possibly by many orders of magnitude. All other operations on a string do not take any more time with UTF-8 than UTF-32.
No you do not need the number of "characters", EVER!!!!
Thinking that Unicode is made of a string of "characters" is WRONG, WRONG, WRONG!
Read up on precomposed and decomposed characters, and all the other nuances, before you make an idiot statement like this again.
A simple one: do you count the BOM at the start of a UTF-16 string as one of the characters? Answer: it does not matter what your answer is, it will be wrong in half the situations.
Although I mostly agree with you, I have to say that if you think strlen() should return the number of "characters" in UTF-8 then you are seriously mistaken. Such idiot-savant thinking has caused more trouble than anything else in getting Unicode to work.
strlen returns the number of fixed-sized units in the string. All other answers are useless.
Python 3 does NOT get it right or better. It gets it MUCH worse and this is why everybody doing serious work is sticking to Python 2.x
A Python "unicode" string cannot store arbitrary data. The only way to convert a UTF-8 string to it is to do a lossy conversion because errors must turn into codes that match things that correct UTF-8 encoding turns into as well. We should all know that lossy conversion is a serious flaw but too many people, incluing Theo, believe some magic pixie is going to make it physically impossible for invalid encodings to appear in a byte array. Nobody thinks there is magic making the byte zero not be able to be stored into the memory used by a C string, and the fact that people act as though this much more complex rule is going to be enforced by the laws of nature indicates a serious disconnect from reality, possibly due to an extreme desire to convince themselves that all the work they did to make their "wide characters" was not wasted.
The idea that "Unicode" is done by making a list of "characters" that can each be individually and atomically looked at is what is preventing I18N from ever working. Unicode contains precomposed and decomposed characters, it contains joins and splits and direction indicators and language tags and BOM symbols, and many languages have varying ideas of what order the various glyphs are in a word. Every single person who has foisted "wide characters" and "UCS-2" and what Windows and Python call "Unicode strings" (which are often UCS-4 or UTF-16 except when it is mistakenly interpreted as UCS-2) are actively hurting internationalization and adoption of Unicode, probably more than the most redneck USA-First programmer could ever have done. And the shameful thing is that they believe they are helping, while making it harder!
Strings should be arrays of bytes with a length (maybe the length should be in bits). Do you want to look at the "characters"? You use an ITERATOR!!!! You can use DIFFERENT iterators depending on how you want the "characters": ie precomposed, decomposed, all kinds of normalization, and they can correctly decode UTF-8 (or UTF-16) in-place and they can report encoding errors exactly and unambigously so they are preserved and cannot be used for security violations. The expression string[n] should be ILLEGAL and undefined (this would also fix the reason C++ std::string cannot share memory between identical strings). The only things you can do is copy and concatenate strings, and split them at an iterator.
Absolutely agree, the FA gets it all wrong. At no time, on machines with 8K of memory, did anybody EVER consider using a 16-bit length. The choices were between using 1 byte for a string terminator, or one byte for a string length. The choices were either unlimited strings but one character cannot be in them, or strings limited to 255 characters. There were no other choices considered, anybody suggesting wasting more than one byte on every string constant would have been ignored.
Some alternatives were worse than either Pascal or C, such as using the high bit in the last character to indicate the end of the string. There was also strong desire to compress strings to 6 bits or less per character (such compression is why filenames and identifiers were often case-insensitive and restricted to number, letter, and underscore). The fact that such things were seriously considered and implemented should show just how insane it would have been at that time to consider using 16 bits for the length.
Anybody using Pascal at the time will tell you that C strings are a HUGE, HUGE, INFINITE win over the length limitation of Pascal. The RIGHT decision was made.
Even if 16-bit numbers were somehow used, they would have been stored at the start of the string (NOBODY would ever consider passing anything larger than a pointer as an argument, C did not support passing structures by value at that time because it was considered prohibitively expensive). Since the PDP-11 could put these at odd addresses, code would certainly have taken advantage of this to pack strings together, making portability to machines that needed the length on even-only much more difficult. And attempting to change 16 bit to 32-bit length would have produced a huge fight, and probably resulted in two string constant types because of the need to support huge piles of back-compatability.
However I disagree that his example of embedded nuls is the worst. The gets style where buffers overflowed have been responsible for far more breaches and crashes than embedded nuls. Embedded nuls only break if there is actually a different function which uses something else to measure the string, such inconsistency is a source of bugs no matter what two schemes are used.
That's just being silly. Lots of Unix filesystems can technically put a '/' in the filenames. Does not mean it will work.
I don't think files that cannot be named by the majority of NT programs count. Therefore any restrictions in the WIN32 API are part of the definition of NT. They have relaxed some of these more recently but they are there still. Amazing they did not scrap this crap when they changed to wchar.
I think you are confusing the fact that it was impossible to change any character on the screen other than the one under the cursor. Yes it might make sense to have a different call that moved the blinking cursor indicator, but that was not done. You had to move the "cursor" to change where the other bios call updated the sceen. Therefore unless your gui worked by changing only a single character on the screen, which happened to be exactly where you wanted the blinking cursor, you had to use this move-cursor call if you wanted any changes.
I'm not sure about the 0x13 bios call, there was a reason nobody (including that DOS write-string call) used it. I think it may have ignored the cursor position? The only working way to use the BIOS to update the screen with any ability to position the cursor was to call set-cursor-postion and write-character alternately for every single screen location on the screen. Obviously no sane programmer did this on a 5Mhz machine.
"Driver" is probably misleading. I believe MSDOS called the bios calls, and that by replacing these you could make the file system reside on any disk-like device. There was at least enough API that you could claim different numbers of disks and sizes of the disks and read/write 512-byte blocks on them. Certainly there were implementations on MSDOS 1.0 that talked to the existing home 5 and 10 Mbyte drives such as the apple drive.
I would say this is true. You can see what IBM *did* design in the IBM-PC. For instance the totally useless "bios" calls.
The best example was the official way to put a character on the screen. I'm sure IBM asked Microsoft what BASIC needed to do, and they probably said "put a character at the cursor, and some way to move the cursor around". IBM then dutifully implemented the BIOS with TWO calls, one that placed a character at the cursor and did not move it, and another that moved the cursor. Unbelievable. If you took the stupidest programmer in the world, you might expect that they would make an api that took one call per character. IBM managed to make it take two!, thus proving they were stupider than the stupidest programmer I can imagine!
(in case you are wondering, any mildly intelligent programmer, even with the incredibly limited resources of the IBM PC and a 1 or 2K bios, would have easily made an api that took a pointer and a length of characters and put them on the screen. They may have even interpreted return/line feed and even escape sequences. The history of the PC and clones may have been far different, because programs for the PC would not have bypassed the bios as much to update the screen. Early attempts at multitasking and windowing would have been much more likely to work. Microsoft would likely have been faced with a lot more competition long before Windows came out).
NT still has drive letters and a lot of weird restrictions on filenames due to DOS, so it certainly is DOS-based.
You might as well claim Linux is not Unix-based because it has a kernel that was written after 1979. It still does not allow a forward slash in a filename, which is a feature that is there only because it is Unix-based.
We had "32 bit machines with GUI, preemptive multitasking and hardware-accelerated 3D graphics" prior to August 1981? Any links/info?
Yes, stupid. Take a look at Sun, Apollo, and SGI.
All had bitmapped graphics (no window system, programs took over the screen), mice, and the SGI machines at least had hardware-accelerated 3D graphics (the hardware did matrix mulitplications and polygon fills).
More importantly MS-DOS 1.0 didn't support hard drives. That wasn't until MS-DOS 2.0.
Actually it did (they were 5-10 Megabytes, and looked just like the floppy drives, and drivers had to be written, nothing came with DOS). What MS-DOS 1.0 did not support was hierarchical file systems. The '\' would have been considered the first character in the filename, I think then the file system would have rejected it as an invalid filename.
I think it is pretty clear that strategic voting means that nobody will vote 0. They can *always* make their vote "stronger" by voting -1 for everybody they did not vote 1 for. (or conversely, if they "hate" somebody they can vote -1 on that person, but their hate becomes "stronger" by voting 1 for everybody else).
Your other idea of the requiring a positive sum to the same as requiring the winning candidate to get a yes vote from more than 50% of the voters. Perhaps that should require a revote, however there is no reason to kick out the current candidates, if they don't change they will still get less than 50%, and a changed version may be the strongest candidate.
The images seem to show that the roof slants slightly from the center to the edges. Rain would threrefore run toward the edges and drip off there. It might even clean the dust off the glass (sand blowing onto that big flat surface seems to me to be a problem).
I think you explained what I was trying to say more clearly. Since strategic voting requires everybody not marked "yes" to be marked "no" then there is no reason for any third state, as voters will not choose it.
The only way a write-in candidate will win is if more people vote yes for that person than the most popular person on the ballot. It does not matter whether the people not writing the candidate count as "no" or "abstain", as there are fewer of these than the ones writing "no" for the popular candidate.
I do agree that it would help a lot if there were two bubble marked yes and no. However I would require the voter to fill one or the other. This makes it easy to check if a ballot is incorrectly filled out, and makes it impossible to add more marks to a ballot after it is submitted to change the vote.
This is image reconstruction, where additional information (not necessarily correct) is derived from a limited image.
Close equivalents are the "font smoothing" done by the earliest versions of Macintosh for printing their bitmap graphics on a PostScript printer to draw 72 dpi 1-bit images at 300 dpi. Also I believe Microsoft's earliest subpixel font rendering, smoothtype, was done this way (not cleartype or any other modern font rendering).
Much more complicated examples are algorithms for scaling up images, including ones for converting video to HDTV or even IMAX resolution. These create images that replace the pixels, based on analysis of sometimes very large areas around the pixel. And by far the most complicated example are the programs that recover shapes from very low-resolution bitmaps, such as the Microsoft one posted earlier on slashdot.
You are talking about http://en.wikipedia.org/wiki/Approval_voting which I agree would be an excellent way to get an actual measure of how popular third party candidates are, and may even allow one to win.
It is possible your idea is to have 3 states for each candidate on the ballot: yes, no, and abstain. However this will not work, as it is obvious strategic voting to write no for everybody other than the ones you like, as it will improve the chances of the ones you like winning (conversely if you really hate somebody then the logic is to write yes for everybody other than that person). Therefore only two states, yes and no, are needed, and this is what approval voting does.
The rolling blackouts happened in Santa Monica. I WAS IN A RESTAURANT WHEN THEY HAPPENED!! I SAW THEM FOR REAL. AND THEY DID NOT HAPPEN IN THE LA DWP AREA, EVER!. Don't make yourself look idiotic by LYING trying to support your position.
I fully agree that private enterprise can do a lot better than goverment in every case where private enterprise actually wants to do it and there is actual competition. However your inability to see that there are cases where there is no competition, or no ability to profit from an enterprise, shows a blindness to reality that probably exceeds that of Marxists.
I'm not saying the government does better. I am just complaining that the essay "iPencil" makes no sense what so ever. It does not explain why government does not work. This seems to be a problem with a lot of libertarian diatribes, they make some nice introduction that demonstrates fact A, and then says "A, therefore B" (where B is some evil thing government does). If you attempt to argue that B does not follow A, they then try to claim you are saying A is false.
I can assure you that the communists were able to produce pencils, and that did not require somebody at the pencil factory to know every detail about every possible part of pencil production. In fact they probably were political appointments and knew *less* than the equivalent person at a capitalist pencil factory. They did not know how to grow coffee, instead they probably got the coffee from the coffee ministry. But (surprise!) so did other parts of the communist machine, they actually succeeded in getting coffee to many people without them all having to know about how to grow it! (I AM NOT CLAIMING THEY DID THIS BETTER, SO DON'T SPOUT OFF!) This is called network effects and is what that entire paper was talking about, with the tacked-on "I will claim that capitalism does network effects perfectly and government is incapable of it" with no logical reason what so ever.
By the way, I get vastly better electrical service from LA DWP than my neighbors get from commercial electrical service. No brownouts or rolling blackouts and my bill is lower. Government-run ISP's are much much better. Another thing government does better than private industry is anything where the job is needed by society but nobody will do it for a profit.
Okay I read the libertarian essay. It's a bunch of bull that makes me question your sanity.
What it is claiming is that a product produced by a for-profit company is made without any one person having total knowledge of every aspect of it's creation. That is because they contact others, who know how to do parts of the job, and they contact others, and so on and so on. Rather cool.
And then this idiot makes, for no reason whatsoever, a claim that because the EVVVVIL GUBERMENT tries to do it, for some reason the same rules do not apply, and instead a single person has to know every aspect of the job. Just so they can they can say it can't work.
Of course it can't work, because they are making totally incorrect and unwarranted assumptions, which they try to gloss over by cramming them in the top half of one paragraph (after spending 15 paragraphs talking about how pencils are made!).
The truth is, the government is perfectly capable of hiring others to do the parts of the work. In fact the real problem with the government is that it does this TOO MUCH, in that it farms off work into as many pieces as possible, thus increasing expense and waste. This stupid essay is claiming the opposite, that government offices try to accomplish work with too few people!
You only have to license *YOUR* patents for GPL 3.0, if you want to redistribute code (you can use the code even if it implements your patented idea, and even modify it to add your patented idea, and this is all fine as long as you don't redistribute the result).
Other people's patents are exactly the same as GPL 2.2, BSD, the public domain, and every commercial license in existence. There is no way they could not be since they are out of your control and you often don't even know if they exist.
I have INCANDESCENT bulbs that buzz worse than any of the CFL's I have. In particular I am pissed off at some high-voltage expensive ceiling fixtures designed to light a wall, which we never use due to the horrible buzzing. An outdoor CFL buzzed a bunch but it turned out the socket was bad (it failed, the CFL still worked in other sockets and no bulbs at all work in that socket any more).
I have no idea how you could possibly get a 20% savings from CFLs.
He didn't mean he saved 20% of his total energy. He is saying that cost of bulbs plus cost of energy is 20% less than it would be for incandescents. Does not sound like a lot to me, but I doubt he is lying.
Slashdot Mirror
Are you sure Perl does not just store 8-bit strings?
Transcoding UTF-8 to UTF-32 is a huge WASTE of processing time, not a saving. You are seriously over-estimating the number of times that somebody needs to get to the N'th code point without looking at the N-1 code points before it. Possibly by many orders of magnitude. All other operations on a string do not take any more time with UTF-8 than UTF-32.
No you do not need the number of "characters", EVER!!!!
Thinking that Unicode is made of a string of "characters" is WRONG, WRONG, WRONG!
Read up on precomposed and decomposed characters, and all the other nuances, before you make an idiot statement like this again.
A simple one: do you count the BOM at the start of a UTF-16 string as one of the characters? Answer: it does not matter what your answer is, it will be wrong in half the situations.
Although I mostly agree with you, I have to say that if you think strlen() should return the number of "characters" in UTF-8 then you are seriously mistaken. Such idiot-savant thinking has caused more trouble than anything else in getting Unicode to work.
strlen returns the number of fixed-sized units in the string. All other answers are useless.
Python 3 does NOT get it right or better. It gets it MUCH worse and this is why everybody doing serious work is sticking to Python 2.x
A Python "unicode" string cannot store arbitrary data. The only way to convert a UTF-8 string to it is to do a lossy conversion because errors must turn into codes that match things that correct UTF-8 encoding turns into as well. We should all know that lossy conversion is a serious flaw but too many people, incluing Theo, believe some magic pixie is going to make it physically impossible for invalid encodings to appear in a byte array. Nobody thinks there is magic making the byte zero not be able to be stored into the memory used by a C string, and the fact that people act as though this much more complex rule is going to be enforced by the laws of nature indicates a serious disconnect from reality, possibly due to an extreme desire to convince themselves that all the work they did to make their "wide characters" was not wasted.
The idea that "Unicode" is done by making a list of "characters" that can each be individually and atomically looked at is what is preventing I18N from ever working. Unicode contains precomposed and decomposed characters, it contains joins and splits and direction indicators and language tags and BOM symbols, and many languages have varying ideas of what order the various glyphs are in a word. Every single person who has foisted "wide characters" and "UCS-2" and what Windows and Python call "Unicode strings" (which are often UCS-4 or UTF-16 except when it is mistakenly interpreted as UCS-2) are actively hurting internationalization and adoption of Unicode, probably more than the most redneck USA-First programmer could ever have done. And the shameful thing is that they believe they are helping, while making it harder!
Strings should be arrays of bytes with a length (maybe the length should be in bits). Do you want to look at the "characters"? You use an ITERATOR!!!! You can use DIFFERENT iterators depending on how you want the "characters": ie precomposed, decomposed, all kinds of normalization, and they can correctly decode UTF-8 (or UTF-16) in-place and they can report encoding errors exactly and unambigously so they are preserved and cannot be used for security violations. The expression string[n] should be ILLEGAL and undefined (this would also fix the reason C++ std::string cannot share memory between identical strings). The only things you can do is copy and concatenate strings, and split them at an iterator.
Absolutely agree, the FA gets it all wrong. At no time, on machines with 8K of memory, did anybody EVER consider using a 16-bit length. The choices were between using 1 byte for a string terminator, or one byte for a string length. The choices were either unlimited strings but one character cannot be in them, or strings limited to 255 characters. There were no other choices considered, anybody suggesting wasting more than one byte on every string constant would have been ignored.
Some alternatives were worse than either Pascal or C, such as using the high bit in the last character to indicate the end of the string. There was also strong desire to compress strings to 6 bits or less per character (such compression is why filenames and identifiers were often case-insensitive and restricted to number, letter, and underscore). The fact that such things were seriously considered and implemented should show just how insane it would have been at that time to consider using 16 bits for the length.
Anybody using Pascal at the time will tell you that C strings are a HUGE, HUGE, INFINITE win over the length limitation of Pascal. The RIGHT decision was made.
Even if 16-bit numbers were somehow used, they would have been stored at the start of the string (NOBODY would ever consider passing anything larger than a pointer as an argument, C did not support passing structures by value at that time because it was considered prohibitively expensive). Since the PDP-11 could put these at odd addresses, code would certainly have taken advantage of this to pack strings together, making portability to machines that needed the length on even-only much more difficult. And attempting to change 16 bit to 32-bit length would have produced a huge fight, and probably resulted in two string constant types because of the need to support huge piles of back-compatability.
However I disagree that his example of embedded nuls is the worst. The gets style where buffers overflowed have been responsible for far more breaches and crashes than embedded nuls. Embedded nuls only break if there is actually a different function which uses something else to measure the string, such inconsistency is a source of bugs no matter what two schemes are used.
That's just being silly. Lots of Unix filesystems can technically put a '/' in the filenames. Does not mean it will work.
I don't think files that cannot be named by the majority of NT programs count. Therefore any restrictions in the WIN32 API are part of the definition of NT. They have relaxed some of these more recently but they are there still. Amazing they did not scrap this crap when they changed to wchar.
I think you are confusing the fact that it was impossible to change any character on the screen other than the one under the cursor. Yes it might make sense to have a different call that moved the blinking cursor indicator, but that was not done. You had to move the "cursor" to change where the other bios call updated the sceen. Therefore unless your gui worked by changing only a single character on the screen, which happened to be exactly where you wanted the blinking cursor, you had to use this move-cursor call if you wanted any changes.
I'm not sure about the 0x13 bios call, there was a reason nobody (including that DOS write-string call) used it. I think it may have ignored the cursor position? The only working way to use the BIOS to update the screen with any ability to position the cursor was to call set-cursor-postion and write-character alternately for every single screen location on the screen. Obviously no sane programmer did this on a 5Mhz machine.
"Driver" is probably misleading. I believe MSDOS called the bios calls, and that by replacing these you could make the file system reside on any disk-like device. There was at least enough API that you could claim different numbers of disks and sizes of the disks and read/write 512-byte blocks on them. Certainly there were implementations on MSDOS 1.0 that talked to the existing home 5 and 10 Mbyte drives such as the apple drive.
I would say this is true. You can see what IBM *did* design in the IBM-PC. For instance the totally useless "bios" calls.
The best example was the official way to put a character on the screen. I'm sure IBM asked Microsoft what BASIC needed to do, and they probably said "put a character at the cursor, and some way to move the cursor around". IBM then dutifully implemented the BIOS with TWO calls, one that placed a character at the cursor and did not move it, and another that moved the cursor. Unbelievable. If you took the stupidest programmer in the world, you might expect that they would make an api that took one call per character. IBM managed to make it take two!, thus proving they were stupider than the stupidest programmer I can imagine!
(in case you are wondering, any mildly intelligent programmer, even with the incredibly limited resources of the IBM PC and a 1 or 2K bios, would have easily made an api that took a pointer and a length of characters and put them on the screen. They may have even interpreted return/line feed and even escape sequences. The history of the PC and clones may have been far different, because programs for the PC would not have bypassed the bios as much to update the screen. Early attempts at multitasking and windowing would have been much more likely to work. Microsoft would likely have been faced with a lot more competition long before Windows came out).
NT still has drive letters and a lot of weird restrictions on filenames due to DOS, so it certainly is DOS-based.
You might as well claim Linux is not Unix-based because it has a kernel that was written after 1979. It still does not allow a forward slash in a filename, which is a feature that is there only because it is Unix-based.
We had "32 bit machines with GUI, preemptive multitasking and hardware-accelerated 3D graphics" prior to August 1981? Any links/info?
Yes, stupid. Take a look at Sun, Apollo, and SGI.
All had bitmapped graphics (no window system, programs took over the screen), mice, and the SGI machines at least had hardware-accelerated 3D graphics (the hardware did matrix mulitplications and polygon fills).
More importantly MS-DOS 1.0 didn't support hard drives. That wasn't until MS-DOS 2.0.
Actually it did (they were 5-10 Megabytes, and looked just like the floppy drives, and drivers had to be written, nothing came with DOS). What MS-DOS 1.0 did not support was hierarchical file systems. The '\' would have been considered the first character in the filename, I think then the file system would have rejected it as an invalid filename.
He's talking about doing a "git push" of some subset of files, not what git calls a commit.
I think it is pretty clear that strategic voting means that nobody will vote 0. They can *always* make their vote "stronger" by voting -1 for everybody they did not vote 1 for. (or conversely, if they "hate" somebody they can vote -1 on that person, but their hate becomes "stronger" by voting 1 for everybody else).
Your other idea of the requiring a positive sum to the same as requiring the winning candidate to get a yes vote from more than 50% of the voters. Perhaps that should require a revote, however there is no reason to kick out the current candidates, if they don't change they will still get less than 50%, and a changed version may be the strongest candidate.
The images seem to show that the roof slants slightly from the center to the edges. Rain would threrefore run toward the edges and drip off there. It might even clean the dust off the glass (sand blowing onto that big flat surface seems to me to be a problem).
The Burj Khalifa has some features that makes it a good deal more expensive than this structure. Floors for one :-)
I think you explained what I was trying to say more clearly. Since strategic voting requires everybody not marked "yes" to be marked "no" then there is no reason for any third state, as voters will not choose it.
The only way a write-in candidate will win is if more people vote yes for that person than the most popular person on the ballot. It does not matter whether the people not writing the candidate count as "no" or "abstain", as there are fewer of these than the ones writing "no" for the popular candidate.
I do agree that it would help a lot if there were two bubble marked yes and no. However I would require the voter to fill one or the other. This makes it easy to check if a ballot is incorrectly filled out, and makes it impossible to add more marks to a ballot after it is submitted to change the vote.
This is image reconstruction, where additional information (not necessarily correct) is derived from a limited image.
Close equivalents are the "font smoothing" done by the earliest versions of Macintosh for printing their bitmap graphics on a PostScript printer to draw 72 dpi 1-bit images at 300 dpi. Also I believe Microsoft's earliest subpixel font rendering, smoothtype, was done this way (not cleartype or any other modern font rendering).
Much more complicated examples are algorithms for scaling up images, including ones for converting video to HDTV or even IMAX resolution. These create images that replace the pixels, based on analysis of sometimes very large areas around the pixel. And by far the most complicated example are the programs that recover shapes from very low-resolution bitmaps, such as the Microsoft one posted earlier on slashdot.
You are talking about http://en.wikipedia.org/wiki/Approval_voting which I agree would be an excellent way to get an actual measure of how popular third party candidates are, and may even allow one to win.
It is possible your idea is to have 3 states for each candidate on the ballot: yes, no, and abstain. However this will not work, as it is obvious strategic voting to write no for everybody other than the ones you like, as it will improve the chances of the ones you like winning (conversely if you really hate somebody then the logic is to write yes for everybody other than that person). Therefore only two states, yes and no, are needed, and this is what approval voting does.
The rolling blackouts happened in Santa Monica. I WAS IN A RESTAURANT WHEN THEY HAPPENED!! I SAW THEM FOR REAL. AND THEY DID NOT HAPPEN IN THE LA DWP AREA, EVER!. Don't make yourself look idiotic by LYING trying to support your position.
I fully agree that private enterprise can do a lot better than goverment in every case where private enterprise actually wants to do it and there is actual competition. However your inability to see that there are cases where there is no competition, or no ability to profit from an enterprise, shows a blindness to reality that probably exceeds that of Marxists.
To be 100% accurate, a mixture of water and melamine was the substitute for milk.
I'm not saying the government does better. I am just complaining that the essay "iPencil" makes no sense what so ever. It does not explain why government does not work. This seems to be a problem with a lot of libertarian diatribes, they make some nice introduction that demonstrates fact A, and then says "A, therefore B" (where B is some evil thing government does). If you attempt to argue that B does not follow A, they then try to claim you are saying A is false.
I can assure you that the communists were able to produce pencils, and that did not require somebody at the pencil factory to know every detail about every possible part of pencil production. In fact they probably were political appointments and knew *less* than the equivalent person at a capitalist pencil factory. They did not know how to grow coffee, instead they probably got the coffee from the coffee ministry. But (surprise!) so did other parts of the communist machine, they actually succeeded in getting coffee to many people without them all having to know about how to grow it! (I AM NOT CLAIMING THEY DID THIS BETTER, SO DON'T SPOUT OFF!) This is called network effects and is what that entire paper was talking about, with the tacked-on "I will claim that capitalism does network effects perfectly and government is incapable of it" with no logical reason what so ever.
By the way, I get vastly better electrical service from LA DWP than my neighbors get from commercial electrical service. No brownouts or rolling blackouts and my bill is lower. Government-run ISP's are much much better. Another thing government does better than private industry is anything where the job is needed by society but nobody will do it for a profit.
Okay I read the libertarian essay. It's a bunch of bull that makes me question your sanity.
What it is claiming is that a product produced by a for-profit company is made without any one person having total knowledge of every aspect of it's creation. That is because they contact others, who know how to do parts of the job, and they contact others, and so on and so on. Rather cool.
And then this idiot makes, for no reason whatsoever, a claim that because the EVVVVIL GUBERMENT tries to do it, for some reason the same rules do not apply, and instead a single person has to know every aspect of the job. Just so they can they can say it can't work.
Of course it can't work, because they are making totally incorrect and unwarranted assumptions, which they try to gloss over by cramming them in the top half of one paragraph (after spending 15 paragraphs talking about how pencils are made!).
The truth is, the government is perfectly capable of hiring others to do the parts of the work. In fact the real problem with the government is that it does this TOO MUCH, in that it farms off work into as many pieces as possible, thus increasing expense and waste. This stupid essay is claiming the opposite, that government offices try to accomplish work with too few people!
This claim is FUD.
You only have to license *YOUR* patents for GPL 3.0, if you want to redistribute code (you can use the code even if it implements your patented idea, and even modify it to add your patented idea, and this is all fine as long as you don't redistribute the result).
Other people's patents are exactly the same as GPL 2.2, BSD, the public domain, and every commercial license in existence. There is no way they could not be since they are out of your control and you often don't even know if they exist.
I have INCANDESCENT bulbs that buzz worse than any of the CFL's I have. In particular I am pissed off at some high-voltage expensive ceiling fixtures designed to light a wall, which we never use due to the horrible buzzing. An outdoor CFL buzzed a bunch but it turned out the socket was bad (it failed, the CFL still worked in other sockets and no bulbs at all work in that socket any more).
I have no idea how you could possibly get a 20% savings from CFLs.
He didn't mean he saved 20% of his total energy. He is saying that cost of bulbs plus cost of energy is 20% less than it would be for incandescents. Does not sound like a lot to me, but I doubt he is lying.