The way things are looking, I can hack one out in a few days. We will borrow from X, Y, and Z projects since they have most of the functionality we need. It will be a matter of fitting them all together. Thus, Gnumeric was born. And I am dead serious on this too.
Nice story, but it's bullshit. Gnumeric couldn't have borrowed code because there was no one to borrow from. Neither KSpread nor OpenOffice Calc were around: Gnumeric was the first of the modern Linux spreadsheets. The only options around at that time Oleo and Siag. You don't get an app of Gnumeric's quality (it's probably the best OSS spreadsheet around, including OO.o) by copying all your code from Siag and Oleo.
I know that. The original poster was ranting about how Japan needed the energy that would be produced by this plant. I'm just trying to say that there won't be a net energy increase from this plant.
That depends on the person, their talents, and their employment situation. Some people could probably do it in a few weeks of really hard work (i.e. full time). For others, it could take up all of their spare time for a year.
Just go to your local Best Buy/CompUSA and experiment with the keyboards they have out. You won't find a silent one, but some are much better than other. If you don't pound the keys, some standard keyboards are barely audible (my MS MultiMedia Keyboard is pretty quiet, although I don't recommend it because the F-keys are castrated).
You said that "encryption and DRM sections of code would still need to be locked". That's bullshit. Encryption products can be made entirely open-source without compromising security, as GPG and OpenSSL. Those programs are typically not distributed with keys, because the user generates their own.
DRM products are a different story. Obviously, if a program can decrypt a file to play it, then a modified version of that program can dump the decrypted version to disk. That doesn't really matter though, because the kind of people stupid enough to insist on DRM would never consider open-source anyway.
Okay, I only read the BBC article and missed that. Still, this reactor is experimental and only meant to operate for 500 seconds at a time or so. If nothing else, it will take far more energy to construct than it will ever produce.
This reactor is simply an experiment, and will pump out less energy than it takes to operate. No power is going to be distributed from it, in fact it will actually need power distributed to it. But don't let the facts get in the way of your ranting.
Japan is a model nation that would benefit form this technology (Japan lacks natural energy resources)
Except, this reactor will take more energy to operate than it will actually produce. That's the problem with fusion power in its current form. At the moment, this technology won't benefit Japan's energy needs at all.
a country that harbors more support for terrorism than any other western nation on the planet
No western country that I know of (except possibly a few conflicted South American states) supports terrorism in any form. If you really mean harbors support for terrorism, I'd say the US probably harbors more terrorists (knowingly or not) than a good deal of other nations combined.
So? If you're storing a cryto key in your actual code, you've got some serious problems. It's perfectly possible to write a completely open-source crypto program - look at GPG or OpenSSL.
Android (Google for it) provides a low-level way to do this. The framework is built into GTK (and QT too, I think) for much better scripting support, but it's not really implemented at the moment.
So how do you copy/cut/paste an image? A file in Nautilus or Konqueror? Formatted text? An embedded Bonobo/KParts object? You can't, without hacking around the X way and implementing your own method. That's the problem.
Perl.com is registered in Colorado, where the legal age is 15, so long as you're no more than ten years older than Perl. If you are, you've only got one more year to wait - she'll be full legal at 17.
I wasn't talking about using an rdbms at all. I was talking about two different ways to organize a traditional hierarchical system, both of which require a "database" in the loosest sense of the term (i.e. could easily be a flat text file).
A RDBMS for storing user data is nice, but do you want your/sbin or even/usr/bin stored in an RDBMS? Even with a true database-based system, there has to be a decent way to organize binaries outside of the database.
With virtual directories, you could have a setup like: /applications/$application/bin /applications/$application/conf /applications/$application/conf/$user /applications/$application/init
And then to get rid of an application, just rm -rf/application/$application.
As I see it, there are two ways to do it. You can put binaries together in one location and keep a database of the other files in the app (what dpkg/rpm do now), or you can put all app files together in one location and keep a database of where all the different binaries are (what you're proposing). Aside from installation (and is drag-and-drop really that much easier than 'dpkg -i' or the graphical equivilant?), I don't see much benefit to switching from the current system.
Are you sure about that? I can't find Trolltech's proprietary license terms on their site, but your scenario implies that they allow you to resell a binary-only QT for profit under your own license (thus meaning that anyone who bought QT could then sell it to anyone else, undercutting Trolltech). That's not exactly standard for a commercial library license.
Good point, but XMMS was designed before the HIG existed and is pretty much unmaintained right now (it's not even using GTK2, and has no plans to). A next-generation XMMS is currently being developed (in secret) and will hopefully be better in that regard. There's also the beep fork of XMMS, which is advancing more rapidly. The problem is that XMMS aims to emulate the Winamp interface, and it's not really possible to make that HIG-compliant (unless they aim for Winamp 5, which is probably not going to be duplicated by OSS for a while).
Note also that we're talking about a corporate desktop here. If a corparate user needs music playback at all, they should probably be using Rhythmbox. It has a much better interface and is completely HIG-ified.
If they actually had, that wouldn't delay them. They would get to develop with the engine before it was released, just as Raven is developing with the Doom 3 engine before it's released.
LGPL is good if you like giving other people the freedom to use proprietary software if it better suits their needs. No one forces you to use proprietary software just because a library is LGPL'd.
Slashdot Mirror
Nice story, but it's bullshit. Gnumeric couldn't have borrowed code because there was no one to borrow from. Neither KSpread nor OpenOffice Calc were around: Gnumeric was the first of the modern Linux spreadsheets. The only options around at that time Oleo and Siag. You don't get an app of Gnumeric's quality (it's probably the best OSS spreadsheet around, including OO.o) by copying all your code from Siag and Oleo.
I know that. The original poster was ranting about how Japan needed the energy that would be produced by this plant. I'm just trying to say that there won't be a net energy increase from this plant.
Obviously, he doesn't think it was wasted.
Several RedHat releases have shipped and been EOL'd within that time frame.
That depends on the person, their talents, and their employment situation. Some people could probably do it in a few weeks of really hard work (i.e. full time). For others, it could take up all of their spare time for a year.
Just go to your local Best Buy/CompUSA and experiment with the keyboards they have out. You won't find a silent one, but some are much better than other. If you don't pound the keys, some standard keyboards are barely audible (my MS MultiMedia Keyboard is pretty quiet, although I don't recommend it because the F-keys are castrated).
DRM products are a different story. Obviously, if a program can decrypt a file to play it, then a modified version of that program can dump the decrypted version to disk. That doesn't really matter though, because the kind of people stupid enough to insist on DRM would never consider open-source anyway.
Okay, I only read the BBC article and missed that. Still, this reactor is experimental and only meant to operate for 500 seconds at a time or so. If nothing else, it will take far more energy to construct than it will ever produce.
This reactor is simply an experiment, and will pump out less energy than it takes to operate. No power is going to be distributed from it, in fact it will actually need power distributed to it. But don't let the facts get in the way of your ranting.
Except, this reactor will take more energy to operate than it will actually produce. That's the problem with fusion power in its current form. At the moment, this technology won't benefit Japan's energy needs at all.
No western country that I know of (except possibly a few conflicted South American states) supports terrorism in any form. If you really mean harbors support for terrorism, I'd say the US probably harbors more terrorists (knowingly or not) than a good deal of other nations combined.
So? If you're storing a cryto key in your actual code, you've got some serious problems. It's perfectly possible to write a completely open-source crypto program - look at GPG or OpenSSL.
Android (Google for it) provides a low-level way to do this. The framework is built into GTK (and QT too, I think) for much better scripting support, but it's not really implemented at the moment.
The GNOME Human Interface Guidelines and to a somewhat lesser extent the KDE Style Guidelines fufill the same purpose as the MS and Apple guidelines.
So how do you copy/cut/paste an image? A file in Nautilus or Konqueror? Formatted text? An embedded Bonobo/KParts object? You can't, without hacking around the X way and implementing your own method. That's the problem.
I will if you spend enormous amounts of your time porting Mozilla. $4000 is plenty of money, but for most people it's not worth the time investment.
Perl.com is registered in Colorado, where the legal age is 15, so long as you're no more than ten years older than Perl. If you are, you've only got one more year to wait - she'll be full legal at 17.
A RDBMS for storing user data is nice, but do you want your /sbin or even /usr/bin stored in an RDBMS? Even with a true database-based system, there has to be a decent way to organize binaries outside of the database.
And then to get rid of an application, just rm -rf
As I see it, there are two ways to do it. You can put binaries together in one location and keep a database of the other files in the app (what dpkg/rpm do now), or you can put all app files together in one location and keep a database of where all the different binaries are (what you're proposing). Aside from installation (and is drag-and-drop really that much easier than 'dpkg -i' or the graphical equivilant?), I don't see much benefit to switching from the current system.
Are you sure about that? I can't find Trolltech's proprietary license terms on their site, but your scenario implies that they allow you to resell a binary-only QT for profit under your own license (thus meaning that anyone who bought QT could then sell it to anyone else, undercutting Trolltech). That's not exactly standard for a commercial library license.
Possibly true, but that's irrelevent to the Freedoms we're discussing.
A commercial license of QT gives you no more freedom than the LGPL does. Yet, it costs money. I'm not seeing why it's a better solution.
Note also that we're talking about a corporate desktop here. If a corparate user needs music playback at all, they should probably be using Rhythmbox. It has a much better interface and is completely HIG-ified.
If they actually had, that wouldn't delay them. They would get to develop with the engine before it was released, just as Raven is developing with the Doom 3 engine before it's released.
LGPL is good if you like giving other people the freedom to use proprietary software if it better suits their needs. No one forces you to use proprietary software just because a library is LGPL'd.