Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Always a cheaper fish... (Score 2) 59

by fuzzyfuzzyfungus (#49146395) Attached to: Microsoft Closing Two Phone Factories In China
Given that China has historically been the nominally-communist-but-attractively-cheap-and-open-for-business destination, they can't be entirely surprised that Vietnam is now cutting into their action.

That aside, though, I wonder if this is more or less purely cost focused, or whether the quasi-mercantalist Chinese government policies aimed at aiding domestic firms and speeding up acquisition of foreign firms' tech has a bigger role? They aren't necessarily irrational, given that competing on price and low environmental standards isn't exactly a fun game, even when you are winning it; but such policies presumably do encourage foreign firms to head for the exit more quickly at the same time as they reduce the impact of their doing so.

Comment: Re:It's not just the fragmentation (Score 2) 133

by iluvcapra (#49144819) Attached to: Who's Afraid of Android Fragmentation?

Meanwhile, there is this PC platform that wiped out all of it's other bespoke competitors probably before you even touched your first computer.

An open platform running a bespoke OS stack. It also helped that the original PC clone makers were just that, cloning down to the schematic level the IBM PC.

Android smartphones are bespoke hardware, the average Samsung or Nokia smartphone might as well be Kaypro or a Commodore PET. iPhones are relatively generic by comparison.

In the end this isn't really a technological problem, the business dynamics of the smartphone business just aren't the same as PCs. Development man-hours are very cheap now compared to the 1980s, it's very practical to port an app back and forth. But this means that there is the Network Effect for the OSs quite diminished, so the platform that offers the best business case to developers is going to get the most developers.

And Google doesn't care about third party developers. Google just isn't MS in the 1980s, it doesn't approach app devs as if they were clients, or their core constituency. It doesn't hate them, it doesn't like them, doesn't lock them out, doesn't lock them in, it's just indifferent. They make a big show when it comes to cool libraries and features, but they have minimal commitment to seeing app dev paid. Fragmentation is what iOS fanboys point to when they want to see Android fail, and it's what Android devs point to when they want to talk about something other than revenue.

But Android will continue to be the dominant cellphone platform for the foreseeable future worldwide, because it's cheap and it's "enough." App devs will continue to be losers who need to sell to iOS to make money, smartphone manufacturers will continue to get piss-poor margins as they grind each other into the ground, and actual smartphone users won't really get anything more out of their phone than they ever did, but Google will get its a impressions and user metrics. Which was the whole reason they started this cockamamie thing in the first place.

This is just NOT the PC business in 1980 -- you've got a billion-dollar behemoth basically giving away the keys to the castle so it can make money on the ads and front-running web searches. This completely disrupts the model that MS and the PC manufacturers exploited.

Comment: Re:Simple methodology (Score 4, Funny) 304

by presidenteloco (#49143761) Attached to: The Programmers Who Want To Get Rid of Software Estimates

My methodology:

If someone gives me their estimate for a software project or task, I double it and add 30.

If someone asks me for an estimate for a software project or task, I rough it out, then double it and add 30.

It's really amazing how much stress that avoids (oh, and it also does a passable job of converting Celsius to Fahrenheit.)

Comment: System Development Foundation (Score 1) 43

by Baldrson (#49141679) Attached to: The Believers: Behind the Rise of Neural Nets

Its "System Development Foundation" not "System Development Corporation" and Charlie's full name is Charles Sinclair Smith. He's semi-retired now and living the next county over from me in southeast Iowa where we've been collaborating on a couple of projects -- one of which is to photosynthesize all of the CO2 effluent from US fossil fuel power plants (as Charlie got his start co-founding the Energy Information Administration of the DoE under Carter).

Its ironic that in the 80s I was living in La Jolla, which was an epicenter of the neural net revival at UCSD, had taken neural net courses from Robert Hecht-Nielsen and by 1990 had prototyped the highest performance neural network image processing system (as Neural Engines Corporation) -- but I then later worked with Charlie for almost 15 years before discovering he had had played such a key role in the revival of neural nets. Even more ironic is that, circa 2005, I came up with the idea for the Hutter Prize for Lossless Compression of Human Knowledge -- based on Hutter's entirely different, top down mathematics approach to AI -- and Shane Legg, founder of Deep Mind, which is largely identified with deep learning neural nets, actuality studied under Hutter and achieved Deep Mind's famous ability to learn to play video games using Hutter's approach but everyone thinks that capability is uniquely attributable to deep neural net learning alone.

Comment: Re: Cost savings (Score 1) 102

by presidenteloco (#49134017) Attached to: Argonne National Laboratory Shuts Down Online Ask a Scientist Program

"You want this kind of thing to continue? Make sure there's funding (and paid time) earmarked for doing it."

So let's see. A simple web-app with a database hosted on a crappy server computer somewhere.
That's going to cost the whopping sum of what $50 a year to maintain right?

I for one welcome our new fiscal watchdog overlords.

Comment: Yes and no (Score 1) 286

by jd (#49129871) Attached to: Moxie Marlinspike: GPG Has Run Its Course

First, the complexity of the engine shouldn't matter. You will never get the bulk of users out there to use, or care about, the real power of the engine. They don't want to mess with the engine. The engine should be under the hood, in a black box, whatever engineering metaphor you want. Users just want things that work.

I remember way back when I was at university. There were various absolute rules for good software engineering. The first was that the user should be presented with a must-read manual no longer than one paragraph. Tips and tricks could be more extensive, but that one paragraph was all you needed.

The second was that the user absolutely must not care about how something was implemented. In the case of encryption, I take that to mean, in the case of e-mail, that the engine should not be visible outside of configuration. A supplied key should trigger any behind-the-scenes compatibility mode or necessary configuration to talk to that user. If the keys the user has aren't suitable to correspond with that person, the system should ask if one is needed and tie it to that protocol.

There should be no extra controls in e-mail, except at an advanced user level. If a key exists to correspond with a user, it should be used. If a key exists for inbound e-mail, the key should be applied. The process should be transparent, beyond getting passwords.

Any indexes (particularly if full indexes) should be as secure as the message, good security practices on both will take care of any issues.

Ideally, you want to have the same grades of authentication as for the early certification system, adapted to embed the idea that different people in the web of trust will have done different levels of validation and will be trusted to different degrees. The user should see, but not have to deal with, the level of trust.

Last, GnuPG is probably not the system I'd use. Compatibility cruft needs to be as an optional layer and I'm not confident in implementation.

There should be eight main libraries - public key methods, secret key methods, encryption modes, hashes (which encryption modes will obviously pull from), high level protocols, key store, index store and lacing store. (Lacing is how these are threaded together.) The APIs and ABIs to those libraries should be standardized, so that patching is minimally intrusive and you can exploit the Bazaar approach to get the best mix-n-match.

There should also be a trusted source in the community who can evaluate the code against the various secure and robust programming standards, any utilized theorum provers and the accepted best practices in cryptography. Essentially replicate the sort of work NIST does, but keeping it open and keeping it free of conflict of NSA interest.

Comment: Re:Pesticides for humans (Score 1) 224

by fuzzyfuzzyfungus (#49125975) Attached to: 100 Years of Chemical Weapons
The other problem with chlorine is that it's among the cheaper ways of bringing a semblance of sanitation to a municipal water supply.

Really classy first-world jurisdictions can use Ozone systems(which have the advantage of basically perfect decomposition into harmless oxygen by the time the water reaches customers, and need only electricity and occasional spare parts at the treatment plant, rather than big tanks of chlorine); but anywhere else is probably chlorinating the fecal bacteria out of the water supply, which saves a ton of lives(especially if the medical system is lousy); but also means that chlorine is basically just sitting around.

We ran into that issue in Iraq from time to time. Chlorine is a really lousy war gas, barely toxic enough to count as one at all; but just sending a couple guys with guns and a truck down to the water treatment plant could score you enough of the stuff to release in the nearest crowded area for some reliable freaking out and some casualties.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.