remember the mattel lawsuit (google barbie vs bratz): everything you make (design) during working hours is owned by your employer. So probably also the design (or parts of it) of your new software.
The problem with avoiding threads and using the alternatives (like cooperative multitasking + event driven models), is that it will become increasingly difficult to be responsive as an application grows. trying to handle GUI events every now and then while you are doing a lot of computation will very quickly go wrong when the amount of work you have to do becomes longer and longer. Threads are difficult indeed, and trying to avoid them might look reasonable, but it doesn't always work well. The KDE core apps tried to avoid threading for most of KDE3, but i believe that at least some of them will start using threads now (maybe it also has to do with QT supporting threads).
I don't know if this applies to firefox, as i don't know how firefox works. If firefox 2 doesn't use threads, then i'm really surprised by how responsive it is, when a lot of tabs are open (still very okay for me).
A big thanks to the very helpful people on the #postgres irc channel. I have been there several times asking for help, and always i have gotten an excellent, very in-depth answer, for what i tought were quite difficult questions (performance problems, weirdness with inherited tables, or just how to build a query to give you what you want in an efficient way). Thank you !
okay, you have a point (the "without central server" thing was incorrect). But i would still argue tinyp2p is not a real p2p app, as it doesn't have any functionality that ftp doesn't have. napster and edonkey had functionality to build a large (= more than 2 hosts) network. tinyp2p doesn't.
is that tinyp2p is not actually a p2p app, or only if you see p2p very broadly.
just offering/transferring files is not really enough to satisfy the "p2p" demand, because then http and ftp would classify as "p2p" too. a real p2p app would make a distributed peer-to-peer network without central server possible.
If you invented something completely new and revolutionary, such as Bell's telephone, or the Wright brothers' plane, would you want to earn money from it for some time- or let anyone and everyone produce it and make the money (instead of you). Patents provide an incentive to discover and invent new things, and ensure your time, money and efforts don't go to waste.
(for software patents)
i have read on several places that no statistical evidence has ever been found supporting the "patents stimulate innovation" claim, and for software patents, there was even some statistical evidence proving the contrary. (http://swpat.ffii.org/, eurolinux,...).
offcourse, my sources are not objective, but - while trying to find me an opinion - i spent some time searching the web, and i could find tons of sites with good arguments against software patents, and i could not find any good sites defending software patents (all of them use a few very abstract arguments, without evidence). did i miss something ?
even for such a limited system, the claim that it was written in 3 hours surprised me a lot. I can imagine you can come up with the basic idea in 3 hours, but to write, setup (serial) and debug such a thing in 3 hours would require a level of talent i have never seen before... if its true, wow
why not turn this discussion in some kde/gnome speedup tips ?
here are a few: - on KDE, a different style really matters. 'matters' not as in 'use -fomit-frame-stuff', but as in 'it really matters'. stop using keramik/plastik and use light V3, or QT windows. you will notice it very quickly, both in speed and in memory usage (very significant)
- watch out with konq's process caching. keep an eye on the memory usage of cached processes, and if you see they are too leaky, disable konq proces caching. konq starts up quickly without caching anyway
- tired of people saying 'its the nvidia drivers' for every performance problem ? i have to confirm this. I'm not talking about FPS in games or so, just basic GUI performance. for example, try the RenderAccel setting (also try disabling it, there are some problems that seem to occur only in some situations)
offcourse, all of this is not an excuse, but at least it can offer some relief. i am no fedora user, but i wonder if some simple research on fedora could point out where the (perceived and real) slowness is coming from... i remember seeing success stories like "colorful KDE3 performance on low-end hardware", and i run KDE3 at home on a 233mhz 128mb ram at home (debian). But i also saw a (very) slow mandrake installation.. it must be possible to find out the cause.
what tools could be used to investigate ? like xrestop, strace, profilers (but i have no idea how to profile a whole desktop and not a single application)
ow, and some problems i'd like to know more about:
- openoffice painting slowness. i can type quicker than openoffice can paint in some situations, in other situations its very quick. it doesn't even seem related to document size
- gtk double buffering slowness... it started since gtk2, i don't know if it improved much (i don't notice it anymore on my new-faster pc, but i can see it in other setups)
- some KDE apps (like kopete and kontact) have slow dropdown menu's, others have quick ones. very strange, i tought dropdown menus are just basic QT stuff
- x terminals often perform badly. With multi-console you would be able to do 3D graphics, full multimedia,...
- think of offices. One pc with 4 consoles, saving maintenance and hardware costs. you can't ask a company to "get some old PC's or unsupported obsolete X-terminals at ebay"
- dualhead cards become more and more common, so the hardware costs of 'multi-console' are low and going down.
i first was fairly sceptical of dbus too... (why replace something that works so well). But now, i realise it is the only way to solve some pretty fundamental problems that have seen lots of solve-attempts but no real solution.
All those problems are related with making things work together that are not designed to work together. (hardware-configurators, application wrappers that use undocumented and non-robust assumptions) Those mostly work, but are one of the main reasons for the 'unpolished' or 'unfinished' feeling you get when using linux (and thats only one symptom). Clearly defined interfaces with a broad scope (not only kde) would solve a lot here, so i'm all for dbus now, even if it means that people will have to go to the trouble of immature software again.
... apart from the fact that the mars express (or the fregat launcher, or...) probably cannot carry 11 beagles to mars... you would have other costs too
beagle 2 is offcourse less-featured than the mars rovers, but nasa, esa, russia work together to avoid 'feature duplications' or to give experiments from failed mars missions a new home. We see experiments from mars 96 now reappearing in other spacecraft (not sure if its the mars express). Each mission sent to another planet has a worthwhile (ambitious or less ambitious) goal, missions that make no sense apart from 'i want to do this too' don't exist (atleast not between esa/russia/nasa)
beagle 2 was small, had only limited number of experiments and limited powersource, but it had equipment that was never transported to mars before - see nasa site, they helped), and that would be useful, even if the rovers would provide much more information
As an european, i want to congratulate america for its achievements. The beagle was not comparable by far to the polar rover (in all areas). Beagle's only merit was to be cheaper. Well, seems we've had bad luck and you had good luck, and we could even say you deserved the good luck and we deserved the bad luck.
So there is no need to party you are number 1 now... we believe you. and luckily nasa officials also don't do that : nasa assisted the projects of its little brothers (esa could even use nasa equipment when we were in trouble, and nasa helped us out a bit in creating the mars express as you can see on nasa's site)
i was considering to buy a soekris, but when i added up all costs (shipping,...) it turned out to be not worth the money. Soekris is silent okay, and powersaving okay, but the slow CPU limits the use to routing/firewalling/VPN/... and you can buy cheaper equipment for that.
another reason would be: no matter how small the chance that beagle actually survived (i think they are realising it is pretty small too), it is still worth it to try, even with that much manpower, because there is a lot to win. So they are concentrating on the 'beagle is not lost' scenario now..
i don't agree totally for deploying zope/cmf/plone with only existing components. Installing additional CMF components is very easy if you know the QuickInstaller tool, which is not in the standard plone distribution (maybe it is in the new 2.0 one, don't know)
developing for zope/cmf is something different. first of all i don't like the security model at all (it is a pain to work with, and it makes using existing python modules in restricted mode impossible, but i heard this is going to be fixed in zope 3). secondly zope/cmf is a fairly complex design to understand, and the sometimes non-evident method names (parent of an object is object.aq_parent) don't help. There are also a lot of unwritten rules (but i'm not really experienced yet, so i could be wrong here), and a lot of cool functionality is only available as a 3rd party module (like filesystem-based ZODB, and Epoz WYSIWYG editor that works also in mozilla)
but now that i discovered archetypes and its excellent tutorial, it is a lot easier to develop for zope/cmf/plone.
i'd say zope/cmf/plone has a lot of potential, but it isn't ready yet. i'm looking forward to zope3
except that you don't run it on linux but on some layer directly above the hardware (user mode linux is linux on linux). that explains the better performance too
same here. i guess telnet is atleast as safe or even safer than ssh in reality... who ever got owned because of a sniffed plaintext password auth ? and who got owned because a remote root hole in sshd ?
is it just me, or is there something odd with the font rendering on all the scribus screenshots i've seen ? maybe its because of scaling and aliasing, i don't really know, but it looks strange...
Slashdot Mirror
remember the mattel lawsuit (google barbie vs bratz): everything you make (design) during working hours is owned by your employer. So probably also the design (or parts of it) of your new software.
The problem with avoiding threads and using the alternatives (like cooperative multitasking + event driven models), is that it will become increasingly difficult to be responsive as an application grows. trying to handle GUI events every now and then while you are doing a lot of computation will very quickly go wrong when the amount of work you have to do becomes longer and longer. Threads are difficult indeed, and trying to avoid them might look reasonable, but it doesn't always work well. The KDE core apps tried to avoid threading for most of KDE3, but i believe that at least some of them will start using threads now (maybe it also has to do with QT supporting threads).
I don't know if this applies to firefox, as i don't know how firefox works. If firefox 2 doesn't use threads, then i'm really surprised by how responsive it is, when a lot of tabs are open (still very okay for me).
A big thanks to the very helpful people on the #postgres irc channel. I have been there several times asking for help, and always i have gotten an excellent, very in-depth answer, for what i tought were quite difficult questions (performance problems, weirdness with inherited tables, or just how to build a query to give you what you want in an efficient way). Thank you !
this is actually a great move. by banning the word "freedom", a lot of chinese people will realize what situation they are in.
okay, you have a point (the "without central server" thing was incorrect). But i would still argue tinyp2p is not a real p2p app, as it doesn't have any functionality that ftp doesn't have. napster and edonkey had functionality to build a large (= more than 2 hosts) network. tinyp2p doesn't.
is that tinyp2p is not actually a p2p app, or only if you see p2p very broadly.
just offering/transferring files is not really enough to satisfy the "p2p" demand, because then http and ftp would classify as "p2p" too. a real p2p app would make a distributed peer-to-peer network without central server possible.
If you invented something completely new and revolutionary, such as Bell's telephone, or the Wright brothers' plane, would you want to earn money from it for some time- or let anyone and everyone produce it and make the money (instead of you). Patents provide an incentive to discover and invent new things, and ensure your time, money and efforts don't go to waste.
...).
offcourse, my sources are not objective, but - while trying to find me an opinion - i spent some time searching the web, and i could find tons of sites with good arguments against software patents, and i could not find any good sites defending software patents (all of them use a few very abstract arguments, without evidence). did i miss something ?
(for software patents) i have read on several places that no statistical evidence has ever been found supporting the "patents stimulate innovation" claim, and for software patents, there was even some statistical evidence proving the contrary. (http://swpat.ffii.org/, eurolinux,
even for such a limited system, the claim that it was written in 3 hours surprised me a lot. I can imagine you can come up with the basic idea in 3 hours, but to write, setup (serial) and debug such a thing in 3 hours would require a level of talent i have never seen before ... if its true, wow
why not turn this discussion in some kde/gnome speedup tips ?
here are a few:
- on KDE, a different style really matters. 'matters' not as in 'use -fomit-frame-stuff', but as in 'it really matters'. stop using keramik/plastik and use light V3, or QT windows. you will notice it very quickly, both in speed and in memory usage (very significant)
- watch out with konq's process caching. keep an eye on the memory usage of cached processes, and if you see they are too leaky, disable konq proces caching. konq starts up quickly without caching anyway
- tired of people saying 'its the nvidia drivers' for every performance problem ? i have to confirm this. I'm not talking about FPS in games or so, just basic GUI performance. for example, try the RenderAccel setting (also try disabling it, there are some problems that seem to occur only in some situations)
offcourse, all of this is not an excuse, but at least it can offer some relief. i am no fedora user, but i wonder if some simple research on fedora could point out where the (perceived and real) slowness is coming from... i remember seeing success stories like "colorful KDE3 performance on low-end hardware", and i run KDE3 at home on a 233mhz 128mb ram at home (debian). But i also saw a (very) slow mandrake installation.. it must be possible to find out the cause.
what tools could be used to investigate ? like xrestop, strace, profilers (but i have no idea how to profile a whole desktop and not a single application)
ow, and some problems i'd like to know more about:
- openoffice painting slowness. i can type quicker than openoffice can paint in some situations, in other situations its very quick. it doesn't even seem related to document size
- gtk double buffering slowness... it started since gtk2, i don't know if it improved much (i don't notice it anymore on my new-faster pc, but i can see it in other setups)
- some KDE apps (like kopete and kontact) have slow dropdown menu's, others have quick ones. very strange, i tought dropdown menus are just basic QT stuff
there IS a method for moving apps from server to server, its called xmove...
:)
not that i got it working
- x terminals often perform badly. With multi-console you would be able to do 3D graphics, full multimedia, ...
- think of offices. One pc with 4 consoles, saving maintenance and hardware costs. you can't ask a company to "get some old PC's or unsupported obsolete X-terminals at ebay"
- dualhead cards become more and more common, so the hardware costs of 'multi-console' are low and going down.
i first was fairly sceptical of dbus too ... (why replace something that works so well). But now, i realise it is the only way to solve some pretty fundamental problems that have seen lots of solve-attempts but no real solution.
All those problems are related with making things work together that are not designed to work together. (hardware-configurators, application wrappers that use undocumented and non-robust assumptions) Those mostly work, but are one of the main reasons for the 'unpolished' or 'unfinished' feeling you get when using linux (and thats only one symptom). Clearly defined interfaces with a broad scope (not only kde) would solve a lot here, so i'm all for dbus now, even if it means that people will have to go to the trouble of immature software again.
... apart from the fact that the mars express (or the fregat launcher, or ...) probably cannot carry 11 beagles to mars ... you would have other costs too
beagle 2 is offcourse less-featured than the mars rovers, but nasa, esa, russia work together to avoid 'feature duplications' or to give experiments from failed mars missions a new home. We see experiments from mars 96 now reappearing in other spacecraft (not sure if its the mars express). Each mission sent to another planet has a worthwhile (ambitious or less ambitious) goal, missions that make no sense apart from 'i want to do this too' don't exist (atleast not between esa/russia/nasa)
beagle 2 was small, had only limited number of experiments and limited powersource, but it had equipment that was never transported to mars before - see nasa site, they helped), and that would be useful, even if the rovers would provide much more information
As an european, i want to congratulate america for its achievements. The beagle was not comparable by far to the polar rover (in all areas). Beagle's only merit was to be cheaper. Well, seems we've had bad luck and you had good luck, and we could even say you deserved the good luck and we deserved the bad luck.
So there is no need to party you are number 1 now... we believe you. and luckily nasa officials also don't do that : nasa assisted the projects of its little brothers (esa could even use nasa equipment when we were in trouble, and nasa helped us out a bit in creating the mars express as you can see on nasa's site)
the crater was there before landing: http://www.beagle2.com/resources/down-crater3.htm
i was considering to buy a soekris, but when i added up all costs (shipping, ...) it turned out to be not worth the money. Soekris is silent okay, and powersaving okay, but the slow CPU limits the use to routing/firewalling/VPN/... and you can buy cheaper equipment for that.
another reason would be: no matter how small the chance that beagle actually survived (i think they are realising it is pretty small too), it is still worth it to try, even with that much manpower, because there is a lot to win. So they are concentrating on the 'beagle is not lost' scenario now..
i think they mean the same layout as ./ comments when you set view to 'nested' (not 'threaded')
i don't agree totally for deploying zope/cmf/plone with only existing components. Installing additional CMF components is very easy if you know the QuickInstaller tool, which is not in the standard plone distribution (maybe it is in the new 2.0 one, don't know)
developing for zope/cmf is something different. first of all i don't like the security model at all (it is a pain to work with, and it makes using existing python modules in restricted mode impossible, but i heard this is going to be fixed in zope 3).
secondly zope/cmf is a fairly complex design to understand, and the sometimes non-evident method names (parent of an object is object.aq_parent) don't help. There are also a lot of unwritten rules (but i'm not really experienced yet, so i could be wrong here), and a lot of cool functionality is only available as a 3rd party module (like filesystem-based ZODB, and Epoz WYSIWYG editor that works also in mozilla)
but now that i discovered archetypes and its excellent tutorial, it is a lot easier to develop for zope/cmf/plone.
i'd say zope/cmf/plone has a lot of potential, but it isn't ready yet. i'm looking forward to zope3
does that mean 16 % has ?? that looks like a lot already ...
except that you don't run it on linux but on some layer directly above the hardware (user mode linux is linux on linux). that explains the better performance too
same here. i guess telnet is atleast as safe or even safer than ssh in reality ... who ever got owned because of a sniffed plaintext password auth ? and who got owned because a remote root hole in sshd ?
is it just me, or is there something odd with the font rendering on all the scribus screenshots i've seen ? maybe its because of scaling and aliasing, i don't really know, but it looks strange ...
"You can use the mouse to manipulate windows either by click/dragging the 1 pixel border"
hm, that must be fun on a 1600x1200 screen (okay okay, you can use alt too)