My opinion on Ubuntu cancelling Intel 80386/80386-clone processor support

[Xen]

Thierry Andriamirado schreef op 12-09-2016 19:54:

> I understand that the Ubuntu developers must choose.
> What is important now is to know that doing advocacy for Linux in
> developing countries  must integrate this 2021 deadline.

Late to the ball, but...

I think that if you really did the calcuations you would find that the 
effort or resources required to support 32-bit i386 compared to or 
relative to or as a part of the total effort required to ship ISOs 
regardless, is minimal.

In these discussions, almost never numbers are actually named.

If shipping a distribution of Ubuntu on ISO takes 1000 man hours (units, 
so to speak) and the i386-32-bit takes 10 of that, is that significant? 
It is never going to be 500. We can never agree on anything if we don't 
know the numbers, and people like to exaggerate what they don't know if 
they are in favour (of discontinuing) but never use actual data on the 
subject.

So what is this huge effort required to continue i386-32-bit images?

It's probably only going to come down to testing, isn't it? But why, 
actually, should testing i386 take so much time if amd64 has already 
been tested? Differences between the ISOs will be absolutely minimal 
apart from all the i386 packages, that are needed to be kept supported 
anyway?

If the kernel is no longer producing an image that will run on i386-32 
bit, fair point. From the point of view of security updates, maybe 
difficult. Who takes the burden for that. But that is Linux-wide, in a 
sense. If people would get together (and I am sure they do) it is not 
hard to keep supporting that community-wide.

So what are we actually talking about here? Only ISO-testing, really?

How much effort does it require to release a i386-32-bit specific 
version, compared to the full total?

In other words, what are the /marginal costs/, in percentage?

I am reminded of many companies here wanting to do away with paper mail. 
They voice concerns about the environment and we all know or could see 
that the impact of a few thin bank transaction sheets once a month is 
going to be completely insignificant on the grand scheme of things. 
Companies advise you not to print their documents because it would have 
such a big impact on the environment. And it is ludicrous. Any 
functioning organisation needs paper or something of the kind. Trying to 
cut down on the minimal amount you use just to send email through an 
actual mailbox (ie., paper mail) in order to "save the environment" is 
just a scam for being able to cut down on costs a little bit and 
disenfranchise people in the mean time who now no longer have paper 
copies unless they print them themselves -- so where is the cost savings 
there? Paper copies are absolutely required for many "home" 
administrations and paper is more reliable than having digital copies 
lying somewhere around. Aside from these concerns, it is pretty clear 
the advantages of "digital" are getting exaggerated while the 
disadvantages are hardly ever named, particularly by those who want to 
cut back on costs and jobs.

I can grab a copy from my local administration in seconds, if I did that 
digitally online, it might take minutes, particularly if I have to use a 
password reset form for it ;-). Then, if I want to use it for most 
purposes, I need to print it. Now I suddenly require the ownership of a 
functioning printer that will work (in my case) in Linux.

Living light is nice, but at this point central administration and 
online access of it hardly has any advantage for me apart from being 
able to access it anywhere.

And it's not that there are no advantages, it is just that the 
disadvantages are never named.

It is unfair and deceitful and they are just trying to save money and 
lose employees, they are not really doing it for you.

Now not saying that the same has to be true here (particularly the 
losing of employees ;-)), but....

I just think it is important to know what actual numbers we are talking 
about here before anyone can make a reasonable assessment, because many 
discussions are held on "hear say" data that is never quantified, but 
only qualified by those who want to get rid of it as "too much".

And my feeling is simply that if we actually knew the numbers, we would 
find that:

- i386-32-bit doesn't take more than 20% of resources of the total, if 
at all
- most of it probably goes into testing
- you could choose to stage testing of 32-bit after 64-bit has been 
completed, or something similar

- you could choose to release 32-bit at a later release date, so it only 
needs to test particular differences for 32-bit, which would be 
absolutely minimal if the issues of 64-bit have been worked out.

- kernel work for 32-bit could be shared with other distro's, and I 
don't know the Debian road map for this.

So I think that when it comes down to it the real costs are not that 
great if you play it well and if there are some problems to be solved, 
you should just go and solve them and not act like Necessity plays your 
hand here. Sorry for those words, but I hardly think circumstances 
dictates what needs to happen here. I think that with enough will and 
interest, the 32-bit could be supported indefinitely with minimal cost.

Recently there was some discussion on Debian-devel on the topic of some 
package and SysV scripts.

It was advised to discontinue the shipping of SysV scripts by some.

When it came down to it, at least from my perspective, the problems were 
being exaggerated and the only ones who would benefit from SysV 
abandonment for those scripts would be fierce and staunch SystemD 
supporters who would see their competitor depart.

The discussion was held on the basis of the words "very bad race 
condition" and when you actually looked at what it was about, it was a 
/very simple problem to solve/.

But the person making those claims treated it as a huge ass software 
engineering difficulty. And it just *was* *not*. But the discussion was 
held on the basis of the claims made by the package maintainer, and not 
on the basis of actual data or a factual or detailed description.

So I'm just saying: ensure you have the data first, before you try to 
reach conclusions.

And I'm saying that if this data is not given... well... you can hardly 
make sound conclusions based on that, right.

Anyway, signing out again.