Yes. I did a lot of shopping and bought a 17" MBP as well, because I wanted that 1920x1200 display. In the world of "higher end" laptops like this, it was actually quite price-competitive with Thinkpads and Dells. I could have matched the MBP's specs and price (mostly) by going with a 10-pound luggable monster from Alienware, but I'm 35 at this point and I don't need clients laughing at me when I bust out my laptop at a meeting and the glowing alien eyes and HR Giger-lite styling light up.
I've found the latest (early 2011) model pretty decent for gaming! ATI 6750M 1GB isn't too bad at all. Portal 2 ran great even under OSX.
Heat was more of an issue than framerate (the machine never overheated or anything) but even Visual Studio + Resharper makes the fans spin, so the fans are really cranking when I play games.
I knew the core was supposed to be the cause of our magnetosphere
That's a large part of the answer right there! The magnetosphere acts as a shield to keep a lot of harmful particles from the solar wind away, things which would work to strip away the atmosphere. Mars is an example of what can happen to planets that lack this. (Obviously, Mars' lower gravity works against it in this regard as well)
Discussing the price of developer tools isn't really a useful argument -- where do you stop? Do you compare prices of the computer? What about electricity and internet access? Office space? Clearly those aren't relevant.
I don't understand why those things wouldn't be useful and relevant if our goal is to discuss the costs of development, and not to just cherrypick numbers here and there.
And if you don't ignore development costs, that $99 becomes trivial; less than a rounding error. It's less than the cost of a padded office chair from Staples that your developer is probably sitting on... or the sneakers she's wearing, if it's a standing desk.
that argument has always been rather flimsy to non-existent to those with at least a decent amount of technical knowledge.
That argument is not flimsy for professionals that have "a decent amount of technical knowledge" but value their time. I have assembled, tweaked, and overclocked many PCs but for the last few years I've grown to prefer Macs more and more.
The "Apple premium" is pretty affordable when you compare it to the cost of several days of downtime over the course of 3 years of computer ownership, and it shrinks even further when you consider that Macs fetch a premium price on the used market and you are able to recoup some of the "Apple premium" when it's time to sell.
The major problem with Rails is that it's tied to Ruby. Historically, Ruby's interpreters have not exactly been speed demons.
Non-rhetorical question: when you write web applications, do you ever do anything performance-intensive in the framework/application layer?
I don't know about you, but in my experience with small/medium sites, the execution time of the ASP.NET/Ruby/whatever code is absolutely dwarfed by the execution time of the database calls.
Usually, all the framework/application layer is really doing for each page request is grabbing some data from the database and spitting out some markup. It's not rocket science, and no matter how slow my framework is (including like, VBscript-powered ASP "classic"...yuck) I've never found it to be a performance bottleneck.
I am sure that there are web applications where perhaps it would come into play. Sites that do heavy manipulation of images or other media types in the application layer are obvious candidates. I am sure there are others.
That's a legitimate concern, though there are good reasons that performance of the runtime isn't the overwhelming concern when choosing a platform for a project, but the speed with which something can be developed, tested, and deployed is more critical, and the Ruby ecosystem and Rails have features that lots of people find attractive in that direction.
This is absolutely true. Developer time is in shorter supply than CPU cycles. Additionally, in most web applications, it's the data storage layer that's doing the heavy lifting anyway. In my experience with small/medium sites, about 90-95% of the time it takes to generate a response is tied up just waiting for database calls to complete. If a page takes 50ms to generate I'm usually looking at about 5ms spent in the framework and 45ms in the database.
You pay a high performance price for the dynamic nature of Ruby whether you need it or not.
I don't think that's accurate at all. Typically, your choice of web framework/language is never even close to being your performance bottleneck anyway - it's the data storage layer that's doing all of the heavy lifting. MySql isn't any faster or slower whether you're calling it from Ruby, C#, COBOL, or hand-tuned machine language.
When I say "typically," I realize that's a nebulous term and that there's no "average" web application. What I'm thinking of as typical is a small/medium server that's serving up to several million page views a month, several database calls per page view, with a database perhaps 50MB-10GB in size.
SLC flash memory, which the article claims Braidwood will use, is an order of magnitude or two more durable (in terms of write cycles) than MLC flash memory, which is what is used in most consumer-level devices like Intel's X-25M SSDs.
Wear-leveling and overprovisioning should ensure a long life for the memory used in a scheme like Braidwood. Intel, generally speaking, knows what they're doing in this area. Now if only I could afford one of their drives...
I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.
-jcr
You're both right.
The problem here is that "random I/O" can have at least two subtly different meanings. In the very old days they talked about random I/O as opposed to sequential (ie, tape) I/O. In that sense, yes, random I/O is often extremely cacheable, as you say. That's why virtual memory works, as system files, drivers, commonly-used applications, and so forth are accessed much more often than other daa.
"Random I/O" can also refer to I/O that does not follow any real pattern - ie, a 50GB database in which all records are accessed about equally as often. This kind of I/O is not really cacheable, practically speaking. Unless you can cache the entire thing.
What's the correct terminology for the second kind of random I/O? Random I/O with very low locality?
I love how AMD is touting the lack of DDR3 support on a new chip as a "feature".
That was my initial reaction too. However, remember that most (not all, obviously) typical server tasks aren't particularly memory bandwidth-hungry. Email, web serving... even databases aren't usually coming anywhere close to saturating the bandwidth DDR2 can provide, even with several virtualized OSes sharing that bandwidth.
Right. There's (almost) no friction in space, so your craft isn't going to slow down just because it's no longer receiving enough power from the sun to accelerate. But after a certain point it won't receive enough solar power to power onboard navigation and communications systems. Those would likely be powered by a wee bit o' radioactive power like today's deep space probes.
Without even getting into specific operating systems: if Operating System A and Operating System B do different things well, why would it possibly be bizarre to run them both?
When it comes to OSX and Linux, each runs a great deal of software that the other doesnt. Specifically: Cocoa, Carbon, KDE, and Gnome desktop applications.
Also, quite a few developers work with multiple operating systems. Since desktop OSX is simultaneously the most difficult OS (yes, because Apple has fought it) to virtualize and is generally regarded as providing the most pleasant desktop experience, a popular strategy among developers is to run OSX as their desktop OS and virtualize the rest.
Not very hard to understand, though it's also easy to avoid replying to trolls and that's what I just did.!
There is a real shortage of talented programmers out there. Most programmers are completely awful and write disgusting lumps of buggy spaghetti code, regardless of their age. Nobody in the market for a talented programmer -- nobody worth working for, anyway -- is going to turn a talented programmer away because they have a receding hairline.
Yes, there is mild ageism. It's not because people in the industry have some sort of innate hatred of people over 35; it's because older programmers tend to lack the geeky dedication and up-to-date skillsets of younger programmers, and tend to have higher pay requirements because of their families, mortgages, etc.
Tend. Tend.
Show yourself to be otherwise and you'll be on an even footing with the younger coders. And if you do carry those drawbacks, well, it's not really your age that's holding you back.
(Of course, there are enormous numbers of older programmers who defy that tendency and are superior programmers because of their experience, and enormous numbers of younger programmers who are absolutely total crap)
For whatever it's worth, I'll be 33 in a few months and the most talented programmer currently in my personal/professional circle is over 40.
How is that any worse than traditional web development environments, where it's equally easy to a "select * from orders" ? It's so easy to forget a WHERE clause.
If anything, I think the presence of "all" in "Orders.all.each { |order|... code goes here... }" is much easier to spot than a missing SQL clause.
Not that that excuses any of Rails' other flaws that you pointed out.
I grew up on the early Sierra and Lucasarts adventure games, and even some text adventures, but even then - puzzles often felt forced and arbitrary.
"Oh, look -- another door in this dungeon is locked, but has a series of gem-shaped indentations in it! I can't wait to figure out the proper order of the gems! Hooray!"
The best puzzles were the ones integrated into the story, when Character A (whom we already care about, because of previous plot developments) needs Item B and I need to talk to Character C (whom we also already care about) and figure out that I need to use Item D with Item E at Location F to accomplish that goal.
But even then, those puzzles bordered on tedium that you simply had to endure in order to see the next bit of (often wonderfully-written) story.
It was downright schizophrenic: wonderful story, tedious puzzle, wonderful story, tedious puzzle, wonderful story, etc.
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.
If you write your own non-trivial Javascript code, you have to test on IE 6/7/8, FF 2/3, Opera 9.whatever, Safari 2/3, etc etc etc etc.
And I've noticed that my Unicomp keyboards have more spring tension than any of my Model M's, including a factory-sealed 1993 model I bought last year. (Thus eliminating keyboard wear as a factor)
I wrote to Unicomp about this and they sent me a very detailed reply. Their answer, essentially, is that the original Model M spec allowed quite a variance (40%, or +/- 20%) in spring tension. Whereas Unicomp's springs all fall within about 20% range of variance centered around the original Model M specifications.
So yes, there are Model M keyboards with more tension and there are Model M keyboards with less spring tension relative to the Unicomp keyboards.
I upgraded the hard drive and memory on my MacBook Pro and had no problems with getting my machine serviced by AppleCare on two occasions. And those were full logic board replacements, not cursory looks at the battery or anything.
(It was the first-gen MacBook Pro. Lots of issues with those, although Apple did take care of me.)
Even with the warranty and OS costs factored in I'm still paying almost a 40% markup on the Mac Pro versus a system I can build myself. More power to you if you love paying such a huge markup, but I'll save myself the money and use it to buy other stuff for the system.
You failed to read what I wrote. I said I have a Mac laptop. I have not attempted to "justify" anything and most certainly don't "have to." I don't have a Mac Pro and really don't care if you or anybody else buy one or not.
But comparing a pre-built system to a build-your-own is silly. I saved a lot of money when I built my own server but it also took hours of my time. It wasn't worth it to me to pay somebody else to build and support my server but I understand basic economics so I understand where that price difference goes.
For some people, paying a company $800 dollars to build and support a workstation that will essentially require zero expertise to deploy is worth it. For other people (and this includes me, much of the time) it isn't.
Let me ask you a question: how much is your time worth?
I reckon I've spent a good 10-20 hours dicking around with my most recent PC workstation that I built myself, if you include the initial build+install and a few hardware issues I sorted out over the past year or two.
That's mostly time I'd have back if I'd spent an extra $800 on a Mac Pro. $800 divided by 10 or 20 hours comes out to about $40 to $80 an hour. That's pretty much what a mid-level software engineer can make an hour if (it's a big "if," obviously) they've got work. So I'm still glad I built it myself but it wasn't exactly the financial coup of the century.
Considering I've spec'd out comparable systems with parts from Newegg and Frys that cost anywhere from 50% to 66% the Mac Pro, I'd say they have a pretty hefty margin.
That's not a reasonable comparison. With the Apple (or a comparable Dell, or whatever) you're getting service, support, a system-wide warranty, etc.
I'm not saying home-built systems are better or worse than prebuilt systems but it's silly to compare them. For the record my personal systems are a mix of Macs and home-built boxes. Right tool for the right job. My Mac laptop cost more than my quad-core server with two RAID arrays, but I don't compare them because it doesn't make sense.
Slashdot Mirror
Yes. I did a lot of shopping and bought a 17" MBP as well, because I wanted that 1920x1200 display. In the world of "higher end" laptops like this, it was actually quite price-competitive with Thinkpads and Dells. I could have matched the MBP's specs and price (mostly) by going with a 10-pound luggable monster from Alienware, but I'm 35 at this point and I don't need clients laughing at me when I bust out my laptop at a meeting and the glowing alien eyes and HR Giger-lite styling light up.
I've found the latest (early 2011) model pretty decent for gaming! ATI 6750M 1GB isn't too bad at all. Portal 2 ran great even under OSX.
Heat was more of an issue than framerate (the machine never overheated or anything) but even Visual Studio + Resharper makes the fans spin, so the fans are really cranking when I play games.
I knew the core was supposed to be the cause of our magnetosphere
That's a large part of the answer right there! The magnetosphere acts as a shield to keep a lot of harmful particles from the solar wind away, things which would work to strip away the atmosphere. Mars is an example of what can happen to planets that lack this. (Obviously, Mars' lower gravity works against it in this regard as well)
http://science.nasa.gov/science-news/science-at-nasa/2001/ast31jan_1/
Discussing the price of developer tools isn't really a useful argument -- where do you stop? Do you compare prices of the computer? What about electricity and internet access? Office space? Clearly those aren't relevant.
I don't understand why those things wouldn't be useful and relevant if our goal is to discuss the costs of development, and not to just cherrypick numbers here and there.
If you ignore development costs, yes.
And if you don't ignore development costs, that $99 becomes trivial; less than a rounding error. It's less than the cost of a padded office chair from Staples that your developer is probably sitting on... or the sneakers she's wearing, if it's a standing desk.
that argument has always been rather flimsy to non-existent to those with at least a decent amount of technical knowledge.
That argument is not flimsy for professionals that have "a decent amount of technical knowledge" but value their time. I have assembled, tweaked, and overclocked many PCs but for the last few years I've grown to prefer Macs more and more.
The "Apple premium" is pretty affordable when you compare it to the cost of several days of downtime over the course of 3 years of computer ownership, and it shrinks even further when you consider that Macs fetch a premium price on the used market and you are able to recoup some of the "Apple premium" when it's time to sell.
Yer mum's pretty nice, mate. Winkwink nudgenudge.
I like how this guy thinks it's a conspiracy or something. You're right, man. SSDs aren't faster or anything. What were we thinking?
Non-rhetorical question: when you write web applications, do you ever do anything performance-intensive in the framework/application layer?
I don't know about you, but in my experience with small/medium sites, the execution time of the ASP.NET/Ruby/whatever code is absolutely dwarfed by the execution time of the database calls.
Usually, all the framework/application layer is really doing for each page request is grabbing some data from the database and spitting out some markup. It's not rocket science, and no matter how slow my framework is (including like, VBscript-powered ASP "classic" ...yuck) I've never found it to be a performance bottleneck.
I am sure that there are web applications where perhaps it would come into play. Sites that do heavy manipulation of images or other media types in the application layer are obvious candidates. I am sure there are others.
This is absolutely true. Developer time is in shorter supply than CPU cycles. Additionally, in most web applications, it's the data storage layer that's doing the heavy lifting anyway. In my experience with small/medium sites, about 90-95% of the time it takes to generate a response is tied up just waiting for database calls to complete. If a page takes 50ms to generate I'm usually looking at about 5ms spent in the framework and 45ms in the database.
You pay a high performance price for the dynamic nature of Ruby whether you need it or not.
I don't think that's accurate at all. Typically, your choice of web framework/language is never even close to being your performance bottleneck anyway - it's the data storage layer that's doing all of the heavy lifting. MySql isn't any faster or slower whether you're calling it from Ruby, C#, COBOL, or hand-tuned machine language.
When I say "typically," I realize that's a nebulous term and that there's no "average" web application. What I'm thinking of as typical is a small/medium server that's serving up to several million page views a month, several database calls per page view, with a database perhaps 50MB-10GB in size.
SLC flash memory, which the article claims Braidwood will use, is an order of magnitude or two more durable (in terms of write cycles) than MLC flash memory, which is what is used in most consumer-level devices like Intel's X-25M SSDs.
Wear-leveling and overprovisioning should ensure a long life for the memory used in a scheme like Braidwood. Intel, generally speaking, knows what they're doing in this area. Now if only I could afford one of their drives...
Random I/O is essentially uncacheable.
I'm sure that would come as a great surprise to anyone who ever implemented a virtual memory system.
-jcr
You're both right.
The problem here is that "random I/O" can have at least two subtly different meanings. In the very old days they talked about random I/O as opposed to sequential (ie, tape) I/O. In that sense, yes, random I/O is often extremely cacheable, as you say. That's why virtual memory works, as system files, drivers, commonly-used applications, and so forth are accessed much more often than other daa.
"Random I/O" can also refer to I/O that does not follow any real pattern - ie, a 50GB database in which all records are accessed about equally as often. This kind of I/O is not really cacheable, practically speaking. Unless you can cache the entire thing.
What's the correct terminology for the second kind of random I/O? Random I/O with very low locality?
I love how AMD is touting the lack of DDR3 support on a new chip as a "feature".
That was my initial reaction too. However, remember that most (not all, obviously) typical server tasks aren't particularly memory bandwidth-hungry. Email, web serving... even databases aren't usually coming anywhere close to saturating the bandwidth DDR2 can provide, even with several virtualized OSes sharing that bandwidth.
Right. There's (almost) no friction in space, so your craft isn't going to slow down just because it's no longer receiving enough power from the sun to accelerate. But after a certain point it won't receive enough solar power to power onboard navigation and communications systems. Those would likely be powered by a wee bit o' radioactive power like today's deep space probes.
How is this even remotely bizarre?
Without even getting into specific operating systems: if Operating System A and Operating System B do different things well, why would it possibly be bizarre to run them both?
When it comes to OSX and Linux, each runs a great deal of software that the other doesnt. Specifically: Cocoa, Carbon, KDE, and Gnome desktop applications.
Also, quite a few developers work with multiple operating systems. Since desktop OSX is simultaneously the most difficult OS (yes, because Apple has fought it) to virtualize and is generally regarded as providing the most pleasant desktop experience, a popular strategy among developers is to run OSX as their desktop OS and virtualize the rest.
Not very hard to understand, though it's also easy to avoid replying to trolls and that's what I just did.!
There is a real shortage of talented programmers out there. Most programmers are completely awful and write disgusting lumps of buggy spaghetti code, regardless of their age. Nobody in the market for a talented programmer -- nobody worth working for, anyway -- is going to turn a talented programmer away because they have a receding hairline.
Yes, there is mild ageism. It's not because people in the industry have some sort of innate hatred of people over 35; it's because older programmers tend to lack the geeky dedication and up-to-date skillsets of younger programmers, and tend to have higher pay requirements because of their families, mortgages, etc.
Tend. Tend.
Show yourself to be otherwise and you'll be on an even footing with the younger coders. And if you do carry those drawbacks, well, it's not really your age that's holding you back.
(Of course, there are enormous numbers of older programmers who defy that tendency and are superior programmers because of their experience, and enormous numbers of younger programmers who are absolutely total crap)
For whatever it's worth, I'll be 33 in a few months and the most talented programmer currently in my personal/professional circle is over 40.
I got him to sign the petition to ban dihydrogen monoxide.
So I take it your friend doesn't like Water and wants to ban it....good thinking on his part....brilliant scam on yours.
Congratulations. You got the joke.
How is that any worse than traditional web development environments, where it's equally easy to a "select * from orders" ? It's so easy to forget a WHERE clause.
If anything, I think the presence of "all" in "Orders.all.each { |order| ... code goes here ... }" is much easier to spot than a missing SQL clause.
Not that that excuses any of Rails' other flaws that you pointed out.
I grew up on the early Sierra and Lucasarts adventure games, and even some text adventures, but even then - puzzles often felt forced and arbitrary.
"Oh, look -- another door in this dungeon is locked, but has a series of gem-shaped indentations in it! I can't wait to figure out the proper order of the gems! Hooray!"
The best puzzles were the ones integrated into the story, when Character A (whom we already care about, because of previous plot developments) needs Item B and I need to talk to Character C (whom we also already care about) and figure out that I need to use Item D with Item E at Location F to accomplish that goal.
But even then, those puzzles bordered on tedium that you simply had to endure in order to see the next bit of (often wonderfully-written) story.
It was downright schizophrenic: wonderful story, tedious puzzle, wonderful story, tedious puzzle, wonderful story, etc.
On a personal level, I'd rather see the effort spent learning GWT applied to learning Javascript and the web technologies instead. There are a lot of frameworks out there, but none of them are actually needed in 90% of the cases. What we actually need are programmers who know how to write maintainable and highly interactive Javascript components for their sites. Such knowledge allows them to get the job done faster than mucking about with Yet Another Framework(TM) designed to take a cannon to the problem of killing a fly.
It's not learning Javascript that's the big obstacle to coding your own solutions sans framework; it's dealing with the browser compatibility issues. Frameworks largely compensate for that.
If you write your own non-trivial Javascript code, you have to test on IE 6/7/8, FF 2/3, Opera 9.whatever, Safari 2/3, etc etc etc etc.
And I've noticed that my Unicomp keyboards have more spring tension than any of my Model M's, including a factory-sealed 1993 model I bought last year. (Thus eliminating keyboard wear as a factor)
I wrote to Unicomp about this and they sent me a very detailed reply. Their answer, essentially, is that the original Model M spec allowed quite a variance (40%, or +/- 20%) in spring tension. Whereas Unicomp's springs all fall within about 20% range of variance centered around the original Model M specifications.
So yes, there are Model M keyboards with more tension and there are Model M keyboards with less spring tension relative to the Unicomp keyboards.
I upgraded the hard drive and memory on my MacBook Pro and had no problems with getting my machine serviced by AppleCare on two occasions. And those were full logic board replacements, not cursory looks at the battery or anything.
(It was the first-gen MacBook Pro. Lots of issues with those, although Apple did take care of me.)
Well, that sure worked.
You failed to read what I wrote. I said I have a Mac laptop. I have not attempted to "justify" anything and most certainly don't "have to." I don't have a Mac Pro and really don't care if you or anybody else buy one or not.
But comparing a pre-built system to a build-your-own is silly. I saved a lot of money when I built my own server but it also took hours of my time. It wasn't worth it to me to pay somebody else to build and support my server but I understand basic economics so I understand where that price difference goes.
For some people, paying a company $800 dollars to build and support a workstation that will essentially require zero expertise to deploy is worth it. For other people (and this includes me, much of the time) it isn't.
Let me ask you a question: how much is your time worth?
I reckon I've spent a good 10-20 hours dicking around with my most recent PC workstation that I built myself, if you include the initial build+install and a few hardware issues I sorted out over the past year or two.
That's mostly time I'd have back if I'd spent an extra $800 on a Mac Pro. $800 divided by 10 or 20 hours comes out to about $40 to $80 an hour. That's pretty much what a mid-level software engineer can make an hour if (it's a big "if," obviously) they've got work. So I'm still glad I built it myself but it wasn't exactly the financial coup of the century.
That's not a reasonable comparison. With the Apple (or a comparable Dell, or whatever) you're getting service, support, a system-wide warranty, etc.
I'm not saying home-built systems are better or worse than prebuilt systems but it's silly to compare them. For the record my personal systems are a mix of Macs and home-built boxes. Right tool for the right job. My Mac laptop cost more than my quad-core server with two RAID arrays, but I don't compare them because it doesn't make sense.