[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