Using a tool such as (subtle plug) rtprof. It makes pretty call graph visualisations of programs as they're running. It's not very robust and probably doesn't even compile given that I haven't touched it for nearly 4 years, but there you go. Go open source! (And for the record I think making statements about security by comparing the call graphs of two competing products is, well, dumb).
Most total conversions (SUBTLE PLUG: such as http://tremulous.net/) do not rely on the base pk3s a great deal. It's predominantly textures that are the problem, but they're also the easiest to replace.
I wasn't refering to your example specifically, merely disagreeing with your assertion that Gnome is slow because of demands on the CPU. This is not the case. It is slow because it is heavily IO bound.
For instance: if you look (strace) at a typical gnome program when it starts up, it stats zillions of files; many of them more than once. This is why startup is so sloooooow.
You kind of contradict your own point here. CPU cycles or less CPU intensive code is not what is needed, but less IO intensive code. It's all Amdahl's law see, and IO is the biggest f.
So what? It was clearly a loving, successful marriage, what does the age difference matter for?
You or I may not be comfortable having a relationship with such an age difference, but they clearly were and it obviously worked for them -- what's the problem?
I think it should be obvious to any one remotely interested in linux on the desktop that some consolidation is required for things to go further. I think this is probably also obvious to the developers. The trouble is, in the absense of a marketting/direction body telling them what to do (as in a commercial environment), most development is geared towards what it the "best" "technical" solution.
There are disagreements about what the best solutions are. Each solution is conflicting and would require compromise in order to resolve. Now being a stubborn opinionated (software developing) bastard myself, it is quite obvious that such compromise is the number one reason linux is not consolidating.
I don't really see solutions like AutoPackage being particularly helpful. All they do is add another layer to the problem -- a meta-distribution almost. The problem of consolidation needs to be approached from the bottom up and not the top down.
There is another scenario where linux consolidates, and that is where one distro is so superior to the rest that it gains momentum such that the other distros become smaller and smaller until they effectively vanish. This seems unlikely to happen though, since each distro is simultaneously fed by upstream software developers and as such they will all tend to move lockstep.
Having said that, of the distros out there I believe Ubuntu is currently best placed for this.
I've never really understood why MS feel the need to support the running of decade(s) old DOS applications, and yet they're not planning on supporting a new browser on an OS that is one generation old?
I suspect this is probably a question you get asked a lot, but I don't know the answer. Would it be possible to write a replacement OpenGL driver for certain guest operating systems (i'm thinking opengl32.dll), which passes though to the real GL lib on the host operating system? This is basically what wine does.
I realise VMWare isn't only used for "running Windows programs on Linux", but I really think this would be a killer extension.
There was an old slashdot story eons ago about people using DNS tunnels to abuse the free dial up lines used for setting up a dial up ISP account. Covert comms over DNS is nothing new, but oddly it doesn't seem to have ever caught on.
For my final year dissertation I wrote an interactive profiler named rtprof. The idea is you have a remote machine calculating the profile of a process running on another machine in real time, all of which is visualised in three dimensions.
Daviid: Quando es il dejeuner que la nyktos? La Rutha: O no. Aga non es functivo, ma microsoftos destructivos la dejeuner. Daviid: De nada. Mater que pater beefsteak cuisinarti tel para. Lizabet: El parenticos favoritos! Alberto: Scorchio!
Older intel CPUs used a performance metric named iCOMP which was stamped on many CPUs. A bit of googling suggests this is still around. Perhaps this is another case of reinventing an old idea?
Slashdot Mirror
Dear davemc,
Our records show that you're lacking a sense of humour. We suggest you remedy this situation as soon as possible, or our lawyers will be dispatched.
Sincerely, Timbo.
http://flex.sourceforge.net/
;)
Adobe should concentrate on opening sourcing something of worth instead of reinventing the wheel.
Using a tool such as (subtle plug) rtprof. It makes pretty call graph visualisations of programs as they're running. It's not very robust and probably doesn't even compile given that I haven't touched it for nearly 4 years, but there you go. Go open source! (And for the record I think making statements about security by comparing the call graphs of two competing products is, well, dumb).
What has playing Quake got to do with AOL instant messanger?
Oh wait...
If I had any mod points atm, I'd mod this up...
Emacs is the only operating system you need too.
Most total conversions (SUBTLE PLUG: such as http://tremulous.net/) do not rely on the base pk3s a great deal. It's predominantly textures that are the problem, but they're also the easiest to replace.
Um yeah. Tremulous is really good. You should all play it. :paranoid:
I wasn't refering to your example specifically, merely disagreeing with your assertion that Gnome is slow because of demands on the CPU. This is not the case. It is slow because it is heavily IO bound.
Robert Love - Optimizing Gnome
For instance: if you look (strace) at a typical gnome program when it starts up, it stats zillions of files; many of them more than once. This is why startup is so sloooooow.
You kind of contradict your own point here. CPU cycles or less CPU intensive code is not what is needed, but less IO intensive code. It's all Amdahl's law see, and IO is the biggest f.
"...because people didn't really understand buffer overruns and port 80 and I/O issues 10 years ago...
Those damn port 80 and I/O issues. Such a bitch to fix.
So what? It was clearly a loving, successful marriage, what does the age difference matter for?
You or I may not be comfortable having a relationship with such an age difference, but they clearly were and it obviously worked for them -- what's the problem?
I think it should be obvious to any one remotely interested in linux on the desktop that some consolidation is required for things to go further. I think this is probably also obvious to the developers. The trouble is, in the absense of a marketting/direction body telling them what to do (as in a commercial environment), most development is geared towards what it the "best" "technical" solution.
There are disagreements about what the best solutions are. Each solution is conflicting and would require compromise in order to resolve. Now being a stubborn opinionated (software developing) bastard myself, it is quite obvious that such compromise is the number one reason linux is not consolidating.
I don't really see solutions like AutoPackage being particularly helpful. All they do is add another layer to the problem -- a meta-distribution almost. The problem of consolidation needs to be approached from the bottom up and not the top down.
There is another scenario where linux consolidates, and that is where one distro is so superior to the rest that it gains momentum such that the other distros become smaller and smaller until they effectively vanish. This seems unlikely to happen though, since each distro is simultaneously fed by upstream software developers and as such they will all tend to move lockstep.
Having said that, of the distros out there I believe Ubuntu is currently best placed for this.
Pure and simple.
What they say: "allowing Linspire users to play hundreds of popular Windows-format games right out of the box."
What they mean: "about 90 or so games run after spending hours changing config files and trying different version of cedega. 90 is nearly 100 right?"
http://yubnub.org/example/tts?args=i+don't+have+an y+speakers+you+insensitive+clod
What do you mean "next"? They're already here.
Patent 1
Patent 2
Patent 3
I've never really understood why MS feel the need to support the running of decade(s) old DOS applications, and yet they're not planning on supporting a new browser on an OS that is one generation old?
Excuse me, but WTF?
..LaTeX :)
I suspect this is probably a question you get asked a lot, but I don't know the answer. Would it be possible to write a replacement OpenGL driver for certain guest operating systems (i'm thinking opengl32.dll), which passes though to the real GL lib on the host operating system? This is basically what wine does.
I realise VMWare isn't only used for "running Windows programs on Linux", but I really think this would be a killer extension.
There was an old slashdot story eons ago about people using DNS tunnels to abuse the free dial up lines used for setting up a dial up ISP account. Covert comms over DNS is nothing new, but oddly it doesn't seem to have ever caught on.
For my final year dissertation I wrote an interactive profiler named rtprof. The idea is you have a remote machine calculating the profile of a process running on another machine in real time, all of which is visualised in three dimensions.
Daviid: Quando es il dejeuner que la nyktos?
La Rutha: O no. Aga non es functivo, ma microsoftos destructivos la dejeuner.
Daviid: De nada. Mater que pater beefsteak cuisinarti tel para.
Lizabet: El parenticos favoritos!
Alberto: Scorchio!
Older intel CPUs used a performance metric named iCOMP which was stamped on many CPUs. A bit of googling suggests this is still around. Perhaps this is another case of reinventing an old idea?
CV
I'm currently looking for employment in or around Edinburgh, UK as a software developer, preferably in C/C++.
Hey... it was worth a try...