Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Submission + - Wozniak Gets Personal On Innovation

snydeq writes: Companies are doggedly pursuing the next big thing in technology, but nothing seems to be pointing to the right way these days, claims the legendary Steve Wozniak. The reason? 'You tend to deal with the past,' replicating what you know in a new form. Consider the notion of computing eyeware like Google Glass: 'People have been marrying eyewear with TV inputs for 20 years,' Wozniak says. True innovation, Wozniak claims, becomes more human, more personal. People use technology more the less it feels like technology. 'The software gets more accepted when it works in human ways — meaning in noncomputer ways.' Here, Wozniak says, is the key to technology's role in the education system.

Submission + - Hewlett Packard Turns Buggy Software and Firmware Into a Revenue Stream!

neversleepy writes: In the face of ever declining server sales. And in a move certian to affect many readers here, Hewlett Packard decides to provide updates to firmware and critical OS drivers only to customers who pay a premium for a CarePack, extended service contract. If this affects you negatively, try telling Hewlett Packard what you think about payola for hardware bug fixes.

Or maybe, the time is right to abandon vanity servers?

Submission + - Audience Jeers Contestant Who Uses Game Theory to Win at 'Jeopardy'

Hugh Pickens DOT Com writes: USA Today reports that Arthur Chu, an insurance compliance analyst and aspiring actor, has won $102,800 in four Jeopardy! appearances using a strategy —- jumping around the board instead of running categories straight down, betting odd amounts on Daily Doubles and doing a final wager to tie — that has fans calling him a "villain" and "smug". Arthur's in-game strategy of searching for the Daily Double that has made him such a target. Typically, contestants choose a single category and progressively move from the lowest amount up to the highest, giving viewers an easy-to-understand escalation of difficulty. But Arthur has his sights solely set on finding those hidden Daily Doubles, which are usually located on the three highest-paying rungs in the categories (the category itself is random). That means, rather than building up in difficulty, he begins at the most difficult questions. Once the two most difficult questions have been taken off the board in one column, he quickly jumps to another category. It's a grating experience for the viewer, who isn't given enough to time to get in a rhythm or fully comprehend the new subject area. "The more unpredictable you are, the more you put your opponents off-balance, the longer you can keep an initial advantage," says Chu. "It greatly increases your chance of winning the game if you can pull it off, and I saw no reason not to do it." Another contra-intuitive move Chu has made is playing for a tie rather than to win in "Final Jeopardy" because that allows you advance to the next round which is the most important thing, not the amount of money you win in one game. "In terms of influence on the game, Arthur looks like a trendsetter of things to come," says Eric Levenson. "Hopefully that has more to do with his game theory than with his aggressive button-pressing."

Submission + - Why a Google Ethics commission is an oxymoron (computerworld.com)

rsmiller510 writes: Ah, you have to love Google. After people raised concerns about its purchase of Deep Mind, an artificial intelligence company, Google reportedly responded by saying it would form an ethics commission to make sure that all of Google's artificial intelligence research was on the up and up. Excuse me while I spit out my coffee, but Google and ethics go together about as well the House Intelligence Committee. Which of these things is not like the other and who in their right mind is going to trust Google to be self-policing on anything, never mind AI?

Submission + - When the Project Manager Is the Problem

Esther Schindler writes: Project managers need to be great traffic cops, coordinators, and problem solvers. When they do their jobs right, they make everyone around them more effective. But when they’re bad — ouch. They can become the worst sort of bottleneck, and inspiration for a lot of heavy drinking.

The question is: How can you tell that the source of the problem is the project manager rather than the situation in which an otherwise-good project manager finds herself? And even when it's obvious, what can you do about it? In The Cure After Diagnosing a Bad Project Manager, Tim Walker helps you identify when it’s the project manager who’s the problem as well as causes and some useful, non-career-limiting solutions. ("Copy out, then copy up" might have been useful to me in one poopstorm.)

Got suggestions to add to his list?

Submission + - Moving beyond Snowden, what kind of country does America want to be (computerworld.com)

rsmiller510 writes: We've pretty much exhausted the Edward Snowden debate. You may think he's a hero or a villain, but whatever you think you can't undo what he did. The genie is out of the bottle and we now what we know about the extent of government surveillance. We can't pretend we don't, so the time has come to debate the issues and figure just what level of surveillance is required to make us safe --and if we can do it within the rule of law or continue to give security apparatus carte blance to monitor anyone's activities at any time, regardless of whether they are suspected of a crime or not.

Submission + - OF COURSE I want a Star Trek Bridge at home!

Esther Schindler writes: Anyone who hangs out on slashdot can be relied on for Star Trek literacy if not fandom. As Carol Pinchefsky writes, "Chances are you've wanted to live on the Enterprise, quaff a glass of tranya and wager your quatloos on a death match. You can't — not until quatloos are legal tender. But if you're Line Rainville, you can have the next best thing: a full-sized basement that replicates the spirit of the NCC-1701." And so, in Fan explains why she spent $30,000 to re-create the bridge of Star Trek's Enterprise, Pinchefsky interviews the woman who made that kind of investment. Admit it: Even if you think this is overboard, you want to peek at the photos.

Submission + - The Pre-History of Software as a Service

Esther Schindler writes: Nowadays, everyone uses Software as a Service; it's the one part of cloud computing that doesn't make anybody sneer. But some of us are old enough to remember that we tried this business model before, over a decade ago, and it failed miserably. What changed in cloud computing to make SaaS work today, when few Application Service Providers survived?

Steven Vaughan-Nichols and I worked together at Sm@rt Reseller magazine in the late 90s during the heyday of ASPs (along with Mary Jo Foley, Debbie Gage, Jason Perlow, and other journalists whose names you know), and we got into a discussion about what made SaaS work where ASPs failed. In The Pre-History of Software as a Service, sjvn goes into the reasons... and no, it's not just a matter of virtualization technologies.

Submission + - A Short History of Computers in the Movies

Esther Schindler writes: The big screen has always tried to keep step with technology usually unsuccessfully. Peter Salus looks at how the film industry has treated computing.

For a long time, the "product placement" of big iron was limited to a few brands, primarily Burroughs. For instance:

Batman: The Movie and Fantastic Voyage (both 1966) revert to the archaic Burroughs B205, though Fantastic Voyage also shows an IBM AN/FSQ-7 Combat Direction Central. At 250 tons for each installation (there were about two dozen) the AN/FSQ-7 was the largest computer ever built, with 60,000 vacuum tubes and a requirement of 3 megawatts of power to perform 75,000 ips for regional radar centers. The last IBM AN/FSQ-7, at Luke Air Force Base in Arizona, was demolished in February 1984.

Fun reading, I think.

Submission + - SF movies teach us project management skills

Esther Schindler writes: Or maybe they don't, but it's certainly fun to pretend to find work inspiration from our favorite SF films. That's what Carol Pinchefsky does in two posts, one about positive business lessons you can take away from SF films (such as "agile thinking can save many a project (and project manager) in a crisis" from Robocop and team motivation lessons from Buffy), and the other, 5 Project Management Horror Stories Found in Sci-Fi Movies, with examples of the impact of poor documentation on Captain America.

It's worth a giggle and, maybe, a thoughtful moment.

Submission + - Security hole in ack versions 2.00 to 2.11_02.

Esther Schindler writes: ack is a grep-like tool that is specifically created to make searching source code easier. One of the features added in ack 2.00 was the ability to have command line options in per-project .ackrc files. This has led to a serious security hole. There is, however, a workaround.

Submission + - Heroku will only sponsor events that have a code of conduct in place (heroku.com)

An anonymous reader writes: No code of conduct? No cash. Heroku (owned by Salesforce) announced a new policy that requires events to have —or adopt— a code of conduct policy before getting sponsorship funds. Heroku also became an Ada Initiative corporate sponsor with a $10,000 contribution.

Submission + - Why Johnny Can't Write Multithreaded Programs

Esther Schindler writes: Programming for multiple threads is not fundamentally different from writing an event-oriented GUI application or even a straight up sequential application, writes Jim Mischel. The important lessons of encapsulation, separation of concerns, loose coupling, etc. all apply.

But developers get into trouble with multiple threads when they don’t apply those lessons; instead they try to apply the mostly-irrelevant bits of information they learned about threads and synchronization primitives from introductory multithreading texts. Mischel focuses on two things that developers do wrong when writing multithreaded code, and explains how to avoid them.

Here's one of them:

Probably the most important lesson to be learned from the past 60 years of software development is that global mutable state is bad. Really bad. Programs that depend on global mutable state are harder to reason about and generally less reliable, because there are too many possible ways for the state to change. There is a huge amount of research to back up that generalization, and countless design patterns whose primary purpose is to implement some type of data hiding. The best thing you can do to make your programs easier to reason about is to eliminate as much global mutable state as possible.

Think he's on track? What have you you learned about writing multithreaded code that might save the next programmer from teeth-gnashing?

Submission + - 12 Things Developers Wish the CIO Remembered

Esther Schindler writes: Every CIO wants to build a development team that’s hard-working, loyal, and devoted to creating quality software. The developers are willing! But they want CIOs to lead them and understand their needs. Andy Lester writes an open letter explaining what developers hope their CIOs keep in mind to motivate them and make them happy.

For instance:
  • We need to be protected from the rest of the organization.
  • We don’t ask for stuff just for the hell of it.
  • Be glad we spend so much time on automated tests.

Read his list, and see if there's anything you'd add, or with which you disagree. (Wait, this is slashdot. Of course you are going to disagree!)

Slashdot Top Deals

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

Working...