Goodness me, that is the most chafed neckbeard I have ever seen! How do you cope?!
"iPods were popular but shit" is just a weak argument. It works better with hipster glasses, but then, I thought it was all the Apple users who were the hipsters. I get so confused!
The amount of butthurt from nerds on slashdot over the success of the iPod and subsequent iOS devices is hilarious.
oooh. Flamebait if I ever saw one. I think parent was pretty reasonable in his/her comment.
The tangible sense of "not getting it" swirls around like a dark cloud, just because something became popular that wasn't exactly what you wanted from a product, thus it is impossible to believe that the success is down to anything other than marketing to braindead consumers.
Actually, it's quite easy to come up with examples of when the general consumer... consumes... substandard stuff rather than the good stuff.
Beer. Budweiser (the American variant) is the most sold in the world.
Audio. Range compression (english term?) makes many pop songs sound loud, but make them lose in dynamic range. Consumers in general don't care.
Food. Fast food compared to anything else.
Games. Farmville compared to anything.
Books. Dan Brown... Sigh.
Films.
... and so on.
So.. What makes you so sure parent isn't "getting it"?
Yeah. I trust Tomshardware's tests about as far as I can throw them. They were notoriously Intel-biased during the netburst era. Just google some old tests. It's hilarious.
I love unit testing. It makes me a lot more productive as a coder - especially if I'm revisiting old code. I can make changes pretty freely without having to analyse the code in detail. I hope that establishes me as a unit test proponent. Now, to visit the articles of faith;
(1) - I definitely write unit tests for, and especially involving, private methods. They are typically the most granular, allowing you to test the smallest 'unit', and are doubly interesting because they may capture objects in an 'unclean' state.
(2) I often start off writing a 'UsageTest'-method that isn't a unit test per se, but lets me imagine a usage scenario for an aspect of the class I'm about to create. The 'UsageTest' method puts me in the role of the coder going to use the tested class. It lets me get a feel for how I would want the class to work, for example see which parameters I have convenient access to, rather than which parameters the class would prefer.
The 'UsageTest' method(s) then become some kind of 'Intended Usage' documentation.
I find this to be a pretty good way to keep focus on what you need to implement to make the class work, rather than just creating methods at whim until they can be refactored and coerced into a workflow.
Not trying to pick a fight here, but I don't think this computes unless you change your mind about the importance of the CPU's computational power, or take some other - not yet mentioned - factor(*) into consideration.
Eg: If the user intends to get a discrete GPU, as you say, s/he will have approx $150 more to spend on the GPU if s/he picks the AMD solution. A $250 GPU vs. a $100 GPU is a pretty significant difference. Thus if graphics matter, the user should pick the AMD solution.
(*) of which there is possibly a boatload to consider. Socket longevity, thermal design power, ability to build a quiet system, ability to use ECC memory, etc. Not only price, but also many 'features' favor AMD since AMD tends to enable ECC, AMD-V and such in consumer CPUs, whereas you have to step up to Xeons to get that from Intel. However, some properties such as Computational power per Watt tend to favor Intel in a significant way. Where I think we agree, is that with Intel you can get pretty much everything you can get from AMD, provided you're willing to spend the money (Eg. step up to a Xeon CPU, add a discrete graphics card).
Not only that, but it will save ~$100 on the CPU and ~$50 more on the motherboard. That's GREAT advice.
But no.. Then we hear this;
If graphics are a big concern, they should get a cheap discrete card as one under $100 will be good for most games. Thus AMD's advantage is negated.
Ummm.. First you made a good case for AMD, and now you're saying they should pick Intel anyway, and not only that, They should cough up an extra $100 on top of the ~$150 extra they already need to cough up, just to negate AMD's advantage. WTF? Why not just pick AMD in the first place then?
I have this same problem with a regular mouse, and would not put it down to input lag, but to the 'grip' point being so small.
I think it has something to do with the scroll bars disappearing. At about the same time it became hard to resize windows unless you grabbed in the title bar.
I knew IBM S/390 has had it for ages, but was older than I thought;
From http://en.wikipedia.org/wiki/Hypervisor
"The first hypervisors providing full virtualization, were the test tool, SIMMON, and IBM's one-off research CP-40 system, which began production use in January 1967, and became the first version of IBM's CP/CMS operating system."
I program primarily in C#, but I actully prefer 'End (keyword)' to the closing curly braces. This is especially true when I'm debugging legacy/spaghetti code.
Compare this:
End Loop
End If
End If
End Loop End Class
to this
}
}
}
} }
Which conveys more information?
Which makes it easier to find where to insert that pesky 'a++' that someone forgot?
Just because he was having a camera, does not mean he is recording anything. Next you will want to assault anyone talking on a smartphone. After all it also has camera and he might be just faking the conversation.
If you're talking in a mobile phone, it doesn't look like you're recording, and people will probably give you the benefit of a doubt. If - on the other hand - you have a head-mounted camera, it looks like you may be recording all the time. (Which he also was, so the perpetrators' misgivings about being filmed were not only easier to understand, they were also correct.)
RTFA. It clearly says that it only records the images when it detects being damaged.
RTFA yourself. Images are being recorded all the time. The images published on the website were saved because they weren't overwritten. That's different from 'not being recorded'.
To me it seems the Mann guy acted like a moron, but I wasn't there, and there's only one source for the story.
One thing that bothers me about his story is the way he touts the 'paper written by his doctor'. The camera is obviously not mounted there for medical purposes, so in what way is it significant that the paper is written by a doctor? It seems Mann uses the doctor-title rather than the contents of the paper to try to trump us into believing it is significant.
Of course, what bothers me most is how he walks around visiting and filming in various places where he shouldn't, just because he himself has designed the glasses so they can't be removed. That the camera is non-removable does not make it OK.
It would be nice if someone could design an EMP generator, mount it in a non-removable fashion to their body, and then go visit this Mann chap, and dissuade any protests from him by touting a paper from a hockey goalie.
I don't read it that way. I read it as:
(i) An implementation doesn't necessarily have to use MS patents, and even if it does, those patents aren't necessarily enforceable.
(ii) MS can't guarantee that an implementation doesn't infringe on third parties' claims. ... followed by some (standard?) legalese that the document only covers the things that the document actually covers.
While writing this, I had to backtrack to find the legal document, and noticed your other posts about MONO. Are you just trolling?
Is the middle of a game testing your patience? Then why not sell it back to your local game shop, get money back in your pocket, or trade it in for a game that's better – or at least better suited for your tastes?
Anybody want a slightly used middle of a game? Willing to trade for a new ending.
I think you misunderstood me. I'm not advocating anything. I just pointed out a (huge) flaw in the original analogy.
With that said, I'll try to answer anyway.
would that mean that a given combination of ingredients/techniques should now be provided protection under the law?
I'll avoid the 'should' and just say that I'm pretty sure it would be more of a question of 'What is enforceable', rather than some ethical discussion/decision.
would there no longer be cause for people to further develop recipes if anybody could trivially reproduce them at the proper level of quality?
Hardly. People enjoy food. People enjoy cooking. Provided there was no major cost involved in producing a recipe at that level of detail, I'd happily make and share recipes with anyone who would want them.
Well.. The analogy does have its flaws. There's nothing stopping you from playing whatever music you like on your own guitar.
The analogy would be a lot more similar to what we're originally discussing if there was a cheap microwave we could feed the recipe into, which would then cook us a meal from the recipe - a LOT better than you typically could cook it yourself.
(Provided you also invested enough money in gourmet peripherals, such as gold-plated power cables, you could fool yourself into thinking the meal was actually as good as if made by the chef himself.)
If you have read the 'readme' and still not found the solution to the problem because it was in the 'README' or vice versa, then you know it can be a problem. I honestly don't see how a case-sensitive file system is beneficial to users. It just gives an extra dimension to make things less clear. Anyone care to explain the benefits?
Say what? The linked article proposes using return values (that will be ignored) instead of exceptions. If you wanted to discredit the use of try/catch, you need to find a better link.
(Or is the article supposed to be ironic? It looks genuine. If not, a big whoosh on me...)
I'm curious, is there any mode or plugin except the "It's open source, make it yourself"-plugin to make Vi/Vim/Emacs support 'intelligent search/replace' or other quick refactorings? By that, I don't mean regexps, I mean that the editor actually has deeper knowledge of the language you're editing, and can help you change the name of a type in a specific namespace, without touching any methods or variables or other strings in the code that happen to have the same name as the type. Or change the method name on this particular type, but not the methods with the same names on other types, etc. Over an entire project with multiple sub-projects.
To me, (and probably anyone who refactors code), this is a huge time-saver compared to standard search/replace. Also, I imagine this would be hard to implement as a plugin to Vi/Vim/emacs if you let the tool chain be totally replaceable links - e.g. how do you determine which files are part of the project and need to be looked through, if you can use any one of a pretty large number of tools that can do the work of 'make'?
(I may be wrong. I used emacs/make etc. on SunOS until the early 90s, then moved on to Windows in mid/late 90's, and am now moving back to the *nix-world again, so I've been out of the loop for quite some time. Maybe this type of functionality is now standard in Vi/Vim/emacs too...)
Basically, an IDE sets a standard that makes it possible to ignore some of the most basic problems and instead concentrate on solving higher-level problems. I think this is a good thing (tm). I also don't value 'understanding the build process' that highly. I've been around enough that I happen to understand it (should probably qualify that with a 'most of the time'), but I'm not sure that it's been all that useful since I started using IDEs. Most of the time the build broke before, it was because I did something stupid in the makefile. An IDE typically handles all that for you. I do not miss editing makefiles.
Slashdot Mirror
Don't forget ECC/REG memory. That only seems to be available if you buy Xeons. And the new i7 4770K doesn't even have VT-x enabled. (GAH!)
oooh. Flamebait if I ever saw one. I think parent was pretty reasonable in his/her comment.
Actually, it's quite easy to come up with examples of when the general consumer... consumes... substandard stuff rather than the good stuff.
So.. What makes you so sure parent isn't "getting it"?
Yeah. I trust Tomshardware's tests about as far as I can throw them. They were notoriously Intel-biased during the netburst era. Just google some old tests. It's hilarious.
Sounds like someone did something with Facebook graph search.
I love unit testing. It makes me a lot more productive as a coder - especially if I'm revisiting old code. I can make changes pretty freely without having to analyse the code in detail. I hope that establishes me as a unit test proponent. Now, to visit the articles of faith;
(1) - I definitely write unit tests for, and especially involving, private methods. They are typically the most granular, allowing you to test the smallest 'unit', and are doubly interesting because they may capture objects in an 'unclean' state.
(2) I often start off writing a 'UsageTest'-method that isn't a unit test per se, but lets me imagine a usage scenario for an aspect of the class I'm about to create. The 'UsageTest' method puts me in the role of the coder going to use the tested class. It lets me get a feel for how I would want the class to work, for example see which parameters I have convenient access to, rather than which parameters the class would prefer.
The 'UsageTest' method(s) then become some kind of 'Intended Usage' documentation.
I find this to be a pretty good way to keep focus on what you need to implement to make the class work, rather than just creating methods at whim until they can be refactored and coerced into a workflow.
Not trying to pick a fight here, but I don't think this computes unless you change your mind about the importance of the CPU's computational power, or take some other - not yet mentioned - factor(*) into consideration.
Eg: If the user intends to get a discrete GPU, as you say, s/he will have approx $150 more to spend on the GPU if s/he picks the AMD solution. A $250 GPU vs. a $100 GPU is a pretty significant difference. Thus if graphics matter, the user should pick the AMD solution.
(*) of which there is possibly a boatload to consider. Socket longevity, thermal design power, ability to build a quiet system, ability to use ECC memory, etc. Not only price, but also many 'features' favor AMD since AMD tends to enable ECC, AMD-V and such in consumer CPUs, whereas you have to step up to Xeons to get that from Intel. However, some properties such as Computational power per Watt tend to favor Intel in a significant way. Where I think we agree, is that with Intel you can get pretty much everything you can get from AMD, provided you're willing to spend the money (Eg. step up to a Xeon CPU, add a discrete graphics card).
Ok. Noted. Either will do fine CPU-wise.
Ah. Great. So AMD is the better buy then.
Not only that, but it will save ~$100 on the CPU and ~$50 more on the motherboard. That's GREAT advice.
But no.. Then we hear this;
Ummm.. First you made a good case for AMD, and now you're saying they should pick Intel anyway, and not only that, They should cough up an extra $100 on top of the ~$150 extra they already need to cough up, just to negate AMD's advantage. WTF? Why not just pick AMD in the first place then?
I have this same problem with a regular mouse, and would not put it down to input lag, but to the 'grip' point being so small.
I think it has something to do with the scroll bars disappearing. At about the same time it became hard to resize windows unless you grabbed in the title bar.
But only appropriately tagged spoilers! I want to read the book first.
I knew IBM S/390 has had it for ages, but was older than I thought; From http://en.wikipedia.org/wiki/Hypervisor
"The first hypervisors providing full virtualization, were the test tool, SIMMON, and IBM's one-off research CP-40 system, which began production use in January 1967, and became the first version of IBM's CP/CMS operating system."
"End"
I'm surprised by this.
I program primarily in C#, but I actully prefer 'End (keyword)' to the closing curly braces. This is especially true when I'm debugging legacy/spaghetti code.
Compare this:
End Loop
End If
End If
End Loop
End Class
to this
}
}
}
}
}
Which conveys more information?
Which makes it easier to find where to insert that pesky 'a++' that someone forgot?
Just because he was having a camera, does not mean he is recording anything. Next you will want to assault anyone talking on a smartphone. After all it also has camera and he might be just faking the conversation.
If you're talking in a mobile phone, it doesn't look like you're recording, and people will probably give you the benefit of a doubt. If - on the other hand - you have a head-mounted camera, it looks like you may be recording all the time. (Which he also was, so the perpetrators' misgivings about being filmed were not only easier to understand, they were also correct.)
RTFA. It clearly says that it only records the images when it detects being damaged.
RTFA yourself. Images are being recorded all the time. The images published on the website were saved because they weren't overwritten. That's different from 'not being recorded'.
To me it seems the Mann guy acted like a moron, but I wasn't there, and there's only one source for the story.
One thing that bothers me about his story is the way he touts the 'paper written by his doctor'. The camera is obviously not mounted there for medical purposes, so in what way is it significant that the paper is written by a doctor? It seems Mann uses the doctor-title rather than the contents of the paper to try to trump us into believing it is significant.
Of course, what bothers me most is how he walks around visiting and filming in various places where he shouldn't, just because he himself has designed the glasses so they can't be removed. That the camera is non-removable does not make it OK.
It would be nice if someone could design an EMP generator, mount it in a non-removable fashion to their body, and then go visit this Mann chap, and dissuade any protests from him by touting a paper from a hockey goalie.
A bit too trigger happy. Sorry about that.
You're wrong. There is a pattern even in the single-shot experiment.
At least during work hours.
I don't read it that way. I read it as:
... followed by some (standard?) legalese that the document only covers the things that the document actually covers.
(i) An implementation doesn't necessarily have to use MS patents, and even if it does, those patents aren't necessarily enforceable.
(ii) MS can't guarantee that an implementation doesn't infringe on third parties' claims.
While writing this, I had to backtrack to find the legal document, and noticed your other posts about MONO. Are you just trolling?
Interesting. You're putting the blame on the people who have to fight uphill.
It's a lot more difficult to organize enough voters to be heard when you don't have a fat wallet behind you.
Is the middle of a game testing your patience? Then why not sell it back to your local game shop, get money back in your pocket, or trade it in for a game that's better – or at least better suited for your tastes?
Anybody want a slightly used middle of a game? Willing to trade for a new ending.
With that said, I'll try to answer anyway.
would that mean that a given combination of ingredients/techniques should now be provided protection under the law?
I'll avoid the 'should' and just say that I'm pretty sure it would be more of a question of 'What is enforceable', rather than some ethical discussion/decision.
would there no longer be cause for people to further develop recipes if anybody could trivially reproduce them at the proper level of quality?
Hardly. People enjoy food. People enjoy cooking. Provided there was no major cost involved in producing a recipe at that level of detail, I'd happily make and share recipes with anyone who would want them.
Now, please leave the analogy. It is flawed.
Well.. The analogy does have its flaws. There's nothing stopping you from playing whatever music you like on your own guitar.
The analogy would be a lot more similar to what we're originally discussing if there was a cheap microwave we could feed the recipe into, which would then cook us a meal from the recipe - a LOT better than you typically could cook it yourself.
(Provided you also invested enough money in gourmet peripherals, such as gold-plated power cables, you could fool yourself into thinking the meal was actually as good as if made by the chef himself.)
If you have read the 'readme' and still not found the solution to the problem because it was in the 'README' or vice versa, then you know it can be a problem. I honestly don't see how a case-sensitive file system is beneficial to users. It just gives an extra dimension to make things less clear. Anyone care to explain the benefits?
..which also describes your post perfectly.
Ugh. Magic invisible gotos FTW!
Say what? The linked article proposes using return values (that will be ignored) instead of exceptions. If you wanted to discredit the use of try/catch, you need to find a better link.
(Or is the article supposed to be ironic? It looks genuine. If not, a big whoosh on me...)
I'm curious, is there any mode or plugin except the "It's open source, make it yourself"-plugin to make Vi/Vim/Emacs support 'intelligent search/replace' or other quick refactorings? By that, I don't mean regexps, I mean that the editor actually has deeper knowledge of the language you're editing, and can help you change the name of a type in a specific namespace, without touching any methods or variables or other strings in the code that happen to have the same name as the type. Or change the method name on this particular type, but not the methods with the same names on other types, etc. Over an entire project with multiple sub-projects.
To me, (and probably anyone who refactors code), this is a huge time-saver compared to standard search/replace. Also, I imagine this would be hard to implement as a plugin to Vi/Vim/emacs if you let the tool chain be totally replaceable links - e.g. how do you determine which files are part of the project and need to be looked through, if you can use any one of a pretty large number of tools that can do the work of 'make'?
(I may be wrong. I used emacs/make etc. on SunOS until the early 90s, then moved on to Windows in mid/late 90's, and am now moving back to the *nix-world again, so I've been out of the loop for quite some time. Maybe this type of functionality is now standard in Vi/Vim/emacs too...)
Basically, an IDE sets a standard that makes it possible to ignore some of the most basic problems and instead concentrate on solving higher-level problems. I think this is a good thing (tm). I also don't value 'understanding the build process' that highly. I've been around enough that I happen to understand it (should probably qualify that with a 'most of the time'), but I'm not sure that it's been all that useful since I started using IDEs. Most of the time the build broke before, it was because I did something stupid in the makefile. An IDE typically handles all that for you. I do not miss editing makefiles.
Nonononono. 'WINE', not 'Whine'.