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.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
