The scene's opinion of GNU/Linux
category: code [glöplog]
Quote:
Why don't you develop it yourself then? If everyone would just wait for others to spoonfeed them with tools and frameworks, then things like crinkler or 4klang would never have been developed either.
I guess that's the bigger question here: why hasn't anyone done serious linux demos/tools/frameworks yet?
That's been on my list for a while. There are 2 problems though:
First, I'm not much of a systems / low-level /bit-fiddling coder. I'd love to write a linux entropy coder competitive with crinkler, but I need someone else to handle all the header corrupting bit squeezing stuff.
Second, a project as the one above takes a significant time commitment, and I have little enough time set aside for democoding as is these days (none, to be precise).
I would actually love to get the ball rolling for a more linux oriented demoscene, but as this thread shows, not a lot of people care. Unless the few of us that do manage to make a coordinated effort, we won't get anywhere.
Just to illustrate the problem of binary compatibility, here's my attempts to run some of the popular Linux-demos on Fedora 20 (64-bit).
To be fair to the following productions, I removed the packages I installed for the previous demo (with the exception of SDL.i686, because I messed up and I don't feel like repeating the experiment), to prevent the first demos from looking bad in comparison to the latter. This means that some of the dependencies gets installed multiple times in total, something that would not be needed on a normal demo-watcher's setup:
Yellow Rose of Texas:
result: works, requires non-standard package
State of Mind:
result:broken.
Variform:
result: broken.
Dose2:
result: works. crashes at exit, leaving the desktop resolution at 640x480. requires non-standard package.
Die Ewigkeit Schmerzt:
result: broken
Chimera:
result: broken
Obsoleet:
result: works, requires non-standard packages.
To be fair to the following productions, I removed the packages I installed for the previous demo (with the exception of SDL.i686, because I messed up and I don't feel like repeating the experiment), to prevent the first demos from looking bad in comparison to the latter. This means that some of the dependencies gets installed multiple times in total, something that would not be needed on a normal demo-watcher's setup:
Yellow Rose of Texas:
Quote:
$ ./yellow_rose
3996+0 records in
3996+0 records out
3996 bytes (4,0 kB) copied, 0,0102145 s, 391 kB/s
./T: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory
$ sudo yum -y -q install SDL
Package SDL-1.2.15-12.fc20.x86_64 already installed and latest version
$ sudo yum -y -q install SDL.i686
$ ./yellow_rose
result: works, requires non-standard package
State of Mind:
Quote:
$ ./MIND
bash: ./MIND: Permission denied
$ chmod a+x ./MIND
$ ./MIND
bash: ./MIND: /lib/ld-linux.so.1: bad ELF interpreter: No such file or directory
$ file MIND
MIND: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ sudo yum search lsb
$ ./MIND
bash: ./MIND: /lib/ld-linux.so.1: bad ELF interpreter: No such file or directory
$ ls /lib/ld-linux.so*
/lib/ld-linux.so.2
$ yum provides /lib/ld-linux.so.1
No matches found
result:broken.
Variform:
Quote:
$ ./variform
./binary: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory
$ sudo yum -y -q install SDL.i686
$ ./variform
./binary: error while loading shared libraries: libglut.so.3: cannot open shared object file: No such file or directory
$ sudo yum -y -q install freeglut.i686
$ ./variform
./binary: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
$ sudo yum -y -q install mesa-libGLU.i686
$ ./variform
could not open mp3
$ ls data/*.mp3
data/variform.mp3
result: broken.
Dose2:
Quote:
$ ./a.out
2chn/44100Hz
ALSA lib dlmisc.c:252:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
sdlerror No available audio device
$ sudo yum -y -q install alsa-plugins-pulseaudio.i686
$ ./a.out
2chn/44100Hz
*** Error in `./a.out': double free or corruption (!prev): 0x09369008 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6e2f3)[0xf75682f3]
/lib/libc.so.6(+0x75e52)[0xf756fe52]
/lib/libc.so.6(fclose+0x142)[0xf755e402]
./a.out[0x805049f]
/lib/libc.so.6(__libc_start_main+0xf3)[0xf7513b73]
result: works. crashes at exit, leaving the desktop resolution at 640x480. requires non-standard package.
Die Ewigkeit Schmerzt:
Quote:
$ ./demo
Traceback (most recent call last):
File "demo.py", line 11, in
import scene_main
File "/home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/scene_main.py", line 7, in
from nedu import mesh, res, m3d, stager, camera, svg, demo, GLSL, keybind, vector
File "/home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/lib/nedu/mesh.py", line 4, in
import GLEXT
File "/home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/lib/nedu/GLEXT.py", line 5, in
from OpenGL.GL import glGetString, \
File "/home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/lib/OpenGL/init.py", line 26, in
from GL.GL__init___ import numeric_present, numeric_support
File "/home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/lib/OpenGL/GL/init.py", line 2, in
from GL__init__ import *
File "/home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/lib/OpenGL/GL/GL__init__.py", line 2, in
import GL__init___
ImportError: /home/erik/Downloads/neuro-die/neuro-die_ewigkeit_schmerzt/lib/OpenGL/GL/GL__init___.so: wrong ELF class: ELFCLASS32
result: broken
Chimera:
Quote:
$ ./RUN
./chimera: error while loading shared libraries: libglut.so.3: cannot open shared object file: No such file or directory
$ sudo yum -y -q install freeglut.i686
$ ./RUN
./chimera: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
$ sudo yum -y -q install compat-libstdc++-296-2.96-145.i686
$ ./RUN
./chimera: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
$ sudo yum -y -q install mesa-libGLU.i686
$ ./RUN
*** Error in ./chimera': malloc(): memory corruption: 0x081a4518 *** *** Error in./chimera': malloc(): memory corruption: 0x081a4518 ***
result: broken
Obsoleet:
Quote:
$ chmod +x obsoleet.sh player/player
chmod: cannot access ‘player/player’: No such file or directory
$ chmod +x bin/player
$ ./obsoleet.sh
bin/player: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
$ sudo yum install compat-libstdc++-33-3.2.3-68.7.i686
$ ./obsoleet.sh
Error: dlopen failed: libGLU.so.1: cannot open shared object file: No such file or directory
Error: Graph: Unable to load module Screen from library modules/libgraphics.so
Error: dlopen failed: libGLU.so.1: cannot open shared object file: No such file or directory
$ sudo yum -y -q install mesa-libGLU.i686
$ ./obsoleet.sh
Error: dlopen failed: libXmu.so.6: cannot open shared object file: No such file or directory
$ sudo yum -y -q install libXmu-1.1.1-5.fc20.i686
$ ./obsoleet.sh
result: works, requires non-standard packages.
Quote:
Says someone on a very heavily code-oriented site...
This may come as a susprise to you, but not everyone here is interested in investing loads of time to keep their operating system alive. As a coder, you want to use the goddamn thing and usually rather prefer reading your favourite language's / SDK's documentation rather than linux manpages.
Quote:
Quote:Says someone on a very heavily code-oriented site...
This may come as a susprise to you, but not everyone here is interested in investing loads of time to keep their operating system alive. As a coder, you want to use the goddamn thing and usually rather prefer reading your favourite language's / SDK's documentation rather than linux manpages.
this.
I'm a coder, and I'd rather just click/double click the executable of a demo to run it, and not spend all that extra bloatwork just as kusma showed.
And yes, I've got enough "apt/yum" and "./configure, make, make install" experience.
Quote:
Die Ewigkeit Schmerzt:
[...]
result: broken
The sad part in this one in particular is that it's in Python.
Quote:
This may come as a susprise to you, but not everyone here is interested in investing loads of time to keep their operating system alive. As a coder, you want to use the goddamn thing and usually rather prefer reading your favourite language's / SDK's documentation rather than linux manpages.
Indeed. Demos are not about OSes, they are about making the hardware do all sorts of audiovisual things.
The OS is just "that thing that gets in the way".
In the golden age of demos, on C64, Amiga, MS-DOS and such, coders would just take over the entire machine. Their OSes did not get in the way.
When Windows arrived, many coders were complaining that Windows was getting in the way, preventing them from doing various hardware tricks, stealing precious CPU time, and messing up tightly timed routines.
Then DirectX arrived, and Windows did not get in the way that much anymore.
In fact, Windows/DX started to play an enabling role in accessing hardware, especially when 3d acceleration arrived.
Linux... just isn't a platform, and isn't all that good at enabling access to hardware, because it still gets in the way with all the library and poor driver issues.
The only reasonable linux-based demo platform would be with an nVidia card and proprietary drivers. But what's the point? You can make the hardware do exactly the same on Windows, just with less headaches.
And less of... let's see how you put it exactly... "big circle-jerk of clueless developers"?
I don't know why ppl always think you spend more time with fixing the OS than doing actual work.
I'm using Linux for quite some years now for coding in my job and all coding at home. Windows is only used for gaming and verifying that my cross-platform stuff still works on it.
Yep, there might be some troubles in the beginning, but it's a minimal price to pay. Of course, in the end it all comes down to a matter of taste, but as a coder who worked on 4 platforms, in over 10 languages for more than 20 years now I don't see a point in using Windows anymore for coding.
Sure, you can't code winapi dependent stuff on Linux, but as everything nowadays should be cross-platform anyways (if it's written in a 'cross-platform' language) this doesn't really matter. Once you have your 'framework' it shouldn't matter on which OS you code.
(Note: The next paragraph is about programs written in e.g. C, C++, D, Delphi, ... that can use standard APIs (and don't need to talk to specific hardware), it's not about coding a demo e.g. in 6502asm for the Commodore....)
The real problem isn't Windows or Linux ... the real problem is that most ppl don't realize that writing software in a OS specific manner is a bad idea nowadays. E.g. if you have a game engine that abstracts away the different audio/video rendering backends you could just write a single codebase and compile for all systems (depending on HWcaps of course).
It even gets simpler for demos ... what stuff is really needed? ... a window, DX/GL setup/context, audio output, basic UI stuff for some selectors, querying a key...
I don't say any of those OSs is superior, this just makes no sense ... and it doesn't even matter. What I really want is that it doesn't matter on which OS you work on a project but it still runs everywhere.
Final thoughts: I don't see much value in Linux-only demos, but I see it in cross-platform demos. Yep, sure, the Windows-only-guys need to switch to OpenGL and 4/64k demos will be a lot larger on OSX/Linux, but does that matter? (And one can still do _full_ releases for OSX/Linux (i.e. shipping all needed libraries))
I'm using Linux for quite some years now for coding in my job and all coding at home. Windows is only used for gaming and verifying that my cross-platform stuff still works on it.
Yep, there might be some troubles in the beginning, but it's a minimal price to pay. Of course, in the end it all comes down to a matter of taste, but as a coder who worked on 4 platforms, in over 10 languages for more than 20 years now I don't see a point in using Windows anymore for coding.
Sure, you can't code winapi dependent stuff on Linux, but as everything nowadays should be cross-platform anyways (if it's written in a 'cross-platform' language) this doesn't really matter. Once you have your 'framework' it shouldn't matter on which OS you code.
(Note: The next paragraph is about programs written in e.g. C, C++, D, Delphi, ... that can use standard APIs (and don't need to talk to specific hardware), it's not about coding a demo e.g. in 6502asm for the Commodore....)
The real problem isn't Windows or Linux ... the real problem is that most ppl don't realize that writing software in a OS specific manner is a bad idea nowadays. E.g. if you have a game engine that abstracts away the different audio/video rendering backends you could just write a single codebase and compile for all systems (depending on HWcaps of course).
It even gets simpler for demos ... what stuff is really needed? ... a window, DX/GL setup/context, audio output, basic UI stuff for some selectors, querying a key...
I don't say any of those OSs is superior, this just makes no sense ... and it doesn't even matter. What I really want is that it doesn't matter on which OS you work on a project but it still runs everywhere.
Final thoughts: I don't see much value in Linux-only demos, but I see it in cross-platform demos. Yep, sure, the Windows-only-guys need to switch to OpenGL and 4/64k demos will be a lot larger on OSX/Linux, but does that matter? (And one can still do _full_ releases for OSX/Linux (i.e. shipping all needed libraries))
Quote:
the real problem is that most ppl don't realize that writing software in a OS specific manner is a bad idea nowadays.
That is not a problem at all, since Windows has a huge marketshare that completely eclipses everything else. Windows demos are accepted at every party, and if people want to run it on real hardware, Windows is by far the largest group.
Writing an OS X/linux demo isn't even practical, if you want to enter a compo.
Having said that, most of the OS X/linux demos out there are actually written as you say: a simple framework to abstract the OS-specific differences, and then compiling for Windows, OS X, linux, and often various other platforms as well (BeOS, GP2X, etc).
Quote:
Quote:Crystal Dream worked with GUS
No, it didn't. Crystal Dream 2 did, though.
You're absolutely right, my bad.
Quote:
Yes it does. A lot. And I am speaking as someone who is still using OpenGL on Windows. Yep, sure, the Windows-only-guys need to switch to OpenGL and 4/64k demos will be a lot larger on OSX/Linux, but does that matter?
I've written code at least on DOS, Amiga, Commodore 64, Linux, OS X, J2ME, Windows, iOS and Android and when I'm doing stuff at home, I couldn't care less if my code doesn't run on an operating system or hardware of your choice. Sure, it can be done and abstracted away nicely and all that, all down to optimized window creation stuff for each platform and proper handling of endian issues on a SPARC architecture, but assuming I have few hours a week for hobby coding, that's the very least concern I have. To me, demos are a method of self-expression and a technical playground, and I can either spend my time working on an engine or a great system or whatever, or then I can spend my time coding.
Also, the dev tools on *nix flat-out suck compared to Visual Studio.
Quote:
the real problem is that most ppl don't realize that writing software in a OS specific manner is a bad idea nowadays.
Why is that?
Quote:
Also, the dev tools on *nix flat-out suck compared to Visual Studio.
QtCreator is imho actually quite nice, though.
Algorias, do you have an email?
Quote:
QtCreator is imho actually quite nice, though.
Nice but still not quite as good as VS + VAX, sadly. But usable with VS keybindings. ;)
CodeLite is supposedly useful as well, haven't tried it yet, though.
Quote:
Yep, there might be some troubles in the beginning, but it's a minimal price to pay.
And if you read a bit more of the thread, the trouble comes back after a few years when your demos automagically stop working. While the majority of Windows demos still work without problems.
Quote:
It is, compared to alternatives. Not that useful for demos though :)QtCreator is imho actually quite nice, though.
Coding for Windows, OpenGL, Nvidia, with Visual Studio, seems to be a sweet spot currently. That combination has a very high fun vs bullshit ratio. If you can tolerate the word Microsoft. I have an Intel+Nvidia+Windows PC built specifically in order to have the most common bulk mainstream system. The only bad thing is, no ATI compatibility, but caring about that would significantly decrease the fun/bullshit ratio. Speaking of which, Outline is coming and they are Nvidia compatible, so ---> on to making my next compofiller.
Quote:
Coding for Windows,OpenGL, Nvidia, with Visual Studio, seems to be a sweet spot currently. That combination has a very high fun vs bullshit ratio.
Yes, that's what the scene in general thinks, since ~1996 or so.
Lasse Reinbong is one of the first Windows prods, you should read the accompanying text file:
Quote:
Q: Why does $eeN port the old ¯Lasse Rein B”ng® Intro to windows95?
A: Well, I read a lot of stuff in the comp.sys.ibm.pc.demos newsgroup
why it would be never possible to write a demo/intro under windows95.
(Same applies for DEMO.GER (fido echo in germany))
Heh
Quote:
Quote:the real problem is that most ppl don't realize that writing software in a OS specific manner is a bad idea nowadays.
Why is that?
I'm more or less talking about real applications here, not demos or private stuff. Why release an application on Windows alone when you can have OSX, iOS, Android and Linux? (Sure, Windows has ~89%, OSX ~10% and Linux ~1% in desktop market shares, but *nix has ~100% mobile market share).
Also (as I'm much more active on the audio side) why should I release a VST only for Windows when the most professional music stuff is done on OSX and I'm only using Linux?
Quote:
Quote:And if you read a bit more of the thread, the trouble comes back after a few years when your demos automagically stop working. While the majority of Windows demos still work without problems.Yep, there might be some troubles in the beginning, but it's a minimal price to pay.
This heavily depends on what stuff you link against and how you package your stuff. And e.g. especially 4k demos from the XP era don't work on 7 without repacking, so there's also a bit work involved ... and don't forget the special dxXX.dll that sometimes need to be copied around ...
neet: Now you're changing the argument. The explicit context of this thread is demo coding. Your fart cushion apps are totally irrelevant.
Quote:
neet: Now you're changing the argument. The explicit context of this thread is demo coding. Your fart cushion apps are totally irrelevant.
... yep, and politeness doesn't seem to be relevant to you.
And the explicit context of this thread is 'the scene's opinion on GNU/Linux'. There's more to demos than just coding (speak music and graphics). So the cross-platform stuff still makes sense.
But nvm, I will never return to Windows for coding as long as I don't have to built Windows specific stuff ... I'm happily getting paid for doing cross-platform development using my beloved Linux :-D
Quote:
Perhaps the linux loving part of the scene could even standardize on some libraries with specific version as a platform, revising it every few years.
Sucks. What I prefer is the following scenario: I have a vanilla OS installation (+ standard drivers), I pick a random intro for that system and it WORKS.
Sure, I know that this is not the case for a lot 4k/8k/64k intros out there, since somebody decided to allow some certain Windows libs in 2005. Hopefully these libs will be disallowed sooner or later.
I would totally hate to introduce something like "you have to install these packages for sizecoded intros". Installing a vanilla OS with default packages is OK (and well, than you get the linkage hell thing I mentioned before), installing additional libraries is a total NO GO, since that's something you should get rid of, instead of introducing it...
Quote:
Why release an application on Windows alone when you can have OSX, iOS, Android and Linux? (Sure, Windows has ~89%, OSX ~10% and Linux ~1% in desktop market shares, but *nix has ~100% mobile market share).
Sounds like an excellent case for releasing demos on YT! YT works everywhere! Even on many dumbphones!
ohh scali, mah nigga
neet: No, that's the *subject* SilverSlimer chose. His *post* on the other hand is about demo coding. And yes, you're right, I don't care much for being nice to trolls.
Quote:
neet: No, that's the *subject* SilverSlimer chose. His *post* on the other hand is about demo coding.
Must admit you're right with this, but this doesn't change anything for you as you already made up your mind^^
Quote:
And yes, you're right, I don't care much for being nice to trolls.
Sure, already got that, but I don't really care. You're just some other random guy on the internet who I don't know nothing about ... and I don't want to change that (same over there I think).
So, hf :-) ... I've said what I wanted to say^^