If you've ever wanted to run a Java app on a debian box, you know why this matters.
The strictly FOSS distros have historically refused to include a Java package due to its non-Free license. There's some really good Java software out there, and without a pre-built java package, it was just that much harder to access them.
Offtopic, but that "old-lady vs McDonalds" lawsuit was actually valid
Every coffee shop still serves their coffee at the same temperature (180 degrees), or hotter. Take a thermometer into starbucks and order a drip coffee. It'll read at least 180. In fact, the ISO standard for coffee machines requires that the water be heated to around 200 degrees.
There have been dozens of spilled-coffee suits since this one, against all the major coffee chains. The vast majority of them failed, and none of them have altered their coffee serving temperatures.
Yes, this woman's injuries were grave. And they were her own damn fault. She sat in the spilled coffee for over NINETY SECONDS. Anyone who wasn't a complete idiot would have jumped out of their car, and ripped their pants off, if necessary, inside of 5 seconds.
Obviously, this woman's lawyers did a hell of a job, if they've still got people believing that this lawsuit wasn't complete bullshit. Because it was. If it wasn't, you wouldn't still be able to get a cup of coffee at the same temperature.
Obviously, the product is interesting if Google supposedly wanted to steal it.
It was interesting, but that doesn't mean it wasn't also trivial and obvious.
There have been many, many outlook importer tools written since outlook was created. They're extremely trivial to write, especially if you take advantage of outlook's CSV export functionality -- this is comp sci 101 level work.
Great. Then you'll know when the kids who grew up with this technology get bored -- they'll subconsciously start to make the "fast forward" facial expression.
And when they mishear something, they'll make the "rewind" face.
The metrics that matter are really dependent on the project. For the shuttle software, the number one priority is reliability. Their software, above all else, must do one thing: not kill a handful of people floating tin can surrounded by vacuum. If that means going over schedule and over budget, while not ideal, better that than 4 corpsicles floating in orbit.
On the other hand, if you're developing the latest and greatest web app, time to market is huge -- otherwise someone else is going to beat you to it. If you took the approach the shuttle team took, by the time you launched, your project would have been obsolete for years, and you'd have sunk more money into development than you could ever recover.
So I suppose that's perhaps that's the first step to good project planning: identify the metrics that really matter for your project.
Specifically, the group that wrote the software for the space shuttle. With a defects-per-line rate less than 1/1000th of the average, they're doing something right.
Of course, with a full pages of documentation for every 10 lines of code, and an average daily output of roughly a dozen lines of code, their process is much more time consuming and expensive than can be supported by most development budgets.
But they serve as an example of the wide spectrum of approaches to software development.
Why not just use the largest 10 or 20, and leave the rest of 'em in the closet for now?
Either your 10-20 drive pilot project will be a raging success, and your boss will be beating down your door to get the other drives plugged in, or it'll prove to be a huge waste of time, in which case you'll be glad you didn't bother with the smaller drives.
I built a machine 6 months ago for about $400 that should work acceptably, according to these specs -- a $100 asus mobo, $100 for an old geforce 7600, $50 for the cheapest AMD dual-core proc, and $50 for 2 gig of ram.
Glad to see they took the time to make sure Spore will run on low end PCs.
And how exactly do you plan to do that? Do we have any material that won't melt under the intense heat?
From TFA:
At closest approach, Solar Probe+ will be 7 million km or 9 solar radii from the sun. There, the spacecraft's carbon-composite heat shield must withstand temperatures greater than 1400 C
It just doesn't pay to get in on the ground floor with an MMO.
There's also a disadvantage to getting in too late, though. Newcomers to WoW are increasingly finding that it's very hard to find people to run low-level instances with, and as a result, when they finally *do* catch up with everyone else at level 70, they don't have the instance-running skills they need to successfully contribute to end-game instance runs.
Similarly, there's no value in low-level trade goods, like there once was. Back around launch, you could make serious bank sewing low level packs to other players, etc. These days, it's next to impossible to find buyers for anything you craft until you get up to higher levels.
For the optimal MMO experience, you want to get in while there are still plenty of new players coming in so you'll have people of the same level to quest, hunt and trade with, but after the major bugs have been worked out.
On a related note, this system is more or less a direct copy of LotRO's deed system.
That's okay, Turbine has cribbed a few features from WoW too. e.g., in their first MMO, Asheron's Call, they recently introduced a quest that's virtually indistinguishable from the various WoW deck quests (deck of warlords, deck of portals, etc. etc.). Hell, the whole LOTR UI looks a lot more like WoW than it does Turbine's previous games...
There's an awful lot of 'borrowing' in the MMO industry.
I stuck by it and fiddled with it until one day in a lab I had to do some extensive spreadsheet work. Specifically, getting data out of a tab-delimited file, approx 15,000 rows and ~5ish columns. Every way I could possibly attempt to open, paste, import this file would throw OpenOffice into a seemingly endless loop. I'd wait 20, 30, 40 minutes, but it couldn't handle this 100kB file no matter how I diced it.
I used OO.o for years for manipulating the exact same kinds of files, and found it vastly superior to Excel. Excel struggles to correctly read many varieties of CSV files, and loves to mangle data -- try opening a CSV full of ISBN numbers, and watch Excel helpfully mangle them to floats. Whatever you do, don't save the file, or Excel will *overwrite* your 10+ digit integers in exponential notation!
Regarding performance, years ago, when I voiced the same complaint here on/., someone suggested disabling Java in OO.o. It made a big difference. I was using a 1.x version at the time; I don't know if this is still the case in 2.x.
The performance may not be stellar (although I really don't recall noticing a substantial difference), but in terms of functionality, there are many areas where OO.o outshines MS Office.
They are the premier provider of web services and that is where they should stay. Desktop applications are the past, web services are the future.
Off the top of my head, I can think of several desktop applications that google produces:
Google earth. Google desktop search. Google Chat.
Their goal is not producing web services, it's making data more accessible. Making it easier to access google docs from a desktop office application may very well fall within that scope.
As others have noted here, google docs does not perform terribly well. For performance-intensive things, desktop applications are still better solutions than web-based ones. Office applications are one of those things -- they have tons of functionality.
Google would do well to:
* make it trivial to save and load google docs docs from within OO.o
* add real-time collaborative editing of google docs to OO.o
It's just not possible to get all the functionality of OO.o into a web app, and have it perform comparably on the same hardware.
I'm wondering if the traditional lock approach used in MySQL (and most SQL databases as far as I know) somewhat kills parallel operations. Wouldn't the interbase approach work better in a parallel environment?
Both interbase and MySQL's InnoDB engine use the concept of Multi Version Concurrency Control (MVCC) to address the issue of simultaneous access -- although their implemenations differ: InnoDB does make use of row-level write locks. The upcoming Falcon engine is said to do the same with even fewer locks than InnoDB.
All should parallelize fairly well -- it's the table-level locks of MySQL's default MyISAM engine that really kill simultaneous access.
In the block of text at the top of the page, it says "NOT an official google product!". Additionally, the whois info for the domain shows it's personally registered by Mr. Grothkopp himself, in Germany.
As such, if by "google side project", you mean "an experimental project created by a google employee", I believe you may be wrong. It's some random hacker's side project, and it queries a google API, but that's the only resemblance to a "google side project" it bears.
Having a huge library of useful stuff built in, and decently documented is a big part of PHP's success.
Most PHP installs include XML parsers, CURL, database client libs, image manipulation, session management, and a whole slew of web-related functions (built in URL parsing, file uploads, etc.) right out of the box. That makes it easy to do damn near anything you'd want to do in a web app without getting into external libraries. And they're (almost) all cross-platform.
Java and Perl both do a pretty good job at making extensibility simple as well. Honestly, that's probably a big reason for VB's success among neophyte programmers as well.
Both PHP and VB also offer a fairly lax syntax, which also makes them a little easier to pick up.
Make it easy to do a lot, and the newbies will follow, it seems.
Back when John Carmack gained his fame, entire video games were produced by 3-4 people.
I know a guy who worked at Lucasfilm Games (now LucasArts) in the 80's. He recently went back for their 25th anniversary party, and talked about his experiences there at the time. He worked on some Commodore 64 games at the time, usually with maybe one other engineer. He was responsible for pretty much everything -- writing the memory manager, networking code, graphics, etc. etc.
At lunch, the kid he sat next to was responsible for wood and ice simulation in the new star wars game -- and nothing else. They said rendering a single pixel in that game required about as much memory as a whole commodore 64 had -- 32k.
So yeah, game development has changed dramatically.
Slashdot Mirror
If you've ever wanted to run a Java app on a debian box, you know why this matters.
The strictly FOSS distros have historically refused to include a Java package due to its non-Free license. There's some really good Java software out there, and without a pre-built java package, it was just that much harder to access them.
There have been dozens of spilled-coffee suits since this one, against all the major coffee chains. The vast majority of them failed, and none of them have altered their coffee serving temperatures.
Yes, this woman's injuries were grave. And they were her own damn fault. She sat in the spilled coffee for over NINETY SECONDS. Anyone who wasn't a complete idiot would have jumped out of their car, and ripped their pants off, if necessary, inside of 5 seconds.
Obviously, this woman's lawyers did a hell of a job, if they've still got people believing that this lawsuit wasn't complete bullshit. Because it was. If it wasn't, you wouldn't still be able to get a cup of coffee at the same temperature.
http://en.wikipedia.org/wiki/McDonald's_coffee_case#Other_coffee_burn_cases
There have been many, many outlook importer tools written since outlook was created. They're extremely trivial to write, especially if you take advantage of outlook's CSV export functionality -- this is comp sci 101 level work.
Great. Then you'll know when the kids who grew up with this technology get bored -- they'll subconsciously start to make the "fast forward" facial expression.
And when they mishear something, they'll make the "rewind" face.
I can't wait. It'll be hilarious.
Apparently it's very achievable -- CMSU came pretty close to claiming the $100,000 prize in late 2006.
You bring up a good point:
The metrics that matter are really dependent on the project. For the shuttle software, the number one priority is reliability. Their software, above all else, must do one thing: not kill a handful of people floating tin can surrounded by vacuum. If that means going over schedule and over budget, while not ideal, better that than 4 corpsicles floating in orbit.
On the other hand, if you're developing the latest and greatest web app, time to market is huge -- otherwise someone else is going to beat you to it. If you took the approach the shuttle team took, by the time you launched, your project would have been obsolete for years, and you'd have sunk more money into development than you could ever recover.
So I suppose that's perhaps that's the first step to good project planning: identify the metrics that really matter for your project.
Specifically, the group that wrote the software for the space shuttle. With a defects-per-line rate less than 1/1000th of the average, they're doing something right.
http://www.fastcompany.com/magazine/06/writestuff.html
Of course, with a full pages of documentation for every 10 lines of code, and an average daily output of roughly a dozen lines of code, their process is much more time consuming and expensive than can be supported by most development budgets.
But they serve as an example of the wide spectrum of approaches to software development.
I hate to sound a bit alarmist here, but which project can we expect to see go next?
I'm just that more hesitant to use google products, if they're prone to axing them without warning.
Why not just use the largest 10 or 20, and leave the rest of 'em in the closet for now?
Either your 10-20 drive pilot project will be a raging success, and your boss will be beating down your door to get the other drives plugged in, or it'll prove to be a huge waste of time, in which case you'll be glad you didn't bother with the smaller drives.
I built a machine 6 months ago for about $400 that should work acceptably, according to these specs -- a $100 asus mobo, $100 for an old geforce 7600, $50 for the cheapest AMD dual-core proc, and $50 for 2 gig of ram.
Glad to see they took the time to make sure Spore will run on low end PCs.
Similarly, there's no value in low-level trade goods, like there once was. Back around launch, you could make serious bank sewing low level packs to other players, etc. These days, it's next to impossible to find buyers for anything you craft until you get up to higher levels.
For the optimal MMO experience, you want to get in while there are still plenty of new players coming in so you'll have people of the same level to quest, hunt and trade with, but after the major bugs have been worked out.
There's an awful lot of 'borrowing' in the MMO industry.
So, his work is already available digitally.
What exactly is preventing piracy in this situation that wouldn't in the case of an eBook release?
Regarding performance, years ago, when I voiced the same complaint here on
The performance may not be stellar (although I really don't recall noticing a substantial difference), but in terms of functionality, there are many areas where OO.o outshines MS Office.
Google earth. Google desktop search. Google Chat.
Their goal is not producing web services, it's making data more accessible. Making it easier to access google docs from a desktop office application may very well fall within that scope.
As others have noted here, google docs does not perform terribly well. For performance-intensive things, desktop applications are still better solutions than web-based ones. Office applications are one of those things -- they have tons of functionality.
Google would do well to:
* make it trivial to save and load google docs docs from within OO.o
* add real-time collaborative editing of google docs to OO.o
It's just not possible to get all the functionality of OO.o into a web app, and have it perform comparably on the same hardware.
All should parallelize fairly well -- it's the table-level locks of MySQL's default MyISAM engine that really kill simultaneous access.
As such, if by "google side project", you mean "an experimental project created by a google employee", I believe you may be wrong. It's some random hacker's side project, and it queries a google API, but that's the only resemblance to a "google side project" it bears.
Yeah, the "open world adventuring" bit makes it sound more like GTA: Persia than an RPG.
Except without the city, hookers, guns, or cars.
It'll fly right off the shelves, I'm sure.
Having a huge library of useful stuff built in, and decently documented is a big part of PHP's success.
Most PHP installs include XML parsers, CURL, database client libs, image manipulation, session management, and a whole slew of web-related functions (built in URL parsing, file uploads, etc.) right out of the box. That makes it easy to do damn near anything you'd want to do in a web app without getting into external libraries. And they're (almost) all cross-platform.
Java and Perl both do a pretty good job at making extensibility simple as well. Honestly, that's probably a big reason for VB's success among neophyte programmers as well.
Both PHP and VB also offer a fairly lax syntax, which also makes them a little easier to pick up.
Make it easy to do a lot, and the newbies will follow, it seems.
At lunch, the kid he sat next to was responsible for wood and ice simulation in the new star wars game -- and nothing else. They said rendering a single pixel in that game required about as much memory as a whole commodore 64 had -- 32k.
So yeah, game development has changed dramatically.