What you really want is a fixed x cents tax, with x open to discussion. That tax puts an effective limit on the minimum margin required to make a purchase/sell pair profitable.
Except you're not looking at the temperature as a whole. Idea is that if, say, you have fluctuations on the magnitude of 1 degree, you're measuring what's happening at the 10^-2 degree scale, with a thermometer with 10^-4 degree precision. The idea here is whatever patterns can be discerned are happening at a much higher magnitude, so the third or fourth digit is effectively random, while not measuring at so low a magnitude that any bias in the sensor at close to its rated precision isn't introducing a pattern by itself.
On today's screens, a fairly large section of the population is on a 15" laptop display (If it's that large). And the resolution should be more or less irrelevant. Also, you'll find that Fitts's law is pretty universal, tiny screens don't come into it. Whether the size of desktop displays (and, especially, multi-display setups -- you do have a point there!) have enough of an effect that the factors change weight, now that is a discussion worth having.
Or, rather, disassociate processes and windows. (...) So if you have, say, four Word documents open, are there four processes running Word, or just one?
I think you just jumped from UI design to internal software architecture. There's absolutely no reason whatsoever the two should even be related.
Not that this makes the hardware particularly different from other consumer-grade machines. It's perhaps better stated as "the only consumer-grade machines in the market that ship with a flavor of Unix as the native OS". (Well, except for netbooks running Linux; I assume the market in question doesn't include tablets, say.)
You can call the unix box thing whatever you like. What I care about is that I get a unix box where I know for a fact that all the hardware inside will work. And no, tablets don't count. I like the Unix toolchain, I'm not making some philosophical statement over the underpinnings of the OS.
You seem to have gotten the whole point of the menu-on-top thing wrong. It's not a matter of maximizing usable space in a low-res environment, it's a consequence of Fitts's Law: The acquisition time for a target on screen is something like log(distance/size). If the menus were on the windows, the distance would be smaller, but by having the menus against an edge of the screen, you can't overshoot towards the edge, so the target size is effectively infinite. No bad UI about that.
Also, leaving an application running without a UI is a perfectly reasonable idea, once you dissociate applications and windows -- in fact, there are many, many programs that practically demand it (mail, bittorrent, IM in general). If you look at the windows world, this distinction also exists, except that windows handled this in a completely hackish way until Windows 7, which was via the system tray icons. Windows 7 finally supports windowless applications properly, though that's a recent advance and many applications still don't support it. I can't honestly think of any non-X11 applications that actually close completely when you close the last window.
All in all, though, I agree: the best part of modern Macs is what's underneath the hood. They're effectively the only consumer-grade machines in the market that are purpose-made to run Unix.
Did you for even a second believe most of those rumours?
4" display? That'd imply changing to a lower dpi display to keep the resolution of the iphone 4 (which they would be quite unlikely to do -- the display's a strong selling point!), or, much worse, keep the dpi and increase the resolution, and break the nice resolution arrangement that exists right now, with the newer devices being exactly twice the resolution of the older ones.
It's also pretty obvious from the 3DS that the glassless 3D idea is a gimmick that doesn't push devices. Plus it'd require developing the 3d for apps, that'd further fracture the developing effort.
NFC I thought was a possibility, if somewhat forward for Apple's style. I can't recall them being early adopter for any tech at all in the last few years. They're usually either pioneers or late to the game, but 4G was definitely a no-go. There's no such thing as a well-defined 4G standard, there's only a handful of competing technologies. I'm pretty sure Apple will only join in on the 4G party once the dust has settled on a more global scale.
How come those who develop for different browsers find there's quite a number of pros and cons for each of the major browsers? Because they take the time to try and test them. Not just talk out their asses.
Some of us have all three of Chrome, FF and Opera installed (and use all three regularly) because each of the three debuggers has some features the others don't and using all three is the easiest way to track down obscure bugs. Oh, and there's also that stupid VM with IE, because we can't just get rid of it.
Here's how you can make private/privileged methods and fields, and also how to make getters/setters in javascript:
MyNS.MyObject = function(p1, p2) {
var privateProp1, privateProp2;
function privateMethod1(pa) {
privateProp1 = pa
}
this.privilegedMethod = function() {
privateMethod(1);
}
this.__defineSetter__("prop2", function(a) {privateProp2 = a;});
this.__defineGetter__("prop2", function() {return privateProp2;});
this.prop1 = "foo";
this.prop2 = "bar";
}
If you control 60% of the advertising space, then you should be able to charge a premium to your direct competition (and anybody else for that matter). Microsoft is directly in competition with Google in almost every way, and Google should not be forced to be "fair". If Microsoft really wants to advertise on Google that bad, then they had better be ready to pony up and make it worth Google's handful of lost customers.
The IE problem was a matter of leveraging a monopoly. IE played on both the Operating System and Web Browser markets, and had a monopoly on operating systems. The issue with bundling IE with Windows was that it unfairly leveraged the OS monopoly to boost its presence in the Web Browser market.
What's happening with google is that they arguably have a monopoly on both the Online Advertising and Web Search markets. Microsoft needs to advertise Bing in order to successfully challenge google on Web Search, but google is using its Online Advertising monopoly to prevent that -- which, to me, sounds like leveraging a monopoly (though this time around the leveraging is defensive, with Google trying to keep its search monopoly, rather than Microsoft's offensive leveraging aimed at conquering a position in the browser market)
You completely missed the point. The 99th percentile frame rendering time gives you a reasonable approximation of 1/fps. What we REALLY want to know about is those few frames that fall above the 99th percentile -- those are the ones that cause stuttering.
Functional is new relative to OOP? The 1950s called, they said to rub Lisp in your face. Functional is also in no way, shape or form a superset of OOP. You can emulate OOP with functional code alone, but that's about how close the two are.
Unfortunately, several studies (at least one was covered here on slashdot) indicate the vast majority of Java development runs on the same platform on which it was written.
That it may be. But "the vast majority" doesn't mean "the totality". I personally develop software on OSX, targeting mostly windows and linux. Yes, I do keep banging my head against the wall over the "run almost anywhere" aspect of it. But, in the vast majority of cases, the fixes to make the code truly portable are tiny.
You evidently didn't RTFA, where the author enumerates a few cases where the glitches in emulation make for either unwinnable games (like Speedy Gonzales) or for materially worse gameplay (like Air Strike Patrol).
because *technically* it's the full Emacs source code all right
Except that, if I wanted to change the grammar, I'd have to plod through the horrid code bison generated rather than the bison grammar files (which are the "true" source) so even technically it's no more the full Emacs source code than releasing the unassembled ASM output of gcc would be the full source for a C program. In this case, the common technical definition and the legal definition seem to be in unison.
Git provides easy tools for hero developers to go off and do their own hero work and drop it all in one go onto everyone else. How is this a good thing?
On the contrary. Git makes it so easy to branch and then merge that branch back that I branch when I feel the need to (which means for most largish feature development), and, since merging the branch back isn't painful at all, I don't delay doing it any more than the actual development work requires. Since it's so cheap to branch off, I can keep partial, non-functioning work committed and pushed without fear of breaking other people's code. How is that promoting bad behaviour?
1. The Canadian government will rule that nobody in the Canadian government did anything wrong, after all they just were acting on info from the US.
Funnily enough, half of the the document was precisely the judge slamming all people involved for not actually looking at the "info from the US" with a critical eye. Unfortunately, points 2 and 3 seem likely enough.
IMOHO, aside from the basic entertainment value provided by Mythbusters, their primary merit is that it allows people to understand they can apply some of the lessons learned from their science class to solve and/or explore real world problems, even if you don't rigorously apply the scientific method in doing so. Science can be fun. That message alone is worth something.
The "science is fun" message is worth loads, but the show's core concept also transmits the most fundamental tenet of science: don't believe in things just because. Try them out, test them, and discard as false the results you can't reproduce unless and until someone can show you why you weren't managing to reproduce them.
Not to mention what TFA neglects is the simple fact that one doesn't need as much memory as they do storage space so comparing the two? More than a little pointless.
My interpretation of the article is as follows: In any given workload, you're likely to have a mixture of memory operations and disk operations. If, instead of putting all your money on RAM that will speed up your memory operations, you put part of it into an SSD that will speed up your disk operations, the overall performance for that workload will be better. Prefetching programs doesn't do nearly enough if the workload involves more disk activity than just loading the code.
Not sure I agree with the article, but the point is a lot better than you were making out to be.
Slashdot Mirror
Games. I tried migrating towards consoles, but certain key games are still PC-specific.
0.1% * 1000$ * 1 transaction = 1$ tax.
0.1% * 1$ * 1000 transactions = 1$ tax.
What you really want is a fixed x cents tax, with x open to discussion. That tax puts an effective limit on the minimum margin required to make a purchase/sell pair profitable.
Except you're not looking at the temperature as a whole. Idea is that if, say, you have fluctuations on the magnitude of 1 degree, you're measuring what's happening at the 10^-2 degree scale, with a thermometer with 10^-4 degree precision. The idea here is whatever patterns can be discerned are happening at a much higher magnitude, so the third or fourth digit is effectively random, while not measuring at so low a magnitude that any bias in the sensor at close to its rated precision isn't introducing a pattern by itself.
How would pseudo-random numbers fit into that theory? That have all the outwards appearance of randomness, all the while being a very precise pattern.
On today's screens, a fairly large section of the population is on a 15" laptop display (If it's that large). And the resolution should be more or less irrelevant. Also, you'll find that Fitts's law is pretty universal, tiny screens don't come into it. Whether the size of desktop displays (and, especially, multi-display setups -- you do have a point there!) have enough of an effect that the factors change weight, now that is a discussion worth having.
Or, rather, disassociate processes and windows. (...) So if you have, say, four Word documents open, are there four processes running Word, or just one?
I think you just jumped from UI design to internal software architecture. There's absolutely no reason whatsoever the two should even be related.
Not that this makes the hardware particularly different from other consumer-grade machines. It's perhaps better stated as "the only consumer-grade machines in the market that ship with a flavor of Unix as the native OS". (Well, except for netbooks running Linux; I assume the market in question doesn't include tablets, say.)
You can call the unix box thing whatever you like. What I care about is that I get a unix box where I know for a fact that all the hardware inside will work. And no, tablets don't count. I like the Unix toolchain, I'm not making some philosophical statement over the underpinnings of the OS.
You seem to have gotten the whole point of the menu-on-top thing wrong. It's not a matter of maximizing usable space in a low-res environment, it's a consequence of Fitts's Law: The acquisition time for a target on screen is something like log(distance/size). If the menus were on the windows, the distance would be smaller, but by having the menus against an edge of the screen, you can't overshoot towards the edge, so the target size is effectively infinite. No bad UI about that.
Also, leaving an application running without a UI is a perfectly reasonable idea, once you dissociate applications and windows -- in fact, there are many, many programs that practically demand it (mail, bittorrent, IM in general). If you look at the windows world, this distinction also exists, except that windows handled this in a completely hackish way until Windows 7, which was via the system tray icons. Windows 7 finally supports windowless applications properly, though that's a recent advance and many applications still don't support it. I can't honestly think of any non-X11 applications that actually close completely when you close the last window.
All in all, though, I agree: the best part of modern Macs is what's underneath the hood. They're effectively the only consumer-grade machines in the market that are purpose-made to run Unix.
It's an extension.
Did you for even a second believe most of those rumours?
4" display? That'd imply changing to a lower dpi display to keep the resolution of the iphone 4 (which they would be quite unlikely to do -- the display's a strong selling point!), or, much worse, keep the dpi and increase the resolution, and break the nice resolution arrangement that exists right now, with the newer devices being exactly twice the resolution of the older ones.
It's also pretty obvious from the 3DS that the glassless 3D idea is a gimmick that doesn't push devices. Plus it'd require developing the 3d for apps, that'd further fracture the developing effort.
NFC I thought was a possibility, if somewhat forward for Apple's style. I can't recall them being early adopter for any tech at all in the last few years. They're usually either pioneers or late to the game, but 4G was definitely a no-go. There's no such thing as a well-defined 4G standard, there's only a handful of competing technologies. I'm pretty sure Apple will only join in on the 4G party once the dust has settled on a more global scale.
It might blow your mind to know that, for many people, $100 isn't pocket change.
How come those who develop for different browsers find there's quite a number of pros and cons for each of the major browsers? Because they take the time to try and test them. Not just talk out their asses.
Some of us have all three of Chrome, FF and Opera installed (and use all three regularly) because each of the three debuggers has some features the others don't and using all three is the easiest way to track down obscure bugs. Oh, and there's also that stupid VM with IE, because we can't just get rid of it.
And now in a readable format:
MyNS.MyObject = function(p1, p2) {
var privateProp1, privateProp2;
function privateMethod1(pa) {
privateProp1 = pa
};
this.privilegedMethod = function() { privateMethod(1); };
this.__defineSetter__("prop2", function(a) {
privateProp2 = a;
});
this.__defineGetter__("prop2", function() {
return privateProp2;
});
this.prop1 = "foo";
this.prop2 = "bar";
}
Here's how you can make private/privileged methods and fields, and also how to make getters/setters in javascript: MyNS.MyObject = function(p1, p2) { var privateProp1, privateProp2; function privateMethod1(pa) { privateProp1 = pa } this.privilegedMethod = function() { privateMethod(1); } this.__defineSetter__("prop2", function(a) {privateProp2 = a;}); this.__defineGetter__("prop2", function() {return privateProp2;}); this.prop1 = "foo"; this.prop2 = "bar"; }
If you control 60% of the advertising space, then you should be able to charge a premium to your direct competition (and anybody else for that matter). Microsoft is directly in competition with Google in almost every way, and Google should not be forced to be "fair". If Microsoft really wants to advertise on Google that bad, then they had better be ready to pony up and make it worth Google's handful of lost customers.
The IE problem was a matter of leveraging a monopoly. IE played on both the Operating System and Web Browser markets, and had a monopoly on operating systems. The issue with bundling IE with Windows was that it unfairly leveraged the OS monopoly to boost its presence in the Web Browser market.
What's happening with google is that they arguably have a monopoly on both the Online Advertising and Web Search markets. Microsoft needs to advertise Bing in order to successfully challenge google on Web Search, but google is using its Online Advertising monopoly to prevent that -- which, to me, sounds like leveraging a monopoly (though this time around the leveraging is defensive, with Google trying to keep its search monopoly, rather than Microsoft's offensive leveraging aimed at conquering a position in the browser market)
Also, Steam.
You completely missed the point. The 99th percentile frame rendering time gives you a reasonable approximation of 1/fps. What we REALLY want to know about is those few frames that fall above the 99th percentile -- those are the ones that cause stuttering.
Functional is new relative to OOP? The 1950s called, they said to rub Lisp in your face. Functional is also in no way, shape or form a superset of OOP. You can emulate OOP with functional code alone, but that's about how close the two are.
Unfortunately, several studies (at least one was covered here on slashdot) indicate the vast majority of Java development runs on the same platform on which it was written.
That it may be. But "the vast majority" doesn't mean "the totality". I personally develop software on OSX, targeting mostly windows and linux. Yes, I do keep banging my head against the wall over the "run almost anywhere" aspect of it. But, in the vast majority of cases, the fixes to make the code truly portable are tiny.
You evidently didn't RTFA, where the author enumerates a few cases where the glitches in emulation make for either unwinnable games (like Speedy Gonzales) or for materially worse gameplay (like Air Strike Patrol).
Good code is self documenting
No it's not. Good code can make it obvious how you're doing things, but it can never explain why.
because *technically* it's the full Emacs source code all right
Except that, if I wanted to change the grammar, I'd have to plod through the horrid code bison generated rather than the bison grammar files (which are the "true" source) so even technically it's no more the full Emacs source code than releasing the unassembled ASM output of gcc would be the full source for a C program. In this case, the common technical definition and the legal definition seem to be in unison.
Git provides easy tools for hero developers to go off and do their own hero work and drop it all in one go onto everyone else. How is this a good thing?
On the contrary. Git makes it so easy to branch and then merge that branch back that I branch when I feel the need to (which means for most largish feature development), and, since merging the branch back isn't painful at all, I don't delay doing it any more than the actual development work requires. Since it's so cheap to branch off, I can keep partial, non-functioning work committed and pushed without fear of breaking other people's code. How is that promoting bad behaviour?
1. The Canadian government will rule that nobody in the Canadian government did anything wrong, after all they just were acting on info from the US.
Funnily enough, half of the the document was precisely the judge slamming all people involved for not actually looking at the "info from the US" with a critical eye. Unfortunately, points 2 and 3 seem likely enough.
IMOHO, aside from the basic entertainment value provided by Mythbusters, their primary merit is that it allows people to understand they can apply some of the lessons learned from their science class to solve and/or explore real world problems, even if you don't rigorously apply the scientific method in doing so. Science can be fun. That message alone is worth something.
The "science is fun" message is worth loads, but the show's core concept also transmits the most fundamental tenet of science: don't believe in things just because. Try them out, test them, and discard as false the results you can't reproduce unless and until someone can show you why you weren't managing to reproduce them.
Not to mention what TFA neglects is the simple fact that one doesn't need as much memory as they do storage space so comparing the two? More than a little pointless.
My interpretation of the article is as follows: In any given workload, you're likely to have a mixture of memory operations and disk operations. If, instead of putting all your money on RAM that will speed up your memory operations, you put part of it into an SSD that will speed up your disk operations, the overall performance for that workload will be better. Prefetching programs doesn't do nearly enough if the workload involves more disk activity than just loading the code.
Not sure I agree with the article, but the point is a lot better than you were making out to be.