Exactly; my original comment was as much, if not more, a criticism (in my mind when I wrote it) of that sort of junk as it was of people actually deliberately installing them.
If anything, I think I'd say that probably enhances my point; people who are least literate are actually reasonably likely to end up with this stuff and not know how to get rid of it.
I'm not a go-to guy on FPSs or games in general by any means, but my impression is that "I didn't see it as much more than DOOM with puzzles and a more detailed story" was pretty revolutionary for a FPS.
(Disclaimer: I haven't finished the original HL (I'm not that good at FPSs and actually stopped playing for a while when I first hit the marines and didn't get past them after about a dozen attempts), but I think HL2 and Episodes are great.)
So? The Church-Turing hypothesis would say we have the same limitations of formal systems.
Furthermore, it's like program verification and such, an active area of research. (That's a substantial part of what falls under "programming language" research nowadays.) The halting problem, and by extension Rice's theorem, say that you can't do what this entire area is trying to do in general. But for programs that people actually write, it's becoming increasingly practical. In the same way, probably just about all statements that mathematicians actually make in practice are possible to prove rigorously, it's just such a PITA that no one actually does.
Totally false. Penn State I'm pretty sure does not claim copyright on anything you do as an undergrad for instance (rather, the line is whether you're doing university-sponsored research, but I don't think this happens as undergrads much); my impression was that that's the norm, though maybe I'm mistaken. University of Wisconsin doesn't claim copyright on work you do even as a grad student (I'm pretty sure this even applies to things you do under the auspices of being a TA or RA, though I'm not positive), only patents on patentable things (and given that, they have some nice compensation arrangements). My impression is that this is unusual, but it's decidedly not unheard of.
Bankruptcy does not mean the company disappears; it is just owned by someone new (as has occurred with several airlines).
It still often means, e.g., large layoffs.
Bankruptcy punishes those who took excessive risks...
But it almost doesn't is my point. Even if the company goes bankrupt, most people who took excessive risks will sit on a comfortable cushion that's more than many people will make in a lifetime.
You do know that 99.999% of the world is NOT made up of CS and slashdot geeks,right?
Which is why that 00.001% of the world that is CS and/. geeks should stop contradicting the 99.999% of the world that thinks 'kilo' means 1000.;-)
(You were being facetious with your percentage, but it only gave me fodder I had to take.)
And you do know that this whole was NOT started to "make things right" or "make the HDDs match the metric system" right? It was.....I know this will be a shocker,wait for it......MARKETING!
Oh, I fully agree. The HDD manufacturers were certainly right for the wrong reason... but they're still right.
Now back to your first point. I agree that there should be a label on the boxes, but only because most OSes "still" report in base-2 units. It's for that reason that the labels are required, not because they're selling you less than they say or something like that (because I still maintain they aren't). I also think more consumer friendly labeling would be nice. For instance, put on the label "500 GiB / 537 GiB" or something. (Though maybe we'd disagree on whether that was more consumer friendly, I suspect it would at least help during those obnoxious support calls.)
So what? You think the executives who actually caused the mess would be really hurt by their company going out of business? They'd just go on to screw the next company. No, if the banks and such had actually gone out of business, the people who'd have been hurt would have been everyone who doesn't make decisions and is making enough to live but not get rich, and, if Bernanke et al are to believed, everyone else through the economy going even further into the crapper. (I don't know enough about the economy to know how realistic this is.)
In short, you're way less cynical than I am if you think that letting the banks go out of business would have caused other companies in the future to go "you know, let's give up significant short term gain for longer term stability."
So anything with BYTE in it should be on orders of 8,NOT ten.
Oh, and just out of curiosity, how big should a kilobyte have been on the CDC 6600, which used "byte" to refer to a 12-bit entity? Should it have been 1728 bytes?
So since "comment" isn't an SI unit, "kilocomment" doesn't have a well-defined meaning?
I guess timothy should have defined how many comments are in a kilocomment so I don't interpret it as 934 or 1187 since they are both about a thousand.
The problem isn't that,the problem is their damned box labeling! Have you looked for the "its base 10,not base 2" label on a HDD box lately?
My point is that it's dumb that they have to put it on there in the first place.
And as one of the earlier posters pointed out it makes NO damned sense! Because we all know that a BYTE is 8 bits,yes? So anything with BYTE in it should be on orders of 8,NOT ten.
1) Why? What does the number of bits in a byte have to do with the number of bytes in a kilobyte?
2) You're still wrong, because kilo- isn't an order of 8 (unless you count fractional ones; 1024 = 8^(3 1/3)). Maybe a kilobyte should be 512 bytes, because that's the closest power of eight to 1000.
So the word simply doesn't work.
So we're agree. We shouldn't use "kilobyte".
And as another poster pointed out with the Tb range becoming common the difference is really becoming staggering.
Yeah, that was me. Which is why we should stop using what are base-10 prefixes everywhere else (and aren't even uniformly base 2 in CS, even outside of HDDs) to mean things that aren't base 10!
First of all (A) it was a joke,which not surprisingly the mods didn't get so I'm surprised you even got to see it at all.
It's not at -1 yet, and I read at 0.
And (B) it was partly aimed at the asshat HDD manufacturers that put in the teenyiest tiniest letters they can possibly print on the box "Oh,BTW 500Gb isn't ACTUALLY 500Gb,because we don't follow the same rules as every OS ever made."
I have two responses: (1) so it was a joke, but it really wasn't a joke. (2) But it is actually 500 GB, or at least would be if CS people were sane. It wasn't so bad with kilo, but now that we're often measuring data in terabytes, the error is ridiculous... almost 10%! Even GB is 7% off. It's long past time to drop using base 10 prefixes that have had meanings for hundreds of years for things that aren't base 10. The HDD manufactures are right, it's the OSes that are lying.
I can't speak to the Blackberry, but I have a Motorola Razr and I'm rather disappointed by the stuff along this line. I've missed calls because it's rung too quietly, and I've almost missed calls because I didn't notice it vibrating in my pocket. (I'm 6' and 170, so hardly overweight.)
But it is not possible for garbage collection to perform better than a competent engineer.
It is. In addition to the link posted by the other reply, I've got another argument. I think a lot of this comes from here though I haven't looked at that page for a while.
First, realize that memory allocation in a C world can actually be fairly expensive. I've been tangentially related to a program where the team responsible for it saw a substantial performance improvement simply by switching malloc implementations. Current malloc implementations can be fairly complex, using one of several allocation strategies depending on the size.
By contrast, a malloc in a GC'd language can be dirt simple; in almost-C pseudocode:
void* malloc(size_t size) {
static void* next = [start of heap];
void* mem = next;
next += (size + sizeof(struct malloc_header));
(struct malloc_header*)(mem)->size = size;
(struct malloc_header*)(mem)->gc_info = 0;
return mem; }
Basically, just keep advancing a pointer.
Second, deletion in the C malloc world can also be expensive for the same reason allocation is. (In that case depending on the allocation strategy you also have to coalesce neighboring blocks, etc.) Deletion in the GC world -- in the strictest sense -- is free, because the GC will do nothing. If we want to be more fair we compare C's deletion costs to GC costs. There C will usually, but depending on the memory behavior, perhaps not by as much as you'd think. If the program allocates a lot of short-lived objects, that's a lot of deletion work that C will have to do but a GC'd program won't, because the GC cost is only determined by the live objects. Sure each live object will be much more expensive than a C delete, but there could be far fewer of them.
Third, I would argue that to be correct, a C program needs to behave correctly with respect to deleting stuff, or else a long-lived process could run out of memory or start using enough that the system starts behaving very poorly. But at the same time, it's easy to see program types out there that are very short-lived; most of the standard Unix utilities fit this bill. In a GC'd world, it's entirely possible for such a process to have zero deletion cost period if the GC is never invoked. The C version is chugging around deleting things because it needs to in order to be safe, but the GC version is being more optimistic in the sense that it doesn't bother incurring any cost until it figures out that the process is using too much memory. In the case where the process is short lived it wins: the C program incurs extra cost from all its allocation and deallocation, while the GC version incurs none. In the long-lived case, the GC version still behaves correctly and won't put the sort of pathologically bad memory pressure that the C version would have if you didn't delete stuff.
(It is true that in practice this benefit basically isn't seen because languages with GC tend to also have large VMs that take a while to start up and will greatly overshadow the allocation costs the C program incurs.)
Fourth, the extra cost of getting memory allocation right can easily come at the expense of other optimizations that someone working in a GC language would have time to do, or bugs that the GC developer would have time to fix, or features that the GC developer would have time to implement. It's true that this doesn't apply in the sort of ideal "give a great C programmer and a great GC language programmer the same task, give them as much time as they need, and measure the result" problem, but it the real world it still matters.
Now, the concession. I still suspect that almost all the time, a well-written program written in a manually-managed language will win out over an equally well-written version in a GC'd language. But at the same time, this is far from necessarily the case.
As many others have brought up, is "school" just a nice way of saying "slave labor"? Or alternately, is "taxes" just a nice way of saying "slave labor"?
I'll admit that these examples are far-fetched, but I don't think either is substantially more ridiculous than yours.
The other reply said how stupid and irrational you're being there better than I can, but I'll add another example. When I did the mandatory community service when I was in high school, it was going to another school and helping to run chess club, teaching chess and stuff like that.
I think there's probably a better way, but describe-bindings (also accessible from the help menu, describe, list key bindings) will list all current bindings, then you can search for the command.
Linux Does have a stable API. What it does lack is a stable binary interface.
As others have said, no it doesn't. From Documentation/stable_api_nonsense.txt:
"Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked."
"As a specific examples of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem."
"Kernel interfaces are cleaned up over time. If there is no one using a current interface, it is deleted."
Slashdot Mirror
Exactly; my original comment was as much, if not more, a criticism (in my mind when I wrote it) of that sort of junk as it was of people actually deliberately installing them.
If anything, I think I'd say that probably enhances my point; people who are least literate are actually reasonably likely to end up with this stuff and not know how to get rid of it.
Many non-power-users don't use addons at all.
And there are plenty more who install the Yahoo and Google toolbars, plus whatever other crap comes up.
I'm not a go-to guy on FPSs or games in general by any means, but my impression is that "I didn't see it as much more than DOOM with puzzles and a more detailed story" was pretty revolutionary for a FPS.
(Disclaimer: I haven't finished the original HL (I'm not that good at FPSs and actually stopped playing for a while when I first hit the marines and didn't get past them after about a dozen attempts), but I think HL2 and Episodes are great.)
So? The Church-Turing hypothesis would say we have the same limitations of formal systems.
Furthermore, it's like program verification and such, an active area of research. (That's a substantial part of what falls under "programming language" research nowadays.) The halting problem, and by extension Rice's theorem, say that you can't do what this entire area is trying to do in general. But for programs that people actually write, it's becoming increasingly practical. In the same way, probably just about all statements that mathematicians actually make in practice are possible to prove rigorously, it's just such a PITA that no one actually does.
Totally false. Penn State I'm pretty sure does not claim copyright on anything you do as an undergrad for instance (rather, the line is whether you're doing university-sponsored research, but I don't think this happens as undergrads much); my impression was that that's the norm, though maybe I'm mistaken. University of Wisconsin doesn't claim copyright on work you do even as a grad student (I'm pretty sure this even applies to things you do under the auspices of being a TA or RA, though I'm not positive), only patents on patentable things (and given that, they have some nice compensation arrangements). My impression is that this is unusual, but it's decidedly not unheard of.
Bankruptcy does not mean the company disappears; it is just owned by someone new (as has occurred with several airlines).
It still often means, e.g., large layoffs.
Bankruptcy punishes those who took excessive risks...
But it almost doesn't is my point. Even if the company goes bankrupt, most people who took excessive risks will sit on a comfortable cushion that's more than many people will make in a lifetime.
(The "537 GiB" was, of course, supposed to be "537 GB")
You do know that 99.999% of the world is NOT made up of CS and slashdot geeks,right?
Which is why that 00.001% of the world that is CS and /. geeks should stop contradicting the 99.999% of the world that thinks 'kilo' means 1000. ;-)
(You were being facetious with your percentage, but it only gave me fodder I had to take.)
And you do know that this whole was NOT started to "make things right" or "make the HDDs match the metric system" right? It was.....I know this will be a shocker,wait for it......MARKETING!
Oh, I fully agree. The HDD manufacturers were certainly right for the wrong reason... but they're still right.
Now back to your first point. I agree that there should be a label on the boxes, but only because most OSes "still" report in base-2 units. It's for that reason that the labels are required, not because they're selling you less than they say or something like that (because I still maintain they aren't). I also think more consumer friendly labeling would be nice. For instance, put on the label "500 GiB / 537 GiB" or something. (Though maybe we'd disagree on whether that was more consumer friendly, I suspect it would at least help during those obnoxious support calls.)
So what? You think the executives who actually caused the mess would be really hurt by their company going out of business? They'd just go on to screw the next company. No, if the banks and such had actually gone out of business, the people who'd have been hurt would have been everyone who doesn't make decisions and is making enough to live but not get rich, and, if Bernanke et al are to believed, everyone else through the economy going even further into the crapper. (I don't know enough about the economy to know how realistic this is.)
In short, you're way less cynical than I am if you think that letting the banks go out of business would have caused other companies in the future to go "you know, let's give up significant short term gain for longer term stability."
So anything with BYTE in it should be on orders of 8,NOT ten.
Oh, and just out of curiosity, how big should a kilobyte have been on the CDC 6600, which used "byte" to refer to a 12-bit entity? Should it have been 1728 bytes?
If 1024 bothers you, why doesn't the use of "byte" to mean "8 bits" bother you?
Because "byte" didn't already have a well-established meaning of "10 bits" before we decided to make it 8?
So since "comment" isn't an SI unit, "kilocomment" doesn't have a well-defined meaning?
I guess timothy should have defined how many comments are in a kilocomment so I don't interpret it as 934 or 1187 since they are both about a thousand.
The problem isn't that,the problem is their damned box labeling! Have you looked for the "its base 10,not base 2" label on a HDD box lately?
My point is that it's dumb that they have to put it on there in the first place.
And as one of the earlier posters pointed out it makes NO damned sense! Because we all know that a BYTE is 8 bits,yes? So anything with BYTE in it should be on orders of 8,NOT ten.
1) Why? What does the number of bits in a byte have to do with the number of bytes in a kilobyte?
2) You're still wrong, because kilo- isn't an order of 8 (unless you count fractional ones; 1024 = 8^(3 1/3)). Maybe a kilobyte should be 512 bytes, because that's the closest power of eight to 1000.
So the word simply doesn't work.
So we're agree. We shouldn't use "kilobyte".
And as another poster pointed out with the Tb range becoming common the difference is really becoming staggering.
Yeah, that was me. Which is why we should stop using what are base-10 prefixes everywhere else (and aren't even uniformly base 2 in CS, even outside of HDDs) to mean things that aren't base 10!
First of all (A) it was a joke,which not surprisingly the mods didn't get so I'm surprised you even got to see it at all.
It's not at -1 yet, and I read at 0.
And (B) it was partly aimed at the asshat HDD manufacturers that put in the teenyiest tiniest letters they can possibly print on the box "Oh,BTW 500Gb isn't ACTUALLY 500Gb,because we don't follow the same rules as every OS ever made."
I have two responses: (1) so it was a joke, but it really wasn't a joke. (2) But it is actually 500 GB, or at least would be if CS people were sane. It wasn't so bad with kilo, but now that we're often measuring data in terabytes, the error is ridiculous... almost 10%! Even GB is 7% off. It's long past time to drop using base 10 prefixes that have had meanings for hundreds of years for things that aren't base 10. The HDD manufactures are right, it's the OSes that are lying.
What I don't understand is why we allowed some asshole RAM and HDD manufacturers to steal our word?
Speaking as someone who grew up learning that "kilo-" means 1000, what I don't understand why we allowed some asshole CS people to steal our prefix?
I can't speak to the Blackberry, but I have a Motorola Razr and I'm rather disappointed by the stuff along this line. I've missed calls because it's rung too quietly, and I've almost missed calls because I didn't notice it vibrating in my pocket. (I'm 6' and 170, so hardly overweight.)
But it is not possible for garbage collection to perform better than a competent engineer.
It is. In addition to the link posted by the other reply, I've got another argument. I think a lot of this comes from here though I haven't looked at that page for a while.
First, realize that memory allocation in a C world can actually be fairly expensive. I've been tangentially related to a program where the team responsible for it saw a substantial performance improvement simply by switching malloc implementations. Current malloc implementations can be fairly complex, using one of several allocation strategies depending on the size.
By contrast, a malloc in a GC'd language can be dirt simple; in almost-C pseudocode:
Basically, just keep advancing a pointer.
Second, deletion in the C malloc world can also be expensive for the same reason allocation is. (In that case depending on the allocation strategy you also have to coalesce neighboring blocks, etc.) Deletion in the GC world -- in the strictest sense -- is free, because the GC will do nothing. If we want to be more fair we compare C's deletion costs to GC costs. There C will usually, but depending on the memory behavior, perhaps not by as much as you'd think. If the program allocates a lot of short-lived objects, that's a lot of deletion work that C will have to do but a GC'd program won't, because the GC cost is only determined by the live objects. Sure each live object will be much more expensive than a C delete, but there could be far fewer of them.
Third, I would argue that to be correct, a C program needs to behave correctly with respect to deleting stuff, or else a long-lived process could run out of memory or start using enough that the system starts behaving very poorly. But at the same time, it's easy to see program types out there that are very short-lived; most of the standard Unix utilities fit this bill. In a GC'd world, it's entirely possible for such a process to have zero deletion cost period if the GC is never invoked. The C version is chugging around deleting things because it needs to in order to be safe, but the GC version is being more optimistic in the sense that it doesn't bother incurring any cost until it figures out that the process is using too much memory. In the case where the process is short lived it wins: the C program incurs extra cost from all its allocation and deallocation, while the GC version incurs none. In the long-lived case, the GC version still behaves correctly and won't put the sort of pathologically bad memory pressure that the C version would have if you didn't delete stuff.
(It is true that in practice this benefit basically isn't seen because languages with GC tend to also have large VMs that take a while to start up and will greatly overshadow the allocation costs the C program incurs.)
Fourth, the extra cost of getting memory allocation right can easily come at the expense of other optimizations that someone working in a GC language would have time to do, or bugs that the GC developer would have time to fix, or features that the GC developer would have time to implement. It's true that this doesn't apply in the sort of ideal "give a great C programmer and a great GC language programmer the same task, give them as much time as they need, and measure the result" problem, but it the real world it still matters.
Now, the concession. I still suspect that almost all the time, a well-written program written in a manually-managed language will win out over an equally well-written version in a GC'd language. But at the same time, this is far from necessarily the case.
Funniest post I've seen in a while; thanks.
As many others have brought up, is "school" just a nice way of saying "slave labor"? Or alternately, is "taxes" just a nice way of saying "slave labor"?
I'll admit that these examples are far-fetched, but I don't think either is substantially more ridiculous than yours.
We're requiring people to do manual labor?!
The other reply said how stupid and irrational you're being there better than I can, but I'll add another example. When I did the mandatory community service when I was in high school, it was going to another school and helping to run chess club, teaching chess and stuff like that.
This effectively adds another 30 people in front of you, pushing you back another 30 minutes, while speeding them up about an hour and a half.
It gets worse when people start to give birth.
You forgot to chsh to zsh
I think there's probably a better way, but describe-bindings (also accessible from the help menu, describe, list key bindings) will list all current bindings, then you can search for the command.
Indeed. Probably because Vi is a popular and usable text editor (unlike Emacs).
To paraphrase Arthur Dent, "this is obviously some strange usage of the word 'usable' that I wasn't previously aware of." ;-)
(I kid, for my preference is Emacs.)
Linux Does have a stable API. What it does lack is a stable binary interface.
As others have said, no it doesn't. From Documentation/stable_api_nonsense.txt:
"Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked."
"As a specific examples of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem."
"Kernel interfaces are cleaned up over time. If there is no one using a current interface, it is deleted."