Notebook (Posts about business)/categories/business.atom2019-05-05T21:20:57ZToni MüllerNikolaWhy Do DigitalOcean, AWS & Co Not Default To Debian?/posts/2017-03-25-why-do-digital-ocean-aws-not-default-to-debian/2017-03-25T00:00:00+01:002017-03-25T00:00:00+01:00Toni Mueller<div><p>I just read Chris Lamb's platform[1] for this year's DPL elections,
where he asks why enterprises do not use Debian by default. In this
article, I want to give some answers, although I think Chris is
very likely already aware of them, given his track record.</p>
<ul>
<li>
<p>Marketing</p>
<p>I think Chris is partially right: Marketing is important, whether we
like it or not. The ArchWiki example that he mentions, shows that
they manage to present relevant content in a very accessible manner.
This has in part to do with their organization of the information,
and also with them possibly keeping the information better up to date
than we probably do (I frequently find better information in the
ArchWiki myself.)</p>
<p>Their styling is imho on par with ours, so the difference should lie
elsewhere. This may be partially due to them using a different
software which has a much bigger userbase than ours, which certainly
does contribute to users findig it easier to work with, because they
don't need to learn anything new - no new procedures, no new markup
language, the software already feels familiar. In short, it conforms
more to existing user habits because of the market share of that
other software.</p>
</li>
<li>
<p>Commercial Viability</p>
<p>In my professional experience, I found that there are a few factors
which make other versions of Linux, particularly CentOS and friends,
more attractive to enterprises like eg. AWS:</p>
<ul>
<li>
<p>Our support cycle is too short.</p>
<p>These enterprises like to have that 10 years of support and never
worry about any ugprades, because after 10 years, you can usually
safely throw the machine away. The impact is that the vendor, eg.
Amazon, does not need to involve the customer about upgrading
their application, which the customer usually does not want to
do, and also does not allocate any budget to. The typical
customer expects, that once he has his application deployed, it
will continue to run without change until he decides to stop
running that version of said software, and considers upgrades to
be a waste of time an money. Also, both security updates and
newer versions of some third-party software become available on
older versions of such Linux systems without the need for a big
upgrade. The former enables the vendor to say that his platform
is secure, and that any breaches are solely the fault of the
customer, while the latter enables the vendor to offer new
features to the customer without requiring him to upgrade. As an
example, I'd like to point to the availability of PHP7 on CentOS
6.8, which is from 2016, but does not deviate too much from even
older versions of CentOS and thus require not too much
re-learning, with their first 6.x version being released in 2011,
alongside Squeeze.</p>
<p>[2018-01] It looks like Snaps are addressing this
problem.</p>
</li>
<li>
<p>As a corollary to that, there is a much clearer separation between
the very small core distribution, and the large amount of
third-party commercial software.</p>
<p>Also, us having tons of software already included, which eat a lot
of manpower, is an underemphasized, so it may not be obvious how
Debian can make users' lives easier.</p>
</li>
<li>
<p>There is a certification system in place, that gives the enterprise
some confidence about the abilities of any prospective hires. I am
not aware of any certification system for Debian.</p>
</li>
<li>
<p>The boon and the bane of Debian is the non-commercial nature of
it. There is no single commercial entity behind Debian, which
results in enterprises not knowing whom to sue, or how long the
project will survive. Nevermind that similar problems have occurred
with many vendors in the past, but there is a vendor which could be
sued, if need be. And it looks like they have enough government
backing to not easily go bankrupt, either. But the distrust against
volunteer organisations which are as loosely knit as Debian is,
runs deep.</p>
</li>
</ul>
</li>
</ul>
<p>Links:</p>
<ul>
<li>https://www.debian.org/vote/2017/platforms/lamby</li>
</ul></div>Fixing the Android Update Problem - A Few Thoughts/posts/2014-06-25-fixing-the-android-update-problem/2014-06-25T00:00:00+02:002014-06-25T00:00:00+02:00Toni Mueller<div><p>Time and again, Android has been getting the heat for leaving its
users in the lurch in the face of security problems, while fixing such
problems only in the most recent version. But in my opinion, not only
Google, but also the manufacturers, are to blaim for this situation:
They are the ones who aim to lock down the devices with their
Frankenstein'ed versions of Android because they think it's their
selling point, or at least their way to more revenue.</p>
<p>The following suggestions relies purely on speculation, because I am
not privy to any contracts, product design or marketing discussions on
behalf of any party. But from all I know, the following approach could
be used to alleviate the problem from the user's perspective:</p>
<p>Google should imho</p>
<blockquote>
<ol class="arabic simple">
<li>fix such bugs in as many versions of Android as
required to achieve 75% market coverage, and</li>
<li>adjust their contracts in a way so that manufacturers who desire
early-access and support from Google, as opposed to simply warping
AOSP, are required to offer these updates for all handsets that
were originally shipped or are currently running with any of the
fixed versions of Android, within two weeks time, lest they lose
some kind of access to the program, and the right to use the
Android logo. Compliance should be determined frequently enough to
not water down these requirements.</li>
</ol>
</blockquote>
<p>This would have the following nice side effects:</p>
<blockquote>
<ul class="simple">
<li>Google gets rid of the blame for not supporting their users (see
point 1).</li>
<li>The manufacturers can still avoid the huge and profit-eating work
of supplying the users with new versions of Android, but are being
pressed to at least not leave their users alone (see point 2).</li>
</ul>
</blockquote>
<p>By going this route, the manufacturers are not required to give up a
part of their business relationship to Google, which would be hard to
argue despite them doing it all the time towards the carriers (let's
think about that battle later), while making sure that the users are
safe, sort of (and relegate the general security debate about Android
to a different debate, too), without making it impossible to market
new devices with new versions of Android.</p>
<p>The current situation, which I'd liken to driving a car with broken
brakes, would imho warrant compulsory recall actions on behalf the
manufacturers, which they would otherwise be legally obligued to
perform - at least as far as my understanding of German consumer
protection laws goes. It would be somewhat interesting to see such a
case being heard before a German court, and I'm far from confident
that the Android brand will not be hurt while the problem festers.</p>
<p>I have the nagging feeling that I cannot be the first to have had
these ideas, but wanted to state them nonetheless.</p></div>