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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users >
-- Ubuntu-Studio-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users
