- You didn't explain how Nautilus is vastly inferior to Finder, but you still affirm it
The scanning & displaying speed. I thought this was self-explaining in my post. well, I was mistaken.
Of course Windows Explorer will display the directory faster, which does not mean it has scanned it faster or that it scanned it correctly.
It is irrelevant if it is the scanning that is so slow, or the sorting, the filetype enumeration etc. Fact is that from opening to the final display the thing takes too much time.
As for the extension stuff: yes, that is an inherent flaw in Explorer. But its not better with most Unix file managers, actually. Most use "file" for finding out the filetype. Without it, they have to resort to the extensions. OK, there are inodes, but how many programs actually use them? Also, the filetype is pointless when I CANNOT BROWSE because the browser seems to be in a catatonic state.
What is the purpose of your fast displaying of thousands of files if you can't even be sure of their type, let alone see their content instantly ? You will take more time finding the right one than me with my Nautilus in the end !!! Unlike you, I don't open directories for the sake of opening them, but to get work done.
You call these arguments? First: I am USED to browsing with the Explorer (I have a dual-boot system). I can find the files pretty quickly. One of the first things I disable in Nautilus is the preview, since it takes too much time, eats CPU thus having the laptop CPU running at 100%, and is usually not necessary (useful for browsing through images though). For the record: I disable the preview in Explorer too. And no, I dont open directories for the sake of opening them, I want to do my work thank you very much. But fact is that the files are on my file server, and some directories have thounsands of files - no, more subdirectories don't help here, I already subdivided. I want to get at my files QUICKLY, thats why I usually use rox, gentoo (the filer), xfe, mc, or the plain console instead of Nautilus (Konqueror only when using KDE).
I would have thought that only the configuration GUI design was at fault, but you know better of course... You're pathetic really, you talk like Gnome is a huge block like Windows while every self-respecting troll knows that Gnome is made of lots of parts, the configuration being one. And yet you say the whole design is wrong if a config file has been edited ? I see, you prefer having nothing at all like in other OSes ?
I am talking about the OS as a whole, not only gnome, AS I SAID IN MY POST. Now who's pathetic? The whole user-friendly distro design DOES fail if there is one case of mandatory config file editing, since the distro should prevent this (assuming we are talking about the distros for users, of course). Editing config files is NOT user friendly. You can write as many comments as you want, it is simply too scary for most people.
Are you confused ? We call them "obscure manpages" the "Web" or "distribution vendor support". You did pay for the distro you're complaining about right ? You know they offer free phone support when you buy their distro right ?
Now here we are at a crucial point. Linux problems can be extremely frustrating. It should NOT require technical support for most hardware. I admit, exotic hardware is a problem. But there are lots of brain-dead errors, even in modern distros. For example, the famous USB scanner error of not being able to scan as a non-root user. One has to manually edit the fstab to have the usbfs be available for non-root users. This is the job of the distro developers, and NOT the users job. Or the really annoying DPI issue mentioned earlier here.
By the same someone than before or another ? You seem to base your facts on random writing by random people : are you a stupid fool or what ?
I am talking with you, so yeah I must be one. Also, references can be found anywhere in the postings her
Re:KDE Zealots: A vocal minority of a dying DE
on
GNOME 2.12 Released
·
· Score: 1
Ubuntu and Fedora are primarily Gnome based. Mandriva and MEPIS are primarily KDE based.
Well, as for Ubuntu, you are wrong - Kubuntu is the KDE-based version. Also, you fail to include the people that switch from GNOME to KDE once the distro is installed (I did - KDE has a much better filemanager and integration than GNOME) and the ones who use a distro that does not install a DE by default (Debian, Gentoo...). The entire Vienna University of Technology uses KDE and rejected GNOME because of latency and integration issues. So your numbers are way off. Also, AFAIK in business solutions usually KDE is preferred because it respects the X DPI settings, looks & feels more "solid", and has a much better responsiveness.
Someone wrote that GNOME is an OSX killer before. Well yeah, maybe in 2020.
You see, Nautilus alone is vastly inferior to Finder (the new one). Of all gnome components, nautilus is the one that sucks most. Try browsing a large directory with thousands of files with nautilus, konqueror and windows explorer. The latter ones scan the directory MUCH faster. Nautilus takes about 1-2 MINUTES - unacceptable.
The main point of new gnome bugfix releases should be to improve nautilus. Speed it up, say, to about 100 times its current "speed".
Also, it is evident that once an ORDINARY USER (no hacker, no power user, no admin, no dev) has to edit a config file, the whole design has failed. Of course, this is not gnomes problem alone, but to a great deal the underlying OS; however, we are talking about an OSX killer, right? If you aren't lucky, and the hardware doesn't fit 1:1 with the distro, you have to dig through obscure manpages.
I also read that anyone that is not able to edit configfiles is an idiot and everyone MUST learn how to do this. See, I doubt a biologist that made some photos about a weird plant and want to download them from his cam to his PC is interested in editing config files just to get this to work - he JUST WANTS TO DO HIS JOB and is certainly not interested in learning sh and all about the Unix architecture. Config files per se are ok, as long as editing them is optional. Unfortunately, it still is mandatory sometimes (fortunately, the camera issue is resolved automatically by modern distros - but still, simple samba shares have to be edited by hand for example).
The ion WM is a wonderful idea. It may alienate at first, because ion looks like a hacker WM. Ironically, once I tried it, I never had to edit the configuration file - something that is usually mandatory.
This shows some points:
1. ion window tiling mode makes perfect sense. However, it lacks proper dialog window handling.
2. One of the - if not THE - main weakness of all Linux distros is the fact that sooner or later everyone has to dig through config files. So what, Power Users have to work a bit more in every OS! True, but with a Linux distro, not only they have to. Even things as simple as to get the wireless card to work involves some config hacking. Also, most distros have a horrible bug with scanners which doesnt allow access to the scanner unless the user has root rights. The solution: go to/etc/fstab, and write a usbfs mount with an umask that enables usage by anyone. This is NOT user-friendly.
Thus, there is nothing wrong with config files, as long as tweaking them is OPTIONAL and not mandatory.
3. Many advances can be done if the underlying filesystem is a better database. Directories become obsolete, search is much easier, and as a whole, the system becomes much easier to use. For example, applications have a metadata "Application". Now there can be a menu "Applications" showing all entries that are apps. This is a very active R&D field, and probably the next big thing.
4. Elimination of the RAM/external memory distincition. This is mainly a matter of time. Once persistent RAMs are fast enough to replace normal RAM, the entire software structure changes. "Loading" files becomes obsolete, since it would equal copying a file. As a result, booting reduces to device initialization and program execution - NO loading of stuff into memory needed anymore. This has some serious implications to the UI. Together with step 3, navigation through the files becomes very easy.
A console has an unmatched flexibility, but a horrible learning curve, and it is a very inconvenient tool for several tasks. Drawing with the console? 3d-Modeling with the console? Web browsing with the console?
Also, a file manager like Midnight Commander is sometimes preferable over a copy command by using the console, especially when copying, for example, 5 files that cannot be filtered out by simple regexps and/or have awkward names that make it very likely that you misspell them (ok, theres tab-completion, but some shells have problems with this when the filename contains invalid characters).
Most parts in a game cannot be parallelized well. Only crude splitting is possible, like network, graphics, AI, sound, physics each having its own thread.
Sound, physics and network are loaded in their own threads already - but for low latency, and not for high speed. It is vital for the network code to be independent of the rest (like the graphics card blocking everything - ping requests cannot be answered, and the connection drops). Same for sound: unlike graphics, sound cannot "stutter", because it is much more disturbing, thus the whole sound stream must continue without interrumption. Threads are ideal for this. Physics engines are loaded in their own threads sometimes to be able to deal better with varying step sizes.
Further threading? I can only imagine of one thread for each network connection, one thread for each AI, and one or several threads for loading levels in the background. But how can I speed up RENDERING with threads? Sending a visitor through a scenegraph isnt very thread-friendly. The different steps (visibility determination, reordering for least state switches to prevent pipeline flushes) cannot be parallelized, since they depend on each other. So. Can anyone explain me where one could further parallelize?
Yeah, it IS getting off-track, so I'll make it short as well:
Several render paths bloat up the OS? Do you really think that another renderpath would be responsible for 200+ MB additional size? If cleverly designed, and with modularization in mind, one can create those renderpaths independently of each other. Talk about plugins. Also, you DO NOT HAVE TO USE IT if you don't want to!
The 40 meg OS precedessors didn't behave like virtual machines - but thats exactly what they should do. Agreed, todays OS are oversized, but this is not the fault of a goddamn renderpath!
Actually, no, the heavy part isn't done by the CPU if the driver manufacturers are smart. T&L with the CPU? Complex fragment programs by the CPU? Forget it. AGP transfers cost a lot, the bus gets saturated easily, especially in the card->sysmem transfer. Also, things like the fragment program are way too complex to be done with the CPU. While it is true that OpenGL may fall back to emulated mode where the CPU does all the stuff, today's ICDs are written quite well, and usually don't behave like this. And again: such a renderpath would *****NOT***** be mandatory.
About the 1.5+ features: they are a driver issue ONLY. VBOs are supported by every card capable of T&L, PBOs are supported by just about every card, FBOs by every one who supports render targets. Due to their novelty, the drivers aren't adapted to these yet (VBOs are supported by almost every card, PBOs - less cards, FBOs - even less cards, since its brand new).
You are acting as if "the new Linux supporty only superduper OpenGL-supporting ultra cards". Again, this GL drawing would be an OPTION. You cannot forbid people to code an OpenGL renderpath for X11. They want it, and they want to create a new option for X, and it WILL exist, no matter if you like it or not. You know, not all people like super-spartan evilwm UIs, and I actually like some eye candy thank you very much. I WANT the Linux desktop to have the features OSX has. It is quite irritating that I have to defend myself every time because some l33t unix hackers see it as blasphemy that someone does not stick to yesterday's interfaces. Man, I'm glad that X11 managed to get truecolor video modes. Must have been a fierce battle.
If you aren't using Translate, your pixel/poly ops will not align correctly with point and line ops (see appendix H of your red book) - this can be seen in certain Accolate products:P
You don't need Translate for that. Just add 0.5 to the x/y-coordinates (assuming that you set up an orthogonal matrix with 1.0 = 1 pixel).
Aah, so the GPU is now responsible for system heap allocation. Glad to know a non-local processor is handling memory allocation. This still involves considerable CPU intervention, especially with the allocation and management of these 1.5-only objects. When you're updating verticies, what do you think is happening? Some magical GPU prediction of your next update? This all still has to be processed by the OpenGL pipeline, which is deep and complex and interlaced with both CPU and GPU interactions (Read the Apple Developer Guide).
Well, what is happening? The card processes the data I gave it last time, while I am filling the buffer with new data. I'm not entirely sure if this behaviour is fully implemented in dynamic VBOs, it IS implemented in dynamic D3D VBs with the "discard" flag, however. Besides, anyone how had to do stuff like complex particle systems or extensive 2D output using 3D had to address this issue.
Also, consider this: While your OS is bloating up the video memory, what's happening to your 3D applications? They don't mind that suddenly you have half the texture memory, or that something is consuming GPU time?
Bloating up? Oh come on. How much space is that geometry gonna take? You don't have to create a PBO for each window, you can reuse one, or create a couple of them and reuse them, but for EACH window a PBO/texture is a total waste. Besides, you are not going to use mipmaps, so another space-wasting thing is removed.
So that leaves us with geometry, which almost NEVER fills up half of the GPU RAM (except when dealing with models with about 12 million triangles). Taking up half of the mem is ridiculous. Does your card have only 512 KB RAM?
As for Quake 4: you do *not* have to repaint the GUI all the time; just when its needed. So Quake 4 won't get into trouble unless the entire GUI is updated all the time.
2D blit setup is less than trivial unless there's overlapping regions, and then it's just _trivial_. Integer conversions are also less than trivial, bit ops are sub-cycle for a processor, and sub-sub-cycle for a proper blitter. Floating-to-integer conversions are much less trivial, as floats are more complex and totally incompatible with integers, and require serialized operations (you cannot shift the mantissa until you've extracted and subtracted the exponent down to it's real level, whereas you can extract all four color components and recombine them in an orderless manner (r|g|b is equal to b|g|r which is equal to r|b|g which is..) ) which will not take advantage of modern pipelined _anything_.
This is all totally irrelevant since you usually use integers for textures (unless you use HDR floating point textures). And the fillrate of today's cards is enormous. Basic setup for a 2D-OpenGL-Blit is also absolutely trivial.
Quoting from Apple, "In OpenGL, there are several obvious and other not-so-obvious ways to cause either the CPU or GPU to stall on the other."... I'm complicating it because it is complicated, and complicated = evil in computing. See above regarding "Fast".
Absolutely. But this does not rule out fast rendering. Not at all. Also, if you follow some rather logical rules, you won't end with a crappy performance. Like, using VBOs for geometry, since they are very well optimized, both for static and dynamic geometry (on the other hand, do NOT use glVertex3f unless its not possible to avoid it).
This ATI Charger 512 does not support ANY of that (nor blitting for that matter), and this Rage II here only has the basic rasterization. I don't really know the specs for this S3 Trio64, but I doub
I dunno about that, OpenGL is rather CPU bound. Much of the OpenGL pipeline is still done by the processor, and the primitives for OpenGL are often optimized for fully 3D rendering, which is more than a little unoptimized for 2D blitting. glTranslate3f ?
A 2D-specific blitter is a simple matter of setting up a few registers and letting it happen. A 3D operation in OpenGL has to be converted to native formats, be processed through the fragment pipeline, and then multiplied through several matrix operations before anything happens. While a modern T&L card does much of the more costly things involved in this, there's still all the necessary conversion and setup which is done by the processor.
You should not use glTranslate3f at all with 2D. Instead, use dynamic vertex buffer objects. Similarly, use pixel buffer objects for the textures (the window contents). And no, nowadays almost nothing is done by the CPU. Just commands are sent, and in this case, vertex data is transmitted. But transfer is mandatory anyway. Ever seen a GL GUI? Those things are *FAST*.
With a 2D blitter, you have to perform conversions too (32->16 bit for instance). The CPU has to do setup for a 2D blitter, too.
Some of these OpenGL operations may require serialization, which might even involve a hidden busy loop, depending on how defective the operating system/drivers is/are.
No, you are complicating it. As I said, GL GUIs are real and blazing fast. There are tons of GL GUIs for SDL, and ClanLib renders *everything* with GL (yes, the 2D stuff too).
While much of this may be relatively trivial on a modern, ghz-scale system, anything that is taking away from my BOINC credits is teh devil, I say! (Plus one day, you might end up stuck on a lesser machine, waiting for the parts store to open...)
Yes, the lesser machine is a problem. However, 3D support is not. Today, EVERY graphics chip set supports basic 3D rasterization and T&L. In case where there is no support available, simply fall back to traditional methods.
I have been using X.org for almost a year, and it works rock solid. It is MUCH faster than Xfree, and Debian still starts fairly quickly (X.org didn't lengthen the startup time at all).
As for the special effects: wrong, wrong, wrong. OSX shows how these effects can be useful. Also, the transition to a GL desktop will most likely be implemented in a new version of X.org which merges with Packard's work. A GL desktop actually helps the CPU by taking away the task of drawing stuff from it and having the GPU do it, which is the logical thing to do.
But I know, anything else than crude blitting is l4m3, hard core spartan X11 is l33t. Yeah....
1. signals & slots. These *must* be introduced. Event handling is a breeze with them.
2. make it mandatory for allocations to be deallocated in the heap they were allocated, that is, for example if you allocate memory with new or malloc() in a DLL, and you deallocate it with delete or free(), then the deallocation must be done in the DLL. This could be done with some tables storing the heap for each allocation. This is *very* important if you work with several DLLs in your project, since if you deallocate something that was allocated in a different module, the system crashes because you try to deallocate in the wrong heap. Especially STL containers cause a lot of trouble with DLLs. Well, this can be solved by overloading the new & delete operators; also, choosing "multithreaded DLL" as CRT in VisualC is a solution, since then all "multithreded DLL"-Modules share the same heap. Nevertheless, this is something that should be dealt with in the language.
I'm Austrian, and want to clarify some stuff I keep hearing about Austria by tourists:
* no, we are not the country with the kangaroos * no, we don't have a Nazi government (I keep hearing that from Americans all the time) * our Wiener Schnitzel is really tasty, yeah * our kids don't go to school by skiing (well, most of them don't) * we don't eat much sauerkraut. That's what Germans do. * never confuse us with Germans. We really don't like that. Its like confusing americans with canadians. They eat us alive if we do this. * We don't wear Lederhosen all the time.
how can he get the rights for a word that is in PUBLIC DOMAIN? Could anyone kill this guy please?
You see? Patent trolls, legal trolls, almost all of them are small: either one person, or a small company. We keep whining about the evil megacorps squashing everyone with patents while the real danger comes from these small entities.
This is the funny thing about flying cars: they have been technologically feasible for a long time - the real problem is the control. You need to be a pilot to fly/drive these. A driving license is something everyone can get, a piloting license is not.
As for the moon base, it would be great for digging for He-3. Besides, the surface of the moon would be very well suited for a vast array of antenna dishes. Although I think that advanced aliens rather use neutrinos for communication.... I read something about sapphire crystals being used as sender/receiver unit for this a while ago.
No. You can take a controller chip and flash a new code on it. Patents do not protect against this. If the chip is encrypted and you have to crack the encryption, then you can be sued.
You would be in trouble if you reverse-engineer the code and use the mechanisms of it in your stuff.
Your points are valid, but the issued software patents DID come to court already. Again, ask EADS.
I'm aware that most companies pushing for the directive are the big ones. But the really DANGEROUS ones are small. Is Acacia big? No. Big companies do patent trivialities, but they usually don't use them unless they get attacked. Small patent holders like Acacia however destroy EVERYTHING and are even proud of it.
The thing with GSM is: while it is true that there are patents blocking its adoption, GSM is far from being trivial. Same with MPEG4 and H264: there are many patented techniques involved in these standards, but the patents involved are often made to prevent other from adopting them on their own. MPEG-4 patents aren't trivial, either. Best thing would be to have these patents issued as "no-cost-patents" for the public, but the companies involved in the creation of MPEG4 do want something for the money they invested. So you are mixing two kinds of problems: trivial patents (which NOBODY wants, not even the big companies - they get some only to be able to defend themselves from trivial-patent attacks) and non-trivial, blocking patents like the GSM issue.
Now mplayer, VLC and xine are in trouble. They implement patented stuff with no licenses for it. (Except H264 - you don't need any licenses for creating an opensource codec. People using these codecs for commercial playback need one, though.) Fortunately, GStreamer isn't in trouble, because of its plugin-based system.
What this directive cannot prevent are GSM-patents. What it SHOULD prevent, however, are the trivial ones, not only because the council directive isn't effective enough, but also because the CURRENT legislation isn't effective enough. No company wants trivial patents except scavengers like Acacia and Forgent (could anyone shoot these guys please?). The major IT groups like GI (Gesellschaft Informatik) now are pushing the planned amendments of the parliament. Lets hope that it pays off.
The EPO chose to ignore it because it is useless. The lawyer just has to circumvent the definiton "software patent". That is what many US patents do too.
As for the directive in local countries: this is a directive, not a law. The countries have to implement a law based upon that directive. Things like the definition of the required "technical nature" of the invention can be implemented in any way possible. This is a double-edged sword: Europe will still be a mess for patentability - each country will have variations that need to be adressed, which makes patenting quite annoying. The council version is not detailed enough to tackle down important issues - these will be implemented in different ways. This helps against patent trolls, but makes it harder for people with stuff worthy of patenting really hard to do so (useful patenting: the car controller I mentioned before, and extremely complicated algorithms for speeding up holographic projections in a prototype holographic screen; Slashdot mentioned this in the past, a year ago or such).
Several large groups formerly pushing hard FOR swpats are now AGAINST them. Which is quite late.
The majority in the EU parliament wants modifications to the directive, which would bind sw-pats to controlled effects on natural forces. This excludes things like "patent on data-streaming" pretty well. You keep mentioning large companies pushing for software patents: many of these companies are car manufacturers who want to patent their controller software for their cars. This IS reasonable, since it costs a hell of a lot of money to develop this software, and copyright can't do a thing to prevent other from stealing the mechanisms. They don't want to be able to patent all software - just the one they need. They are not patent trolls like Acacia or Forgent.
I hope the directive gets adopted. Because the real question is not whether we get sw-patents or not; the question is: can the current situation be remedied by this? Contrary to what many people say, it IS possible to patent software in the EU right now. Just ask EADS, they patented mapping software, and already filed lawsuits about it. The software exclusion clause in the current patent law is useless, because any skilled lawyer can bypass it. So, if the Council version gets adopted, it won't change much - which is bad. The parliament can help us to adopt a better way.
If I built a laptop completely encased in fans, and I mounted them the wrong way so that the laptop starts to fly (battery power), do I get sued the FAA for distracting the pilots with a flying laptop?
Slashdot Mirror
- You didn't explain how Nautilus is vastly inferior to Finder, but you still affirm it
... You're pathetic really, you talk like Gnome is a huge block like Windows while every self-respecting troll knows that Gnome is made of lots of parts, the configuration being one. And yet you say the whole design is wrong if a config file has been edited ? I see, you prefer having nothing at all like in other OSes ?
The scanning & displaying speed. I thought this was self-explaining in my post. well, I was mistaken.
Of course Windows Explorer will display the directory faster, which does not mean it has scanned it faster or that it scanned it correctly.
It is irrelevant if it is the scanning that is so slow, or the sorting, the filetype enumeration etc. Fact is that from opening to the final display the thing takes too much time.
As for the extension stuff: yes, that is an inherent flaw in Explorer. But its not better with most Unix file managers, actually. Most use "file" for finding out the filetype. Without it, they have to resort to the extensions. OK, there are inodes, but how many programs actually use them?
Also, the filetype is pointless when I CANNOT BROWSE because the browser seems to be in a catatonic state.
What is the purpose of your fast displaying of thousands of files if you can't even be sure of their type, let alone see their content instantly ? You will take more time finding the right one than me with my Nautilus in the end !!! Unlike you, I don't open directories for the sake of opening them, but to get work done.
You call these arguments? First: I am USED to browsing with the Explorer (I have a dual-boot system). I can find the files pretty quickly. One of the first things I disable in Nautilus is the preview, since it takes too much time, eats CPU thus having the laptop CPU running at 100%, and is usually not necessary (useful for browsing through images though). For the record: I disable the preview in Explorer too. And no, I dont open directories for the sake of opening them, I want to do my work thank you very much. But fact is that the files are on my file server, and some directories have thounsands of files - no, more subdirectories don't help here, I already subdivided. I want to get at my files QUICKLY, thats why I usually use rox, gentoo (the filer), xfe, mc, or the plain console instead of Nautilus (Konqueror only when using KDE).
I would have thought that only the configuration GUI design was at fault, but you know better of course
I am talking about the OS as a whole, not only gnome, AS I SAID IN MY POST. Now who's pathetic? The whole user-friendly distro design DOES fail if there is one case of mandatory config file editing, since the distro should prevent this (assuming we are talking about the distros for users, of course). Editing config files is NOT user friendly. You can write as many comments as you want, it is simply too scary for most people.
Are you confused ? We call them "obscure manpages" the "Web" or "distribution vendor support". You did pay for the distro you're complaining about right ? You know they offer free phone support when you buy their distro right ?
Now here we are at a crucial point. Linux problems can be extremely frustrating. It should NOT require technical support for most hardware. I admit, exotic hardware is a problem. But there are lots of brain-dead errors, even in modern distros. For example, the famous USB scanner error of not being able to scan as a non-root user. One has to manually edit the fstab to have the usbfs be available for non-root users. This is the job of the distro developers, and NOT the users job.
Or the really annoying DPI issue mentioned earlier here.
By the same someone than before or another ? You seem to base your facts on random writing by random people : are you a stupid fool or what ?
I am talking with you, so yeah I must be one. Also, references can be found anywhere in the postings her
How about not hiding it at all?
Ubuntu and Fedora are primarily Gnome based. Mandriva and MEPIS are primarily KDE based.
Well, as for Ubuntu, you are wrong - Kubuntu is the KDE-based version. Also, you fail to include the people that switch from GNOME to KDE once the distro is installed (I did - KDE has a much better filemanager and integration than GNOME) and the ones who use a distro that does not install a DE by default (Debian, Gentoo...). The entire Vienna University of Technology uses KDE and rejected GNOME because of latency and integration issues. So your numbers are way off. Also, AFAIK in business solutions usually KDE is preferred because it respects the X DPI settings, looks & feels more "solid", and has a much better responsiveness.
Someone wrote that GNOME is an OSX killer before.
Well yeah, maybe in 2020.
You see, Nautilus alone is vastly inferior to Finder (the new one). Of all gnome components, nautilus is the one that sucks most. Try browsing a large directory with thousands of files with nautilus, konqueror and windows explorer. The latter ones scan the directory MUCH faster. Nautilus takes about 1-2 MINUTES - unacceptable.
The main point of new gnome bugfix releases should be to improve nautilus. Speed it up, say, to about 100 times its current "speed".
Also, it is evident that once an ORDINARY USER (no hacker, no power user, no admin, no dev) has to edit a config file, the whole design has failed. Of course, this is not gnomes problem alone, but to a great deal the underlying OS; however, we are talking about an OSX killer, right? If you aren't lucky, and the hardware doesn't fit 1:1 with the distro, you have to dig through obscure manpages.
I also read that anyone that is not able to edit configfiles is an idiot and everyone MUST learn how to do this. See, I doubt a biologist that made some photos about a weird plant and want to download them from his cam to his PC is interested in editing config files just to get this to work - he JUST WANTS TO DO HIS JOB and is certainly not interested in learning sh and all about the Unix architecture. Config files per se are ok, as long as editing them is optional. Unfortunately, it still is mandatory sometimes (fortunately, the camera issue is resolved automatically by modern distros - but still, simple samba shares have to be edited by hand for example).
The ion WM is a wonderful idea. It may alienate at first, because ion looks like a hacker WM. Ironically, once I tried it, I never had to edit the configuration file - something that is usually mandatory.
/etc/fstab, and write a usbfs mount with an umask that enables usage by anyone. This is NOT user-friendly.
This shows some points:
1. ion window tiling mode makes perfect sense. However, it lacks proper dialog window handling.
2. One of the - if not THE - main weakness of all Linux distros is the fact that sooner or later everyone has to dig through config files. So what, Power Users have to work a bit more in every OS! True, but with a Linux distro, not only they have to. Even things as simple as to get the wireless card to work involves some config hacking. Also, most distros have a horrible bug with scanners which doesnt allow access to the scanner unless the user has root rights. The solution: go to
Thus, there is nothing wrong with config files, as long as tweaking them is OPTIONAL and not mandatory.
3. Many advances can be done if the underlying filesystem is a better database. Directories become obsolete, search is much easier, and as a whole, the system becomes much easier to use. For example, applications have a metadata "Application". Now there can be a menu "Applications" showing all entries that are apps. This is a very active R&D field, and probably the next big thing.
4. Elimination of the RAM/external memory distincition. This is mainly a matter of time. Once persistent RAMs are fast enough to replace normal RAM, the entire software structure changes. "Loading" files becomes obsolete, since it would equal copying a file. As a result, booting reduces to device initialization and program execution - NO loading of stuff into memory needed anymore.
This has some serious implications to the UI. Together with step 3, navigation through the files becomes very easy.
A console has an unmatched flexibility, but a horrible learning curve, and it is a very inconvenient tool for several tasks. Drawing with the console? 3d-Modeling with the console? Web browsing with the console?
Also, a file manager like Midnight Commander is sometimes preferable over a copy command by using the console, especially when copying, for example, 5 files that cannot be filtered out by simple regexps and/or have awkward names that make it very likely that you misspell them (ok, theres tab-completion, but some shells have problems with this when the filename contains invalid characters).
Most parts in a game cannot be parallelized well.
Only crude splitting is possible, like network, graphics, AI, sound, physics each having its own thread.
Sound, physics and network are loaded in their own threads already - but for low latency, and not for high speed. It is vital for the network code to be independent of the rest (like the graphics card blocking everything - ping requests cannot be answered, and the connection drops). Same for sound: unlike graphics, sound cannot "stutter", because it is much more disturbing, thus the whole sound stream must continue without interrumption. Threads are ideal for this. Physics engines are loaded in their own threads sometimes to be able to deal better with varying step sizes.
Further threading? I can only imagine of one thread for each network connection, one thread for each AI, and one or several threads for loading levels in the background. But how can I speed up RENDERING with threads? Sending a visitor through a scenegraph isnt very thread-friendly. The different steps (visibility determination, reordering for least state switches to prevent pipeline flushes) cannot be parallelized, since they depend on each other. So. Can anyone explain me where one could further parallelize?
If cleverly designed, and with modularization in mind, one can create those renderpaths independently of each other. Talk about plugins. Also, you DO NOT HAVE TO USE IT if you don't want to!
Agreed, todays OS are oversized, but this is not the fault of a goddamn renderpath!
You are acting as if "the new Linux supporty only superduper OpenGL-supporting ultra cards". Again, this GL drawing would be an OPTION. You cannot forbid people to code an OpenGL renderpath for X11. They want it, and they want to create a new option for X, and it WILL exist, no matter if you like it or not. You know, not all people like super-spartan evilwm UIs, and I actually like some eye candy thank you very much. I WANT the Linux desktop to have the features OSX has. It is quite irritating that I have to defend myself every time because some l33t unix hackers see it as blasphemy that someone does not stick to yesterday's interfaces. Man, I'm glad that X11 managed to get truecolor video modes. Must have been a fierce battle.
If you aren't using Translate, your pixel/poly ops will not align correctly with point and line ops (see appendix H of your red book) - this can be seen in certain Accolate products :P
... I'm complicating it because it is complicated, and complicated = evil in computing. See above regarding "Fast".
You don't need Translate for that. Just add 0.5 to the x/y-coordinates (assuming that you set up an orthogonal matrix with 1.0 = 1 pixel).
Aah, so the GPU is now responsible for system heap allocation. Glad to know a non-local processor is handling memory allocation. This still involves considerable CPU intervention, especially with the allocation and management of these 1.5-only objects. When you're updating verticies, what do you think is happening? Some magical GPU prediction of your next update? This all still has to be processed by the OpenGL pipeline, which is deep and complex and interlaced with both CPU and GPU interactions (Read the Apple Developer Guide).
Well, what is happening? The card processes the data I gave it last time, while I am filling the buffer with new data. I'm not entirely sure if this behaviour is fully implemented in dynamic VBOs, it IS implemented in dynamic D3D VBs with the "discard" flag, however.
Besides, anyone how had to do stuff like complex particle systems or extensive 2D output using 3D had to address this issue.
Also, consider this: While your OS is bloating up the video memory, what's happening to your 3D applications? They don't mind that suddenly you have half the texture memory, or that something is consuming GPU time?
Bloating up? Oh come on. How much space is that geometry gonna take? You don't have to create a PBO for each window, you can reuse one, or create a couple of them and reuse them, but for EACH window a PBO/texture is a total waste. Besides, you are not going to use mipmaps, so another space-wasting thing is removed.
So that leaves us with geometry, which almost NEVER fills up half of the GPU RAM (except when dealing with models with about 12 million triangles). Taking up half of the mem is ridiculous. Does your card have only 512 KB RAM?
As for Quake 4: you do *not* have to repaint the GUI all the time; just when its needed. So Quake 4 won't get into trouble unless the entire GUI is updated all the time.
2D blit setup is less than trivial unless there's overlapping regions, and then it's just _trivial_. Integer conversions are also less than trivial, bit ops are sub-cycle for a processor, and sub-sub-cycle for a proper blitter. Floating-to-integer conversions are much less trivial, as floats are more complex and totally incompatible with integers, and require serialized operations (you cannot shift the mantissa until you've extracted and subtracted the exponent down to it's real level, whereas you can extract all four color components and recombine them in an orderless manner (r|g|b is equal to b|g|r which is equal to r|b|g which is..) ) which will not take advantage of modern pipelined _anything_.
This is all totally irrelevant since you usually use integers for textures (unless you use HDR floating point textures). And the fillrate of today's cards is enormous. Basic setup for a 2D-OpenGL-Blit is also absolutely trivial.
Quoting from Apple, "In OpenGL, there are several obvious and other not-so-obvious ways to cause either the CPU or GPU to stall on the other."
Absolutely. But this does not rule out fast rendering. Not at all. Also, if you follow some rather logical rules, you won't end with a crappy performance. Like, using VBOs for geometry, since they are very well optimized, both for static and dynamic geometry (on the other hand, do NOT use glVertex3f unless its not possible to avoid it).
This ATI Charger 512 does not support ANY of that (nor blitting for that matter), and this Rage II here only has the basic rasterization. I don't really know the specs for this S3 Trio64, but I doub
I dunno about that, OpenGL is rather CPU bound. Much of the OpenGL pipeline is still done by the processor, and the primitives for OpenGL are often optimized for fully 3D rendering, which is more than a little unoptimized for 2D blitting. glTranslate3f ?
A 2D-specific blitter is a simple matter of setting up a few registers and letting it happen. A 3D operation in OpenGL has to be converted to native formats, be processed through the fragment pipeline, and then multiplied through several matrix operations before anything happens. While a modern T&L card does much of the more costly things involved in this, there's still all the necessary conversion and setup which is done by the processor.
You should not use glTranslate3f at all with 2D.
Instead, use dynamic vertex buffer objects. Similarly, use pixel buffer objects for the textures (the window contents). And no, nowadays almost nothing is done by the CPU. Just commands are sent, and in this case, vertex data is transmitted. But transfer is mandatory anyway.
Ever seen a GL GUI? Those things are *FAST*.
With a 2D blitter, you have to perform conversions too (32->16 bit for instance). The CPU has to do setup for a 2D blitter, too.
Some of these OpenGL operations may require serialization, which might even involve a hidden busy loop, depending on how defective the operating system/drivers is/are.
No, you are complicating it. As I said, GL GUIs are real and blazing fast. There are tons of GL GUIs for SDL, and ClanLib renders *everything* with GL (yes, the 2D stuff too).
While much of this may be relatively trivial on a modern, ghz-scale system, anything that is taking away from my BOINC credits is teh devil, I say! (Plus one day, you might end up stuck on a lesser machine, waiting for the parts store to open...)
Yes, the lesser machine is a problem. However, 3D support is not. Today, EVERY graphics chip set supports basic 3D rasterization and T&L. In case where there is no support available, simply fall back to traditional methods.
I have been using X.org for almost a year, and it works rock solid. It is MUCH faster than Xfree, and Debian still starts fairly quickly (X.org didn't lengthen the startup time at all).
As for the special effects: wrong, wrong, wrong. OSX shows how these effects can be useful. Also, the transition to a GL desktop will most likely be implemented in a new version of X.org which merges with Packard's work. A GL desktop actually helps the CPU by taking away the task of drawing stuff from it and having the GPU do it, which is the logical thing to do.
But I know, anything else than crude blitting is l4m3, hard core spartan X11 is l33t. Yeah....
Focus fusion is nearly unknown, although it seems to be quite advanced. Slashdot should something about it.
Its the other way round. Cavitation *does* seem promising. They didn't scale it up yet. In theory, surpassing break-even should be possible with it.
1. signals & slots. These *must* be introduced. Event handling is a breeze with them.
2. make it mandatory for allocations to be deallocated in the heap they were allocated, that is, for example if you allocate memory with new or malloc() in a DLL, and you deallocate it with delete or free(), then the deallocation must be done in the DLL. This could be done with some tables storing the heap for each allocation. This is *very* important if you work with several DLLs in your project, since if you deallocate something that was allocated in a different module, the system crashes because you try to deallocate in the wrong heap. Especially STL containers cause a lot of trouble with DLLs.
Well, this can be solved by overloading the new & delete operators; also, choosing "multithreaded DLL" as CRT in VisualC is a solution, since then all "multithreded DLL"-Modules share the same heap. Nevertheless, this is something that should be dealt with in the language.
Your Rights Online: Police Arrests Slashdot Authors For Dupes
Your Rights Online: Slashdot Authors Arrested For Massive Dupe Terrorism
I'm Austrian, and want to clarify some stuff I keep hearing about Austria by tourists:
* no, we are not the country with the kangaroos
* no, we don't have a Nazi government (I keep hearing that from Americans all the time)
* our Wiener Schnitzel is really tasty, yeah
* our kids don't go to school by skiing (well, most of them don't)
* we don't eat much sauerkraut. That's what Germans do.
* never confuse us with Germans. We really don't like that. Its like confusing americans with canadians. They eat us alive if we do this.
* We don't wear Lederhosen all the time.
how can he get the rights for a word that is in PUBLIC DOMAIN? Could anyone kill this guy please?
You see? Patent trolls, legal trolls, almost all of them are small: either one person, or a small company. We keep whining about the evil megacorps squashing everyone with patents while the real danger comes from these small entities.
This is the funny thing about flying cars: they have been technologically feasible for a long time - the real problem is the control. You need to be a pilot to fly/drive these. A driving license is something everyone can get, a piloting license is not.
As for the moon base, it would be great for digging for He-3. Besides, the surface of the moon would be very well suited for a vast array of antenna dishes.
Although I think that advanced aliens rather use neutrinos for communication.... I read something about sapphire crystals being used as sender/receiver unit for this a while ago.
If they can't patent it, then they have to keep it secret.
If they can patent it, then they can license the software to other car companies.
No. You can take a controller chip and flash a new code on it. Patents do not protect against this. If the chip is encrypted and you have to crack the encryption, then you can be sued.
You would be in trouble if you reverse-engineer the code and use the mechanisms of it in your stuff.
Your points are valid, but the issued software patents DID come to court already. Again, ask EADS.
I'm aware that most companies pushing for the directive are the big ones. But the really DANGEROUS ones are small. Is Acacia big? No. Big companies do patent trivialities, but they usually don't use them unless they get attacked. Small patent holders like Acacia however destroy EVERYTHING and are even proud of it.
The thing with GSM is: while it is true that there are patents blocking its adoption, GSM is far from being trivial. Same with MPEG4 and H264: there are many patented techniques involved in these standards, but the patents involved are often made to prevent other from adopting them on their own. MPEG-4 patents aren't trivial, either. Best thing would be to have these patents issued as "no-cost-patents" for the public, but the companies involved in the creation of MPEG4 do want something for the money they invested. So you are mixing two kinds of problems: trivial patents (which NOBODY wants, not even the big companies - they get some only to be able to defend themselves from trivial-patent attacks) and non-trivial, blocking patents like the GSM issue.
Now mplayer, VLC and xine are in trouble. They implement patented stuff with no licenses for it. (Except H264 - you don't need any licenses for creating an opensource codec. People using these codecs for commercial playback need one, though.)
Fortunately, GStreamer isn't in trouble, because of its plugin-based system.
What this directive cannot prevent are GSM-patents. What it SHOULD prevent, however, are the trivial ones, not only because the council directive isn't effective enough, but also because the CURRENT legislation isn't effective enough. No company wants trivial patents except scavengers like Acacia and Forgent (could anyone shoot these guys please?). The major IT groups like GI (Gesellschaft Informatik) now are pushing the planned amendments of the parliament. Lets hope that it pays off.
The EPO chose to ignore it because it is useless. The lawyer just has to circumvent the definiton "software patent". That is what many US patents do too.
As for the directive in local countries: this is a directive, not a law. The countries have to implement a law based upon that directive. Things like the definition of the required "technical nature" of the invention can be implemented in any way possible. This is a double-edged sword: Europe will still be a mess for patentability - each country will have variations that need to be adressed, which makes patenting quite annoying. The council version is not detailed enough to tackle down important issues - these will be implemented in different ways. This helps against patent trolls, but makes it harder for people with stuff worthy of patenting really hard to do so (useful patenting: the car controller I mentioned before, and extremely complicated algorithms for speeding up holographic projections in a prototype holographic screen; Slashdot mentioned this in the past, a year ago or such).
Several large groups formerly pushing hard FOR swpats are now AGAINST them. Which is quite late.
The majority in the EU parliament wants modifications to the directive, which would bind sw-pats to controlled effects on natural forces. This excludes things like "patent on data-streaming" pretty well. You keep mentioning large companies pushing for software patents: many of these companies are car manufacturers who want to patent their controller software for their cars. This IS reasonable, since it costs a hell of a lot of money to develop this software, and copyright can't do a thing to prevent other from stealing the mechanisms. They don't want to be able to patent all software - just the one they need. They are not patent trolls like Acacia or Forgent.
I hope the directive gets adopted. Because the real question is not whether we get sw-patents or not; the question is: can the current situation be remedied by this? Contrary to what many people say, it IS possible to patent software in the EU right now. Just ask EADS, they patented mapping software, and already filed lawsuits about it. The software exclusion clause in the current patent law is useless, because any skilled lawyer can bypass it. So, if the Council version gets adopted, it won't change much - which is bad. The parliament can help us to adopt a better way.
-by- the FAA, that is.
If I built a laptop completely encased in fans, and I mounted them the wrong way so that the laptop starts to fly (battery power), do I get sued the FAA for distracting the pilots with a flying laptop?