Ubuntu-Studio-users Digest, Vol 32, Issue 7

[Robert Klaar]

One thing on the subjekt of standardise things that I would like to see is a
easy-acces compatible-hardware list, Maybe on the ubuntu studio homepage. As
of now all of this is spread across lists and forums and damned hard to find
to those not involved. I recently bought a new computer and tried to look
around for these stuff and I think I managed to put together something quite
nice, just a few major problems like that it freezes on network overload and
that I still don't know weither my firewire card works or not. .)

A list like this would get a more standardised platform for the US-user, I
think.
//Paco

On Mon, Dec 7, 2009 at 5:57 PM, Lindsay Haisley <fmouse at fmp.com> wrote:

> On Sun, 2009-12-06 at 23:57 -0500, Karlheinz Noise wrote:
>
> > > Also I read that we should look at the MACintosh to see how it
> > > works, because everyone in the industry use it for years, and it is
> > solid
> > > etc...
> >
> >
> > If you're making an A/V distro, it makes sense that you should know
> > what most A/V users use, and why they use them. Simple, really. And
> > why they use those tools really boils down to two things: ease of use,
> > and stability... which are intimately related.
> >
> >
> > > Well This is a little bit disturbing indeed, because, normally there
> are
> > > very few inputs to the DEV team. very few ideas and test cases etc. But
> i
> > > see a lot of people complaining. And this nobody can deny. Peple come
> and
> > > just complain, instead of describing the error or the feature etc.
> >
> > If a user is complaining, it means that you're not doing your job as a
> > programmer - simple as that. To everyone's credit, the usual response
> > is not "shut up," but "give me more details."
>
> Some people, and even one of my educated and computer-literate IT
> colleagues, don't get the difference between a bug report (or beta test
> report) and a complaint.  Getting these people past the point of just
> saying "such-and-such doesn't work" and leaving it at that is often a
> matter of education, and sometimes it ain't easy :-)
>
> > - A/V is unfortunately not very open source at the moment, so should
> > allow for easy installation of stuff that is not open.
>
> I heard someone once describe working with multimedia programming as a
> patent-infringement minefield.  Every step has to be made very
> carefully!
>
> > > The bottom line is that, by its very nature, F/OSS developers
> > > have _no_ responsibility to the end-user community, whatever that may
> > > be. None! Zarro! Zilch!! Open Source is developed in the context of
> > > a gift economy.
> >
> > This statement really surprises me, as it would also surprise
> > businesses like Sun or IBM (or even Microsoft, who are trying to get
> > into the open source game).
>
> Yes, it may well be in the interest of the likes of IBM and Sun to get
> into Open Source.  Enlightened self interest is an effective motivator,
> and these companies seem to get it with regard to the advantages of
> F/OSS software and how a thriving F/OSS community is important to the
> rest of their business.  The bottom line is still that the GPL and other
> legal trappings of F/OSS software don't imply a responsibility to the
> end user, and in fact just about all F/OSS packages contain a legal
> clause, quoted below, stating this fact in clear legalese.
>
> This in no way negates what I said.  If there is no contractual
> relationship between maker and consumer, express or implied by the
> exchange of consideration for purchase, then there is no obligation
> other than to do no harm.
>
> I recommend, if you haven't read it, Eric Raymond's "The Cathedral and
> the Bazaar" - the full book, not just the essay of the same name.
>
> > Leaving that aside, if you're not writing software for the end-user
> > community, why are you even writing software in the first place? Who's
> > supposed to use it, our future Martian overlords or something?
>
> Actually, some F/OSS software seems to be written for the benefit of
> other developers.  The community of people around a F/OSS project can
> get very in-grown.  The result is that the people involved are more in
> touch with what's clever and goes over well with their colleagues than
> with the end-user experience.  Their work may be more along the lines of
> proof-of-concept, or some such.
>
> There are a lot of programmers who aren't particularly socially skilled,
> and making the conceptual leap to look at and evaluate their work from
> the perspective of someone who knows absolutely nothing about the
> underlying software technology isn't always easy.
>
> This doesn't mean that they're not developing valid F/OSS software, nor
> that their work is inherently of no value.  Very often such work is akin
> to what's called "pure research" in the natural sciences - science with
> no, or very little practical application.
>
> Commercial software development is driven by market dynamics.  If you
> make it and it's not good, or not as good as the competition, or not
> properly marketed, it's a dead duck.  F/OSS software developers _may_
> look at end-user satisfaction as a goal, but there are no guarantees,
> and no requirement that they do.  Just about every F/OSS package out
> there contains the words:
>
> "THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
> WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
> BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND
> PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE
> DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
> CORRECTION."
>
> > > Often F/OSS software is
> > > written by geeks, for geeks, which is why some packages seem to be
> > > perpetually in a state of flux, or poorly documented.
> >
> > That's true in some cases, but it ignores something that should be
> > obvious: Idiot-proofing your software makes a programmer's life
> > easier, not harder.
>
> This is logical, and indeed should be obvious.  Writing good
> documentation should do the same thing.  Somehow, however, there seems
> often to be an inverse relationship between the ability to do good,
> creative programming and the ability to write decent documentation for
> it.  The same can be said about designing an intuitive user interface,
> or even intuitive APIs.
>
> > - It's pretty hard to tell people to RTFM if there's no F-ing manual
> > to read.
>
> Yep!
>
> > ...Okay, sorry for the long rant. Obviously I think too much about
> > these things. Have a good day, everyone.
>
> No apologies necessary, at least from my perspective :-)
>
> --
> Lindsay Haisley       |"Fighting against human |     PGP public key
> FMP Computer Services |   creativity is like   |      available at
> 512-259-1190          |   trying to eradicate  |<http://pubkeys.fmp.com>
> http://www.fmp.com    |       dandelions"      |
>                      |     (Pamela Jones)     |
>
>
>
> --
> Ubuntu-Studio-users mailing list
> Ubuntu-Studio-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-studio-users/attachments/20091208/16aa385e/attachment-0001.htm