|
Dear all,
sorry it took long to reply to all the posting concerning the issue
of the linux version. I'd like to thank all that wrote about it
for many reasons, but principally for the level of subtle humour
instilled in many of the postings, a humour that I really appreciate
personally (in particular, I think the trademarking of version numbering
and the comparison of csound to the Java vs. Microsoft Java especially
funny - god if my mother knew I was being compared to Micro$oft...:-))
But, let's try to be serious now (change of face, trying hard to stop
giggles in the audience).
I will tell the story of the infamous linux distribuition. Sorry if
most of you know the story already. I'm trying to keep things clear
outside the realm of jokes and fun (which I appreciate and I deem
necessary to relax and enjoy life). Before that, let me state in the
clearest way I can with my poor english vocabulary that I really appreciate
jpff's work on the canonical distribution, his attempt on harmonizing
issues etc. I will underline this every time I can in this and in further
mails if they will occur. On with the story:
1) since version 3.33 (I guess), I used to cook my home-grown csound
at home on my linux system; I had to do that because the app would
not compile straight out of the box and needed some patching here
and there in order to compile and function properly under linux
2) funnily enough, out of necessity I had built my own set of Makefiles
which were using a variable called "PREFIX" (in contrast to GNU
configuring standards "prefix") which I could set to anything in
order to distinguish the old classic MIT csound version from the
bath version; at the time I used to set PREFIX=pc, so I would build
"pccsound". Since then, I dropped the MIT version and dropped the
prefix mechanism; it would be extremely easy to pick it up again
and use it - I propose to the people that is currently following
my distribution to set PREFIX="InfamousLinux" (ok, ok just joking :-))
3) personally, I am extremely lazy; so of course, the very first thing I
thought was that I would submit all my work to the list - and so
I did
4) up until very recently, I never got one single reply for these submissions
and I never saw anything coming into the main distribution; so what
I have done was extremely simple: I would simply re-apply all my patches
to any new distribution provided and we were all happy; PLEASE NOTE:
I don't imply here anything against jpff - I do really understand that
he is very busy and dealing with problems that are indeed more important
than having my home-grown version running at home and I don't blame him
at all for not responding: the list is very big and keeping up with
all things (distribution, submitters, book, documentation) is extremely
time consuming and technically very hard; another nice joke was
that one patch that I submitted that finally got the attention of jpff
was *wrong* (it was the one on Midi file reading, pretty recent) and
had to be corrected right away; if jpff's esteem in my intellectual
properties did not grow in this case, I can really understand him
5) around version 3.48 I got contacted by a number of other people that were
interested in my distribution and I provided them with these;
since the trend expanded, I asked AIMI (Italian Association of Computer
Music - a 100 or so members association that is active here in third
world Italy) if they could host my (later to become ours - in the sense
that it is not my anymore) distribution
6) AIMI kindly accepted (and I am very grateful to them) and I duly advertised
everywhere that this happened (sorry for double postings); sorry also
if some of you missed these posting
7) several others instead did not miss these posting and started using
this distribution pressing me (and everybody else using the distribution)
on some specific issues: in particular, use on csound some linux-GNU
specific tools like configure and CVS
8) I obliged to these requests, so since 3.482 there has been a packaged
distribution and an anonymous CVS repository, thanks to my friends
at Ax Digital who provided machine space etc.;
9) to provide some coordination mechanism, Damien Miller provided a mailing
list which was initially called csound-linux-dev@ilogic.com.au; the
name was changed to csound-unix-dev (as it is now) because some of
us felt that through linux and the GNU tools we could support other
unices - true, this was perhaps not a good choice and is potentially
misleading (needless to say, I am grateful to Damien for this and a
number of other issues he helped to solve)
10) that mailing list has constantly grown in size and members and the
contributions there are very specific to aspects of linux development
and distribution (and I must say, the contributions are very high-level
and I have learned a lot from them)
11) again, all of this has been always advertised everywhere and by all
means known to us; the proof of this is that we are (personally I am,
at least) very surprised of how well this system has worked up to now
End of the story. (Unfortunately I'm not finished yet...:-)
Since everybody here seems to have strong principles and live by it, I
will state a number of things so to make believe that I do too (unfortunately
I live in the difficult state of perennial doubt, instead).
a) two basic operation principles
1) release early, release often
2) if it's not broken, don't fix it
These are very much in use in the Linux community, and it's (fairly)
easy for us to stick to them. I even sort of like them and they
fit quite well with my idiosyncratic lazyness.
b) the infamous linux distribution *MUST* be backward-compatible with the
canonical one at all times; this means: it must not break orchestras
and scores that run otherwise on the canonical distribution. As I
understand, this is the main course meat in this discussion, so I'll
delve a bit into it:
1) of course, it is difficult to do
2) there are probably millions of orc/scos that break the
ilcsound (ill-csound?) distribuition;
3) I ask anybody interested in this matter to submit them to
to the linux mailing list and we (not me, all of us)
oblige the best we can and know
4) up to now, we have received very few of these, and fixed
them immediately (insomma, we have tried our best...)
c) given my idiosyncratic lazyness and the complete distrust I have in my
programming chops, it is much more easy for me to take sources as they
are from anyone who is submitting them; I usually refrain to impose
any change (tabbing, pretty-printing, *any* change) because I feel
that changed code will then have to be changed over and over again
and because of the respect I have for other programming people;
my interventions are thus limited in trying to resolve conflicts (and
this already takes up 150% of my allotted sleep time); I trust other
people programming chops much more than I do trust mine, and I am
really happy with that; this means that I usually stick to the original
version of the original writer and trust that if/when that source will
break, we'll squeeze our poor brains to the max in order to fix it
(thus abiding to principle a.2)
c) all sources *MUST* be *ALWAYS* available at *any* stage of development.
Save server breaks and hardware problems, this has always been the case,
and in fact, by several means:
1) ftp
2) anonymous cvs
I would like also other means, such as the various cvsweb clients,
bonsai/tinkelsomething or other etc. But I personally don't have
access to a web server (and am busy enough as it is): if anybody
wants to provide this, I urge she/he to contact us immediately and
we'll be glad to arrange it.
d) since c) pretty much works, the idea of submitting patches to the canonical
distribution is, IMHO, not the best possible; the canonical maintainer
has all the tools and the intellectual capabilities to decide for
her/himself when/how to integrate changes if necessary at this point;
I can, of course, submit patches in an agreed diff form at anytime,
whether privately or to the list, and will do so if expressly requested
to do so (the 'expressely' means that it is imposes a strong load
on mailing systems); it is reasonably easy for me to submit:
1) diff patches canonical->ilcsound and back
2) diff patches between versions of ilcsound
3) diff patches between version of canonical (that's the ones I use
to do merging and integration)
I would like to note that CVS allows to me but also anybody else
to build these diffs instantaneously and with the desired degree
of specificity: so anybody can run diffs as they please on any
or all the code. Also, CVS maintains almost automatically a ChangeLog
and posting to the appropriate mailing list so log changes in plain
english are also available at any time (they are even duplicate because
of a bug/feature of CVS, but I am about to fix that).
e) I am personally very happy that jpff is proposing his own version of linux
csound, which is probably far better than ilcsound, and urge anybody
scared to wade through infamous places to use that one; unfortunately,
it is now difficult for me to step back from continuing distributing
my version because of the number of people that constantly requires
the tools we have set in place; from now on, I'll stamp our version
with 'Infamous Linux', hoping that this will be clear enough (I
started using the name at the beginning of this mail, and I sort of
like it...)(I will do this personally, I don't imply that anybody
else has to do it)
Ok. I'm done. I hope this clears out some of the issues.
Thanks again to all of you. I really enjoy the humour and
the serious issues. In particular, I am really glad that Linux
is getting all this attention (I'm a bit embarassed too: there are
so many other fantastic operating systems...)
ciao ciao
Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
Re graphics: A picture is worth 10K words -- but only those to describe
the picture. Hardly any sets of 10K words can be adequately described
with pictures. |