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! ×

AMD Sued Over Allegedly Misleading Bulldozer Core Count 311

An anonymous reader writes: A class action suit accuses AMD of misleading buyers about the number of cores in its Bulldozer-based CPUs. The complaint claims that the chips effectively had only four cores, while AMD claims there are eight. According to Ars: "AMD's multi-core Bulldozer chips use a unique design that combines the functions of what would normally be two discrete cores into a single package, which the company calls a module. Each module is identified as two separate cores in Windows, but the cores share a single floating point unit and instruction and execution resources. This is different from Intel's cores, which feature independent FPUs. The suit claims that Bulldozer's design means its cores cannot work independently, and as a result, cannot perform eight instructions simultaneously and independently. This, the claim continues, results in performance degradation, and average consumers in the market for a CPU lack the technical expertise to understand the design of AMD's processors and trust the company to give accurate specifications regarding its CPUs."

Twitpic Shutting Down Over Trademark Dispute 81

First time accepted submitter exiguus writes As of September 25th Twitpic will be no more. Twitter, allegedly, has threatened to deny them access to their API. Noah Everett said "Unfortunately we do not have the resources to fend off a large company like Twitter to maintain our mark which we believe whole heartedly is rightfully ours. Therefore, we have decided to shut down Twitpic." Resources will be made available to users to download their videos and photos, but a date when that function will be available has not been made available. "We'll let everyone know when this feature is live in the next few days."

Comment Re:Attorneys (Score 5, Interesting) 730

I did some negotiation with Rumblefish and Paul about 5 years ago when I ran a digital music company and I have to say that in the sea of bloodsucking fucktards that exist in music licensing Paul and Rumblefish were a breath of fresh air. They were the only company I dealt with that actually gave a flying fuck about their artists and were always very supportive of up-and-coming bands. Hell, their entire business model is around putting unknown artists on soundtracks, or in commercials, and henceforth are actually supporting the artists in a way that previously only the major labels would do.

All of that being said, it is obvious Rumblefish fucked up this time. Who knows exactly why, but they did. I think it is important that before crucifying them you understand that the service they provide is extremely valuable to artists not on a major label.... so at least give them that.

And before the venomous masses can call me a shill or whatever: we actually never did business together, nor did I remain contact with Paul, and so I have no reason to defend them other than what I stated above. People and companies fuck up some times. I have a feeling Rumblefish will learn from this mistake.

Comment Re:BitCoin (Score 0) 528

You are clever! Some people would just use their fingers to count (or straws if you aren't just drinking beer), but you, my fine sir, have found a way to count while buttraping the person on the other side of the bar! Brilliant! I can only imagine that you are the most popular patron at every establishment you frequent.

Comment Re:This rant just proves that how important (Score 1) 354

It really depends on what you are trying to do with Facebook. The newish Graph API is an absolute DREAM compared to the cobbled together mess that was the old API. Nearly everything you could ever care to pull from/post to Facebook is available via a fairly well thought out RESTful-ish interface. The only thing you need to pass into them is an access token which you can get with another simple call to the Graph API. The Graph API also has a push notification service so you can subscribe to events and Facebook will ping you when there are changes. I cannot believe I just posted something defending Facebook, but their API is FAR from the worst API out there.

Comment Re:Same here (Score 1) 235

Washington state is downright hostile to small business. The DOR is evil and will treat you like a mega corporation even if you only have a single employee. I have had several corporations and LLCs registered in Washington (and stupidly just set up a new one here) but next time I will pay for an empty office space in Las Vegas and do it that way.

Comment Re:Texas vs. TSA (Score 1) 570

I had the same thing happen with my son when he was maybe 3. I began screaming at the agents and came VERY close to being arrested. I actually crossed back through the screener and grabbed my son since he had thrown himself on the floor and threw a fit. You don't fuck with a parent when their child is in distress. :-)

Comment Re:My experience (Score 1) 758

Agreed that the guy is an idiot but only because he publicly admitted what he did. All people in hiring positions have preferences. I used to have a thing against CompSci grads... all based on a unfortunate stream of incompetents that came to me. I got over it, but it took a few years and a couple of rockstars that were CompSci grads.

What I look for is breadth and depth of knowledge. If a candidate has the vast majority of their experience with a singular platform that may set off red flags for me. But I also understand that people have to work for a living and just because they use a platform at work that I don't care for doesn't necessarily mean I won't hire them. The type of work they have done IS very important though. In my business someone who has written custom CRMs for large corporate clients probably doesn't have the skillset I need, whereas someone who doesn't even blink when I say that we use Scala/Lift, with some Python glue and a ton of bash scripts IS someone I would want to talk to.

Submission + - PostgreSQL 9.0 High Performance (

eggyknap writes: Thanks in large part to the oft-hyped "NoSQL" movement, database performance has received a great deal of press in the past few years. Organizations large and small have replaced their traditional relational database applications with new technologies like key-value stores, document databases, and other systems, with great fanfare and often great success. But replacing a database system with something radically different is a difficult undertaking, and these new database systems achieve their impressive results principally because they abandon some of the guarantees traditional database systems have always provided.

For those of us who need improved performance but don't have the luxury of redesigning our systems, and even more for those of us who still need traditional transactions, data integrity, and SQL, there is an option. Greg Smith's book, "PostgreSQL 9.0 High Performance" takes the reader step-by-step through the process of building an efficient and responsive database using "the world's most advanced open source database".

Greg Smith has been a major contributor to PostgreSQL for many years, with work focusing particularly on performance. In "PostgreSQL 9.0 High Performance", Smith starts at the lowest level and works through a complete system, sharing his experience with systematic benchmarking and detailed performance improvement at each step. Despite the title, the material applies not only to PostgreSQL's still fairly new 9.0 release, but to previous releases as well. After introducing PostgreSQL, briefly discussing its history, strengths and weaknesses, and basic management, the book dives into a detailed discussion of hardware and benchmarking, and doesn't come out for 400 pages.

Databases vary, of course, but in general they depend on three main hardware factors: CPU, memory, and disks. Smith discusses each in turn, and in substantial detail, as demonstrated in a sample chapter available from the publisher, Packt Publishing. After describing the various features and important considerations of each aspect of a database server's hardware, the book introduces and demonstrates powerful and widely available tools for testing and benchmarking. This section in particular should apply easily not only to administrators of PostgreSQL databases, but users of other databases, or indeed other applications as well, where CPU, memory, or disk performance is a critical factor. Did you know, for instance, the difference between "write-through" and "write-back" caching in disk, and why it matters to a database? Or did you know that disks perform better depending on which part of the physical platter they're reading? How does memory performance compare between various common CPUs through the evolution of their different architectures?

At every step, Smith encourages small changes and strict testing, to ensure optimum results from your performance efforts. His discussion includes methods for reducing and correcting variability, and sticks to easily obtained and interpreted tools, whose output is widely understood and for which support is readily available. The underlying philosophy has correctly been described as "measure, don't guess," a welcome relief in a world where system administrators often make changes based on a hunch or institutional mythology.

Database administrators often limit their tools to little more than building new indexes and rewriting queries, so it's surprising to note that those topics don't make their appearance until chapters 9 and 10 respectively, halfway through the book. That said, they receive the same detailed attention given earlier to database hardware, and later on to monitoring tools and replication. Smith thoroughly explains each of the operations that may appear in PostgreSQL's often overwhelming query plans, describes each index type and its variations, and goes deeply into how the query planner decides on the best way to execute a query.

Other chapters cover such topics as file systems, configuration options suitable for various scenarios, partitioning, and common pitfalls, each in depth. In fact, the whole book is extremely detailed. Although the tools introduced for benchmarking, monitoring, and the like are well described and their use nicely demonstrated, this is not a book a PostgreSQL beginner would use to get started. Smith's writing style is clear and blessedly free of errors and confusion, as is easily seen by his many posts on PostgreSQL mailing lists throughout the years, but it is deeply detailed, and the uninitiated could quickly get lost.

This is also a very long book, and although not built strictly as a reference manual, it's probably best treated as one, after an initial thorough reading. It covers each topic in such detail that each must be absorbed before further reading can be beneficial. Figures and other non-textual interruptions are, unfortunately, almost nowhere to be found, so despite the author's clear and easy style, it can be a tiring read.

It is, however, one of the clearest, most thorough, and best presented descriptions of the full depth of PostgreSQL currently available, and doubtless has something to teach any frequent user of a PostgreSQL database. Those planning a new database will welcome the straightforward and comprehensive presentation of hardware-level details that are difficult or impossible to change after a system goes into production; administrators will benefit from its discussion of configuration options and applicable tools; and users and developers will embrace its comprehensive description of query planning and optimization. "PostgreSQL 9.0 High Performance" will be a valuable tool for all PostgreSQL users interested in getting the most from their database.

Comment Re:What it takes (Score 1) 997

Where possible my "deadlines" are actually milestones based on how long I think it would take ME to perform the task. I keep my skills pretty up to date and 9 times out of 10 am a contributing member of the team so I know the code pretty well. I wouldn't fire someone for missing a deadline... I would consider it if they missed it without giving a heads up or some explanation.

Comment Re:What it takes (Score 4, Interesting) 997

As a startup founder, director, and CTO (not all at the same time, mind you) I would frequently send developers home if they weren't being productive... even if they were only there for 4 or 5 hours. Sometimes you hit a wall and no amount of staring at that screen is going to help. Why would I want to pay you to sit there and do nothing when I could send you home and you come back tomorrow refreshed and ready to tackle the problem? I rarely let anyone work more than 10 or 11 hours because my experience taught me that the quality of what is produced is *drastically* reduced during those death marches. Again... sure a team may roll out a dozen new features over an 18 hour day but how many bugs will that produce? More importantly, how demotivated will they be the next day on 3 hours of sleep? It's a vicious cycle that I never allow my teams to enter. It's all about the bottom line and to me inching a race forward is no good unless you meet the finish line. That being said, a developer who has to be sent home after 5 or 6 hours every day is completely worthless to me. You are either on-board or you are not. I don't care how or when you work as long as you produce product that is exceptional. A rule that I had at my first CTO gig was as follows: "I don't care if I ever see you in the office. If you miss a deadline without giving me sufficient advance warning I will fire you. You were hired because you are smart and a quality coder. I shouldn't have to babysit you." Works well if you have a driven team.

Slashdot Top Deals

Yes, we will be going to OSI, Mars, and Pluto, but not necessarily in that order. -- Jeffrey Honig