Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Resolution (Score 1) 399

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.

Comment Re:Ho Hum (Score 5, Informative) 181

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)

Comment Re:Welcome to real world (Score 1) 542

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.

Comment Re:Welcome to real world (Score 1) 542

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.

Comment Re:Define professionals? (Score 1) 556

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.

Comment Re:It's a nice framework (Score 1) 110

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.

Comment Re:It's a nice framework (Score 1) 110

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.

Comment Re:It's a nice framework (Score 1) 110

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.

Comment Re:How about the reliability ? (Score 5, Informative) 271

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...

Comment Re:Bullshit (Score 5, Insightful) 271

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.


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?

Comment Re:TFS is a bit light on details (Score 2, Insightful) 181

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.

Slashdot Top Deals

"No matter where you go, there you are..." -- Buckaroo Banzai