The scene's opinion of GNU/Linux
category: code [glöplog]
I think Scali's last post points to the conclusion of the subject. Linux and demos can go together, as long as you distribute the sources. If you want to keep your code secret, then Windows is your thing. Trying to spread Linux demos as binaries is a flawed idea, unless you provide the entire distribution as well.
Live CD demos! :P
I admit Linux is better than it use to be. But, like some coders point out before... I like coding, I can spend time reading hardware or SDK documentation, but if I have to start reading how to configure or install packages to make something work... then you can lost me easily.
I was doing demos on GP2X... I knew the platform was death but I felt.. who care? I knew that most people might just look to the Youtube video... because it's more convenient. But... during the party and some fans... will take the time to check it on the real hardware.
I think making a cool demo it`s not about the platform but end up to be about taking time to get some quality releases... Your first demo might be a disaster, but after a few, you start to have more stuff ready to create them faster... also the artist might be more recognize for their style and more and more people might follow you...
We know LFT, C64/Amiga/Amstrad/... demos groups... not because they did an amazing Win32 demos.. but because they did something amazing on what they liked!
I was doing demos on GP2X... I knew the platform was death but I felt.. who care? I knew that most people might just look to the Youtube video... because it's more convenient. But... during the party and some fans... will take the time to check it on the real hardware.
I think making a cool demo it`s not about the platform but end up to be about taking time to get some quality releases... Your first demo might be a disaster, but after a few, you start to have more stuff ready to create them faster... also the artist might be more recognize for their style and more and more people might follow you...
We know LFT, C64/Amiga/Amstrad/... demos groups... not because they did an amazing Win32 demos.. but because they did something amazing on what they liked!
Quote:
Trying to spread Linux demos as binaries is a flawed idea, unless you provide the entire distribution as well.
SteamOS may be an option though.
Steam is a platform that distributes games in binary form. We have yet to see how it will hold itself in the future, but it is likely that Valve will try to keep the system as consistent as possible. Otherwise, everytime the OS is updated, people need to re-download their games as well.
So ideally SteamOS should be as stable as a binary platform as Windows, OS X, Android etc.
If Valve manages that, then closed source linux demos could become a viable option.
SteamOS should also come with a good collection of pre-installed graphics and audio libraries, which can also be useful as a target for intros.
Quote:
Trying to spread Linux demos as binaries is a flawed idea, unless you provide the entire distribution as well.
Or via a signed repo at least.
Anyone running an unknown shell script or downloading and running binaries from an "unknown" source (as with most oses) is probably looking for trouble.
Steamos seems like a good idea, let's see if it pans out.
Quote:
Most demosceners like to keep at least some of their routines a secret, after all, it is a competitive arena.
Is that really true, I wonder? I think that's one of these Things That Everyone Knows About The Scene that no-one's actually questioned since the 90s.
I suspect that most coders don't give a crap either way, and their code only stays closed because the value of opening it up is not worth the effort of cleaning it up, taking out the nasty hacks and demo-specific data and repackaging it in a way that's usable and understandable to other people (and inevitably having to give those people free tech support for ever afterwards). In most cases, there's absolutely no demand for it: if someone writes a really good particle engine, say, then the other people capable of using that code will probably find it much more fun to write their own, rather than decipher someone else's code. On the other hand, stuff that *is* designed to be re-used, like compressors, intro frameworks and synths, generally does get shared.
I would be genuinely interested to hear someone prove me wrong here. Go on, somebody step up and say "actually, yes, I do have routines that I keep secret to give myself a competitive advantage".
@gasman: one reason for keeping routines secret (at least on the 8/16-bit platforms) is to see if someone else can figure it out rather than having a competitive advantage, as the routine has already been used once
Quote:
"actually, yes, I do have routines that I keep secret to give myself a competitive advantage".
at least for some years. And that's very common, even with closed source tools.
If you opensource, this happens. Don't do it.
At some point I just stopped caring and started publishing the sources with every blurb. It's not like there's any secrets there. Being ashamed of the messy code and "borrowed" snippets are some probable reasons for keeping the source closed.
This might happen if the source is available.
Quote:
@gasman: one reason for keeping routines secret (at least on the 8/16-bit platforms) is to see if someone else can figure it out rather than having a competitive advantage, as the routine has already been used once
That too.
Looking at it from the other side... I am not interested in source code anyway. I think part of the fun is figuring out how someone else has done a certain effect, and then trying to do even better yourself.
I do value descriptions of effects or tricks, but I don't want to be spoonfed the actual code.
Eg, I really liked reading Mahoney's paper on the 44.1 KHz sample playback on C64, and it's fun that he doesn't give up all his secrets. He just presents the basic idea, and then you can craft your own code with it, and figure out ways to use this trick.
I do the same thing... I blog about basic ideas and tricks I do (such as subpixel-correct lines/polygons on Amiga blitter, or the various hacks used in 1991 donut), but I don't give out source code. Perhaps "competitive advantage" is not the right term, but I do like to see others figuring out how my stuff works, and improving on it.
Having said that, portability is not an option with my code anyway. I mean, code that manipulates the Amiga blitter... that's not going to work on any other hardware.
Likewise, my MS-DOS stuff manipulates EGA registers and timers directly. Useless in any modern protected mode OS. As I already said before: my stuff can't be ported to linux anyway.
Likewise, my MS-DOS stuff manipulates EGA registers and timers directly. Useless in any modern protected mode OS. As I already said before: my stuff can't be ported to linux anyway.
Quote:
If you opensource, this happens. Don't do it.
Yeah, that is one of the major problems. That's also a reason why there are so damn many libs and so few and very thin front-ends. This way you can build applications based on libs which themselves are "software" as stated in their licenses and don't have to adopt the license to your front-end. you have to deal with API changes and stuff yourself then which for a demo would mean: provide fixes regularly for all the distros you support and stuff.
source code distribution is also actually no way to overcome the problem, since even the source has dependencies on lib APIs. a function gets an additional parameter? fucked... ofc everyone can fix it with the right knowledge and skills, but these problems accumulate over time, and one day your code might not even be compilable with a recent version of gcc/clang/make/whatever. actually the same happens on windows and mac as well, but regarding api changes they are both much more stable. prolly the only *nix system i ever used that is as stable in these regards is FreeBSD.
Quote:
source code distribution is also actually no way to overcome the problem, since even the source has dependencies on lib APIs. a function gets an additional parameter? fucked... ofc everyone can fix it with the right knowledge and skills, but these problems accumulate over time, and one day your code might not even be compilable with a recent version of gcc/clang/make/whatever. actually the same happens on windows and mac as well, but regarding api changes they are both much more stable.
Indeed, source code has a lot more dependencies than binaries. I often run into code that only works on certain compilers, or certain versions of compilers... Or you need to link against libraries that are very difficult to find. Or makefiles for a different flavour of make... etc.
As long as libraries have a stable binary interface, binaries will continue to work for a LONG time.
API functions getting additional parameters is a deadly sin. People who do this should be shot. Say what you want about Microsoft, but they keep their interfaces perfectly stable. If they want to add extra parameters to a function, they will introduce a *Ex() version of the function, while the old version remains available.
And with COM, they just support multiple interfaces side-by-side. You just query the one you want to use.
Quote:
Quote:@gasman: one reason for keeping routines secret (at least on the 8/16-bit platforms) is to see if someone else can figure it out rather than having a competitive advantage, as the routine has already been used once
That too.
Looking at it from the other side... I am not interested in source code anyway. I think part of the fun is figuring out how someone else has done a certain effect, and then trying to do even better yourself.
I do value descriptions of effects or tricks, but I don't want to be spoonfed the actual code.
Your approach is fine of course, but not everybody does write-ups of their effects (it's even more work after all). So the downside is that (semi-)newbies are prevented from learning and advancing their skills by having a look into actual code from a pro (source cleaned up or not doesn't really matter). I consider this a missed opportunity: Scene is dying, lack of new blood and so on...
The way you get a competitive advantage is: spend hours, hone your skills, do teamwork, produce with taste, don't accept crap. Sure, if you've just come up with some cool new optimization tricks, maybe you don't want to show them right away, before using them a couple of times first. The most important question is, how to invent something cool, and having someone's sources isn't going to hand the stuff to you on a silver plate.
Quote:
So the downside is that (semi-)newbies are prevented from learning and advancing their skills by having a look into actual code from a pro (source cleaned up or not doesn't really matter)
At least on 8/16-bit platforms it's still easy to have a look at the code, if you really want to :)
Quote:
Your approach is fine of course, but not everybody does write-ups of their effects (it's even more work after all). So the downside is that (semi-)newbies are prevented from learning and advancing their skills by having a look into actual code from a pro (source cleaned up or not doesn't really matter). I consider this a missed opportunity: Scene is dying, lack of new blood and so on...
I think it's a catch-22: if you're too newbie to learn basic democoding skills by yourself, you're also too newbie to be able to understand code from 'pro' democoders.
Us 'old guys' have all taught ourselves as well... and we didn't have the luxury of the internet, Google and all that. We did fine.
These days it's already a LOT easier to start demo coding, because there are tons of resources around (and my blog also links to relevant online tutorials, e-books and other resources).
I think most people don't release code because of competitive advantage, but just due to the amount of effort it takes. Also possible embarrassment.
Here, I share with you our latest demo, not yet released:
http://pastebin.com/hrnqdeEf
happy? :-)
http://pastebin.com/hrnqdeEf
happy? :-)
navis: some of your comments are spoilers!!! ;)
at least the comments are not in Spanish or French or even worst Greek!! (same for variable names) :-)
i kinda respect being able to even finish a project where the code looks like that
Wow, Navis has even conclusively resolved the tabs vs spaces debate!