| View previous topic :: View next topic |
| Which should be the default in Gentoo, ffmpeg or libav? |
| I prefer ffmpeg, and it should be the default. |
|
61% |
[ 199 ] |
| I prefer ffmpeg, but I am fine if libav is the default. |
|
4% |
[ 14 ] |
| I prefer libav, and it should be the default. |
|
5% |
[ 18 ] |
| I prefer libav, but I am fine if ffmpeg is the default. |
|
2% |
[ 8 ] |
| I don't care about the default, but users should have a smooth experience with it, even if that means additional hardships for those who choose differently. |
|
7% |
[ 24 ] |
| I don't care about the default, but it should be easy to use the non-default, even if that causes a less smooth experience for users of the default. |
|
11% |
[ 38 ] |
| I don't care either way. |
|
4% |
[ 14 ] |
| None of the above/Other (please comment) |
|
2% |
[ 7 ] |
|
| Total Votes : 322 |
|
| Author |
Message |
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
 Posted: Fri Feb 20, 2015 11:59 am Post subject: |
 |
|
| John R. Graham wrote: | Also, this implementation flies in the face of standard (and, in my opinion, reasonable) practise. From the Gentoo Development Guide:Conflicting USE Flags
Occasionally, ebuilds will have conflicting USE flags for functionality. Checking for them and returning an error is not a viable solution. Instead, you must pick one of the USE flags in conflict to favour and should alert the user that a particular flag is being used instead. The Gentoo ebuild philosophy on this topic has long been, "Make a reasonable choice, inform, and keep going."
So that brings us back around to the original question.
- John |
Please follow the direction of discussion.... its all in this thread so I am not sure why you cherry picked one part without taking consideration for the rest
| pietinger wrote: | Naib,
thanks for your clear conclusion ... but I dont understand why you need a third USE-Flag.
| Naib wrote: |
Now:
clear incompatibilities and technical reasons not to choose libav, a new USE flag created to "manage" the choice but it obtusified the issue. People read up on the issue and see that ffmpeg works so USE="ffmpeg" is natural and logical BUT libav is then pulled in because of the new USE flag *FACEPALM*
wouldn't it be more logical to
1) rename the present ffmpeg USE flag to say ... medialib since at the end of the day this is indicating that the user/package want to have media capability provided by another package
2) the ffmpeg USE flag indicates ffmpeg to be ... USED
2) the libav USE flag indicates libav to be ... USED
So:
USE = "-medialib" no media capability enabled in the ebuild: this covers: USE="-medialib -ffmpeg -libav" USE="-medialib ffmpeg -libav" USE="-medialib -ffmpeg libav" USE="-medialib ffmpeg libav #invalid but -medialib dominate"
USE = medialib would then require one of two USE flags
USE = "medialib -ffmpeg -libav" = EBUILD USE warning that the user needs to choose,set a flag
USE = "medialib -ffmpeg libav" = builds ok, pulls in libav and builds with that
USE = "medialib ffmpeg -libav" = builds ok, pulls in ffmpeg and builds with that
USE = "medialib ffmpeg libav" = WARNING!!! incompatible combination, the ebuild for ffmpeg and libav will themselves report a blockage.
|
If ... the USE-Flag "ffmpeg" would only pulls in ffmpeg and the USE-Flag "libav" would only pulls in "libav" you have only 4 possibilities:
1. if no one is set and an application needs one of them you get an EBUILD USE warning
2. you get ffmpeg
3. you get libav
4. if both are set you get the WARNING
Please correct me if Im wrong. |
| Naib wrote: | More for clarity. You are right this can be done with just two USE flags but the present method "is with two USE flags ... poorly"
The issue at present is the definition of the present ffmpeg USE flag, it is actually closer to a medialib USE flag thus, explicitly labeling it as a medialib USE flag in my example helps remove any ambiguity based upon present implementation (tunnel vision by some...) split that misuse and a lot of things become simpler and self-explanatory to the user.
OR even better drop the ffmpeg USE flag to provide a clear split
libff and libav USE flags |
| Naib wrote: | | pietinger wrote: | | Naib wrote: | OR even better drop the ffmpeg USE flag to provide a clear split
libff and libav USE flags |
This would be only a renaming and I dont like to check my Use-flags the whole time. BTW: I installed a new Notebook in Dec.2014 and didnt recognize that I have "avlib" instead of ffmpeg. I thought, with having the same Use-flags as I have on my PC I get the same installation as I have on my PC ...  (
So more even better: Drop the libav-Use-Flag !
If someone (like me) have it set, ffmpeg will be installed. If it isnt set and an application needs one of them, avlib will be installed ... |
Your case (and quite a few like it) are exactly why what has been done is wrong! ffmpeg is being treated as a medialib USE flag and libav is being treated as a BINARY libav OR ffmpeg USE flag (what if a 3rd library comes along)
IDEALLY libav is dropped
2nd best re-define what the ffmpeg USE flag means as right now it does NOT mean use ffmpeg *facepalm* |
| Naib wrote: | | khayyam wrote: | | Naib wrote: | There is the issue of why, in its present state, libav is available as it is - I still think it should be hard-masked until a few of what I listed is resolved: security, namespace at the very least...
There is a separate issue as to how to deal with this. LibAV is "special" as there is a gentoo dev associated with the split, but what if another project does this? Its bad form but clearly assuming civilised behaviour cannot be guaranteed upon |
Naib ... it should be hardmasked and/or removed and those responsible be given a stern warning that they have a responsibility not to create such situations for users. That's the problem here, users (and gentoo as a whole) are having to deal with the consequences of allowing developers to "do what they want" in violation of the stated principles of the gentoo charter: for the community, by the community. Users were not clamouring for libav and so have the 'choice' or one or other, nor would they expect such a choice would lead to a situation in which some package would build with one and not the other, or that they would have to abandon some specific app because the required lib can't co-exist (as libav is attempting, via namespace occupation, to replace ffmpeg). None of this is "for the community", or for the benefit of users ... it the very opposite. Fine, libav forked, they are now free of the shackles of MN's dictatorial rule, good for them, but for all of the repercussions of this fork to then effect users negatively, and for this to be played out within a distribution with the stated aim of being "for the community" is basically shameful.
This view is contested, somehow these effects were all unforeseen, or the outcome of developers trying to provide what users want ... well, I'll leave the reader to decide the truth of this. |
Those two sentences were more of a quick summary, especially as I have and others covered it. I agree basically was just trying to separate it out for the next part.
| khayyam wrote: |
| Naib wrote: | wouldn't it be more logical to
1) rename the present ffmpeg USE flag to say ... medialib since at the end of the day this is indicating that the user/package want to have media capability provided by another package
2) the ffmpeg USE flag indicates ffmpeg to be ... USED
2) the libav USE flag indicates libav to be ... USED |
The problem I have with this is that it requires changes (and so effects users) simply because developers need to sort out a problem that any rational person would have seen as an outcome of the path that was chosen. So, again, its the users getting short changed for a decision that was made without consideration of those users ... because developers "do what they want". If anyone should pay the price of this it is the developers who got us here, and they should be put in line and told in no uncertain terms on who's behalf they are working.
best ... khay |
Short term yes, rip it out of the tree, put it in an overlay. Thing is it won't, a gentoo developer is part of libav (how involve in the manner in the split... thats a ffmpeg political concern, hopefully not a gentoo, had too many such behaviours in the past re. exherbo) and as such it is useful for him to use his distro of choice and equally gentoo dev's seem to hold more faith in libav (http://article.gmane.org/gmane.linux.gentoo.devel/94686
So what todo if it will stay, if it is equally accepted that ffmpeg will stay.. what can be done to help the users ride through upstreams sandbox and gentoo's inaction over it (and yes its inaction because it shouldn't be in the tree in this state!) on the basis that their ABI continues to diverge but their API stays compatible. Either way the meaning of the ffmpeg USE flag is now wrong as the present labeling is closer to a medialib. Make it a USE flag for ffmpeg and help users that think the ffmpeg USE flag means use ffmpeg, its common sense |
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
Last edited by Naib on Fri Feb 20, 2015 2:32 pm; edited 1 time in total |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Fri Feb 20, 2015 1:05 pm Post subject: |
|
|
| John R. Graham wrote: | | Conflicting USE Flags |
This policy was practically dropped with the introduction of REQUIRED_USE whose only purpose is to violate the long-standing policy.
A reason for this is the ebuild code without REQUIRED_USE gets rather messy, since there is not such a thing like "if this and that USE-flag combination has been set, behave as if USE-flag X has (not) been set": Inside code, this is easy to handle, but inside *DEDEPEND/SRC_URI you must not use any code.
From the viewpoint of developers, REQUIRED_USE makes life much easier. For instance, if you want to set defaults (with gentoo tools, i.e. without the above mentioned feature), e.g. for choosing a default python implementation, your length of thr DEPEND/RDEPEND and possibly also SRC_URI strings would grow exponentially with the number of possible python interpreters for that package. Thus, practially, this is not handable without introducing the mentioned feature. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Feb 20, 2015 8:09 pm Post subject: |
|
|
| Naib wrote: | Please follow the direction of discussion.... its all in this thread so I am not sure why you cherry picked one part without taking consideration for the rest
..
Now:
clear incompatibilities and technical reasons not to choose libav, a new USE flag created to "manage" the choice but it obtusified the issue. People read up on the issue and see that ffmpeg works so USE="ffmpeg" is natural and logical BUT libav is then pulled in because of the new USE flag *FACEPALM*
wouldn't it be more logical to
1) rename the present ffmpeg USE flag to say ... medialib since at the end of the day this is indicating that the user/package want to have media capability provided by another package
2) the ffmpeg USE flag indicates ffmpeg to be ... USED
2) the libav USE flag indicates libav to be ... USED |
No. It's awful. If a package absolutely requires libav then we should provide a way for it to link with libav, without polluting the global library-space with libav, which is the badly-behaved lib, in that it tromps another lib's namespace incompatibly.
What you're missing is that the above would be required in any case, one way or the other, for your magic three flags to work.
It should not be a USE setting, since there is no option; it requires libav, or we wouldn't be discussing it. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Feb 21, 2015 6:17 pm Post subject: |
|
|
No to "medialib". A USE flag whose only purpose is to allow other USE flags to have any effect is bad design.
USE="libav" should enable libav.
USE="ffmpeg" should enable ffmpeg.
USE="ffmpeg libav" should ignore libav and enable ffmpeg on packages only allowing one at a time, as the opposite behaviour of installing a known-insecure library with less compatibility and hostile upstream is clearly a mistake nobody intended. You wouldn't default to OpenOffice if someone had a package with USE="libreoffice openoffice", would you? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Sat Feb 21, 2015 6:35 pm Post subject: |
|
|
| Ant P. wrote: | No to "medialib". A USE flag whose only purpose is to allow other USE flags to have any effect is bad design.
USE="libav" should enable libav.
USE="ffmpeg" should enable ffmpeg.
USE="ffmpeg libav" should ignore libav and enable ffmpeg on packages only allowing one at a time, as the opposite behaviour of installing a known-insecure library with less compatibility and hostile upstream is clearly a mistake nobody intended. You wouldn't default to OpenOffice if someone had a package with USE="libreoffice openoffice", would you? |
I believe I covered that... The 1st part that JG was referring to was more as an aid to describe THAT the present ffmpeg is more of a media lib.
About three times now I have stated that ffmpeg USE flag should enable ffmpeg, libav to enable libav...
NOT what we presently have which has ffmpeg more like a media lib ( hence what I was showing...)
So again...third time by my reckoning, which has been ignored. Redefine what mlffmpeg USE flag means, make it mean use ffmpeg, common sense
| Naib wrote: |
Please follow the direction of discussion.... its all in this thread so I am not sure why you cherry picked one part without taking consideration for the rest
|
| Naib wrote: |
Now:
clear incompatibilities and technical reasons not to choose libav, a new USE flag created to "manage" the choice but it obtusified the issue. People read up on the issue and see that ffmpeg works so USE="ffmpeg" is natural and logical BUT libav is then pulled in because of the new USE flag *FACEPALM*
|
| Naib wrote: | More for clarity. You are right this can be done with just two USE flags but the present method "is with two USE flags ... poorly"
|
| Naib wrote: |
IDEALLY libav is dropped
2nd best re-define what the ffmpeg USE flag means as right now it does NOT mean use ffmpeg *facepalm* |
| Naib wrote: | | Either way the meaning of the ffmpeg USE flag is now wrong as the present labeling is closer to a medialib. Make it a USE flag for ffmpeg and help users that think the ffmpeg USE flag means use ffmpeg, its common sense really... |
Some people need to learn to follow a thread rather than cherry pick to push their own agenda
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
Last edited by Naib on Mon Feb 23, 2015 7:42 pm; edited 1 time in total |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Feb 22, 2015 4:38 am Post subject: |
|
|
| Ant P. wrote: | No to "medialib". A USE flag whose only purpose is to allow other USE flags to have any effect is bad design.
USE="libav" should enable libav.
USE="ffmpeg" should enable ffmpeg.
USE="ffmpeg libav" should ignore libav and enable ffmpeg on packages only allowing one at a time, as the opposite behaviour of installing a known-insecure library with less compatibility and hostile upstream is clearly a mistake nobody intended. You wouldn't default to OpenOffice if someone had a package with USE="libreoffice openoffice", would you? |
Agreed.
| Naib wrote: | I believe I covered that... The 1st part that JG was referring to was more as an aid to describe THAT the present ffmpeg is more of a media lib.
About three times now I have stated that ffmpeg USE flag should enable ffmpeg, libav to enable libav...
NOT what we presently have which has ffmpeg more like a media lib ( hence what I was showing...)
So again...third time by my reckoning, which has been ignored. Redefine what mlffmpeg USE flag means, make it mean use ffmpeg, common sense |
Which isn't what you wrote above, and have been banging on about for the last 2 pages. |
|
| Back to top |
|
|
RayDude
Advocate
Joined: 29 May 2004
Posts: 2088
Location: San Jose, CA
|
| Posted: Mon Feb 23, 2015 6:01 pm Post subject: |
|
|
I've read through this thread and have a few comments.
1. Thanks for having a discussion on this topic. The conversations, despite the banter, is really healthy.
2. I've come to the conclusion that everything libav's devs have done to give birth to that library has been an insult to open software. They could have branched cleanly and kept themselves separate, but they are clearly doing the opposite of that, trying to take over an existing healthy project without concern for anyone but their own agenda and egos. They have an unhealthy attitude.
3. Personally I'm going to say "no" to libav and only use code that uses ffmpeg. I choose the healthy coders over the unhealthy ones. Perhaps if we all do that, the unhealthy code will die out. If a tool I use only has a libav option, I will find an alternative. And if more developers have this idea, then perhaps we can fork code that switches to libav and put it back on ffmepg. If we persistently and forcefully choose ffmpeg, then we can get things back in order.
Summary, "Just say no to LIBAV."
_________________
Some day there will only be free software. |
|
| Back to top |
|
|
yngwin
Retired Dev
Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China
|
| Posted: Tue Feb 24, 2015 6:13 am Post subject: |
|
|
| RayDude wrote: | | The conversations, despite the banter, is really healthy. |
I don't understand how you could come to that conclusion. I would say it's pretty toxic. So much so that I have become hesitant to take any further steps in the matter.
There seems to be a lot of misinformation and animosity towards just one of the involved projects. But things really aren't that black and white. It's a messy situation, and certain people here try to make things simple and lay all the blame on the fork. But both sides have made mistakes, and are continuing to let this mess fester.
From a technical point of view, libav seems the better choice, because of the cleaner code base and quicker fixes (this is also the main reason it has been the Gentoo default for years). But from an end-user point of view ffmpeg seems better, because they keep compatibility with older features around for longer, and merge in all the new features and fixes from libav. Current ffmpeg wouldn't be what it is without all the development work the libav devs have done on the code.
So I think both the blame and the praise should be spread much more evenly that what I see in this thread.
| RayDude wrote: | | Summary, "Just say no to LIBAV." |
Then you need to say no to ffmpeg too, because it takes a lot of code from the libav developers, thanks to the open source license which allows that. So you enjoy the benefits of the libav devs work when you use ffmpeg.
So please let's stop painting things black and white, because the situation really isn't that simple.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Feb 24, 2015 11:02 am Post subject: |
|
|
| RayDude wrote: | | The conversations, despite the banter, is really healthy. |
| yngwin wrote: | | I don't understand how you could come to that conclusion. I would say it's pretty toxic. So much so that I have become hesitant to take any further steps in the matter. |
Why do you feel it is "toxic"? All I see are people expressing themselves in simple, straightforward language, without playing one-upmanship games.
Much more refreshing than the posturing, misinformation, and plain ignorance that passes for discussion on the dev ML, let alone the culture of self-obsessed nastiness.
| Quote: | | There seems to be a lot of misinformation and animosity towards just one of the involved projects. But things really aren't that black and white. It's a messy situation, and certain people here try to make things simple and lay all the blame on the fork. But both sides have made mistakes, and are continuing to let this mess fester. |
Lots of vague in that sentence; and the animosity is simply the usual "let's not use this crap" because it is crap.
You shouldn't read it so personally, since that's just how people talk about software that messes up their lives.
| Quote: | | From a technical point of view, libav seems the better choice, because of the cleaner code base and quicker fixes (this is also the main reason it has been the Gentoo default for years). |
Oh dear. Form over function? IDK where to begin. Let alone "quicker fixes" which does not seem to have any basis in reality, from what everyone else is saying.
"It's about the results, stoopid."
| Quote: | | But from an end-user point of view ffmpeg seems better, because they keep compatibility with older features around for longer, and merge in all the new features and fixes from libav. Current ffmpeg wouldn't be what it is without all the development work the libav devs have done on the code. |
And current libav would not be what it is, without ffmpeg as project to do all the initial years of development in the first place.
| Quote: | | So I think both the blame and the praise should be spread much more evenly that what I see in this thread. |
I think you should stop playing a blame game, as well as letting go of your attachment to some idea of code as anything other than a tool.
| Quote: | | So please let's stop painting things black and white, because the situation really isn't that simple. |
Yes it is: your software as an end-product (ie: deliverable) is broken. Correct it, or get off the pot.
The reason it is broken is principally wish-fulfilment; as usual some dreaming dev has some wacky idea of "progress" and imposes it on all without even a by-your-leave, let alone any actual testing. I am still at a loss as to why the "developers" are so incapable of using their own tools; tools it seems users are more capable with.
It's not about what you think is clean or elegant; frankly none of us has time for that discussion, nor for the "developers" to take years to even begin to understand the basics of getting the job done, let alone the structure of "their own" distro.
This is our distro too, btw.
Feel free to ignore my points as you have done across threads consistently.
It just makes you look incapable of answering them, as well as rude and "toxic" as you put it. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6188
Location: Dallas area
|
| Posted: Tue Feb 24, 2015 11:39 am Post subject: |
|
|
| steveL wrote: | | Quote: | | But from an end-user point of view ffmpeg seems better, because they keep compatibility with older features around for longer, and merge in all the new features and fixes from libav. Current ffmpeg wouldn't be what it is without all the development work the libav devs have done on the code. |
And current libav would not be what it is, without ffmpeg as project to do all the initial years of development in the first place. |
I really dislike the unfounded assumptions here (ffmpeg wouldn't have improved without libav fork, etc)
Maybe it would, and maybe it wouldn't have, but either way doesn't matter. We have what exists.
The ones making improvements to libav could simply have applied their improvements to ffmpeg,
they simply chose to go the libav route and continue on with the toxic "we're better" arguments.
Steve is right, without forking from ffmpeg, libav wouldn't exist at least in it's current form.
And it's highly unlikely that if they wrote it from scratch that they would be anywhere near
the level of usability that they now enjoy. But they've also made choices that break backwards
compatibility, yes it's their choice to make. But with that choice comes both kudos and criticism.
They need to learn to deal with it and get their egos out of the way (something that seems to be a problem for many devs).
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Feb 24, 2015 11:52 am Post subject: |
|
|
| yngwin wrote: | | I don't understand how you could come to that conclusion. I would say it's pretty toxic. So much so that I have become hesitant to take any further steps in the matter. |
yngwin ... I don't see how such unqualified 'toxicity' as any relation to what should be done, your just placing the blame on users, making them a block on the path toward resolution, users are not at fault here, nor are they in any way the cause.
| yngwin wrote: | | There seems to be a lot of misinformation and animosity towards just one of the involved projects. But things really aren't that black and white. It's a messy situation, and certain people here try to make things simple and lay all the blame on the fork. But both sides have made mistakes, and are continuing to let this mess fester. |
You should qualify exactly what ffmpeg's mistake were, occupying libav's namespace? I don't see what ffmpeg could do in that regard, and that is the crux of the issue. The blame for this can be laid squarely at the feet of libav ... it was they who let that 'fester'.
| yngwin wrote: | | From a technical point of view, libav seems the better choice, because of the cleaner code base and quicker fixes (this is also the main reason it has been the Gentoo default for years). But from an end-user point of view ffmpeg seems better, because they keep compatibility with older features around for longer, and merge in all the new features and fixes from libav. Current ffmpeg wouldn't be what it is without all the development work the libav devs have done on the code. |
No, it was not "the main reason", there were political reasons relating to upstreams choices, and the fact that a gentoo developer was on the libav team can't be dismissed as playing some part in it. Also, is if was a decision based on "reasons" then why would Alex Ballier state that it occurred "without any kind of discussion"?
| yngwin wrote: | | So I think both the blame and the praise should be spread much more evenly that what I see in this thread. |
User don't care until these things start effecting them negatively, I'm fairly sure you can't point to a single user who at the time of the split was bugging developers to support libav. So, whoever's to blame it isn't the users, they played no role in this. That they are now pissed off about the whole mess is testament to how such things are not providing the best for end users ... and that is entirely the blame of developers. So, take that into consideration when evaluating how balanced this thread may, or may not, be.
| yngwin wrote: | | RayDude wrote: | | Summary, "Just say no to LIBAV." |
Then you need to say no to ffmpeg too, because it takes a lot of code from the libav developers, thanks to the open source license which allows that. So you enjoy the benefits of the libav devs work when you use ffmpeg. |
Which is a fallacious argument ... your making a positive in favour of ffmpeg a negative against them. Had they been like libav and not incorporated these changes than you could probably hold that against them too. Subsequent to the fork they should have simply thrown in the towel and done nothing, certainly not tried to maintain some ABI compatibility, or incorporated any changes from libav into ffmpeg.
| yngwin wrote: | | So please let's stop painting things black and white, because the situation really isn't that simple. |
Well, we're simpletons ... we see everything in black and white, knee-jerk at the least provocation and reach for the pitchforks.
| Dante Alighieri wrote: | | The hottest places in hell are reserved for those who, in times of great moral crisis, maintain their neutrality. |
.
best ... khay |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Feb 24, 2015 12:10 pm Post subject: |
|
|
| Dante Alighieri wrote: | | The hottest places in hell are reserved for those who, in times of great moral crisis, maintain their neutrality. |
Brilliant quote, thanks khayyam. Foresaw the whole "They came for the disabled, and I did nothing because I was not disabled.. They came for the gypsies.." |
|
| Back to top |
|
|
yngwin
Retired Dev
Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China
|
| Posted: Tue Feb 24, 2015 12:54 pm Post subject: |
|
|
| steveL wrote: | | Much more refreshing than the posturing, misinformation, and plain ignorance that passes for discussion on the dev ML, let alone the culture of self-obsessed nastiness. |
This is an example of why I ignore most of what you write, because you are the rude and toxic one.
| steveL wrote: | I am still at a loss as to why the "developers" are so incapable of using their own tools; tools it seems users are more capable with.
[...]
This is our distro too, btw. |
Then step up and do something about it! Or stop slinging mud.
Anyway, all this negativity is bad for my mood, and unproductive. I'm off to do something better with my time, since it sure feels wasted here.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Feb 24, 2015 1:54 pm Post subject: |
|
|
| steveL wrote: | | Much more refreshing than the posturing, misinformation, and plain ignorance that passes for discussion on the dev ML, let alone the culture of self-obsessed nastiness. |
| yngwin wrote: | | This is an example of why I ignore most of what you write, because you are the rude and toxic one. |
I just talk to developers like they're fellow users. They seem unable to cope with that; it seems to freak them out, disrupting their conception of themselves as "above" users, deserving of special treatment that I haven't got time for; nor do I respect that stance.
It's not been the one taken by any of the people I've conversed with who know wtf they're doing, including people way outside the Gentoo arena, which is a very small pond.
I appreciate you're only just starting to comprehend the mistaken ideas you've been labouring under for several years, but that doesn't make civil discourse rude or toxic.
Not sure if that is just because you are unable to deal with being talked to like any other user, like so many of your peers, or because you cannot handle unvarnished opinion, for whatever reason (which is irrelevant to the actual discussion, though may be relevant to your own personal growth, or not), or simply because you are upset that none of us have bought your line of "if you want us to engage, treat us special".
I don't much care, tbh; nonetheless you are out of line, afaic.
| Quote: | | Or stop slinging mud. |
Let's see what you are calling "slinging mud" shall we, and then we can reason as to whether it is in fact "mud":
| steveL wrote: | | I am still at a loss as to why the "developers" are so incapable of using their own tools; tools it seems users are more capable with. |
How is that inaccurate? It's perfectly simple to do things in an experimental overlay, and then bring in packages masked-for-testing if they are essential to startup.
What is so wrong with expecting developers to do what users do all the time? Aren't they supposed to be more competent than us at this sort of thing, not less? Why then should we accept all this reinvention of their own wheels, or rather pretend that it is anything else?
We won't get a better distro like that, just lots of politically-correct but absolutely politically-naive "developers" who are more capable at hype and propaganda, than boring old reliable code.
| Quote: | | Quote: | | This is our distro too, btw. |
Then step up and do something about it! |
I did, and do, thanks. Yet every time the reality is pointed out, all that happens is developers stick their fingers in their ears and go "la-la-la we're not listening, have some crap of an idea we didn't want to talk out properly, as that's too hard and means we have to correct our mistakes rather than pretend they're all divinely-inspired. BTW it's all your fault, so there."
If you mean "become a developer" then I'd simply point out that you do not know the history of the crap I've gone through with Gentoo politicking, leading to 3 solid days work being tanked for no reason, quite apart from all the wasted time dealing with bitchiness masquerading as individuality and so-called machismo.
And in no way do I wish to fall prey to the groupthink that pervades any group, especially not when it leads to bland acceptance of the kind of behaviour I've been subject to, so Lord knows what others have gone through.
I'm much happier just being a user; the work they were trying to recruit me for back in the day wasn't anything to do with writing ebuilds anyhow. So when it comes to tools to make Gentoo nicer, I don't need to be a developer.
Like I said, the developer culture makes it very hard for me to even consider signing-on.
And by not being a developer, I'm liable to be treated with just as much disdain as any other user, which gives me a much better appreciation of my fellow users, who are the people I maintain software for.
So all things considered, I'd rather be a user: not like I'd maintain ebuilds in any case, so no point. Sure I might add a few, but it's hardly something that's crying out for people. Your real issue is the lack of cohesion, down to woeful grasp of the value of notation.
| Quote: | | Anyway, all this negativity is bad for my mood, and unproductive. I'm off to do something better with my time, since it sure feels wasted here. |
Yes, I know the feeling; you can argue with a wall, but you can't reason with a developer who doesn't have any self-insight into what cognitive dissonance is all about. La-la-land sure would be a nice place to live, if it existed.
Thanks for wasting my time by not in fact considering any of the points put to you.
Maybe you could consider whether developers have had any role in leading to the toxicity you observe in Gentoo.
And no, it's not all down to me, as tempting as you clearly find it to scapegoat me, along with so many of your nasty brethren.
Good day. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6188
Location: Dallas area
|
| Posted: Tue Feb 24, 2015 2:15 pm Post subject: |
|
|
| steveL wrote: | | Maybe you could consider whether developers have had any role in leading to the toxicity you observe in Gentoo. |
+1
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Feb 24, 2015 2:21 pm Post subject: |
|
|
Sorry, should have said "it seems to freak some of them out"; the vast majority I've spoken with (at least the ones I don't have on /ignore) have no issue with it whatsoever.
The more recently they've joined, the less likely they are to be prone to that delusion, ime. It started to get better with the influx about 4 or 5 years ago, that I recall. |
|
| Back to top |
|
|
RayDude
Advocate
Joined: 29 May 2004
Posts: 2088
Location: San Jose, CA
|
| Posted: Tue Feb 24, 2015 7:24 pm Post subject: |
|
|
| yngwin wrote: |
| RayDude wrote: | | Summary, "Just say no to LIBAV." |
Then you need to say no to ffmpeg too, because it takes a lot of code from the libav developers, thanks to the open source license which allows that. So you enjoy the benefits of the libav devs work when you use ffmpeg.
So please let's stop painting things black and white, because the situation really isn't that simple. |
But that's my point. FFMPEG rolls in all fixes and changes. They are open to fixes and roll in everything they can to keep FFMPEG up to date. The libav guys are not playing nice. They have it in for the FFMPEG guys and it shows in their actions.
I don't know what you mean when you say that libav is cleaner code. Does that mean it has a better architecture? Even if it does, if it's developers are combative and uncooperative (which, by definition, they are) then why would I choose to support them?
If the FFMPEG guys were being combative I might choose neither, but I don't think that's the case.
_________________
Some day there will only be free software. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Tue Feb 24, 2015 7:42 pm Post subject: |
|
|
| RayDude wrote: | | yngwin wrote: |
| RayDude wrote: | | Summary, "Just say no to LIBAV." |
Then you need to say no to ffmpeg too, because it takes a lot of code from the libav developers, thanks to the open source license which allows that. So you enjoy the benefits of the libav devs work when you use ffmpeg.
So please let's stop painting things black and white, because the situation really isn't that simple. |
But that's my point. FFMPEG rolls in all fixes and changes. They are open to fixes and roll in everything they can to keep FFMPEG up to date. The libav guys are not playing nice. They have it in for the FFMPEG guys and it shows in their actions.
I don't know what you mean when you say that libav is cleaner code. Does that mean it has a better architecture? Even if it does, if it's developers are combative and uncooperative (which, by definition, they are) then why would I choose to support them?
If the FFMPEG guys were being combative I might choose neither, but I don't think that's the case. |
Politics aside for a moment and PURELY on the technical
Two libraries who aim to do the same thing (afterall one was a "fork" of the other)
- LibAV has alot more security concerns for ffmpeg
- ffmpeg api and abi is stable - while ffmpeg may sync api changes, they don't with regards to abi
- ffmpeg laid claim to the namespace that is now being polluted.
- More programs compile and function as expected with ffmpeg
Maybe in 6months, a year libav will prove itself stable and reliable enough to be "the default" but that time isn't now
it was politics that forced it as the default on the 1st of feb from a "prefered default" and only a "prefered" simply due to the fact it appeared 1st in a list an inevitable fact about lists...
Since when does politics win over clear technical issues (unless there are other questionable activities afoot).
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
RayDude
Advocate
Joined: 29 May 2004
Posts: 2088
Location: San Jose, CA
|
| Posted: Tue Feb 24, 2015 7:49 pm Post subject: |
|
|
I have used Gentoo since the early 2000's. I joined the forums in 2004 to get help.
Gentoo has always been a pain in the ass for me. Always. Whether it was glib updates that break EVERY FUCKING THING or the endless tail chasing of breaking dependency loops.
BUT ... AND THIS IS IMPORTANT. I FUCKING LOVE GENTOO.
And that's what this is about for me.
I don't care if everyone of you bastards hates me or each other. Hurt each other's feelings as much as you want. Duke it out in your nerdy repartee all you want. Just make sure my hobby doesn't go away and my frustrated fun with emerge -DNuvp @world is still here for years to come.
If I wanted my linux to be simple, I would install Ubuntu (I have for friends), but I like monkeying with code with ebuilds with gcc and portage.
But and this is also really important: when it comes to assholes fucking with my distro, like these libav dickwads are, I take it personally. Just like when the glib guy kept breaking backward compatibility. MAN THAT PISSED ME OFF. I wanted the gentoo devs to excise the asshole from our lives so we wouldn't have to deal with his entire lack of concern for his customers.
And that's what this is: the libav devs don't give a shit about us or our systems. They are putting millions of linux users through hell to play a political fucking game. If they gave even a small slice of shit for any of us or linux or gnu, they would set aside their petty problems and fucking find a way to work with the ffmpeg guys. OR AT LEAST DO A COMPLETE FORK SO THE REST OF US DON'T HAVE TO CHOOSE SIDES.
I cannot express how pissed off I am at this. It reminds me of the kernel dev (who's name I'll never remember) who quit the kernel because they consistently chose to support all cases instead of just the desktop users. I understand his frustration, but instead of finding a solution, he gave up. That's what the libav guys did. They fucking gave up and went to war instead of trying to find a solution, they made the problems MUCH BIGGER FOR EVERYONE.
It's exactly like what Russia is doing in Ukraine. They are fucking around so that all of Europe is going to be affected. To them its a political game, for the rest of us it's fucking war.
I WANT THE ASSHOLES from libav and ffmpeg to put their heads together and find a solution to their differences. I don't want to have to choose sides.
I just want my gentoo back in working order.
When you see people yelling, screaming and complaining at each other in this thread just remember that what you seeing is the outward expression of their inner angst. When someone calls you a name, attacks your ideas, presses your buttons, or is in general an asshole, it's almost always because he's hurting inside. This is my philosophy and why I don't take anything any of you say personally.
So: you dick wads can yell at me all you want, but please make my gentoo work, I LOVE IT!
_________________
Some day there will only be free software. |
|
| Back to top |
|
|
RayDude
Advocate
Joined: 29 May 2004
Posts: 2088
Location: San Jose, CA
|
| Posted: Tue Feb 24, 2015 7:51 pm Post subject: |
|
|
| Naib wrote: |
Politics aside for a moment and PURELY on the technical
Two libraries who aim to do the same thing (afterall one was a "fork" of the other)
- LibAV has alot more security concerns for ffmpeg
- ffmpeg api and abi is stable - while ffmpeg may sync api changes, they don't with regards to abi
- ffmpeg laid claim to the namespace that is now being polluted.
- More programs compile and function as expected with ffmpeg
Maybe in 6months, a year libav will prove itself stable and reliable enough to be "the default" but that time isn't now
it was politics that forced it as the default on the 1st of feb from a "prefered default" and only a "prefered" simply due to the fact it appeared 1st in a list an inevitable fact about lists...
Since when does politics win over clear technical issues (unless there are other questionable activities afoot). |
Thanks for this. I like facts.
_________________
Some day there will only be free software. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6069
Location: Removed by Neddy
|
| Posted: Tue Feb 24, 2015 7:54 pm Post subject: |
|
|
This is why I mentioned that libav needs to stop polluting ffmpeg namespace...
This split is political, the distro's and applications that are choosing libav over ffmpeg are doing so for political reasons (those staying with ffmpeg are equally doing it for political reasons but there are clear technical reasons as well)
If application-X *wants* to be libAV only, a non-polluted namespace works
If application-Y *wants* to be ffmpeg only, a non-polluted namespace works
If application-Z *wants* to work with libAV & ffmpeg, a non-polluted namespace works (a bit of work for them but well...)
With a polluted namespace, do all these three function? if the answer is no, hardmask it. its very simple. Also sort out the USE flag definitions...
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0; |
|
| Back to top |
|
|
RayDude
Advocate
Joined: 29 May 2004
Posts: 2088
Location: San Jose, CA
|
| Posted: Tue Feb 24, 2015 7:57 pm Post subject: |
|
|
| Naib wrote: | This is why I mentioned that libav needs to stop polluting ffmpeg namespace...
This split is political, the distro's and applications that are choosing libav over ffmpeg are doing so for political reasons (those staying with ffmpeg are equally doing it for political reasons but there are clear technical reasons as well)
If application-X *wants* to be libAV only, a non-polluted namespace works
If application-Y *wants* to be ffmpeg only, a non-polluted namespace works
If application-Z *wants* to work with libAV & ffmpeg, a non-polluted namespace works (a bit of work for them but well...)
With a polluted namespace, do all these three function? if the answer is no, hardmask it. its very simple. Also sort out the USE flag definitions... |
Which is why, as a political maneuver, I think projects that choose libav should be forked back to FFMPEG by people who care about linux and don't care about politics.
_________________
Some day there will only be free software. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Feb 24, 2015 8:15 pm Post subject: |
|
|
| Naib wrote: | | Since when does politics win over clear technical issues (unless there are other questionable activities afoot). |
I'm of the opinion that going through the developer quiz only to be rewarded a CVS commit bit and a red flag on all your posts is a questionable activity in itself.
One would almost certainly have a severe masochistic streak, excessively naïve sense of optimism, or ulterior motive to willingly submit to that. Most of the first two groups already quit and made their own spin-off distros.
Which leaves us with endless threads like this, where we're being told something's "better" for us just because some of its developers happen to have *@{gentoo,debian}.org email addresses. Sorry, I don't care how much "better" that code is, libav is full of holes - more than one kind of them. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 355
Location: usa
|
| Posted: Wed Feb 25, 2015 12:41 pm Post subject: My 2 cents |
|
|
Where was this poll 2 years ago when I became embroiled in my first 'discussion'?  Back then it was some kind of hush hush topic to try to ignore akin to udev->systemd.
| yngwin wrote: | | From a technical point of view, libav seems the better choice, because of the cleaner code base and quicker fixes (this is also the main reason it has been the Gentoo default for years). But from an end-user point of view ffmpeg seems better, because they keep compatibility with older features around for longer, and merge in all the new features and fixes from libav. Current ffmpeg wouldn't be what it is without all the development work the libav devs have done on the code. |
Ah yes, the holy Agile grenade campaign. That is really quite the list of high claims.
So we have this which was much of the early rhetoric from TomWij in 2013. That was my first involvement into the tar pit of what became a locked thread. I was so proud (not really).
I looked at the source during that time; watched libav mailing lists. Did anyone else notice the changes from the libav camp? I had to do this because both camps were claiming A vs B (aka myths, because both assertions can't be right), but libav seemed the most outspoken. Libav has also been the grandiose claimer of all things camp: stability, features, most secure, less bugs, the active code base route, etc. Coke, Pepsi.
This mindset in comparison to ffmpeg conveniently changes to suit (i.e. claimed less features and deprecation implies more stability and less hackish). At other times it was almost a parody of the old Python routine, claiming ffmpeg was dead while it rationally asserted it was not. So, in any case, I expected to see a lot from libav code.
I didn't see improvements, I saw style issues being restructured, most of which fall completely into the bike shed camp. None of which mattered at compile time. Where were all the actual improvements claimed then as part of the commit rights friction that started the split? I expected to see some professional mudslinging here, as dmr and Torvalds did.
Now, there is the today's overused term of re-factoring; to fit a style guide; method cleanup, remove redundancy, improve readability; finally to accommodate reasonable design changes and reliability. Those are the eventual (and often subjectively questionable) merits, when executed with care and discretion. But re-factoring != redesign even though too many abuse it that way. One of the main tenents is to NOT break pre-existing functionality (particularly w.r.t. all end users of a library). One of the main reasons for unit tests at 'legacy code'. And then there was what the libav folk were doing. Here's an alternate library and the group behind that split is insistent upon breaking API/ABI. The ffmpeg folks didn't suffer any regression issues trying to merge from libav during this warpath... 
And people question why the ffmpeg camp just deals with pulling libav as the new master when it's acting like the rebellious redheaded step child that just went all Baker crazy? Really? If the rest of the world had ignored libav entirely instead of immediately listening to the malicious rhetoric, they could have left them to obscurity (and had they merit, libav should eventually prevail). It reminds me very much of the abuses of udev. So the child ignores the parent (other than to cry foul of parental efforts) while it parades about and the parent does its best to quietly hold onto its continued efforts. The crux of the matter continues to be this claim that ffmpeg is adding new hacked sloppy functionality while libav is doing all the re-factoring housework for beauty and elegant design.
That'd be just dandy if there were no CVEs against libav. Honestly, if it was that bad, if there were truth to the claims; just quietly start over, do all the work of re-invention yourselves. Then you really could avoid attribution and all. I doubt you would have attracted the ire you did, if any.
Regarding that, it's open source. Borrowed code is the norm or there would be no libav. Referring to one camp faction of pulling from or pulling to yours as some kind of doggedly non-deserving is silly. What's really going on is hatred and lack of cooperation, even, sadly, apparently to today.
From a developer consumer of said product, do you realize how much this can piss people off in wasted time and effort? I won't even go into the which to contribute to aspect. How was any of this good PR? It's certainly not something I'd want my name ascribed to. Nothing says team player like having that associated on your C.V.
On the Gentoo user side, as you mentioned, a forced change occurred to the ebuild to make libav be the default versus prior. I was disappointed seeing how that decision was reached on the mailing lists. It caused no end of confusion headaches for some. A small change (condition order) in a virtual ebuild wrapper caused unnecessary work for end users, much like the systemd/udev fallout. The weak basis of which remained political, even to now, rather than issues of stability, function and features. If those claims were true, particular in 2013 as it were, where was the proof? How about now?
Libraries are for useful consumption, not breakage. You should leave ego at the door when you're involved with one and not go out of your way to pit thy consumer on the front of any (internal) war. The media industry business models are bad enough at end user abuse for monetary gain; we didn't need open source devs to add to that mix. Instead just return to focusing on the continued solution of implementation of common standard formats. That was the basis for Bellard's substantial ffmpeg project fifteen years ago; what was yours? Seemed like a power grab against the efforts and persona of Niedermayer.
This is the closest I've seen to all involved of having a clue. Life is short. Harmony towards a shared goal. You should continue with that focus rather than revert if you wish to avoid seeing possibly more seemingly vitriolic responses from others who haven't appreciated the outcomes. At the very least you should question continued modus operandi and motive.
Last edited by Navar on Sun Mar 22, 2015 4:14 am; edited 1 time in total |
|
| Back to top |
|
|
haarp
Guru
Joined: 31 Oct 2007
Posts: 535
|
| Posted: Wed Feb 25, 2015 1:29 pm Post subject: |
|
|
I'll make a summary so far.
Technical reasons:
Pro libav: slightly better code quality
Pro ffmpeg: everything else
Political reasons:
Pro libav: libav guys don't like ffmpeg guys
Pro ffmpeg: everything else |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
