Comment Re:I've read this before (Score 1) 239
I also use 'hunter2' but when I post it somewhere it always shows as "*******". It's fool-proof.
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.
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:Civil rights violation to be asked to speak cle (Score 1) 448
I spent about a year doing some work for the Seattle school district but quit shortly after I found out there were multiple teachers in the district that they had to hire "translators" for because the teacher could not effectively communicate.
Comment Re:MS ahead of the game for once? (Score 1) 302
This is why Slashdot needs a "Like" or "+1" button.
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
People who had learned on their own. Since the bulk of what I did at the time was not exactly rocket science it didn't matter if the candidate had a deep compsci background. What was important was having been around the block a few times.
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.
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.
Comment Re:....fast (Score 1) 378
You should change it to hunter2. Just don't use ******* as that is my password.
Submission + - PostgreSQL 9.0 High Performance (packtpub.com)
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.
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.
Slashdot Top Deals
Work continues in this area. -- DEC's SPR-Answering-Automaton
