[SC.LUG] Damian Parker Is Right !

Ian Molton spyro at f2s.com
Mon Jan 2 13:28:43 GMT 2006


Frank Mitchell wrote:
> Dear LUGs:
> 
> Yes obviously I arrived from the Windows Environment, like most people.

Most people, or most of use *here* ?

I arrived from the RISC OS community, many others here from the old 
AMIGA communities and so on.

> My reason for believing in Linux was a bit different though. It actually
> started with my B-Tree Code. First I discovered it could index many
> thousands of records on disk in the same time a Windows Application took to
> get started. Then I tried it under Linux and discovered that every Random
> Access operation took only 60% of the time it took under Windows.

Your reason for believing in it is similar to many other peoples. You 
discovered it outperforms the closed source competition.

> I have a different attitude to modifying stuff obviously. I looked through
> mkisofs and cdrecord, noticed the Authors didn't do things the way I would,
> and concluded this was undoubtedly the cause of the problem ;-).

Smiley noted, but I havent seen people having a major 'problem' with 
mkisofs / cdrecord... For the record, I've considered rewriting both X 
and cdrecord at various points. I researched it and didnt bother. there 
werent enough problems with them to warrant a rebuild.

 > Seriously,
> these programs have been worked over by a number of people who disagree
> about some fundamental issues. That can't be good.

As someone else pointed out, they have only a couple of maintainers, 
which results in clean code on the whole.

> I hate the whole business of adapting other people's Code anyway.

It takes some getting used to - I had the same trouble when I moved from 
RISC OS to linux - I actually wrote my own windowing toolkit under RISC 
OS, (although thats mainly because I wanted one I had the source to, not 
  through lac k of alternatives)

 > Surely these programs have got so big and complicated you can expect
> something to go wrong, and further changes could only make things worse.

Im not seeing massive numbers of people having trouble with cdrecord...

> CD Recording Utility of my own. So that's what I did. And if other
> people ever work on it I hope it never gets to be like mkisofs and cdrecord.

You mean secure, stable, and cross platform? You've noticed problems in 
writing cross platform code yourself already - thats why theres only one 
version of Trebus - you dont own any of those other platforms so you 
cant test it...

Look at linux itself (the kernel) that has to be the best example of 
*thousands* of people writing a piece of code - and as you stated 
yourself - if outperforms windows in almost every way.

> I haven't just reinvented the wheel. If you experiment with Trebus you'll
> discover it's entirely different from mkisofs & cdrecord. It performs
> genuine On-The-Fly File CD Recording without using an ISO Image.

Thats just not true - CD recorders simply write a stream of data. if 
that stream isnt an ISO image you dont burn an ISO compatible disc.

What I suspect you mean is that there is no way to get at the ISO data 
Trebus generates. thats not a feature, you've REMOVED a feature - 
cdrecord and mkisofs work together - mkisofs generates the stream and 
cdrecord burns it. if I want to I can intercept the stream, pipe it over 
a network, and run cdrecord on an entirely seperate machine - which I 
have done (via SSH) to back up an ailing machine whose CD drive had 
failed. Can trebus offer that flexibility?

You've made a classic windows-developer type error. You're trying to 
write a 'one program does it all' application. using multiple 
commandline tools allows far greater flexibility.

> Now just
> when I've got it working to what I regard as a Proof-Of-Concept stage,
> people talk about modifying it. For a Utility which is likely to be used for
> Backup, I regard that as premature.

Another classic windows developer error "I know what my users want 
syndrome".

Clearly your 'users' want to modify and mould your tool themselves. Dont 
tell them what to do with it! Perhaps some, or even most, will use it 
for backup, but what about the one that wants to embed the CD burning 
core into some PVR application? without the source its not possible.

the source YOU distribute can be exac tly what you THINK it should be. 
likewise, distribute binaries of that source if you wish. dont think 
about what people will do with your code - its up to them! just be happy 
that you made something people find useful - whatever they do with it.

 > First I want some User Feedback to
> establish there isn't some issue which needs fixing rapidly.

If it was open source you may very well have been sent patches for those 
bugs by now. And if you let users do what they like with the source, 
they tend to find new and interesting ways to break it - leading to your 
code getting fixed faster.

> Okay some people want to be able to adapt Source Code to their own needs.
> But as Linux becomes more popular it's attracting people who aren't C
> Programmers. They don't want to get a dysfunctional program with a
> suggestion to fix it themselves.

Duh. they are the ones that will download your binary and use it the way 
you expect. you can even put a big sign on your website (get one btw, it 
will improve your credibility) saying "clueless idiots use this version"

> They want it to work, understandably, and
> if it doesn't they'll pester the original Author. That's the experience of
> Joerg Schilling and Peter Anvin. They get contacted by Users from all over
> the World complaining about some version of their Software which wasn't
> released in the form they intended.

And its happening now - you're getting pestered by people asking you for 
the source! you cant please everyone, but I really dont see the harm in 
you distributing both sources AND binaries... who does it inconvienience ?

> So there's the problem: One person's Useful Modification can cause trouble
> for somebody else.

You're the maintainer - you get to chose what patches make it into the 
'official version'

 > And if it gets Redistributed as Open Source allows, the
> Original Author will get alot of flak from the many people World-Wide who
> aren't C Programmers. You can't please everybody.

Actually, those people arent very vocal. they tend to try stuff and give 
up if it doesnt work instantly. Anyway - open source licenses typically 
do allow redistribution, but that generally doesnt happen in the sense 
of a 'fork' of a project - good maintainership tends to prevent forking.

redistribution in terms of distros just means more BINARY versions out 
there than you could ever hope to get by spaming LUG mailinglists...

> Probably you expect to be reassured that I'm not a Virus Writer very
> shortly,

I dont think you're a virus writer, but why should I bother to find out? 
mkisofs/cdrecord havent let me down yet, I have the source, and they 
offer me more flexibility than Trebus does at present.

 > and you don't believe I'm too incompetent about MMC either.
> Otherwise you wouldn't urge me to participate in the cdrecord project.

I havent a clue how much you know about MMC. apparently enough to write 
a CD burning application. It matters not to me. If your patches to 
cdrecord are good, they will be accepted. if not, they wont.

-Ian



More information about the SC mailing list