People seem to be focussing on the "patents are too easy" part of IBMs argument and ignoring the "collecting and hoarding" part of them. That part is clearly just mercenary (money-driven) on IBMs part. Here's the goose-and-gander deal:
If IBM has a patent on something you want to do, and you have patents, you arrange a cross-licensing deal. They're happy because they get to use your patents, you're happy because you get to use their patents.
If IBM has a patent on something you want to do, and you don't have patents, you license the patent from them. They're happy because they get money, you're kinda happy because you got to use their patents.
If you have a patent on something IBM wants to do, and you don't need IBM's patents, IBM is annoyed and will look for some way to justify not having to license your patents.
Now, I agree with IBM, patent-hoarders that don't have products and just rape people who need patent licensing suck. But I think that's not evidence of the badness of patent-hoarders; it's evidence of the badness of patents. IBM can rape you just as bad if you don't have any patents to license back to them. Patents are a profit center, though, so you won't hear IBM advocating toasting them entirely. Instead, IBM is going to a crazy space where their intellectual property isn't even exactly property anymore--you presumably can't sell it to just anybody (e.g. a hoarder, or at least, you won't sell it to them since it's worthless to them).
IMO, the biggest problem, as always, is the focus on prior art instead of insisting on a fairly high obviousness barrier (or a low barrier for accepting re-invention as not being covered by a patent).
Your trollishness aside, it's unfortunately the case that when things are good, the director gets the credit, and when things are bad, the screenwriter gets the blame. Ah, Hollywood.
See this critique of Hollywood's habit of letting people other than the screenwriter muck with the script. Towards the end the author produces an analysis of Academy Awards for best original screenplay, which is pretty damning.
Reposting from the previous slashdot thread, responding to a djbdns user; note specifically that djb admits the forgery resistance is "quantitative, not qualitative".
While I don't think I'm in the clear because of this, I feel better protected from the (unwashed;)) internet.
That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee (emphasis mine):
Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)
Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.
There seem to be a lot of posts here assuming that BitKeeper really is all that, technically, and it really did enable Linus and etc. etc. However, the article says something totally different:
Prior to using BitKeeper, Linus would review every single patch detail by detail, and he would pull out just the pieces that he wanted.
But with BitKeeper, this became more difficult. Larry explained that this resulted in more trust being placed on some of the various subsystem maintainers, with Linus beginning to look at some patches category by category rather than line by line. [...] Effectively, much of the effort involved in assuring high quality was delegated, and ultimately this led to doubling the pace of kernel development.
Reading this, it seems to have nothing to do with technical advantages of BitKeeper, and everything to do with Linus delegating. Is it true? Where did this part of the article come from?
Convenient rule of thumb: possessive pronouns never have apostrophes:
me ==> my, mine
he ==> his, his
it ==> its, its
she ==> her, hers
you ==> your, yours
them ==> their, theirs
who ==> whose
So just remember that "its" works like "his". Whatever belongs to Jane, like her babydoll tee, is hers. Whatever belongs to Dick, like his pr0n, is his. Whatever belongs to Slashdot, like its dupe-posting editors, is its.
While I don't think I'm in the clear because of this, I feel better protected from the (unwashed;)) internet.
That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee:
Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
The vulnerability of DNS to forgery. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)
Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.
"They don't lose anything if I copy this, because they aren't offering it for sale and
aren't going to offer it for sale"
If you read through the thread, you will see that the emphasized part is an assumption, not a truth, and it was something grandparent was not assuming. "didn't release it when it was convenient for you": you want it now. convenient for you == released before you want it.
programs are at times behind by up to 8 months! According to an independent study, it takes an average of four months to watch the latest episodes of top-rated shows like Lost and Desperate Housewives.
[momentary speechlessness]
What the fuck? That has to be the lamest justification for "piracy" ever.
It's not like most TV shows are brutally tied to real-world time. Lost? Not that I'm aware of. 24? Clearly not. We're not talking about TV news with tsunami reports taking eight months before they get broadcast. So Australia's TV programs are time-shifted forward by four months... poor Australians! That obviously makes experiencing those shows worthless. I mean, come on, without the Internet supporting cross-continental communications, how would you ever even know? So how can these even matter for the typical non-rabid fan? (Heck, a six-month delay would make the seasons match up.)
Yes, I realize from other comments there are other bad things about Australian TV; I'm just amazed at the anonymous submitter who had this as their only complaint, and even hammered on it twice. I mean, people griping about not seeing a program at all, that makes me remark on their apparently clueless entitlement and clueless lack-of-sense-of-proportion. Seeing it late? I don't even know what kind of cluelessness to accuse.
I guess that makes me a troll, but really. I mean, I often wait after a new book is released until it comes out on softback to buy it. That time delay has never noticeably hurt my experience in reading it. So... yeah. I don't get it. What's the actual problem with seeing a TV show four months late, other than envy and ingratitude? I mean, sure, I only saw Buffy on DVD, so I wasn't able to talk to my friends about it when they first saw it "in real time"; but assuming most Australians' friends are Australian, that can't be it.
It is true that "a few more TLDs" is no solution. However, a lot more TLDs would probably work handily. If there are several hundred TLDs, are companies actually going to register every single one?
It also offers a handy solution to trademark issues and disposable domain names. Why not "matrix.movie" instead of "matrixmovie.com"? Do you actually think, if this were common, people would have more trouble with the former than the latter? It seems to me that if we had a ton of TLDs, and their usage actually made sense in terms of contributing useful information, people would probably learn to use them properly. As long as we leave things as they stand--with, as you say, companies buying up every TLD version of their name--the population at large is still going to keep using ".com" on everything, because it will always work.
As others have pointed out, there already are middleware physics engines, so having to conform to one to get this isn't that big a deal. "real" physics as opposed to "game" physics (a ballpark difference: you can stack objects and then push the stack into a corner with a slanted roof, and the former will behave reasonably) is really really hard to implement, hence the middleware.
The actual problem here is a chicken-and-egg one, unless they get this built into a next-gen console. If the performance gain of the hardware (and I have no idea, so I'll pick two values and speculate on them for illustration) is only 2x or 3x, then you can drop it in and get a performance boost, and maybe that's cool, but it's going to be hardcore-only to bother with. If the performance gain is 10x or 100x, then you can do a lot more crazy stuff--but only on machines that have the hardware, and normal machines without the hardware just aren't going to get anything like the same gameplay experience, unless the physics is used entirely as a special effect and doesn't feed into gameplay.
Of course, the PC confronted the same chicken-and-egg problem with hardware in the past; we had PC speaker sound, then AdLib FM music, then Soundblaster sampled audio. We had CGA, EGA, VGA, mode X, SVGA, and then hardware-accelerated graphics. But, in fact, audio and graphics are output-only; they're close a feedback loop between the game and the player, but they never feed back into the game logic, so it was always possible to compromise on them... and we were never looking at a factor of 100 difference.
Whereas the console industry is littered with failed add-on peripherals--Sega CD, 32X, I don't even remember the ones from Nintendo. Karaoke Revolution comes with a microphone; AntiGrav comes with the eyetoy camera--because trying to sell the peripherals separately is so totally doomed. I doubt any games are going to be sold with a so-called PPU, so it remains to be seen whether, chicken-and-egg-wise, the physics chip (purely computational) ends up more like a peripheral (input device) or sound/graphics (output device).
Maybe the better analogy is to the inclusion of an FPU. On games that had to work on computers without FPUs (you remember the 386?), the software simply didn't use floating point. It didn't make sense to write two versions of the code. Instead, you just target the lowest common-denominator and optimize for that. If someone has a faster/more-capable machine, well, it will be faster than the machine you optimized for, and hopefully that's good enough.
Not just round to int. FP rounding mode refers to how all operations round the bottommost bit of precision--IEE754 specifies that operations must (effectively) be copmuted with sufficient extra precision at the bottom to then round in the various directions.
The first is that it's at 4ghz. The P4 hasn't been able to reach that
This is meaningless when we don't know what is at 4Ghz. If it only means certain processing components, then Intel's already hit that. Even a lowly 2Ghz P4 already has two integer units each running at 4Ghz, because the P4 has a double-pumped integer core (scroll down to 'execution units').
He didn't say the user experience hasn't changed. He agrees with you. He mentioned anti-aliased fonts and windowing system shadows and transparency etc. himself.
What he said was that the user experience of performance hasn't changed. The user's perception of how quickly the machine responds. Not how glitzy it is. Pac Man ran at 60hz everywhere; Doom 3 doesn't on lots of machines.
Also, I think he's mostly wrong. The main reason why programs seem to run about as fast as they ever have is because programmers tend to make them that way. Certain parts of code are so slow that they need effort spent optimizing them. Some parts are fast enough that they don't need it. As programs are developed for newer, faster platforms, parts of code that would have previously needed optimization no longer do, and the programmers can spend the extra development effort on creating more features.
Technically, I guess it depends on your machine. For example, I have no automatic antivirus scan running, so that can't be it on my machine. But I do see that old programs clearly run faster than they used to, and yet new programs are at the same speed as the old ones were back in the day, so there's no doubt that the problem is that new programs are slower. I think the pattern described above is the likely cause, since I've seen happen on multiple projects.
In fact, as much as possible, I use versions of programs that are four or more years old, since they tend to be notably more responsive. I only switched from Win98 to Win2K a year ago; I program under MSVC 6, which is from 1998. I only stopped using Netscape Navigator 4 a year or two ago when ubiquitous CSS made it effectively unusable (and I checked again recently, it does indeed render noticeabley faster than Firefox for most pages that displayed identically).
The survey (or two?) I've read on the subject said this did not perform competitively with other techniques. The granularity of information is kind of poor.
It also doesn't help with the problem of detecting stores of new pointers into old objects for generational collection.
Malloc and free are simple algorithms, and whoever told you otherwise was wrong.
I don't know where you got your understanding of malloc, and especially free, but it's severely out of date. Knuth published about "Boundary Tags" no later than 1973 (citeseer is down, so no link). Saying that a coalesce operation "can be arbirarily slow" is just FUD. A boundary tag makes free() a fast O(1) operation: check the previous block in memory to see if it's free and if so join, a fast O(1) operation; check the next block in memory to see if it's free and if so coalesce; add free block to free-list, done. Yes, it's not zero work like a GC implementation sort-of is, but "arbitrarily slow"? It's basically at least as fast as malloc().
Allocation requests can hit disk, sure, but so can GC allocations even if they're just bumping a pointer: it all depends on the working set size. GC compaction can reduce fragmentation to reduce working set size, but that is only a big win if there's a lot of fragmentation, and most apps using a good malloc() don't exhibit that much. (It is also possible for a GC to rearrange memory so more in-working-set data is on pages together, reducing the working set page count without changing the total memory used. I don't know of any in-use implementations of this, since you need hardware support to know what objects are more-in-use; generally this is only available at the page level, where it's no help. I think maybe an early microde-based Smalltalk implementation might have done this.)
If your malloc has to walk giant free lists to find an open block, then sure, that can be slow. That's why people use trees of free lists based on size and such to make it more O(log N), and O(1) for small allocations. (On large allocations, actually using the memory amortizes the cost.) Read about dlmalloc, for example.
Furthermore, let's not misrepresent GC. Stop-and-collect GCs have obvious extra costs beyond the free-of-charge free (or lack of need for one). Incremental GCs that don't pause are usually slower overall and only preferred for interactive programs. For example, incremental GCs usually require "write barriers" or "read barriers" which require several extra instruction on every fetch from memory or every write of a pointer variable in memory. This can add up across the entire program. Incremental GCs also tend to be conservative, and only end up collecting things that, say, were garbage at the start of the most recent collection round, and generational collectors allow garbage to collect in later generations for some time, so they don't actually necessarily have a smaller working set than a non-leaky malloc()/free() program.
Another big win in non-GC systems is that you can use pointers that don't come off the heap. That way you can avoid allocation and deallocation and GC entirely. (You can actually do some of this in a GC system too if it's a 'conservative' GC that copes with pointers into the middle of blocks. Those pretty much only get used for adding GC to C and C++, though.) Here are some common ways this happens:
statically allocated arrays
small arrays and strcts on the stack
structs that are components of other structs, or arrays at the end of structs
use of special allocators:
slab allocators (it's even possible to embed this entirely inside the default allocator for all small allocations)
pool allocators (allocate a large block of memory, suballocate from it, deallocate all at once)
"stack" allocators (allocate a large block of memory, suballocate from one end, only allow freeing from the same end, so allocation is a adding to a pointer and deallocation is reseting that pointer)
Of course, doing all these things requires that you balance your different types of malloc()s with the correct, matching type of free(). In practice, GC proponents overestimate the diffi
The Albertson's form I didn't fill out had a checkbox that said "mark here instead of filling out the whole form to remain anonymous". Which was thoughtful, although it didn't seem worth the effort since I already had the card.
Ok, so if half of ID theft is friends & family, then half of it isn't. Friends & family probably do 99% of their theft offline, so let's call it 100%. What does that leave us for stranger-theft?
Friends & family theft: 50% of all theft; 100% occurs offline
Stranger theft: 50% of all theft; 44% occurs offline, 56% occurs online
(Why? Because 72% of all theft occurs offline, and friends and family accounts for 50% of the total. Given 100 thefts, 50 of them are friends and family, and (72-50) are offline non-friends non-family, or 22. That leaves 28 thefts to occur online.)
If that conclusion is really true, then you can spin these numbers in the entirely opposite direction; the headline could be More Identity Theft By Strangers Online than Offline.
However, the article also says that online theft of bank and CC information is only 12% of all identity theft. 72% + 12% = 84%; who knows where the other 16% really are (maybe they're online theft but not bank/CC). Ain't lying with statistics grand?
Appropriately, other people replying to parent have forgotten this or ignore parts of it like the comment that it applies to "99% of commonly used apps", which is clearly true. (Yes, there are parallelizable tasks on the PC. Those are often coded in MMX or SSE. Guess about what percentage of commonly used apps those are?) [Paragraph added for comment lameness reasons.]
Microsoft also promises to release an updated version of the tool on the second Tuesday of each month.
No doubt we will start seeing malicious software under Windows begin spreading on the second Tuesday of each month (or perhaps the first Wednesday after the second Tuesday of each month if the sources want to be on the safe side).
According to TFA, GPL 3 will be authored by Eben Moglen and RMS.
[...]
I will be shocked and dismayed if they don't open up the process, though. [...] They'll surely do it as an open collaboration.
If you read the second page of TFA:
There is also a great deal of work to be done to allow the large number of stakeholders who have grown up around the GPL to have an opportunity to express Opinions and to have their thoughts taken into account in trying to frame the best possible license, Moglen said.
Hitting "back" is an incredibly crucial and common task in web browsing. We click on links to go forward; we click "Back" to go backwards (assuming we don't use the keyboard). Fitts' law says bigger targets are easier to acquire with the mouse, so people will use them faster and with less error; see, for example, this column.
Of course, as that column notes, the easiest target to acquire is the one currently under the mouse cursor. Once upon a time (Netscape Navigator 3), right clicking brought up a context menu which always had "Back" as the first entry, so it was incredibly easy to select (it became a sort of "mouse gesture"). Despite efforts documented in bugzilla, attempts to "fix" Mozilla and Firefox by putting "Back" in that location, and to fix the context menus under Windows which don't display the menu until mouse up, have failed, apparently because the developers don't believe "Back" is actually used enough to justify such extravagances, or, in some cases, because they were asshats.
"Twenty percent of all searching was sex-related back in 1997; now it's about 5 percent,"
Alternatively, people search for exactly the same amount of sex-related that they used to, but they make 4x as many searches as they used to, so it's decreased as a fraction of the total but not in absolute terms.
Without a lot more details, nearly any explanation is possible.
Not at all. Although advertising is still a major source of revenue, Google makes plenty of business offering enterprise solutions.
Not significantly. At least not by sources of data available to me (do you have a cite?). At least not according to their IPO and their quarterly
report ending June 30:
several attempts to get a reasonable faux table, prevented by ECODE's inutility and stupid lameness filter, deleted
Revenues, by revenue source, as a percentage of total revenues
three months ending June 30 2003
Total advertising revenues: 97%
Licensing and other revenues: 3%
three months ending June 30 2004
Total advertising revenues: 98%
Licensing and other revenues: 2%
six months ending June 30 2004
Total advertising revenues: 98%
Licensing and other revenues: 2%
See page 21 of the above link for the nice table with that and more.
So, yes, grandparent was right, this all comes from people clicking on google text ads. Of course, grandparent shouldn't be surprised, as this isn't new information; the same information (ending in March 2004) is available on page 40 of the old IPO prospectus.
The new numbers are bigger, of course, but the old numbers were not insignificant.
I'd cut the agnosticism section (being agnostic towards any currently-unfalsifiable theory leaves you agonistic to a lot of silly things, like unicorns, or the theory that a human being travelling at 0.99c turns into a clone of Jesse Jackson; better to disbelieve and later change your mind), but whatever.
Slashdot Mirror
Now, I agree with IBM, patent-hoarders that don't have products and just rape people who need patent licensing suck. But I think that's not evidence of the badness of patent-hoarders; it's evidence of the badness of patents. IBM can rape you just as bad if you don't have any patents to license back to them. Patents are a profit center, though, so you won't hear IBM advocating toasting them entirely. Instead, IBM is going to a crazy space where their intellectual property isn't even exactly property anymore--you presumably can't sell it to just anybody (e.g. a hoarder, or at least, you won't sell it to them since it's worthless to them).
IMO, the biggest problem, as always, is the focus on prior art instead of insisting on a fairly high obviousness barrier (or a low barrier for accepting re-invention as not being covered by a patent).
Your trollishness aside, it's unfortunately the case that when things are good, the director gets the credit, and when things are bad, the screenwriter gets the blame. Ah, Hollywood.
See this critique of Hollywood's habit of letting people other than the screenwriter muck with the script. Towards the end the author produces an analysis of Academy Awards for best original screenplay, which is pretty damning.
That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee (emphasis mine):
Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.
Reading this, it seems to have nothing to do with technical advantages of BitKeeper, and everything to do with Linus delegating. Is it true? Where did this part of the article come from?
So just remember that "its" works like "his". Whatever belongs to Jane, like her babydoll tee, is hers. Whatever belongs to Dick, like his pr0n, is his. Whatever belongs to Slashdot, like its dupe-posting editors, is its.
That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee:
Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.
If you read through the thread, you will see that the emphasized part is an assumption, not a truth, and it was something grandparent was not assuming. "didn't release it when it was convenient for you": you want it now. convenient for you == released before you want it.
[momentary speechlessness]
What the fuck? That has to be the lamest justification for "piracy" ever.
It's not like most TV shows are brutally tied to real-world time. Lost? Not that I'm aware of. 24? Clearly not. We're not talking about TV news with tsunami reports taking eight months before they get broadcast. So Australia's TV programs are time-shifted forward by four months... poor Australians! That obviously makes experiencing those shows worthless. I mean, come on, without the Internet supporting cross-continental communications, how would you ever even know? So how can these even matter for the typical non-rabid fan? (Heck, a six-month delay would make the seasons match up.)
Yes, I realize from other comments there are other bad things about Australian TV; I'm just amazed at the anonymous submitter who had this as their only complaint, and even hammered on it twice. I mean, people griping about not seeing a program at all, that makes me remark on their apparently clueless entitlement and clueless lack-of-sense-of-proportion. Seeing it late? I don't even know what kind of cluelessness to accuse.
I guess that makes me a troll, but really. I mean, I often wait after a new book is released until it comes out on softback to buy it. That time delay has never noticeably hurt my experience in reading it. So... yeah. I don't get it. What's the actual problem with seeing a TV show four months late, other than envy and ingratitude? I mean, sure, I only saw Buffy on DVD, so I wasn't able to talk to my friends about it when they first saw it "in real time"; but assuming most Australians' friends are Australian, that can't be it.
It also offers a handy solution to trademark issues and disposable domain names. Why not "matrix.movie" instead of "matrixmovie.com"? Do you actually think, if this were common, people would have more trouble with the former than the latter? It seems to me that if we had a ton of TLDs, and their usage actually made sense in terms of contributing useful information, people would probably learn to use them properly. As long as we leave things as they stand--with, as you say, companies buying up every TLD version of their name--the population at large is still going to keep using ".com" on everything, because it will always work.
The actual problem here is a chicken-and-egg one, unless they get this built into a next-gen console. If the performance gain of the hardware (and I have no idea, so I'll pick two values and speculate on them for illustration) is only 2x or 3x, then you can drop it in and get a performance boost, and maybe that's cool, but it's going to be hardcore-only to bother with. If the performance gain is 10x or 100x, then you can do a lot more crazy stuff--but only on machines that have the hardware, and normal machines without the hardware just aren't going to get anything like the same gameplay experience, unless the physics is used entirely as a special effect and doesn't feed into gameplay.
Of course, the PC confronted the same chicken-and-egg problem with hardware in the past; we had PC speaker sound, then AdLib FM music, then Soundblaster sampled audio. We had CGA, EGA, VGA, mode X, SVGA, and then hardware-accelerated graphics. But, in fact, audio and graphics are output-only; they're close a feedback loop between the game and the player, but they never feed back into the game logic, so it was always possible to compromise on them... and we were never looking at a factor of 100 difference.
Whereas the console industry is littered with failed add-on peripherals--Sega CD, 32X, I don't even remember the ones from Nintendo. Karaoke Revolution comes with a microphone; AntiGrav comes with the eyetoy camera--because trying to sell the peripherals separately is so totally doomed. I doubt any games are going to be sold with a so-called PPU, so it remains to be seen whether, chicken-and-egg-wise, the physics chip (purely computational) ends up more like a peripheral (input device) or sound/graphics (output device).
Maybe the better analogy is to the inclusion of an FPU. On games that had to work on computers without FPUs (you remember the 386?), the software simply didn't use floating point. It didn't make sense to write two versions of the code. Instead, you just target the lowest common-denominator and optimize for that. If someone has a faster/more-capable machine, well, it will be faster than the machine you optimized for, and hopefully that's good enough.
Not just round to int. FP rounding mode refers to how all operations round the bottommost bit of precision--IEE754 specifies that operations must (effectively) be copmuted with sufficient extra precision at the bottom to then round in the various directions.
This is meaningless when we don't know what is at 4Ghz. If it only means certain processing components, then Intel's already hit that. Even a lowly 2Ghz P4 already has two integer units each running at 4Ghz, because the P4 has a double-pumped integer core (scroll down to 'execution units').
What he said was that the user experience of performance hasn't changed. The user's perception of how quickly the machine responds. Not how glitzy it is. Pac Man ran at 60hz everywhere; Doom 3 doesn't on lots of machines.
Also, I think he's mostly wrong. The main reason why programs seem to run about as fast as they ever have is because programmers tend to make them that way. Certain parts of code are so slow that they need effort spent optimizing them. Some parts are fast enough that they don't need it. As programs are developed for newer, faster platforms, parts of code that would have previously needed optimization no longer do, and the programmers can spend the extra development effort on creating more features.
Technically, I guess it depends on your machine. For example, I have no automatic antivirus scan running, so that can't be it on my machine. But I do see that old programs clearly run faster than they used to, and yet new programs are at the same speed as the old ones were back in the day, so there's no doubt that the problem is that new programs are slower. I think the pattern described above is the likely cause, since I've seen happen on multiple projects.
In fact, as much as possible, I use versions of programs that are four or more years old, since they tend to be notably more responsive. I only switched from Win98 to Win2K a year ago; I program under MSVC 6, which is from 1998. I only stopped using Netscape Navigator 4 a year or two ago when ubiquitous CSS made it effectively unusable (and I checked again recently, it does indeed render noticeabley faster than Firefox for most pages that displayed identically).
It also doesn't help with the problem of detecting stores of new pointers into old objects for generational collection.
I don't know where you got your understanding of malloc, and especially free, but it's severely out of date. Knuth published about "Boundary Tags" no later than 1973 (citeseer is down, so no link). Saying that a coalesce operation "can be arbirarily slow" is just FUD. A boundary tag makes free() a fast O(1) operation: check the previous block in memory to see if it's free and if so join, a fast O(1) operation; check the next block in memory to see if it's free and if so coalesce; add free block to free-list, done. Yes, it's not zero work like a GC implementation sort-of is, but "arbitrarily slow"? It's basically at least as fast as malloc().
Allocation requests can hit disk, sure, but so can GC allocations even if they're just bumping a pointer: it all depends on the working set size. GC compaction can reduce fragmentation to reduce working set size, but that is only a big win if there's a lot of fragmentation, and most apps using a good malloc() don't exhibit that much. (It is also possible for a GC to rearrange memory so more in-working-set data is on pages together, reducing the working set page count without changing the total memory used. I don't know of any in-use implementations of this, since you need hardware support to know what objects are more-in-use; generally this is only available at the page level, where it's no help. I think maybe an early microde-based Smalltalk implementation might have done this.)
If your malloc has to walk giant free lists to find an open block, then sure, that can be slow. That's why people use trees of free lists based on size and such to make it more O(log N), and O(1) for small allocations. (On large allocations, actually using the memory amortizes the cost.) Read about dlmalloc, for example.
Furthermore, let's not misrepresent GC. Stop-and-collect GCs have obvious extra costs beyond the free-of-charge free (or lack of need for one). Incremental GCs that don't pause are usually slower overall and only preferred for interactive programs. For example, incremental GCs usually require "write barriers" or "read barriers" which require several extra instruction on every fetch from memory or every write of a pointer variable in memory. This can add up across the entire program. Incremental GCs also tend to be conservative, and only end up collecting things that, say, were garbage at the start of the most recent collection round, and generational collectors allow garbage to collect in later generations for some time, so they don't actually necessarily have a smaller working set than a non-leaky malloc()/free() program.
Another big win in non-GC systems is that you can use pointers that don't come off the heap. That way you can avoid allocation and deallocation and GC entirely. (You can actually do some of this in a GC system too if it's a 'conservative' GC that copes with pointers into the middle of blocks. Those pretty much only get used for adding GC to C and C++, though.) Here are some common ways this happens:
Of course, doing all these things requires that you balance your different types of malloc()s with the correct, matching type of free(). In practice, GC proponents overestimate the diffi
The Albertson's form I didn't fill out had a checkbox that said "mark here instead of filling out the whole form to remain anonymous". Which was thoughtful, although it didn't seem worth the effort since I already had the card.
Friends & family theft: 50% of all theft; 100% occurs offline
Stranger theft: 50% of all theft; 44% occurs offline, 56% occurs online
(Why? Because 72% of all theft occurs offline, and friends and family accounts for 50% of the total. Given 100 thefts, 50 of them are friends and family, and (72-50) are offline non-friends non-family, or 22. That leaves 28 thefts to occur online.)
If that conclusion is really true, then you can spin these numbers in the entirely opposite direction; the headline could be More Identity Theft By Strangers Online than Offline.
However, the article also says that online theft of bank and CC information is only 12% of all identity theft. 72% + 12% = 84%; who knows where the other 16% really are (maybe they're online theft but not bank/CC). Ain't lying with statistics grand?
Appropriately, other people replying to parent have forgotten this or ignore parts of it like the comment that it applies to "99% of commonly used apps", which is clearly true. (Yes, there are parallelizable tasks on the PC. Those are often coded in MMX or SSE. Guess about what percentage of commonly used apps those are?) [Paragraph added for comment lameness reasons.]
No doubt we will start seeing malicious software under Windows begin spreading on the second Tuesday of each month (or perhaps the first Wednesday after the second Tuesday of each month if the sources want to be on the safe side).
If you read the second page of TFA:
Of course, as that column notes, the easiest target to acquire is the one currently under the mouse cursor. Once upon a time (Netscape Navigator 3), right clicking brought up a context menu which always had "Back" as the first entry, so it was incredibly easy to select (it became a sort of "mouse gesture"). Despite efforts documented in bugzilla, attempts to "fix" Mozilla and Firefox by putting "Back" in that location, and to fix the context menus under Windows which don't display the menu until mouse up, have failed, apparently because the developers don't believe "Back" is actually used enough to justify such extravagances, or, in some cases, because they were asshats.
Alternatively, people search for exactly the same amount of sex-related that they used to, but they make 4x as many searches as they used to, so it's decreased as a fraction of the total but not in absolute terms.
Without a lot more details, nearly any explanation is possible.
Not significantly. At least not by sources of data available to me (do you have a cite?). At least not according to their IPO and their quarterly report ending June 30:
several attempts to get a reasonable faux table, prevented by ECODE's inutility and stupid lameness filter, deleted
See page 21 of the above link for the nice table with that and more.
So, yes, grandparent was right, this all comes from people clicking on google text ads. Of course, grandparent shouldn't be surprised, as this isn't new information; the same information (ending in March 2004) is available on page 40 of the old IPO prospectus. The new numbers are bigger, of course, but the old numbers were not insignificant.
I did google before posting, and saw multiple references to it having been run with >1000 clients.
I'd cut the agnosticism section (being agnostic towards any currently-unfalsifiable theory leaves you agonistic to a lot of silly things, like unicorns, or the theory that a human being travelling at 0.99c turns into a clone of Jesse Jackson; better to disbelieve and later change your mind), but whatever.