I know everyone hates the question "what is the best distribution", because the question leaves out "best in what ways" and "what bugs and delights the questioner most". So I'll try to ask the question better, and request answers only from people who have tried several distributions.


Here are elements I need (probably some of these are solid in every Linux):
+++ the linux distribution that supports my needs with the least troubles
+++ nvidia driver support (for 7800 and 9800 (and soon 280))
+++ C/C++ development tools with IDE
+++ OpenGL 2.0 or higher
+++ GLSL shader support
+++ GLEE or equivalent


Here are elements I want to have:
+++ the latest release of eclipse IDE (3.4+) and CDT (5.0+) install and work reliably
+++ informative graphics information utilities (like glinfo, glxinfo, GUI equivalents)
+++ latest GLEE installs and works easily (i just include the files into my project)
+++ most helpful and knowledgable distribution experts in the distribution forum
+++ distribution that best supports taking advantage of all 4 cores of phenoms
+++ distribution that best supports co-development of 32-bit / 64-bit versions
...... but I can develop only the 32-bit version for the time being, if necessary


Here are elements I want to avoid:
--- a distribution that tries to protect me from myself
--- a distribution that requires lots of tricks and tweaking
--- a distribution that tries to be cute in non-standard ways
--- a distribution forum populated by non-helpful, non-serious jerks (BTDT)


Here is my hardware (two nearly identical computers)
::: motherboard = MSI K9A2 platinum AM2+
::: CPU = AMD phenom x4 9850 quad core
::: Zalman 9700LEDRTL CPU cooler-fan
::: 2 x 2GB DDR2-SDRAM @ 800MHz
::: PCIe dual RJ45 gigabit ethernet
::: 1 x 1024GB SATAII disk drive
::: 2 x 256GB SATAII disk drive


The above is probably sufficient, but just in case knowing what I need to do, and where I am in the process, the following is a brief description. I have been developing 3D simulation/graphics/vision/game code/engine/libraries/algorithms for many years, off and on (plus a couple commercial 3D game-engine contracts along the way, but that was totally separate code - but good experience). A long time ago I was stupid enough to begin my journey on DirectX/3D. I wised up a few years ago and rewrote my engine in OpenGL (but still on windoze) --- holy smokes did I ever find OpenGL to be massively easier and better designed!!! A year or so ago I created a parallel version in Linux on fedora8 with the eclipse IDE and CDT. When fedora9 was released I installed fedora9 on another disk but was never able to get it working properly - it would not update correctly, which prevented ALL updates from happening. I couldn't find a way around these problems, which led to me being successfully distracted by other work. I'm ready to continue the work now, and have an additional rather high-priority need to get the software working and finish my 5-page list of (small, medium, major) improvements to totally complete this application - which is designed to function as a network independent "server" (but still operate at full / high-as-possible speed when controlled from processes in the same process / computer / LAN instead of over the internet). I have vision-input support (via gigabit ethernet) but have not added sound support yet (and I suspect I will need to adopt some support library for that, even though I prefer to write everything myself when practical).

The bottom line is, I really care much less about distribution weaknesses that I will not notice when doing this development. I have other computers that work fine for any other purpose I am likely to encounter. What I care very much about is being able to get the distribution running with nvidia drivers to enable full hardware acceleration of the nvidia video cards and OpenGL 2.0+ and GLSL --- and --- the latest version of eclipse IDE and CDT (cuz the old versions I was programming with had bugs that were driving me nuts). I also don't want to minimize the importance to me of having very knowledgable and helpful people frequenting the forum associated with my distribution, so I can get back to work and not waste days, weeks, months on utterly trivial problems. So, given all that, what do those of you who "tried 'em all" (or at least a few distributions) think are my best bets --- and what would be my biggest mistakes? Thanks for every thoughtful opinion.

I've been using Slackware (11, 12, 12.1) for 3D OpenGL/GLSL programming.
I think any distribution should do, but most likely you'll have to install stuff (CDT/GLEE/NVIdia driver) yourself.

Notes:
On slackware should be downloaded and installed manually.

C/C++ development tools are available on almost all distirbutions.
On Slackware gcc/g++ is included by default, and KDevelop is available as IDE(I'd recommend Kate or vim, though). You can install eclipse manually, if you wish.

Available on any distribution after nvidia driver installation.

GLEE/GLEW should be installed manually on Slackware.

Can't say anything, since I'm not using them.

glinfo isn't available on my system, but there is much better glewinfo (comes with GLEW library, which should be installed manually). Don't know about GUI equivalents.

Depends on what you call "easily".

This means Slackware or Gentoo, I think.

All distribution support that if kernel has smp support enabled.

AFAIK cross-compilation for another architecture is supported only on Gentoo, which doesn't seem compatible with "doesn't require a lot of tweaking" requirement.

The only problems you might have with slackware are:
1) it reqlly doesn't protect you from yourself, and is based on assumption that you are smart and know what you are doing.
2) Many packages needs to be built from source (i mean packages that aren't on DVD). Either using SlackBuilds or manually. The good thing is that making packages is very easy. Also there is slaptget utility that should search repositories for compiled packages, but I haven't used it.
3) No dependency checking in packages, and no automatic updates. I like this (because you completely control all your system), but some people might have problems with that.

An important note about GLEE/GLEW.
You don't have to use them on Linux (On Windows they are required). If your hardware/software supports OpenGL 2.0, and you just want to compile app to run on your own machine, then you can compile code without those wrappers (by defining OPENGL_2_0 before inclusion of GL/gl.h, I think, but I don't remember details). The only problem with this approach is that if you are using OpenGL 2.0 functions, your program won't compile on system where those functions are not available (due to the "unresolved external" linker errors). The whole dancing with OpenGL wrappers is required only on Windows platform (or cross-platform applications), because Windows (XP) still guarantees OpenGL 1.1 support only.

P.S. I've also learned DirectX/Direct3D first, then decided to switch to OpenGL several years later.

Thanks, ErV for your nicely organized response.

You know what, I think you are right about not needing GLEE or GLEW on Linux, because the nvidia-provided headers contain everything already. I think I knew that, but for some reason included the glee.h and glee.c files in my software anyway - probably cuz I just didn't think it through carefully and copied what I was doing in my windoze version (which I ported over to linux/fedora8 last year). But it will be less problematic to just conditionally include them in the windoze version and leave them out in the linux version --- unless the headers are handled differently by other ATI (and any other high-performance 3D video card companies that might still exist). But this does raise the question of what I'll need to do to support other video cards. I guess I'll eventually need to compile separate versions that are linked to each manufacturers libraries. Sigh. Oh well.

I hate software that tries to protect me from myself - beyond the basic fundamental kinds of protections that are appropriate and unavoidable (like processes being in separate memory spaces, etc). Those kinds of systems always just prevent me from doing things I know how to do and want to do.

I don't like the idea of building packages from source (except my own, of course!). I will avoid doing so as long as possible.

I am starting to think the automatic updates feature is a double-edged sword. On the surface it seems good and helpful. And that probably remains true for all sorts of packages that I don't really care about. But I have noticed in the past day or two that every single package that I really need and care about --- is grossly out of date in the [standard] automatic updates. Examples: the eclipse IDE and CDT are *far* out of date in all the repositories, and nvidia drivers and libraries need to be up-to-date (which is handled by livna for fedora, but not for other distributions). So I guess it is nice to have automatic updates, but only for packages that are not important to the work we're doing.

I'm not sure what you mean by "cross-compiling for another architecture". In my case the closest I would get to that is compiling versions for 32-bit mode AMD/intel CPUs and 64-bit mode AMD/intel CPUs. So I guess we have two situations here. If I am running on 32-bit linux, I cannot test 64-bit executables - even if eclipse can create them. If I am running on 64-bit linux AND eclipse can generate both 32-bit and 64-bit executables (linked to the appropriate 32-bit/64-bit libraries), that would be potentially useful, ***especially*** if I can run == test the 32-bit version on 64-bit linux. I believe *most* 32-bit linux programs will run on 64-bit linux just fine, but I'm not sure this would include my application, because the 32-bit version would need to be linked to the 32-bit versions of the nvidia/OpenGL libraries - which might be kernel-mode drivers (or maybe they aren't).

Funny, I noticed glinfo is not on my just-installed ubuntu 8.04.1 LTS filesystem either - though it was on my fedora8 disks (and it ran on ubuntu when I executed it from the [mounted] fedora8 disk).

Anyhow, thanks for all the information. Once I see whether my attempt to install fedora9 yet again succeeds, I'll consider trying slackware to see how that goes.

You might need them on Linux only if you are building project that is supposed to be distributed in binary form and should be able to run on both OpenGL 2.0 and older hardware. Other than that you don't need them.

I think that the best way will be to stick to some basic standard - i.e. OpenGL 2.0/GLSL without additional extensions, if that's possible. However there also might be problems - for example, as far as I know GLSL's noise() function is currently implemented in different way on ATI and NVidia, and both implementations are incorrect doesn't comply with GLSL specifications (Nvidia's implementation return black color, and ati's produces huge slowdown). Another problem is that (to my experience) ati's GLSL compiler is much more strict (at least, Windows version) than NVidia's. I.e. on Nvidia you can accidentally write number in 1.0f form, forget to specify source component mask, forget to initialise alpha component in output color, etc and that'll work, but ATI video card will refuse to compile that shader. There are also several other such small differences.

In 90% of cases this is straight-forward process.
1) extract
2) ./configure
3) make
4) make package (either manually or using checkinstall), do not "make install".5) install package you made.

Installing software with just "make install" plain is wrong - turns system into mess very quickly, because many packages don't have "make uninstall" functionality, and in many cases you will spend a lot of time trying to figure where has this thing installed itself.

5..9% of programs use unusual build system (i.e. scons) with awkward installation process that either can be handled by checkinstall or there is slackbuild available.

Only 1% of rare programs require thinking to make package from source.

Again, there are utilities on slackware which search for compiled packages.

And don't forget - you are running quad-core CPU (which is generally good for compressing x264 video and compiling things), so if you compile stuff with "make -j4", then it'll be much faster. I think WINE should be able to compile on your machine in something around 10 minutes.

It was my mistake. I know that gentoo can compile it's system (not your programs) packages to other architecture, so that's not what you need. I never needed to cross-compile (for 64 bit on 32 bit and vice-versa), so I don't know how you can handle it.
You should be able to make/run 32bit executables on 64bit system, though, or you can use virtual machines. OpenGL won't work directly on virtual machine, but you might use mesa3d for very slow test rendering (It's uncertified software renderer which is nearly equivalent to OpenGL 2.1). Warning: last time I've checked it mesa3d had some bugs when compared to ATI/NVIDIA OpenGL 2.0 implementation (was unable to call some user-defined GLSL functions), but it otherwise it produced render result identical to OpenGL 2.0 hardware. I've used Mesa3D on Windows to demonstrate OpenGL 2.0 rendering machines without OpenGL 2.0 support. It's VERY slow when you use GLSL (1..0.25 fps in 640x480 window, depends on scene/shader complexity), but otherwise is pretty good.

Anyway, good luck with OpenGL programming.

Yes, I have learned to limit myself to the core/basic/fundamental features of packages I adopt (OS/library/etc). That doesn't mean I do without, that means I find some way to implement it myself with only the core/fundamental infrastructure. So I'd just make my own xnoise() if necessary (and perhaps call the built-in noise() on systems that have a good, efficient, reliable one).

I have more-or-less decided to have two [or three] bootable linux systems one of my computer cases (that have nearly identical components). Whichever ends up looking like the best distribution for me (on initial analysis) I have decided to have both 32-bit and 64-bit implementations - one on each of two disk drives. Actually, I created 3 partitions on my ubuntu and fedora disk drives (/ /boot swap) and left room for an additional "/boot64" partition - just in case that works. But I'm not clear whether linux organizes its modus-operandi correctly so a 32-bit and 64-bit implementation can co-exist within one unified directory structure. It sure would be wise to do that - in my opinion - but I'm not knowledgable enough to know whether that works. For *anyone who knows* --- does linux work that way? And if so, !!! great !!! --- how do I set it up?

The work I'm doing absolutely positively *requires* 3D video acceleration to be practical at all. That said, I implemented as much (or more) than practical in my own CPU code inside my engine. For example, except at the last step where [vertex] data is put into VBOs, my engine is 100% double precision (and written in very carefully written SIMD SSE3+ assembly language). That's partly because most of the transformation routines are also computing all sorts of physical processes, astrodynamics (orbit computation), and so forth - much of which accumulates too much imprecision in single precision. Still, without the 3D acceleration of nv7800 and above video cards (and increasingly more work inside shader language programs in the GPUs) the applications could not run real-time, which they must (in many cases).

Yes, OpenGL and GLSL have been good experiences for me - which has been a rare treat in a world that becomes increasingly difficult and problematic and risky to adopt the infrastructure of others. Fact is, I could not succeed *at all* in what I am doing without the policy of "adopt the absolute minimum possible".

In the end, everything I am doing is a component of ICE / NICE. ICE is my acronym and trademark for "inorganic conscious entity". NICE is my acronym and trademark for "cooperative nexus/network of inorganic conscious entities". The good news is, "it works, and is already smarter and more capable than human level consciousness". The bad news is, the last time I ran the whole system/benchmark that proves that, it clocked in at somewhere around 10 million times too slow to be practical (more-or-less measured with human speed as barely acceptable). The fact is, ICE is much faster in many respects, but the vision system in particular (including the whole feedback loop involving: vision/sensation->perception->recognition/identification->integration/consequences-recognition->options/alternatives-estimates->decisions->action/response-initiation/continuation) is extremely burdensome. Fortunately I was able to identify the most problematic (slow) processes, and over a few years rearchitect the infrastructure and invent new approaches to be hundreds to billions of times faster (depending on which portion and circumstances). When the next round of work is complete (in a few years), the result will be totally off-the-charts fantastic.

phenoms+linux+opengl+glsl+nvidia+robotics/vision-hardware+ICE-software = :-)

Thanks for your help. I appreciate it.

Hey it's really nice to meet both of you I've been interested in 3D gfx for a long time and Linux needs all the 3D/game people it can get. Do you both have webpages with some work on it by any chance? like a small demo or something? Just out of curiosity, when you switched from Win to Lin, you mean Mesa, right? (not something FROM silicon graphics?) Was it equivalent?
How would you say DirectX (esp. the current one, ver 10) compares to OpenGL capability wise?

And also, what's GLEE/GLEW?

Well, I'm working on my webpage right now, but it's unclear how much time it'll get to turn webpage into some kind of final shape (may be weeks). When it'll be worth looking at, I'll put it into profile.
It also happens that I have more "testing" stuff (like physics tests, unfinished game engines, exporters, etc., shader tests, technology tests, etc), but not enough finished stuff. It's also happens that I've been working more with DirectX, because getting freelance jobs for Linux+OpenGL is problematic in my area.

I don't understand you. Mesa 3D is software renderer nearly equivalent to OpenGL (with identical IP), but it's not certified to become OpenGL implementation. Linux has OpenGL libraries, but I don't know who provides these libraries (It isn't really important as long as I keep using SDL).

I've never installed vista, and last DX version I've been working with is DirectX 9.0c. Anyway, you can't compare OpenGL to DirectX, because DirectX includes input/network/sound functionality (but you can compare OpenGL+SDL+something_else with DirectX, though).
Anyway, OpenGL is much easier to learn, more intuitive, better suitable for dynamically-generated geometry, and it's more useful when you'll need to build 3D application quickly. Direct3D has instancing support, that allows you to render (for example) large crowds, and Geometry Shaders (in DX10), but it is constantly being stupiditified by microsoft and become worse since DirectX 8.1 (as usual - Microsoft did create good library, but started building extensions above it, made extensions platform-specific for luring away developers and is on the way to turn the whole library into something ugly), and it's available only on one or two platforms. Anyway, programming with OpenGL+SDL on linux is much easier (you finally get chance to concentrate on non-technical side of your work) and provides more pleasant experience than working with DirectX on windows platform.

GLEE
GLEW
These are libraries for detecting OpenGL extensions, and loading extension-specific/version-specific functions. Without these (or similar) libraries OpenGL programming on Windows will be problematic.

sorry I dont follow - I thought Mesa was, the, as you said "equiv. to OpenGL" open source lib., but there is something from Nvidia as well? When you install their driver, it installs with it?

Would any of you both be interested in Making a 3D Api for Linux?

GLEE and GLEW are essentially C header files that contain declarations for every OpenGL core and extension function, with a bunch of conditional includes to assure it doesn't declare functions that are not available on your machine. They are extremely important on windoze systems because the existing header files provided by macroshaft are extremely out of date.

On linux, life is much better. nvidia (and probably amd/ati too) provide comprehensive header files for OpenGL with the drivers for their video cards.

I do have a webpage, but I haven't updated it in a dozen years, so it doesn't include any of my recent graphics work - if that's what you want to see. I could grab an image of the display or a window with [alt] + PrintScreen to show you a frozen image of something 3D on the screen. But that's not very satisfying, since I am still focused on software development, not making really cool universes, solar systems, planets, spacecraft, environments, buildings, machines, etc --- yet. :-)

I have never run Mesa - except possibly for the first 10 minutes after installing linux (before I installed the nvidia drivers, which is real OpenGL). Or have I misunderstood your question? Let's see, how have I "switched"...

1: 20+ years ago I wrote a couple very basic 3D "engines" entirely from scratch, with no graphics APIs. I had developed my own CPUs and other hardware, and was planning on building an ASIC (application specific IC) to accelerate 3D graphics for PCs. When it came time to bite the bullet and have the chips made, I chicken out - no other way to put it. It would have cost me about 90% of my life savings to have the ASIC made, and if anything (other than trivial) was wrong with the ASIC, I would be wiped out. Another true coulda-shoulda-woulda [been nvidia] story...

2: ~12 and ~10 years ago I wrote a couple commercial 3D game engines under contract (which means, none of the code belongs to me). One was DirectX (or was it Direct3D by then - can't remember) and the other was SonyPlaystation (which has its own API).

3: Several years ago I wrote my own engine in Direct3D. Then macroshaft royally pissed me off for the 2^32 time and I refused to switch to 64-bits to enumerate my gripes. So I bit the bullet, started over from scratch, and wrote a new engine in OpenGL. Wow! All I can say is, OpenGL is vastly better. Not good, but vastly better in comparison. And I'm not being purposely abused any more, which is a relief.

Direct3D and OpenGL have virtually identical capabilities. Direct3D is slightly quicker to support new architecture modifications as the appear in video cards, but that is a teenie, tiny price to pay for all the ways OpenGL is better, easier, and doesn't subject you to the whims and diabolical plans of cretins.

Yes, it is too bad Linux has so few 3D action - in comparison. That implies that most people willing to invest man-years of effort into becoming expert in some technology have their eyes on a monetary prize. And it is true that far more computers run windoze than linux, hence the skew in Linux supporters. OTOH, since OpenGL runs on windoze quite efficiently, it is somewhat surprising that more people don't do work that runs on both - though it does happen.

And why is it you need to reset twice?

Woops, I started my previous reply before your second message appeared.

My 3D simulation/graphics/game engine is designed as a "server". Which means, it more or less inherently IS an API for Linux --- or any other computer. Perhaps that doesn't make sense, so I'll elaborate a bit.

The engine is desiged to be fed "messages", which is essentially just a fancy term that means "a collection of bytes that tells the server what to do". So any program on any computer (anywhere in the universe, but usually "on earth" to evade the speed-of-light problem) can send these messages to the server to tell it what to do (describe objects (cameras, lights, solid objects, etc), modify them, move them around, display them, etc). A program that sends messages (comments, requests, etc) to the 3D "server" is usually called a "client" program, and the common/normal/usual way to send [a group of] messages is in an ethernet "packet" across a LAN (wired or wireless "local area network") or a WAN (the internet).

In other words, any program written in any language running on any computer with any operating system can send messages just as easily as any other. Which means the 3D server doesn't care (or even know) anything about the program-OS-computer that controls it.

As it turns out, I also have a super-duper-efficient "back door" way to get the messages to the server when they come from another program on the same computer (even when that program runs in the same process as the server - though that is generally unwise (less efficient) in the days of quad core CPUs and beyond.

I'm not sure whether that answers your question, or not.

-----

Oh, yeah, one more thing. Since the only way a program can drive the server is by sending it messages --- the nature of the messages must be clearly and openly defined, or the server is totally useless. Which is why, "yes it is a 3D server for Linux, or anything else".

Haaha I dont need to reset twice - that's just a random nickname i chose, i think because "reset" was taken

Anyway, I wasn't going to say it before but I think you need to be welcomed into the demoscene without further delay :

www.scene.org and www.pouet.net . Welcome! (and there is a www.linuxdemos.org but it seems to be down )

(I personally am not a scener but I'm sort of interested in it).




You programmed a 3D engine in *1988*?!! Can I ask you how old you are? On what machine did you do this?



Can we keep in touch? (and you too ErV, I dont know if there's a way to search by nickname on this site). Just post here, because I've lost the password to the email that this site has!

I have no idea what you just said up there about your server Is your engine a DLL file?

Yes, as far as I know NVidia installs it's own libOpenGL.so + bunch of other files (libGlx and other). It's normal approach for the driver, windows works same way, as far as I know.

Why? There is already OpenGL available.

(a bit surprised)Well, it you are much more experienced than I've thought originally, you have my respect, and it looks like I have a lot to be achieved. I've got access to normal 32bit PC only in 2001..2002 (had experience working with older machines (several years, but I really don't remember how many) like ZX-Spectrum before that), wrote one software rasterizer with texturing support and started learning ddraw/directx 8.0 somewhere around 2002, and I was still using Pascal/Delphi (right now I use C++, has basic knowledge about bunch other languages). Since that time there were several (failed) attempts to make team, and make game (DirectX), one finished spacesim engine lost due to the broken medium, many unfinished engines, exporter plugins, tools, etc. No finished commercial engines so far (still working on it ), but I've been tuning/optimizing/modifying several commercial 3D engines and wrote several tools/exporter as a freelancer during last year. Comparing with 20+ year experience looks like there is a lot of things to do...

Technical detail.
GLEW is a library. It has header files, but function entry points are stored locally, and application that uses GLEW requires linking with libglew.so (linux) or glew32.dll(windows). It has advantage over glee in the sense that it doesn't check in every function if this is initialized or not. Glee has other advantage - it allows you to create apps without linking with yet another library.

For fun (since you already KNOW what one API is and does, let's see if better can be done?! ) I'm NOT good at maths myself, but I would like to help out in any way I can.