Draft Product Description for Fedora Workstation
lists at colorremedies.com
Sun Nov 3 17:28:55 UTC 2013
On Nov 3, 2013, at 7:10 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Christian Schaller wrote:
>> And I think that will be the crux here too. To me the main part of
>> 'supporting' something here will be in handling our ABI story better, not
>> about writing custom work arounds for various 3rd party software.
> That still implies shipping legacy libraries and sometimes even withholding
> upgrades (kernel, X11 etc.) and is thus still an unacceptable burden to
> commit to.
>> There are of course many aspects to the ABI story, but one technology I
>> think will be an important part of improving this is the LinuxApps
>> proposal from Lennart Poettering. He did a talk about it at GUADEC which
>> you can find here:
> Ewww! As I wrote in another thread, this would be a HUGE step backwards.
> What we have now is:
> * a free-of-charge repository with central QA ensuring that everything works
> * a commitment of that repository to ship only Free Software and active
> auditing to ensure that,
> * client tooling automatically resolving dependencies, avoiding the need to
> bundle libraries (see also
> * ergo, an installation procedure of "fire up 'Apper (Software Management)',
> enter the package name or some search terms or browse the categories for
> the package, click Install, confirm, (enter root password) (*), use the
> application", as user-friendly as it can get.
> What we would have in an "app" world would be:
> * every upstream attempting to distribute applications themselves, forcing
> users to hunt down their websites one by one to get software,
> * no control whatsoever over licensing, not even a way to check that what
> claims to be "open source" really is (our auditing has found all sorts of
> licenses with bad terms, bundled code under non-free licenses, etc.),
> * giving more viability to all sorts of payware models and the proprietary
> license restrictions (no redistribution etc.) that are usually used to
> enforce payment,
> * massive bundling and the resulting disk space and security issues.
> We DON'T want Apple-like "apps"!
Right, because that's a model for success that shouldn't be either emulated or improved upon, it's better for each little fiefdom's paradise to erect walls to ensure cross influence isn't happening.
And that word we you keep using? I don't think it means, what you think it means. Try to find the huevos to use the word I, seeing as that's what you mean.
What you're arguing for is no one should like, or should have the choice of liking let alone having "Apple-like" apps, or better. Yes, let's have no choice for apps that are sometimes complete blackboxes, that run contained from each other, from a monostore that collects a perpetual 30% finder's fee, and also no options to improve upon this model without the tie in.
You're proposing a continuation of the adolescent state of Linux on the Desktop with its barriers to growing the market. Yes, let's build artificial walls keeping out new users and developers who don't agree with the existing community worldview who might, duh, change the platform to meet their needs. That's just too scary.
Essentially all you're arguing for is a different version of closed that just so happens to cost no money. OH WAIT, OS X is now free! So in reality it's just a different take on closed. That's not innovative.
Making it easier for free and non-free apps to actually work on a platform isn't going to kill it. It's like fertilizer. Instead of advocating platform sabotage as your comforting pacifier, how about you just not use, support, or advocate whatever apps you don't like for whatever subjective reasons you don't like them?
Know what I want? A platform that works. A platform that has apps I want to use. A platform that isn't poking developers or users in the eyeballs when they want to do something unique, innovative, necessary for their own success. If Adobe were to want Photoshop on a linux desktop, I think that would be great news. It would be hugely disruptive.
More information about the devel