My Issues With Commercialized Linux

This is part of the Sigil’s website get page. I figured since I was on a roll with Linux and the issues I have with the Linux community I would publish this here too. It explains a lot of my rational as to why I don’t really like or want to be part of the Linux “community”.

As stated Sigil will run on Linux. We try to maintain compatibility with Linux mainly because it’s easy to with Sigil supporting both OS X and Windows and it uses a number of technologies that already support Linux. That said, Sigil is not officially supported on Linux.

For one thing, with the variety of package formats various distros use it’s not possible to maintain packages in every conceivable format. At one time we tired a generic Linux package but that turned out to be unmaintainable. User’s simply did not like nor did they want to use it and some even demanded that if we were going to provide a Linux package we should provide the package in the format used by their chosen distro. The decision was made that if a distro wants to provide packages for Sigil it’s their responsibility to provide those packages.

Further, some Linux distros haven’t been very helpful, interested or willing to contribute their patches back to us in order to make Sigil better. They have taken the approach that they’d rather offer forks of Sigil instead of offering their patches back upstream (to us).

Bugs opened against distros for other projects I maintain have gone unanswered for years. Also, distros often introduce bugs that break functionality due to their own patches. Not to mention my own experience with Linux developers and distros hasn’t been entirely positive.

Basically, my experience with Linux distros and Linux developers has been very negative. I have no interest in helping or being part of a community that calls itself open but in fact isn’t willing to share and frankly isn’t very nice to deal with.

I should clarify that my main issue is with the commercial companies that employ people to work on Linux. Most community run distros I haven’t had any problems with. It’s RedHat and Ubuntu (both either commercial companies or backed by one) who have paid developers where I have run into multiple issues. Debian while community driven is also pretty bad.

2 thoughts on “My Issues With Commercialized Linux

  1. Judging by the Debian ITP bug report, Sigil was (is?) full of bundled copies of libraries (in most cases, modified bundled copies of libraries); that requires quite some work on the maintainer part (imagine tracking security issues for every custom library, or having to ship thousands copies of libraries, one for every application, etc.), so I am not surprised your first contact with the Linux communities has been a bit rough.

    It seems the Debian maintainers assigned to the package are focused on this task and willing to do the work, so I hope your collaboration with them will land Sigil in the Debian repos succesfully (and make you reconsider your last sentence ;))!

  2. If you bothered to look at the CMakeLists.txt it uses the system copies by default unless FORCE_BUNDLED_COPIES=1 is set when building. Tidy has custom patches but that has no upstream to push patches to so that is always bundled (Tidy is removed by the way for the next major release so this isn’t even an issue). The vast majority of dependencies are not required to be bundled. They’re provided as bundled because Sigil is designed for Windows / OS X which needs bundled copies because those OS’s don’t have the necessary infrastructure to accommodate not bundling them.

    Now lets see, Linux distros are trying to shoehorn something not designed for Linux into Linux and wondering why they’re having issues. Especially when there is either no upstream for a project or upstream has taken years to actually get around to implementing critical patches that without won’t make the application function. So you either get upstream’s version or you get a non-working application. This has especially been true with calibre where upstream has literally taken years to fix bugs and calibre has been forced to provide a fixed version as a bundled copy

    > Sigil was (is?) full of bundled copies of libraries (in most cases, modified bundled copies of libraries); that requires quite some work on the maintainer part…

    First of all the package maintainer’s job is to manage the package. If they don’t feel their up to the task then they should have never made the package in the first place. If they don’t want to maintain it because it’s too hard then why did they even go to the trouble of packaging. Basically what this comes down to is they’re wining that Sigil hasn’t made an application designed for Windows and OS X easy for them to package.

    I should also mention many of the changes (other than Tidy) have no impact on Linux. They’re mostly for Windows or optimizations that aren’t required. Tidy is and has been the only real issue.

    I’d also like to point out two other things about bundled copies. 1) Some like minizip havn’t changed in years. 2) Some of the bundled copies aren’t even copies. XercesExtensions for example’s upstream is Sigil itself but for whatever reason some distros require it to be separated from Sigil even though it’s developed as part of Sigil, only used by Sigil and cannot be used independently of Sigil.

    > (imagine tracking security issues for every custom library, or having to ship thousands copies of libraries, one for every application, etc.)

    Seems to be working out fine for OS X. Even Windows in this day and age (not that it has some proper security policies in place) isn’t having major issues with applications including customized or copies of specific libraries.

    > so I am not surprised your first contact with the Linux communities has been a bit rough.

    You mean my first contact being a Linux user pointing out that distros are maintaining their own patch sets independently of one another and not trying to push them upstream. They’re doing exactly what they’re complaining Sigil isn’t doing by pushing our patches (which we actually do when we can and it makes sense) upstream ourselves? Seems a tad hypocritical to me.

    It’s the package maintainers job to work with upstream. Simply put, until fairly recently, in Sigil’s case the package maintainers for pretty much every distro hasn’t contacted us, worked with us, or provide feedback to us. They simply did their own thing. Just like we have. So once again the package maintainer isn’t doing what their supposed to and actually engaging the upstream project.

    > It seems the Debian maintainers assigned to the package are focused on this task and willing to do the work, so I hope your collaboration with them will land Sigil in the Debian repos successfully (and make you reconsider your last sentence ;))!

    If they’re willing to do the work I’m willing to review it and if it doesn’t negatively impact other OS’s then I’ll accept patches. We have a full set of auto packing for RPM and DEB already in the current version to make it easier on users because distro’s often lock at specific versions for the duration of a release. So we’re (I’m) not against Sigil on Linux but that doesn’t mean I’m willing to do the work myself to make it happen. Especially when I don’t have the necessary expertise to do so.

    However, if a Linux distro doesn’t engage us and Sigil breaks because they make changes then that’s their own damn fault. Mainly for not testing like a package maintainer is supposed to before release.

Comments are closed.