My laptop is a PIII-650 and has only 192MB of RAM (and no possibility of upgrading). I am currently running GNOME 2.2, and look forward to 2.4 partly because it's supposed to use even less memory than 2.2 does.
Currently my uptime is just over 5 days (it's a laptop, remember!), and I generally leave several gnome-terminal windows, rhythmbox, Evolution 1.4, Mozilla Firebird, emacs, a DVI viewer and GnomeGV running all the time. With these apps open (plus all the normal GNOME stuff such as the panel and Nautilus) I write, build and test code and work on my thesis. Obviously this runs into swap, but it doesn't make the computer particularly unresponsive.
Remember that Linux typically uses all the available RAM up and uses it for mystical kernel things like disk caching, so just because top says that all the memory is in use it isn't necessarily a bad thing.
Not quite. If you have a class of problems, characterized by some parameter n, then for large enough n, the problems in a class that is NP will get harder with increasing n faster than they would if the class was P.
True as far as it goes. That's the whole point of complexity: to talk about the growth in the difficulty of solving a problem as the problem size grows. The reason we spend so much time studying NP hard problems is because all known general methods for solving them grow exponentially in the worst case.
Saying that the problem was NPC is a red herring; what they are actually doing is making a time/space tradeoff which would be hard of conventional computers, and then solving a particular example problem (not the class of problems).
The reason I replied to your original comment was that you implied that the work wasn't useful, or wasn't as much of a breakthrough as Adleman claims. Saying that they only solved a single instance isn't relevant: they have a method that works on any 3-SAT problem for which they can construct a long enough DNA chain to represent an assignment, and they have an implementation that actually finds the solution.
Don't forget that the first practical computer algorithm for SAT (Davis and Putnam, A Computing Procedure for Quantification Theory, Journal of the ACM, 1960) didn't even have a computer implementation: they demonstrated its usefulness by working an example out by hand!
However, conventional *serial* problems are something very hard to do with DNA, because it involves the manipulation of a single strand whereas you would be working in parallel with millions, even billions of strands for NP complete problems.
You are missing the point: NP complete problems (like 3-SAT, which is what they are solving with this DNA computer) are incredibly difficult for serial computers to solve. Nobody seems to be suggesting that DNA computers should be used for serial problems that we can already solve with conventional computers. However, being able to solve SAT (and hence other NP-hard) problems more efficiently is incredibly useful, because SAT problems exist that we can't (and might never be able to) solve using existing techniques.
According to Adleman and co-workers, their demonstration represents a watershed in DNA computation comparable with the first time that electronic computers solved a complex problem in the 1960s.
The description of the problem they are solving corresponds to a 3-SAT (propositional satisfiability with clauses of length 3) instance. In 1962 Davis, Logemann and Loveland published a paper entitled "A Machine Program for Theorem-Proving", in which they described a computer program which could solve SAT problems of a similar size, extending earlier work by Davis and others published in 1960. (You can read the paper in Communications of the ACM if you have a library that goes back that far.) So it looks like their comparison is correct.
The method they are using for the DNA computer is rather crude compared to that proposed by Davis et al, whose procedure is still in use today for solving SAT problems. We can now solve problems with thousands of variables, and actually do useful things in the process (e.g. verify hardware specifications).
There are debs of an earlier version of the gnome2 libs in unstable already, and they install alongside the gnome1.4 stuff without any problems.
The difficulty is that the gnome2 core apps (panel, control-center, nautilus, etc) are replacements for the gnome1.4 core apps, and so at some point users will have to upgrade to gnome2-core (I assume). In other words, while the libraries can be parallel installed, individual applications can't be (though of course you can still use old gnome1.4 apps alongside new gnome2 apps). Anyway, the upshot is that gnome2-core isn't in unstable yet, but you can get all the libs.
The biggest problem with your specs is that you are very unlikely to be able to coax a week of battery life out of a machine running a "standard" OS such as Linux. Batteries don't actually last very long when running a reasonably fast CPU, and in addition are extremely heavy (so you can't just solve the problem by adding lots of extra batteries).
With my laptop (Toshiba Portege 3480CT), the closest I could get to a really long uptime on batteries is by adding a high capacity battery, which costs quite a bit but would give me six hours. If I could afford one, then in addition to my two standard batteries (at least two hours from each), I would have a total of 10 hours away from the mains. That's still nowhere near a week though!
It's interesting comparing Opera's progress with Mozilla's. By the looks of things (and I must admit that I haven't tried Opera recently) Mozilla is better at rendering standard HTML + CSS than Opera.
Now it looks possible that Mozilla will be released before Opera on Linux.
Why would anyone want to use Opera if Mozilla is available?
> Now I'm *really* confused. I just started > thinking... the GPL doesn't allow linking to > closed libraries? That kinda weakens it a bit, in > my mind.
Think about what would happen if the GPL did allow linking to closed software. I write a really cool piece of software, which I release under the GPL because I'm a nice guy:-). Your local proprietary software developer finds my software, and realises that it would be just right for integrating with their application. So they link it in, as a library (they might even release the source to my code if they're feeling nice, but their code remains proprietary).
Aaargh!
My free software just became an integral part of their proprietary software, which wasn't what I wanted at all. If I had wanted that to be possible, I would have chosen to use the LGPL (Lesser General Public License), as many other projects such as GTK+ have done.
Great software and an excellent new web site
on
Gnome 1.2.0 Released
·
· Score: 1
This is one upgrade that is definitely worth the effort. GNOME is now really nice to use, and stable. I especially like being able to synchronise my Pilot with the GNOME apps just by putting it in the cradle and pressing the HotSync button. The whole thing is very polished.
The new web site is also an amazing effort. The old one has been looking a bit icky for a while, but the new site looks beautiful. Actually, it reminds me of the Apple site a bit - is it the font?
Anyway, congratulations to all the GNOME developers on a job well done.
As you note, the GPL is incompatible with the QPL (though the KDE developers can add an exception to the GPL to allow linking against QT). It isn't a problem with QT 2, which satisfies the DFSG. The problem is that it is not legal for Debian to distributed KDE without a license change.
I agree that multi-function chips are great for integrated devices like the Palms, but comparing them with PIIIs is pushing it. Putting all the functionality on a single chip does reduce complexity, but it also reduces flexibility. A PIII (or Athlon or PowerPC) can form the basis of a general purpose PC.
Both multi-function chips and more conventional CPUs have their place.
How many people are working on the Royal web site, and the other Government sites? Is your development done internally, or do you outsource much of the work? Was Linux difficult to introduce, or were your developers and management amenable to the idea?
> What I want to avoid though is writing a custom > XML parser, especially if in 2 years, every > Linux distribution is going to have one. Does > anyone know which one that is likely to be?
Several Linux distributions already include an XML parser that could (should?) become the standard: libxml, written by Daniel Viellard (he also runs the rpmfind system) from the W3C. It is already in use by the GNOME project.
Actually, they are distributing it. They have the software, and they are giving me a copy. It doesn't matter if I am a beta tester, Corel employee, or anyone else. Once I have a copy of the software (the GLP'd bits, anyway), I have the right to redistribute that software at my discretion.
Just as serious is the fact that they are claiming copyright of that software.
I'm afraid you are incorrect about being forced to use the gtk_main() function. Have a look at gtk_events_pending() and gtk_do_iteration() to see how to dispense with gtk_main().
I'm not sure what your complaint is about "g*" types being defined. It is difficult to conceive of a GUI library that doesn't define new types.
glib has developed over time to include functionality common to several programs. Some of the stuff in glib is the sort of thing you would see in the C++ STL, while other things (like gmodule (used for plugins in the GIMP and Gnumeric, among other things)) provide really useful platform independent tools.
If Caldera was in the position RedHat is (i.e. most popular distribution, big investments), I would be worried. Caldera ships a lot of proprietary software with OpenLinux (bit of a misnomer), like Netware. RedHat (while still selling some proprietary software) has been very committed to releasing the code for just about everything *they* write.
Slashdot Mirror
My laptop is a PIII-650 and has only 192MB of RAM (and no possibility of upgrading). I am currently running GNOME 2.2, and look forward to 2.4 partly because it's supposed to use even less memory than 2.2 does.
Currently my uptime is just over 5 days (it's a laptop, remember!), and I generally leave several gnome-terminal windows, rhythmbox, Evolution 1.4, Mozilla Firebird, emacs, a DVI viewer and GnomeGV running all the time. With these apps open (plus all the normal GNOME stuff such as the panel and Nautilus) I write, build and test code and work on my thesis. Obviously this runs into swap, but it doesn't make the computer particularly unresponsive.
Remember that Linux typically uses all the available RAM up and uses it for mystical kernel things like disk caching, so just because top says that all the memory is in use it isn't necessarily a bad thing.
Um, it depends how long ago we're talking about. I'm not that old, and when I first set up sendmail the M4 macros weren't available.
The reason I replied to your original comment was that you implied that the work wasn't useful, or wasn't as much of a breakthrough as Adleman claims. Saying that they only solved a single instance isn't relevant: they have a method that works on any 3-SAT problem for which they can construct a long enough DNA chain to represent an assignment, and they have an implementation that actually finds the solution.
Don't forget that the first practical computer algorithm for SAT (Davis and Putnam, A Computing Procedure for Quantification Theory, Journal of the ACM, 1960) didn't even have a computer implementation: they demonstrated its usefulness by working an example out by hand!
You are missing the point: NP complete problems (like 3-SAT, which is what they are solving with this DNA computer) are incredibly difficult for serial computers to solve. Nobody seems to be suggesting that DNA computers should be used for serial problems that we can already solve with conventional computers. However, being able to solve SAT (and hence other NP-hard) problems more efficiently is incredibly useful, because SAT problems exist that we can't (and might never be able to) solve using existing techniques.
The description of the problem they are solving corresponds to a 3-SAT (propositional satisfiability with clauses of length 3) instance. In 1962 Davis, Logemann and Loveland published a paper entitled "A Machine Program for Theorem-Proving", in which they described a computer program which could solve SAT problems of a similar size, extending earlier work by Davis and others published in 1960. (You can read the paper in Communications of the ACM if you have a library that goes back that far.) So it looks like their comparison is correct.
The method they are using for the DNA computer is rather crude compared to that proposed by Davis et al, whose procedure is still in use today for solving SAT problems. We can now solve problems with thousands of variables, and actually do useful things in the process (e.g. verify hardware specifications).
There are debs of an earlier version of the gnome2 libs in unstable already, and they install alongside the gnome1.4 stuff without any problems.
The difficulty is that the gnome2 core apps (panel, control-center, nautilus, etc) are replacements for the gnome1.4 core apps, and so at some point users will have to upgrade to gnome2-core (I assume). In other words, while the libraries can be parallel installed, individual applications can't be (though of course you can still use old gnome1.4 apps alongside new gnome2 apps). Anyway, the upshot is that gnome2-core isn't in unstable yet, but you can get all the libs.
The biggest problem with your specs is that you are very unlikely to be able to coax a week of battery life out of a machine running a "standard" OS such as Linux. Batteries don't actually last very long when running a reasonably fast CPU, and in addition are extremely heavy (so you can't just solve the problem by adding lots of extra batteries).
With my laptop (Toshiba Portege 3480CT), the closest I could get to a really long uptime on batteries is by adding a high capacity battery, which costs quite a bit but would give me six hours. If I could afford one, then in addition to my two standard batteries (at least two hours from each), I would have a total of 10 hours away from the mains. That's still nowhere near a week though!
It's interesting comparing Opera's progress with Mozilla's. By the looks of things (and I must admit that I haven't tried Opera recently) Mozilla is better at rendering standard HTML + CSS than Opera.
Now it looks possible that Mozilla will be released before Opera on Linux.
Why would anyone want to use Opera if Mozilla is available?
> Now I'm *really* confused. I just started
:-). Your local proprietary software developer finds my software, and realises that it would be just right for integrating with their application. So they link it in, as a library (they might even release the source to my code if they're feeling nice, but their code remains proprietary).
> thinking... the GPL doesn't allow linking to
> closed libraries? That kinda weakens it a bit, in
> my mind.
Think about what would happen if the GPL did allow linking to closed software. I write a really cool piece of software, which I release under the GPL because I'm a nice guy
Aaargh!
My free software just became an integral part of their proprietary software, which wasn't what I wanted at all. If I had wanted that to be possible, I would have chosen to use the LGPL (Lesser General Public License), as many other projects such as GTK+ have done.
This is one upgrade that is definitely worth the effort. GNOME is now really nice to use, and stable. I especially like being able to synchronise my Pilot with the GNOME apps just by putting it in the cradle and pressing the HotSync button. The whole thing is very polished.
The new web site is also an amazing effort. The old one has been looking a bit icky for a while, but the new site looks beautiful. Actually, it reminds me of the Apple site a bit - is it the font?
Anyway, congratulations to all the GNOME developers on a job well done.
As you note, the GPL is incompatible with the QPL (though the KDE developers can add an exception to the GPL to allow linking against QT). It isn't a problem with QT 2, which satisfies the DFSG. The problem is that it is not legal for Debian to distributed KDE without a license change.
> Now only if he would update the guidelines for a GNOME compliant window manager to be "panel friendly"
e x.html - it works beautifully with GNOME and the panel.
Try Sawmill at http://www.dcs.warwick.ac.uk/~john/sw/sawmill/ind
I agree that multi-function chips are great for integrated devices like the Palms, but comparing them with PIIIs is pushing it. Putting all the functionality on a single chip does reduce complexity, but it also reduces flexibility. A PIII (or Athlon or PowerPC) can form the basis of a general purpose PC.
Both multi-function chips and more conventional CPUs have their place.
How many people are working on the Royal web site, and the other Government sites?
Is your development done internally, or do you outsource much of the work?
Was Linux difficult to introduce, or were your developers and management amenable to the idea?
> I did a bit of research on Star Wars (the Regan version not the Speilberg version)...
:-).
Star Wars - perhaps you meant George Lucas, rather than Speilberg
> What I want to avoid though is writing a custom
> XML parser, especially if in 2 years, every
> Linux distribution is going to have one. Does
> anyone know which one that is likely to be?
Several Linux distributions already include an XML parser that could (should?) become the standard: libxml, written by Daniel Viellard (he also runs the rpmfind system) from the W3C. It is already in use by the GNOME project.
See http://rufus.w3.org/veillard/XML/xml.html
Actually, they are distributing it. They have the software, and they are giving me a copy. It doesn't matter if I am a beta tester, Corel employee, or anyone else. Once I have a copy of the software (the GLP'd bits, anyway), I have the right to redistribute that software at my discretion.
Just as serious is the fact that they are claiming copyright of that software.
I'm afraid you are incorrect about being forced to use the gtk_main() function. Have a look at gtk_events_pending() and gtk_do_iteration() to see how to dispense with gtk_main().
I'm not sure what your complaint is about "g*" types being defined. It is difficult to conceive of a GUI library that doesn't define new types.
glib has developed over time to include functionality common to several programs. Some of the stuff in glib is the sort of thing you would see in the C++ STL, while other things (like gmodule (used for plugins in the GIMP and Gnumeric, among other things)) provide really useful platform independent tools.
If Caldera was in the position RedHat is (i.e. most popular distribution, big investments), I would be worried. Caldera ships a lot of proprietary software with OpenLinux (bit of a misnomer), like Netware. RedHat (while still selling some proprietary software) has been very committed to releasing the code for just about everything *they* write.
Um, don't you mean the main Australian site? The main server is located in Aussie, not the US.