The "unix world" (or at least Slashdot) is guilty of spreading the "security through obscurity is bad" canard without really understanding it or at least without actually explaining it clearly; as such, it's a lousy slogan. Security through obscurity is the bread-and-butter of security.
Security pretty much requires something secret (unless it something you have or something you are); and something which is secret is by definition something which is obscure. Non-biometric security always comes through obscurity.
Where the slogan comes into play usefully is cases like people using their own secret crytographic algorithm.
The trick is in keeping the amount of obscure stuff to a minimum so that it's easily protected. Typically it's a password or a cryptographic key. When somebody tries to protect something with a secret cryptographic algorithm, they have to keep both the key and the algorithm secret, and the description of the algorithm is a lot of bits to keep secret. Moreover, they're really weak bits; if the description/implementation of the algorithm takes 1000 characters, that's 8000 bits they have to keep secret. If they're going to keep that much secret, maybe they should just use an existing strong cryptographic technique with that many bits.
The argument is actually slightly subtler: if they have 8000 bits of algorithm and 512 bits of key, and their algorithm is itself strong, then even if they leak the 8000 algorithm bits, they still have 512 bits worth of encryption. But you could just use two existing cryptographic techniques, one 512 bits and one 8000 bits, and get just as much protection. Since odds are their algorithm isn't strong, there's also the danger that (a) the leak of the 8000 bits makes it trivial, or (b) that the NSA can just figure out the whole thing without seeing any bits. (Note that something like a chosen plaintext attack is roughly equivalent to access to the algorithm bits, too.)
(8192 bits, whatever. It's a made-up number anyway.)
There were no GPUs in the mid 90s, the Voodoo/Voodoo 2 didn't have GPUs, they were mere rasterizers. The first GPU was nvidia with the GeForce 256, Aug 31 1999. It took a long while for it to really catch on, since it's just as easy to do the 3d to 2d conversion in memory (CPU).
"GPU" was a marketing term invented by NVIDIA for the GeForce 256, attempting to draw a line between hardware that supported T&L (transformation-and-lighting) in hardware, and hardware that didn't, to help sell their hardware which was the only one that did, even though as you say it didn't matter much. Bottom line, it's foolish marketing bullshit that caught on. We are all better served calling all hardware accelerators GPUs, not using NVIDIA's bogus definition.
(Also, please strike your "in memory"; 'on the CPU' is correct, 'in memory' is not.)
Given that all the lighting and shadowing in something like Doom 3 doesn't actually happen in the vertex processing (the "transform and lighting" stage), but in the per-pixel processing (what you call "rasterizing", although generally that has a more specific meaning), the distinction becomes even more foolish; a hardware accelerator with full support for Shader Model 3 in the "rasterizer", but no hardware T&L support, would do a far better job on modern games than a GeForce 256 would; it's just not the most important thing.
AFAIK, the 3d geometry part of it is still mainly CPU based, you can't just send every polygon in the world up to the GPU and expect it to sort the shit out in a timely fashion. BSP trees
This is pretty much wrong. With scenes of 100K to 1M triangles, generally people avoid having the CPU touch every triangle at all. BSP trees are so far out it's not even funny (although some engines may still use them for historical reasons, or for sorting transparent objects). Generally, engines determine what "objects" are visible in the scene (based on which way you're looking, and what large obstacles prevent you from seeing things beyond them), and then for each object tell the GPU 'ok, now draw this mesh'. (There are exceptions; shadow-volume techniques sometimes use per-polygon CPU processing, and some people may still do character-skinning/vertex-blending on the CPU, but for the most part people try to avoid doing this stuff because it cuts your triangle count way down.)
If you feel the need to blame anyone, blame the dictators. Google is just doing business.
I'm not sure why there are 9 replies to you and none of them point this out:
The difference between Google and every other corporation out there is that Google publically said they would (try to) "Do No Evil". Therefore people are angry at Google (in a way they are not at others) because they think Google isn't living up to their mission statement / motto / promise / whatever.
We aren't holding Google to an unreasonably high standard for no reason; we're holding them to it because they set it themselves.
the rights devolve to the original copyright holder
The bands don't hold the copyright, or at least not the relevant part. Contracts all require the musicians to sign the copyright in the recording (not the music) over to the label. So there's nowhere for them to devolve.
(They do keep the copyright in the music itself, which comes into play for new recordings of the same thing, like live recordings and covers and sheet music. Also, there are some exceptions to the recording copyright changing hands on smaller labels.)
The quoted text is talking about _large_ requests. Physical memory fragmentation isn't the issue on large machine; virtual address _space_ fragmentation is. So if the OS and the runtime allocator can play nice, you can get your large allocations for an app using only, say, ~512MB to come out page aligned and from an entirely different section of memory than the smaller allocations. When you free the large allocations, you give the blocks back to the OS. The virtual memory space may become fragmented with difficult-to-fill holes, but those holes do not need to be backed by physical memory, so the fragmentation doesn't use up RAM.
You're hugely confused and/or misinformed, or you replied to the wrong post.
Implementing compaction of memory would require either indirecting all references or going through memory and updating all pointers to the objects that are moved; the latter can't be done in C/C++, and the former could be done in C++ but only clumsily.
What virtual memory does provide is that you don't need to worry about fragmentation in some cases. You have virtual addresses and physical addresses. When dealing with memory allocations that are larger than a page, you no longer need to find a contiguous region of physical memory of that size; you just need to find a contiguous region of virtual memory of that size, and you can use arbitrary physical pages to fill that in.
If your malloc/free/new/delete interacts well with the OS (allocating multiple-page objects to their own pages), you can free unused virtual pages back to the OS. Now you're fragmenting virtual memory, but if your app only uses, say, 256MB, you still get 2^30 or 2^31 bytes of address space in which it can try to get consecutive virtual memory pages to fulfill requests. Of course, if your app uses nearly as much memory as the application address space, this is no help, and if your app uses lots of smaller (sub-page-sized) blocks, this is no help, and if your malloc/free doesn't interact with the OS nicely and return unused pages in the middle of the heap, this is no help.
The JPEG standard actually includes support for an alternate entropy coding method (the last, non-lossy part of the compression applied after the lossy compression) based on something called arithmetic coding. Elements of that method were well-known to be patented, so it was not included in the widely-used basic JPEG implementation (by the Independent Jpeg Group). As such, it may have been part of the official standard, but it was not really part of the de facto standard, because it was known to be patented, so it was avoided.
I'm not sure what the deal is with this patent, although I assume it was covered in earlier stories. Maybe the patent holder agreed not to sue about it, or maybe nobody knew about it. One article linked here says "Forgent Networks Inc. acquired Compression Labs in 1997 and began an aggressive campaign of asserting the '672 patent roughly a year and a half ago, a decade after the patent was originally issued". It's closer to two decades; the patent issued in 1987 so if it were 17 years instead of 20, it would already be dead.
You are looking at it from a flawed perspective. "If I don't do it, somebody else will" is a pragmatic argument, not a moral argument. You're still doing evil.
Your economic analysis is also incorrect. The United States government eventually dropped its laws that cryptographic algorithms should be subject to munitions export laws, in part because those laws caused US companies to be unable to compete in the world market. Refusing to supply Google search to the Chinese could possibly result in China being less competitive with the rest of the world, and certainly it makes their citizenry less happy with their search capabilities than the rest of the world. It's just a drop in the bucket, but that reduced quality of life could be a tiny contribution to the eventual replacement of the Chinese government or at least the easing of some of their censorship laws. Playing along with them definitely won't. And in the long term, that's a much bigger improvement in the value to the Chinese citizenry.
You're correct that "hijacking" is the wrong word for what happened to.tv. There's still a real question to be asked though:
What are countries that have sold off their top-level domain going to do in 50 or 100 years when they want a national TLD? Are they going to be issued a new one? If so, what stops them from selling it again? Isn't allowing sales like.tv a failure to consider long-term consequences for the Internet and its users? (You could argue that disallowing the sale would have been inhumanitarian, but if so, why doesn't ICANN issue Tuvalu a few more high-demand TLDs?)
(If fifty years seems unlikely to you, the slashdot reader, keep in mind that while DNS has only been around for a bit more than 20 years, the Internet has been around for longer, and DNS is the system that was designed to replace the older, non-scalable HOSTS.TXT system. There's no reason to think our current unique host names won't still be valid 50 years from now, assuming we pay the fees.)
I've always been under the impression that it would be fine to perform this live and play it for an audience but once you try to sell it as a record, you're going to face some serious liabilities. I've been in bands that have covered Coldplay, Radiohead, The Beatles, Beck, The Pixies, etc. and we've never got in trouble for playing them live at crowded bars.
That's because the bar pays the license fees. Although it's long, this essay should be mandatory reading for people who are "under the impression" about this sort of thing.
An excerpt:
ASCAP has field agents on payroll, employed by their 23 field offices, who watch the newspapers and radio (and even hire clipping services) and when a new nightclub starts offering live music, for example, an agent will either show up or write a letter demanding money for the license. Refusals and arguments eventually lead to lawsuits, and the club always loses, often to the tune of tens of thousands of dollars in fines plus legal fees per infraction allowed by law. If a nightclub or even a store refuses to buy the license, then ASCAP or BMI will hire spies, often local music teachers or semi-professional musicians, who will make notes and testify in court as expert witnesses that on a certain day at a certain time a certain song was indeed played. Attempts by club owners to post "No ASCAP material to be performed here" signs or to ask that no musicians perform ASCAP material have not worked (Dreamland Ballroom vs. Shapiro, 1929; also Shapiro, Bernstein & Co. vs. Veltin, 1942), and invariably some musician unwittingly performs something in ASCAP's immense catalog. Note that even though the musicians or the employees decide what is played, it is the owner of the establishment where the music is played who gets sued. ASCAP bases this on the claim that "it would be a practical impossibility for ASCAP to locate and license musicians, who are often itinerant."
I think there's a valid meta-debate issue that is implied, though.
In a public policy debate, the idea is supposed to be that the law in question is maybe actually good public policy in that it has indirect benefits for the public, as well as direct benefits for certain individuals.
For example, in the copyright debate, some people will argue that the copyright monopoly offers the population at large a benefit by giving an incentive for creators to create new works. Moreover, some people argue this even though they themselves do not have a significant financial stake in copyright; that is, they will only benefit through that indirect gain of more new works. The fact that some people will argue even this position even though they only gain indirectly gives some credence to the idea that it's a legitimate public policy argument.
On the other hand, you have the patent argument. A similar claim is advanced re: innovation. However, in my experience, everyone who defends (software) patents turns out to have a direct financial stake:
patent holders (and patent-holders-to-be)
patent lawyers
the patent office
Obviously a government program that gives money to people of type A, B, and C is beneficial to people of type A, B, and C, and of course people of type A, B, and C are going to be in favor of such a program. But this is not evidence that such a program is good public policy, especially if it deprives other people of something (in this case, by granting a monopoly).
So when an individual in the patent debate turns out to have a direct stake in patents, I think it's perfectly reasonable to say "I'm not even going to bother reading that because I've seen this patternfar too many timesover the last 15 years.
"small potatoes"? Ok, 15M users in "Kazaa et al" would mean we'd need at least, oh, 30M users on "good, private Bittorrent trackers". Even if that's split amongst 100 totally different trackers, your definition of "private" needs work.
I don't think it's reasonable to draw your conclusions based on your summary of events (I haven't read the original thread).
It sounds like Robin Rowe came along and wanted to add new features to Film Gimp. How hard is it to add new features to an existing project? I don't know if it's easy, but it's doable. Compare that to merging that fork back to something with which it has hugely diverged (or merging the important bits back, or whatever)--that's a huge task that is not going to immediately help introduce new features into Film Gimp (or, presumably, not the new features he wanted).
But I don't even have to examine Robin Rowe's motivations and itch-scratching urges to point out why your argument is fallacious in an open source context.
What Robin Rowe does has no effect on what anyone else can do. Anybody at any time could come along and merge the features from FilmGimp/CinePaint back into Gimp 2.x. What Robin Rowe is doing off in his corner of the world makes no difference there. And the reality is that nobody in the Gimp camp has done this, because they don't care. Maybe they're not opposed to those features (as grandparent implied), but it's also not Robin Rowe's fault that nobody has merged the two projects, only that he himself hasn't. The Gimp developers apparently aren't interested in doing the work themselves. But who in the world is going to have that itch? This is the classic problem with open source: if the work is dirty, somebody needs to get paid for it to happen.
One of my winning entries did something like that; because the judges would c-preprocess the file while judging it, I wrote the program in a high-level assembly language as macros, and let the c-preprocessor "compile" it to (obfuscated) two-opcode machine language inspired by the Analytical Engine. (However, the program wasn't a compiler at all.)
The after-expansion version was too large for me to submit it directly, but it's definitely more impressive than the original entry. If I had done something simpler, I might have just been able to submit the post-processed code, but I doubt it would have won.
to defend against being sued on this patent: just publish your work so it becomes valid prior art (or keep dated, signed notebooks, etc. for your private defense)
to provide patents you can cross-license to prevent being sued over other patents: irrelevant in the face of IP companies that don't cross-license since they have no products
to provide perceived value to investors: supposedly irrelevant since Google claimed they weren't going to become strongly stockholder-driven
Under the FCC spectrum plan, we have provided most existing broadcasters with access to a 6 MHz channel for digital broadcasting within a core digital TV spectrum, i.e., TV channels 2 to 51.
This means that the new digital channels are being assigned to 6 MHz channels within the existing analog TV spectrum.
Reading comprehension alert. It doesn't mean that at all. Maybe what you say is true, but all I have to go on is the FAQ, and it doesn't say that.
Read again:
Under the FCC spectrum plan, we have provided most existing broadcasters with access to a 6 MHz channel for digital broadcasting within a core digital TV spectrum, i.e., TV channels 2 to 51.
Not "6 MHz within the existing analog TV spectrum", "6 MHz within a core digital TV spectrum".
It may well be that what you say is true, but the rest of that FAQ answer is written sufficiently incoherently (or rather, they assume you already know the answer to our question) that I can't tell.
As someone who had to manually upgrade Firefox recently because the built-in updater incorrectly claimed up-to-dateness (somehow an extension was preventing it from upgrading the browser, I bugzilla'd it and it's gotten no love), I have to wonder how many people have run into updates-not-working if it's not a high priority (despite the fact that this means people like me weren't getting critical security fixes).
Torrents seem like the right thing for the large ones, but all the ones I tried earlier today were rejected by the tracker. Not no response from being overloaded, but it claimed it wasn't tracking those torrents at all.
If other people had that experience, that might have overloaded the direct download attempts.
I block ads so that when I right click on the page to pick "back" from the context menu I don't accidentally click on an ad and get "open link in new window" or some other random crap in the top of my context menu with no "back" at all.
Please note that this isn't interesting unless you work in, as, the FA says, a severely memory constrained system. No normal embedded system needs to do this, much less the systems most programmers on Slashdot probably work with.
This is bad, lame, faux cooperative threads.
Local variables are not preserved.
A protothread runs within a single C function and cannot span over other functions. A protothread may call normal C functions, but cannot block inside a called function.
Unless memory is at an absolute premium, just use cooperative threading instead. If you try to use prototheads, you'll quickly discover how unlike "real" programming it is. Even just a 4K stack in your cooperative threads will get you way more than protothreads does.
Slashdot Mirror
Security pretty much requires something secret (unless it something you have or something you are); and something which is secret is by definition something which is obscure. Non-biometric security always comes through obscurity.
Where the slogan comes into play usefully is cases like people using their own secret crytographic algorithm.
The trick is in keeping the amount of obscure stuff to a minimum so that it's easily protected. Typically it's a password or a cryptographic key. When somebody tries to protect something with a secret cryptographic algorithm, they have to keep both the key and the algorithm secret, and the description of the algorithm is a lot of bits to keep secret. Moreover, they're really weak bits; if the description/implementation of the algorithm takes 1000 characters, that's 8000 bits they have to keep secret. If they're going to keep that much secret, maybe they should just use an existing strong cryptographic technique with that many bits.
The argument is actually slightly subtler: if they have 8000 bits of algorithm and 512 bits of key, and their algorithm is itself strong, then even if they leak the 8000 algorithm bits, they still have 512 bits worth of encryption. But you could just use two existing cryptographic techniques, one 512 bits and one 8000 bits, and get just as much protection. Since odds are their algorithm isn't strong, there's also the danger that (a) the leak of the 8000 bits makes it trivial, or (b) that the NSA can just figure out the whole thing without seeing any bits. (Note that something like a chosen plaintext attack is roughly equivalent to access to the algorithm bits, too.)
(8192 bits, whatever. It's a made-up number anyway.)
"GPU" was a marketing term invented by NVIDIA for the GeForce 256, attempting to draw a line between hardware that supported T&L (transformation-and-lighting) in hardware, and hardware that didn't, to help sell their hardware which was the only one that did, even though as you say it didn't matter much. Bottom line, it's foolish marketing bullshit that caught on. We are all better served calling all hardware accelerators GPUs, not using NVIDIA's bogus definition.
(Also, please strike your "in memory"; 'on the CPU' is correct, 'in memory' is not.)
Given that all the lighting and shadowing in something like Doom 3 doesn't actually happen in the vertex processing (the "transform and lighting" stage), but in the per-pixel processing (what you call "rasterizing", although generally that has a more specific meaning), the distinction becomes even more foolish; a hardware accelerator with full support for Shader Model 3 in the "rasterizer", but no hardware T&L support, would do a far better job on modern games than a GeForce 256 would; it's just not the most important thing.
This is pretty much wrong. With scenes of 100K to 1M triangles, generally people avoid having the CPU touch every triangle at all. BSP trees are so far out it's not even funny (although some engines may still use them for historical reasons, or for sorting transparent objects). Generally, engines determine what "objects" are visible in the scene (based on which way you're looking, and what large obstacles prevent you from seeing things beyond them), and then for each object tell the GPU 'ok, now draw this mesh'. (There are exceptions; shadow-volume techniques sometimes use per-polygon CPU processing, and some people may still do character-skinning/vertex-blending on the CPU, but for the most part people try to avoid doing this stuff because it cuts your triangle count way down.)
I'm not sure why there are 9 replies to you and none of them point this out:
The difference between Google and every other corporation out there is that Google publically said they would (try to) "Do No Evil". Therefore people are angry at Google (in a way they are not at others) because they think Google isn't living up to their mission statement / motto / promise / whatever.
We aren't holding Google to an unreasonably high standard for no reason; we're holding them to it because they set it themselves.
The bands don't hold the copyright, or at least not the relevant part. Contracts all require the musicians to sign the copyright in the recording (not the music) over to the label. So there's nowhere for them to devolve.
(They do keep the copyright in the music itself, which comes into play for new recordings of the same thing, like live recordings and covers and sheet music. Also, there are some exceptions to the recording copyright changing hands on smaller labels.)
Is this what they're talking about? Who knows.
Implementing compaction of memory would require either indirecting all references or going through memory and updating all pointers to the objects that are moved; the latter can't be done in C/C++, and the former could be done in C++ but only clumsily.
What virtual memory does provide is that you don't need to worry about fragmentation in some cases. You have virtual addresses and physical addresses. When dealing with memory allocations that are larger than a page, you no longer need to find a contiguous region of physical memory of that size; you just need to find a contiguous region of virtual memory of that size, and you can use arbitrary physical pages to fill that in.
If your malloc/free/new/delete interacts well with the OS (allocating multiple-page objects to their own pages), you can free unused virtual pages back to the OS. Now you're fragmenting virtual memory, but if your app only uses, say, 256MB, you still get 2^30 or 2^31 bytes of address space in which it can try to get consecutive virtual memory pages to fulfill requests. Of course, if your app uses nearly as much memory as the application address space, this is no help, and if your app uses lots of smaller (sub-page-sized) blocks, this is no help, and if your malloc/free doesn't interact with the OS nicely and return unused pages in the middle of the heap, this is no help.
I'm not sure what the deal is with this patent, although I assume it was covered in earlier stories. Maybe the patent holder agreed not to sue about it, or maybe nobody knew about it. One article linked here says "Forgent Networks Inc. acquired Compression Labs in 1997 and began an aggressive campaign of asserting the '672 patent roughly a year and a half ago, a decade after the patent was originally issued". It's closer to two decades; the patent issued in 1987 so if it were 17 years instead of 20, it would already be dead.
Your economic analysis is also incorrect. The United States government eventually dropped its laws that cryptographic algorithms should be subject to munitions export laws, in part because those laws caused US companies to be unable to compete in the world market. Refusing to supply Google search to the Chinese could possibly result in China being less competitive with the rest of the world, and certainly it makes their citizenry less happy with their search capabilities than the rest of the world. It's just a drop in the bucket, but that reduced quality of life could be a tiny contribution to the eventual replacement of the Chinese government or at least the easing of some of their censorship laws. Playing along with them definitely won't. And in the long term, that's a much bigger improvement in the value to the Chinese citizenry.
What are countries that have sold off their top-level domain going to do in 50 or 100 years when they want a national TLD? Are they going to be issued a new one? If so, what stops them from selling it again? Isn't allowing sales like .tv a failure to consider long-term consequences for the Internet and its users? (You could argue that disallowing the sale would have been inhumanitarian, but if so, why doesn't ICANN issue Tuvalu a few more high-demand TLDs?)
(If fifty years seems unlikely to you, the slashdot reader, keep in mind that while DNS has only been around for a bit more than 20 years, the Internet has been around for longer, and DNS is the system that was designed to replace the older, non-scalable HOSTS.TXT system. There's no reason to think our current unique host names won't still be valid 50 years from now, assuming we pay the fees.)
An excerpt:
The word he meant was "encompasses".
In a public policy debate, the idea is supposed to be that the law in question is maybe actually good public policy in that it has indirect benefits for the public, as well as direct benefits for certain individuals.
For example, in the copyright debate, some people will argue that the copyright monopoly offers the population at large a benefit by giving an incentive for creators to create new works. Moreover, some people argue this even though they themselves do not have a significant financial stake in copyright; that is, they will only benefit through that indirect gain of more new works. The fact that some people will argue even this position even though they only gain indirectly gives some credence to the idea that it's a legitimate public policy argument.
On the other hand, you have the patent argument. A similar claim is advanced re: innovation. However, in my experience, everyone who defends (software) patents turns out to have a direct financial stake:
Obviously a government program that gives money to people of type A, B, and C is beneficial to people of type A, B, and C, and of course people of type A, B, and C are going to be in favor of such a program. But this is not evidence that such a program is good public policy, especially if it deprives other people of something (in this case, by granting a monopoly).
So when an individual in the patent debate turns out to have a direct stake in patents, I think it's perfectly reasonable to say "I'm not even going to bother reading that because I've seen this pattern far too many times over the last 15 years.
"small potatoes"? Ok, 15M users in "Kazaa et al" would mean we'd need at least, oh, 30M users on "good, private Bittorrent trackers". Even if that's split amongst 100 totally different trackers, your definition of "private" needs work.
It sounds like Robin Rowe came along and wanted to add new features to Film Gimp. How hard is it to add new features to an existing project? I don't know if it's easy, but it's doable. Compare that to merging that fork back to something with which it has hugely diverged (or merging the important bits back, or whatever)--that's a huge task that is not going to immediately help introduce new features into Film Gimp (or, presumably, not the new features he wanted).
But I don't even have to examine Robin Rowe's motivations and itch-scratching urges to point out why your argument is fallacious in an open source context.
What Robin Rowe does has no effect on what anyone else can do. Anybody at any time could come along and merge the features from FilmGimp/CinePaint back into Gimp 2.x. What Robin Rowe is doing off in his corner of the world makes no difference there. And the reality is that nobody in the Gimp camp has done this, because they don't care. Maybe they're not opposed to those features (as grandparent implied), but it's also not Robin Rowe's fault that nobody has merged the two projects, only that he himself hasn't. The Gimp developers apparently aren't interested in doing the work themselves. But who in the world is going to have that itch? This is the classic problem with open source: if the work is dirty, somebody needs to get paid for it to happen.
The after-expansion version was too large for me to submit it directly, but it's definitely more impressive than the original entry. If I had done something simpler, I might have just been able to submit the post-processed code, but I doubt it would have won.
Reasons you might patent:
Reading comprehension alert. It doesn't mean that at all. Maybe what you say is true, but all I have to go on is the FAQ, and it doesn't say that.
Read again:
Not "6 MHz within the existing analog TV spectrum", "6 MHz within a core digital TV spectrum".
It may well be that what you say is true, but the rest of that FAQ answer is written sufficiently incoherently (or rather, they assume you already know the answer to our question) that I can't tell.
Woohoo, that patent is going to last for all of 20 years! Good job!
As someone who had to manually upgrade Firefox recently because the built-in updater incorrectly claimed up-to-dateness (somehow an extension was preventing it from upgrading the browser, I bugzilla'd it and it's gotten no love), I have to wonder how many people have run into updates-not-working if it's not a high priority (despite the fact that this means people like me weren't getting critical security fixes).
Let f(x) = x^(x^(x^...))). We know f(x) = 2.
Now consider x^f(x). If we expand that out, we get x^(x^(x^...)).
So:
x^f(x) = f(x) [by expansion]
x^2 = 2 [substitution]
x = +-sqrt(2)
So, question: why does x = -sqrt(2) not work?
If other people had that experience, that might have overloaded the direct download attempts.
Oh, and maybe to speed up page loading.
And to stick it to the man.
And to save electrons.
This is bad, lame, faux cooperative threads.
It's also not even particlarly new [1998].Unless memory is at an absolute premium, just use cooperative threading instead. If you try to use prototheads, you'll quickly discover how unlike "real" programming it is. Even just a 4K stack in your cooperative threads will get you way more than protothreads does.
(don't flame my apostrophes--I edited s/someone's/someones'/ intentionally, but I accidentally edited the wrong one)