On Tue, 2015-08-25 at 17:55 -0700, Dirk Hohndel wrote: > Being called stupid and arrogant is usually not a great conversation > opener, but hey, I've been called worse. Well I should have probably immediately apologised along the way, just for the sake of politeness...
But the believe to know it much better than everyone else apparently does qualifies quite well for arrogance. And intentionally trying/wishing to keep the distros, while these are at the same time the major and preferred way of software distribution for the whole community where oneself comes from... for sure you know the German saying "an dem Ast sägen auf dem man sitzt"... so I guess that qualifies quite well for not making the smartest decisions. > And because of those decades of proven philisophy Linux has taken > over the > desktop, correct? And become the #1 targeted platform of all major > desktop > applications. Well the reason for this is for sure not that we have proper package management systems and repositories... something which especially the Windows world never really managed to do and which causes them quite some problems - while everything which has them (or the proprietary/evil versions of them, aka appstores) is quite successful with them. And apart from that,... if one wants to be like Windows or like Mac, than the best is probably just to use these, ain't it? I guess many people in the FLOSS world are actually quite happy with Linux not having the 99% market share. As the past has sown over and over again (even within FLOSS, take GNOME as an exmaple): software with a too high market share tend to get evil, broken or are simply targeted towards end-end-end-users and no longer professionally usable. > Sorry, that was snarky and I had promised myself not to be snarky but > to > be constructive. So let's strike that last comment. Yeah,... let's not go into completely unrelated topics... > No, we have binaries available for Ubuntu, Fedora, OpenSUSE, Mint, > and, of > course, Debian. Then your download page is probably out of date, which still claims: >Linux >The Subsurface team is starting to make our own dedicated binaries >available for a number of Linux versions. It apparently misses Fedora and Mint, and Debian seems to be simply the *buntu package? Anyway,... I probably can't speak for all possible users but I'm quite sure I'm not alone in not using such binaries by principle. That's why distros exist, that people don't have to maintain/upgrade/etc. all software themselves. Not to talk about the security nightmares that your model of software distribution brings along. > So looking at my stats 4x as many Debian users are using the binaries > we > provide than the binaries that used to come with the distribution. > But as > a matter of fact both of those combined are less than 1% of our user > base. And how do you get your stats? Making stats which are actually representative and don't just show what one wants to see isn't that easy. popcon is probably no guarantee, as it's not installed per default. End even if representative statistics would show that the upstream binaries are used more than the distro ones, than the reason may just be the artificial ones you've created yourself, by making subsurface difficult to package and thus outdated in distros. > And of course for the vast majority of our libraries we use the > system > installed ones so the users do indeed benefit from any security > updates > that will happen in the distribution. Security isn't just in terms of up-to-date 3rd party libraries. subsurface itself may have vulnerabilities and it wouldn't be the first project whose website gets hacked and has forged binaries distributed. > An application should be able to bring its own libraries for those > libraries that it is so tightly coupled with that it makes no sense > to > allow random combinations. So today Subsurface prefers to run against > our > own branch of libdivecoputer and our own branch of libmarblewidget > and > requires the very VERY latest libgit2 (0.23) and libgrantlee (5.0.0). I think you're surely not the only program which has tightly coupled 3rd party libraries - yet other projects apoarently manage to properly deal with that... Either they find a way to better cooperate with the 3rd party libs respective upstreams and get their needs into that code (as it could perhaps be done with libdivecomputer),... or they take over / fork an anyway slowly maintained project (again, libdivecomputer?),... or they simply use other libraries which better serve there needs (Robert complained about libmarble beeing buggy[0] - why not just using something much simpler? marble seems to be anyway overkill for something like subsurface). And even *if* you say that a fork is really needed for certain libs, why not doing it properly? As Salvo said, "The problem is caused by the fact that subsurface forked some libraries and made them incompatible, without changing the name." This isn't just bad, it's also quite hostile against the original libdivecomputer... and sounds quite like the ffmpeg/libav debacle. libgit,... well I'm not really into the subsurface code, but I never understood why you introduced that as a storage backend. Even the most prolific divers I know don't have more then 30k-50k dives, and usually these people stopped logging there day to day dives decades ago. Using a plain XML file or poor-man's DB like sqlite should be more than enough ... plus it would have the advantage that one can actually manually edit/parse the log without big problems. I had a few cases where I manually needed to merge dives and realign their timestamps... too rarely to write a proper code for handling such cases, but simple to script with a backend like XML. libmarble,... I would rather not have a fancy globe at all and therefore the program packaged properly in the various distros. Actually there are even many more divelog related features one would miss much more (logging of the used equipment, attaching/linking pictures, logging of divecomputer [firmeware] settings, etc. pp.) than a map. libdivecomputer: Wasn't the whole idea of it to have a _central_ FLOSS lib which allows any program to easily access dive computers instead of having one piece of different lib/code (each with different API) per model? Now we basically have the same again,.. the "official" libdivecomputer and the subsurface internal fork?! Also, Robert said, the problem is that the original libdivecomputer isn't too fast, right? I'd guess the ABI itself doesn't change daily in such lib, and if the distro packaged version is older and supports fewer computers... who cares? And let's be honest,... dive computers aren't smartphones. There isn't a new model every week. > There are four libraries that we want to control Then - even if the alternatives I've named above would be probably better - properly fork them. For libdivecomputer you have even good chances that your fork would become the main fork. And distro maintainers have at least somewhat better chances with their work. (I still could imagine that the release managers and security team wouldn't be all to happy about such forks). > > So that made me curious. There is a sum total of ONE email from you > on the > mailing list, the beginning of which I'm quoting here: Uhm I hade quite a number of bugs/enhancement[1] ideas open in track, some of them fixed some of them not... we two even communicated several times over some of them. Actually I couldn't even remember that I used the ML the one time. > That will give you the reduced user experience that we are trying to > avoid. Well, better some than no experience at all, right? The later which is especially bad for all those people who thought that subsurface would be something that is here to stay and have now all their logs in it. :-( > You are of course welcome to do that. We would appreciate if you > didn't call it Subsurface if you did that, though. Is it already trademarked and patented?! ;-) Reminds me a bit to Mozilla, where the lawyers may have already knocked on your doors when you changed a line of code and still named it FF. O:D > About 15% of our users are on Linux - this has been fairly consistent > for > the past two years during which I have been trying to track those > numbers. Again, I'm a bit curious how you track those numbers? Does subsurface phone home? Or is it by downloads (which again would likely be biased - because why should Linux users download a package, when they have it in their distro)? > And since none of the native dive logs are running on Linux (and the > other > dive log software that appears to exist under Linux is, frankly, a > joke > and not really usable), my guess is that Linux users are much more > motivated to use Subsurface than Windows or Mac users (where there > usually > is a vendor app and of course there are other vendor independent dive > logs > available like MacDive and DivingLog). I haven't said that Linux users weren't motivated to use subsurface... actually that was just my point, when I said that you make it much harder for them now to use subsurface - they typically have no alternative. > If you have a solution that would allow us to tightly control about a > handful of libraries that we link against that would work for Debian Several options have been named,... > I'll > be happy to work with you. Well in then end it wouldn't be me you'd have to work with but the current/previous maintainers of subsurface of Debian. And at least I - from my PoV - could understand if they're no longer keen on working with a upstream which basically said he doesn't want to have distros ship his program and to emphasise this wish he'd even make their lives harder to do so. > (yet it's the > underlying > mechanism that we use for our upcoming cloud storage feature in > Subsurface > 4.5) JFTR: I wouldn't want all my dives to be spied upon in the cloud :) ... so if that was going to be a core / unavoidable part of subsurface, I would anyway loose my interest. Best wishes, Chris. (who is actually about to head into a one month vacation of tec diving,... now unfortunately without a diving log software :-( ) [0] btw: funny that the subsurface side complains about something hardly usable from "outside" (i.e. when not being the the main marble program), while they actively try themselves to make using their stuff more difficult for others :D [1] #180, #181, #192,#193, #194, #198, #440, #453, #454, #649, #672, #684
smime.p7s
Description: S/MIME cryptographic signature
