I was going to point out the "MS Stack" problem myself. Seattle is not the place for MS developers because outside of Microsoft, no one uses them. I've gotten interviews with Amazon and it's all Java/Linux/Unix work.
That's all I'm hiring for in Seattle, minus the Java. Linux/Unix, devs, DevOps... and I'm competing quite a bit for top talent.
Translation: If several counterfactual events occur, something might happen.
Counterfactual #1: Disney leaving the Blu-Ray camp. Given the huge investment that Disney's made in Blu-Ray, and given the absence of reason to switch, there doesn't seem like any reason to believe this.
Counterfactual #2: HD-DVD price drops more rapid than Blu-Ray price drops. Actually, I just went through this, and after two days of agonizing I bought Blu-Ray. In part, the $50 difference between the two (on Amazon.com) helped cement that decision. In the future, if the price gap as a percentage stays the same, the difference in player cost is likely to hit $25 or less.
Counterfactual #3: HD-DVD will catch up to Blu-Ray in capacity. Sure, triple-layer HD-DVDs are coming. So are triple-layer Blu-Ray discs, which will once again cause Blu-Ray capacity to blow away HD-DVD. Kinda funny, if "there's no real need to use the extra capacity of Blu-Ray discs." (Have you ever had a disc that you haven't filled?)
Counterfactual #4: Toshiba has any intention of ever lowering HD-DVD license fees. That's their whole reason for pushing the new standard, actually.
Implied counterfactual #5: Sony blew it with Betamax, so they'll blow it again with Blu-Ray. Sure, it's possible. If Sony hasn't learned anything over the last thirty years, and if owning a movie studio and becoming a huge player in the "content" business haven't changed anything.
If you're using Google to write letters and do spreadsheets, congratulations: your desktop is a thin client, and you didn't even know it. Guess thin clients aren't all that bad, huh?
That was the point that the piece on Slate was trying to make, more or less. Did you RTFA?
RDP is hardly the only way to do remote access, and it's true that most Windows-functional solutions (WebEx, PCAnywhere, ThinAnywhere, VNC, etc.) stink, from at least a performance standpoint.
But those aren't really thin clients; they're really remote access sessions to a thick client running over a network.
A real thin-client package does the computing locally, as well as the display. It just uses storage and some heavy features on the back-end.
he expressed the opinion that the best way to get a raise was to jump from job to job
Now, mentioning that while interviewing is in bad taste, but it's actually prettywellestablished that job-hopping increases salaries. (Yes, those reports are essentially anecdotal; I'm unable to find the survey that report similar results right at the moment, but I recall that they're out there.
But, I see one of two things happening. Fear of using the system due to repercussions, or abuse of the system and a very large number of frivolous complaints.
Since these are obvious, don't you think there might be a deterrent effect --- each side afraid to abuse their status because the other side might abuse it, too?
So, I'm afraid that I'm not receiving adequate government research dollars for my proposal on demonstrating that babies are delivered by storks.
As far as I can tell, any of the arguments used to defend anti-Global-Warming scientists can apply equally well to my babies-come-from-storks argument. Saying that the discussion isn't "balanced" and that we need to "teach the debate" or "show both sides" is what you say when you don't have arguments that are strong enough to convince your opponents in debate.
I'd like to keep an open mind on the issue of climate change, but the proponents of no-climate-crisis have failed to convince me, or pretty much anyone else. I'm not sure why we should continue to fund them. Saying that they're not getting their fair say isn't much of an argument.
We were discussing an article whose claim was "These scientists are denied funding, skewing the debate."
Parent post said, this information is not accurate; these supposed pariah scientists are quite well-compensated for their research.
This post says parent post does not rebut the science, but engages in ad hominem attacks. Then it says, "Real believers in global warming should welcome contrary views and science as an opportunity to refute those views and strengthen their own. Instead it's an attack against how they are funded."
Of course, all of this was a discussion on funding, and discussing the science is (strangely) an attempt to distract from the issue actually at hand. Real opponents of global warming should welcome contrary views and science as an opportunity to refuse those views and strengthen their own. Instead it's an attack against how they are funded. (In this case, against their government funding.)
As far as (3), with HandBrake's Intel build available on the web site, I'm able to encode at 30fps+ and still have one processor free to do other tasks. Subjective performance in my foreground tasks is excellent.
Or to put it another way, I was able to rebuild my darwinports on one CPU and at the same time get better peformance out of Monster Fair (a pinball game) running via Rosetta than I managed at native on my 1ghz 12" PowerBook when I needed to quit every other app on the system on the PowerBook.
A lot of the help is more memory --- 2gb versus 1.25gb on the PowerBook (each system was maxed out) --- but a second core makes a big difference, too. No doubt about it, I'm impressed by system performance. I hadn't thought that Monster Fair would be useable running via Rosetta, let alone faster, let alone faster while compiling software on the other CPU.
Well, you'll still be able to buy G4 laptops after the MacBook Pro is released.
The Core Duo-based iMac is released (I have one), and they're still selling the PowerPC-based iMacs. The price on either model is identical; it's just a question of whether you want perfect backwards compatibility or perfect forwards compatibility.
Just the same, the PowerBooks will continue to be sold up through the end of the year. (That's when Jobs says the transition will be "complete," presumably meaning in terms of the Apple product line.)
And, for the record, my new iMac is pretty incredible. Even when running PowerPC software. (The only apps I've got that haven't run are DiskWarrior, presumably because of the new partitioning scheme, and VLC, which starts but has some problems doing the necessary pixel-pushing...)
Well, remember that corn syrup is cheaper than sugar only because of subsidies to corn growers, and because of tariffs on imported cane sugar, to protect the local sugar industry. Without those barriers, we'd likely have real sugar in our sodas.
(That said, if Americans gave a damn about how their sugar-water tasted, the soda companies would pony up the couple of extra cents to give us real sugar... but obviously it doesn't give them any sort of competitive advantage to do so.)
Since my book is not aimed directly at programmers, I didn't cover reading source code. I did cover basic instructions for debugging documentation when it's wrong, though.
but come on; its blindingly obvious from Anadtech's testing that Mac OS X has got a performance problem around processes/thread creation.
Look, we know it has a problem around process creation. That's not been news for a very long time. Where am I in denial about this?
My only comment amounted to wondering what the basis was to believe that this benchmark tested thread creation performance, which is distinct from process creation performance. Heck, I even said I was sure that thread creation performance was terrible. But this benchmark didn't measure that.
Saying that process creation includes thread creation is fine and good, but unless you can tell me what the additional hit is for process creation versus thread creation, you haven't said much of anything.
To make a thoroughly outlandish analogy, what if you were measuring how long it took to click on a URL, and you included the time to install and configure the operating system in that? It's a compound operation, admittedly not as closely-tied as the operations in thread/fork but a compound operation nonetheless. You could tell me it's absurd to measure the OS install time, and I'd agree --- but using fork() to measure thread creation time is equally bogus, if more subtly so.
Process creation is hardly the slowest part of Mac OS X; I'm having serious issues with its memory management, too. And I want that problem to get fixed, and I want the fork performance to get fixed, and if there's a thread creation performance issue that needs to get fixed (which I'm sure there is, though these benchmarks did nothing to alter that belief one way or the other), I want that fixed, too.
But knowing you have a problem is a question distinct from measuring that problem. The original article may be correct in knowing that there's a problem with thread creation, but it did nothing to measure that problem.
Yes: why the necessity for this pathetic and not really all that correct justification for what is in essence a synthetic benchmark when a different synthetic benchmark would do just fine?
lmbench isn't testing threading; it's testing forking. These are NOT THE SAME on all *nix OSes. Yes, the Linux model may be better --- Sun is switching to a similar model --- but on Mac OS X, fork =/= thread. Not even a little. Not even half.
Yes, Mac OS X has lousy fork performance. Yes, this is a problem. No, that doesn't say anything about thread performance. Which might be lousy or wonderful, but is probably lousy.
That said, you can pry my Powerbook out of my cold, dead hands. I'm looking forward to x86 Powerbooks, too...
I just checked the Amazon page... it appears that the phone has caller ID, but not call waiting caller ID (ie, caller ID for those calls on call waiting).
Did I say that it was a consequence of using the band, or only that phones using those bands were not available with those features?
It's (obviously) not due to the choice of bands, but the expectation on the part of manufacturers that 900mhz phones are low-end products. I'm guessing that nobody's revved their 900mhz phone chipsets in five years at this point.
Or are you suggesting that I should be leet enough to design my own 900mhz phone with all of the features I'd like?
Slashdot Mirror
I was going to point out the "MS Stack" problem myself. Seattle is not the place for MS developers because outside of Microsoft, no one uses them. I've gotten interviews with Amazon and it's all Java/Linux/Unix work.
That's all I'm hiring for in Seattle, minus the Java. Linux/Unix, devs, DevOps... and I'm competing quite a bit for top talent.
Translation: If several counterfactual events occur, something might happen.
Counterfactual #1: Disney leaving the Blu-Ray camp. Given the huge investment that Disney's made in Blu-Ray, and given the absence of reason to switch, there doesn't seem like any reason to believe this.
Counterfactual #2: HD-DVD price drops more rapid than Blu-Ray price drops. Actually, I just went through this, and after two days of agonizing I bought Blu-Ray. In part, the $50 difference between the two (on Amazon.com) helped cement that decision. In the future, if the price gap as a percentage stays the same, the difference in player cost is likely to hit $25 or less.
Counterfactual #3: HD-DVD will catch up to Blu-Ray in capacity. Sure, triple-layer HD-DVDs are coming. So are triple-layer Blu-Ray discs, which will once again cause Blu-Ray capacity to blow away HD-DVD. Kinda funny, if "there's no real need to use the extra capacity of Blu-Ray discs." (Have you ever had a disc that you haven't filled?)
Counterfactual #4: Toshiba has any intention of ever lowering HD-DVD license fees. That's their whole reason for pushing the new standard, actually.
Implied counterfactual #5: Sony blew it with Betamax, so they'll blow it again with Blu-Ray. Sure, it's possible. If Sony hasn't learned anything over the last thirty years, and if owning a movie studio and becoming a huge player in the "content" business haven't changed anything.
If you're using Google to write letters and do spreadsheets, congratulations: your desktop is a thin client, and you didn't even know it. Guess thin clients aren't all that bad, huh?
That was the point that the piece on Slate was trying to make, more or less. Did you RTFA?
RDP is hardly the only way to do remote access, and it's true that most Windows-functional solutions (WebEx, PCAnywhere, ThinAnywhere, VNC, etc.) stink, from at least a performance standpoint.
But those aren't really thin clients; they're really remote access sessions to a thick client running over a network.
A real thin-client package does the computing locally, as well as the display. It just uses storage and some heavy features on the back-end.
Now, mentioning that while interviewing is in bad taste, but it's actually pretty well established that job-hopping increases salaries. (Yes, those reports are essentially anecdotal; I'm unable to find the survey that report similar results right at the moment, but I recall that they're out there.
Since these are obvious, don't you think there might be a deterrent effect --- each side afraid to abuse their status because the other side might abuse it, too?
Right, let's teach the debate.
So, I'm afraid that I'm not receiving adequate government research dollars for my proposal on demonstrating that babies are delivered by storks.
As far as I can tell, any of the arguments used to defend anti-Global-Warming scientists can apply equally well to my babies-come-from-storks argument. Saying that the discussion isn't "balanced" and that we need to "teach the debate" or "show both sides" is what you say when you don't have arguments that are strong enough to convince your opponents in debate.
I'd like to keep an open mind on the issue of climate change, but the proponents of no-climate-crisis have failed to convince me, or pretty much anyone else. I'm not sure why we should continue to fund them. Saying that they're not getting their fair say isn't much of an argument.
We were discussing an article whose claim was "These scientists are denied funding, skewing the debate."
Parent post said, this information is not accurate; these supposed pariah scientists are quite well-compensated for their research.
This post says parent post does not rebut the science, but engages in ad hominem attacks. Then it says, "Real believers in global warming should welcome contrary views and science as an opportunity to refute those views and strengthen their own. Instead it's an attack against how they are funded."
Of course, all of this was a discussion on funding, and discussing the science is (strangely) an attempt to distract from the issue actually at hand. Real opponents of global warming should welcome contrary views and science as an opportunity to refuse those views and strengthen their own. Instead it's an attack against how they are funded. (In this case, against their government funding.)
But what would we do without Jerkcity?
Actually, he's letting the realtimeness (whatever in the heck THAT is) out of its cage, letting it loose.
That it runs away and hides where nobody can find it. So he also does lose it, but only because he loosed it.
He left a month ago. You think he contacted the news media, after waiting a month? Think this through a minute, mmmkay?
(Disclaimer: I know and like Daniel. I worked with him at Microsoft. I'm not there anymore, either.)
Fourthed. I love my Sennheisers.
Rights inline? As far as I know, you can still skate without having to have ID.
Better have health insurance, though...
I understand that; I thought that a full-screen game might be less reliant on OS calls and more reliant on its own code.
As far as (3), with HandBrake's Intel build available on the web site, I'm able to encode at 30fps+ and still have one processor free to do other tasks. Subjective performance in my foreground tasks is excellent.
Or to put it another way, I was able to rebuild my darwinports on one CPU and at the same time get better peformance out of Monster Fair (a pinball game) running via Rosetta than I managed at native on my 1ghz 12" PowerBook when I needed to quit every other app on the system on the PowerBook.
A lot of the help is more memory --- 2gb versus 1.25gb on the PowerBook (each system was maxed out) --- but a second core makes a big difference, too. No doubt about it, I'm impressed by system performance. I hadn't thought that Monster Fair would be useable running via Rosetta, let alone faster, let alone faster while compiling software on the other CPU.
Well, you'll still be able to buy G4 laptops after the MacBook Pro is released.
The Core Duo-based iMac is released (I have one), and they're still selling the PowerPC-based iMacs. The price on either model is identical; it's just a question of whether you want perfect backwards compatibility or perfect forwards compatibility.
Just the same, the PowerBooks will continue to be sold up through the end of the year. (That's when Jobs says the transition will be "complete," presumably meaning in terms of the Apple product line.)
And, for the record, my new iMac is pretty incredible. Even when running PowerPC software. (The only apps I've got that haven't run are DiskWarrior, presumably because of the new partitioning scheme, and VLC, which starts but has some problems doing the necessary pixel-pushing...)
In other words, "So, other than that, Mrs. Lincoln, how did you enjoy the show?"
Well, remember that corn syrup is cheaper than sugar only because of subsidies to corn growers, and because of tariffs on imported cane sugar, to protect the local sugar industry. Without those barriers, we'd likely have real sugar in our sodas.
(That said, if Americans gave a damn about how their sugar-water tasted, the soda companies would pony up the couple of extra cents to give us real sugar... but obviously it doesn't give them any sort of competitive advantage to do so.)
My book teaches how to read documentation. It's the subject of the first chapter, actually. (Slashdot reviewed my book, long ago, FWIW.)
Since my book is not aimed directly at programmers, I didn't cover reading source code. I did cover basic instructions for debugging documentation when it's wrong, though.
Look, we know it has a problem around process creation. That's not been news for a very long time. Where am I in denial about this?
My only comment amounted to wondering what the basis was to believe that this benchmark tested thread creation performance, which is distinct from process creation performance. Heck, I even said I was sure that thread creation performance was terrible. But this benchmark didn't measure that.
Saying that process creation includes thread creation is fine and good, but unless you can tell me what the additional hit is for process creation versus thread creation, you haven't said much of anything.
To make a thoroughly outlandish analogy, what if you were measuring how long it took to click on a URL, and you included the time to install and configure the operating system in that? It's a compound operation, admittedly not as closely-tied as the operations in thread/fork but a compound operation nonetheless. You could tell me it's absurd to measure the OS install time, and I'd agree --- but using fork() to measure thread creation time is equally bogus, if more subtly so.
Process creation is hardly the slowest part of Mac OS X; I'm having serious issues with its memory management, too. And I want that problem to get fixed, and I want the fork performance to get fixed, and if there's a thread creation performance issue that needs to get fixed (which I'm sure there is, though these benchmarks did nothing to alter that belief one way or the other), I want that fixed, too.
But knowing you have a problem is a question distinct from measuring that problem. The original article may be correct in knowing that there's a problem with thread creation, but it did nothing to measure that problem.
Yes: why the necessity for this pathetic and not really all that correct justification for what is in essence a synthetic benchmark when a different synthetic benchmark would do just fine?
lmbench isn't testing threading; it's testing forking. These are NOT THE SAME on all *nix OSes. Yes, the Linux model may be better --- Sun is switching to a similar model --- but on Mac OS X, fork =/= thread. Not even a little. Not even half.
Yes, Mac OS X has lousy fork performance. Yes, this is a problem. No, that doesn't say anything about thread performance. Which might be lousy or wonderful, but is probably lousy.
That said, you can pry my Powerbook out of my cold, dead hands. I'm looking forward to x86 Powerbooks, too...
I just checked the Amazon page... it appears that the phone has caller ID, but not call waiting caller ID (ie, caller ID for those calls on call waiting).
Did I say that it was a consequence of using the band, or only that phones using those bands were not available with those features?
It's (obviously) not due to the choice of bands, but the expectation on the part of manufacturers that 900mhz phones are low-end products. I'm guessing that nobody's revved their 900mhz phone chipsets in five years at this point.
Or are you suggesting that I should be leet enough to design my own 900mhz phone with all of the features I'd like?
Not just caller ID... call waiting caller ID. As in caller ID for that annoying beep, so you can decide if you'd like to answer it at all.