On Wed, 2015-08-26 at 09:05 -0700, Dirk Hohndel wrote: > Some of us have expressed our dismay with the way distributions work > these days. Well to be honest such dismay comes usually always from the same fraction within open source... which is typically exactly that fraction which tries to put more and more control over what the user does and what he (should) want.
Quite often this fraction styles itself as the "modernists" which allegedly bring fancy and blessed technology to opensource, like cloud. And also quite often, what this fraction pushes for is in reality a major step back, security wise, and especially when it comes to longer term questions of freedom of users. That being said, the way distributions work is still considered by many (if not the vast majority) to be simply the way it should be. You may not get they hype with it as when you have a fully totalitarian ruled appstore with some fruit logo on it,... and you may not fully expose your user's data to all kinds of criminals and agencies, as when you put everything in the cloud or even worse run programs directly from there - but therefore you get a system based on proven paradigms which are amongst the main reasons why open source software is so successful and often simply superior. > > But let's get real here. We are not "hostile against core paradigms > of the > FLOSS community". Well but in fact you seem quite close to be: - You don't want distros to use the software as they wish (like using an old version, or properly using the system libs (as nearly all other projects manage to do)) so you even openly say that you work against distros shipping it. Doesn't sound quite friendly towards the community, does it? And even if you'd now argue again "well distros are conceptually broken and thus they're not the 'community' we wish - it still limits the freedom of users, cause shipping a program properly as part of a distro, even if upstream doesn't want that to happen, is still part of that freedom. Of course you can always argue like "People can just fork" or "the license still allows it", but that's merely a sticker of "we're free/open then", not real freedom/openness and thus it's quite obvious hostility against core paradigms. As I've said before,... it's the Oracle way of OpenSource, put a OSS license on it, lock out the community, fully control the whole lifecycle of the project and regularly step on all users toes. - You argue with the "user experience"... so basically, everyone who doesn't to as you define what the current experience is, should either stop so or for&rename. If all projects would behave like this, pushing their wishes trough regardless of other (whether majorities or minorities), we'd probably have millions of forks, and the whole idea of FLOSS would be dead. That's basically the GNOME/Mozilla way of open source, a la "we provide a product, like it as it is, if not, go away... and if we break with long standing and proven behaviours... either like what we give you go away,..." Well in the GNOME case many people went away ;-) which is why we have Cinnamon, et al. This kind of arguing (i.e. with the "experience" you'd need to protect for the sake of the users) is actually the most hostile part against FLOSS here. Below you complain that Debian shipped old versions (for which it has quite some reasons, i.e. the idea of stableness,... and which you as upstream probably provoked as well, by making subsurface more and more difficult to package, unless of course you're happy with providing an installer blow which ships at least parts of it's ext dependencies with it). Which version a distro ships is in most cases (there are some special exceptions) none of upstream's business. It's part of the freedoms one should get by FLOSS. What comes next? That one could argue "our products experience is destroyed if it's shipped in an non QT desktop environment"? Or "you must not change the maps provider e.g. to non-OSM-whatever, as it destroys the experience"? Will future versions of the binary subsurface have a internal update system that nags every 10 minutes to update, because they use a version which no longer matches the current experience? Arguing with the user experience sounds all to familiar to what evil greedy companies like MS/Apple/etc. do. Fully controlling everything, pushing out competitors or non-endorsed usage models... and all of course just "for the sake of their users". And yes, you're not doing this (yet),... but the way you argue is just that. Having the sticker of "GPL" attached to some piece of, code alone doesn't make it free yet - sure everyone could fork subsurface, but as said before this is more theory than practise. - Shall I continue? I guess not... > The catholic church had the crusaders, Islam has ISIS, the open > source > community has their extremists. Neither of those extremist groups > speak > for the whole community. You do not speak for the open source > community. > I don't either. Neither do I claim to do so. And neither did I. Yet we all know that some things are most probably beyond the paradigms and bad (well at least within some of those religions)...like beheading innocent people, or running a plane into a skyscraper. And one doesn't need to be the speaker for all to be able to realise this and it's still true even if god (which would probably be that Finnish PADI diver living somewhere in Oregon, in case of the kernel) would claim so. > I'm sorry we mislead you. Well I haven't said it was done on purpose... :) > I don't quite understand how we mislead you. I > don't quite understand how data in our open XML format is similar to > spending money on a DLSR - but I guess we have by now well > established > that we are talking past each other. Isn't it obvious? The DSLR company changes a major part of their systems (like you change subsurface from being reasonably distributable), like the mount and the electrical stuff there. I can no longer use my old but still good lenses on new camera bodies (like I cannot use my subsurface data in future Debians). Of course you can argue: "you have your open XML format, just convert it to whatever you want"... but while I can easily do it, not every user may have the necessary skills. It's the same with the cameras and lenses,... typically you can always find some way to mount older lenses on a newer camera,... but it's quite some effort and you always loose something (like functionality and/or quality). For the camera manufacturer, the misleading part would have been their promise that this is the new mount which is here to stay for decades to come (ask Olympus users, they know what I'm talking about ^^)... for subsurface it would have been the implicit assumption by common sense, that - unless otherwise noticed - it would behave like most other sane FLOOS project, e.g. not forking libs without renaming them... and not actively working aginst distros shipping it. > We have asked SPECIFICALLY Debian to stop providing an out-dated > version > of Subsurface to its users as that caused confusion and problems for > our > users and support burdon for us. Well I've already mentioned above that it should be none of any upstream's business which versions a distro ships and also which version a user has installed. Or would your users of your binary installers get into troubles when they don't want to update anymore? Of course, however, you're absolutely free to deny support for outdated versions... and point people to the distributor instead. I thought that would be normal and every end-user would understand this. > Debian was unwilling to follow our > choices of open source components that we used. "Unwilling" ... well if you put people obstacles in their way to follow proper policies o.O Plus you shouldn't forget that Debian *is* a community project, so even if you wouldn't have that issues with your internal library forks, it could still simply be a matter of manpower that the current version of subsurface wasn't packaged. > So we asked Debian to drop > bundling Subsurface since we provide a version of Subsurface which a > diver > who happens to run Debian and wants to use Subsurface can install. Well I guess most experts would probably discourage their users from doing so for compatibility and security reasons. > Here's the funny thing. There aren't a lot of options for a diver > looking > for a decent open source dive log. But there are a TON of options for > a > diver looking for an OS that supports her needs. And the numbers that > we > have clearly show that a tiny fractions of divers seem to think that > Debian is their best choice. And the audience for which Subsurface is > being developed is divers, not Debian maintainers. Well you still haven't told where/how you get your numbers from :-) As mentioned before, non of the divers I know (except for one single case) wouldn't even know what Linux/Debian/opensource or subsurface are and simply use the original software for their DC. And that single exception has some 15k of dives on his back and stopped logging like 10 years ago ;) > XML still is the default storage format. Ah nice :) Well that's basically the main reason why I joined the discussion, even if that part fell a bit low: Simply disabling the libgit parts may be a way for the Debian maintainers to keep up with an at least somehow "proper" packaging of subsurface. libdivecomputer could be counted as a special exception that is not separately packaged and maybe even statically linked... and the "main" libdivecomputer isn't used anyway by something else. So only subsurface-marble would be left as a problem maker. > The git backend was added in > preparation for cloud storage of dive data, which is in return one of > the > key features needed before it makes sense to have an Android > application. > > See, we are interested in what divers would like - and a full fledged > Android app has been very high on the list of things people ask us > for... > > And now I would have to tell people in the Android store "seamlessly > exchange data with Subsurface 4.5 on the desktop (except Subsurface > 4.5 as > shipped by Debian)". That's ridiculous. > Demand? I have politely asked to respect our wishes. I can't stop you > from > shipping a pile of dog poop and calling it Subsurface. All I did was > ask. okay then s/demand/wished/g > If by "properly packaged" you mean "broken and incompatible with > upstream" > then yes, you are right. Apart from when one would want to use the Android software and cloud functionality of subsurface - when exactly would it be necessary to be "compatible with upstream" (in the sense of fully up to date)? > They are screwed because Debian maintainers insist on removing > features > and refuse to accept upstreams choice of libraries we want to depend > on. So much for "you just wish" and "don't want to control"... o.O But seriously... I haven't read here that anyone of the former maintainers ultimately insisted on removing features. Sure they weren't all to happy with broken software design (i.e. internally forked libs) but there was that post from Salvo where he showed up a possible way when you'd have properly renamed your forks (yeah call it "branches" or whatever you like... effectively they're forks in this case). He said that "Debian, as a general rule, disallows duplicated source packages" but that doesn't mean that there can't be exceptions if there's good justification (even if there's no good justification - take the former situation with ffmpeg/libav). > They are more than welcome to use the packages that we provide - or > switch > to a more sanely run distribution. > > I'm talking to the Fedora maintainer right now about getting > Subsurface > packaged for Fedora 23. I'm kinda confused now... in the previously mentioned list post, you wrote that you actively work against making packaging subsurface within distributions, quoting: "we'd much rather have distributions drop Subsurface"... "in a way to intentionally prevent distributions from shipping Subsurface" Now you say you don't and distributions are welcome, as long as they're run "sanely"?! So it's basically just Debian which you don't want to ship subsurface and with RH/Fedora it seems to be possible to match their policies (and I'm sure they also have some policies about packaging)?! Honi soit qui mal y pense! Or does "sanely" mean for Fedora to have questionable code duplication and forking without renaming? Then good night poor Fedora ;-) > Actually I talked to Jef (the libdivecomputer maintainer) about this > and > we agreed that this should just be a branch of libdivecomputer, not a > fork. The repository from which you can get our version is named > libdc > instead of libdivecomputer in order to avoid confusion, but it's > still > just a branch in libdc - libdc master is the same as libdivecomputer > master. Ironically libdivecomputer is even hosted on my > infrastructure. To be honest I don't get it... why not just keeping both up to date as one with a stable API? At least if you're really as open as you claim, because wasn't this the idea of libdivecomputer? Having a generic and dive computer library and not just something for subsurface? Then distros could have used their system libdivecomputer, at most at the expense of some models not yet supported,... which, as I've mentioned previously, is a non-issue as new dive computers don't hit the marked weekly. Well long discussion,... thanks for it, but I guess I've lost all interest (aka holidays-mode: doing real dives is much better than arguing how to log them ;) )... so I'm out. Cheers and thanks for all the fish, crustaceans and see snails ;-) Chris.
