Re: Selection of roadmap for i386 platform End-of-Life (EOL)

[Just a Normal Person <tails92@xxxxxxxxx>]

Unluckily this reply was what I expected and it doesn't really address
anything in my opinion.
I am sorry, though, as I quite liked DragonFly back in the day and I
feel decisions as short-sighted as these seriously harm the project.
Anyway, good luck to the people in charge of this project - it's too
evident they really need it.

Giuseppe Gatta

On 5/1/13, John Marino <dragonflybsd@marino.st> wrote:
> I hate responding to this negatively because you obviously put in a lot
> of thought and time into the message.  The problem is that it's missing
> the point, as well as goes down the "let's save i386 path" that I tried
> to ward off.
>
> See below.
>
> On 5/1/2013 19:50, Just a Normal Person wrote:
>> I don't think there is a really good reason to remove support for
>> 32-bit x86 machines in my opinion. As it was pointed out before, it is
>> not like they are not capable of running DragonFly well; granted, for
>> the project running on machines with less than 256 megabytes of RAM
>> may not be a priority, but there are a lot of machines with>= 256 MB
>> of memory and they're 32-bit x86.
>
> Machines running on less than 256M are not a priority.  True.
> 32-bit machines can have more than 4G on them, but only 4G is
> accessible, which is a lot.  However, the discussion isn't about memory.
>
>> I have run the latest DragonFly release on a Pentium 4 machine from
>> 2001 with 512 MB of RDRAM, and it ran perfectly. And we're talking
>> about a machine from 2001; newer ones are going to run it even faster.
>
> As I tried to point out, supporting old h/w isn't the mission of
> DragonFly.  The issue is that supporting old h/w may hinder the
> advancement of DragonFly.  [People can attack this premise, but
> supporting 1 arch takes less resources than 2]
>
>> I think that the thought of thinking that a machine is not useful just
>> because it is old is a naive and dangerous one: people do not usually
>> test lesser known operating systems such as DragonFly on new systems.
>
> And as I have pointed out MANY times, these people can use Release 3.4.
>   There is no reason they need the latest and greatest when their
> hardware is ancient.
>
>>   And if they do not test it, they're not going to be introduced to
>> DragonFly, and the already small userbase will shrink even more.
>> Another thing to remember: not everyone in the world has access to the
>> greatest and latest machines!
>
> See above.  In addition, I am skeptical that catering to the "ancient"
> crowd advances DragonFly, as in "what do they contribute?".  The
> counter-argument is that somebody gets hooked and starts converting
> newer boxes once they see how it works, but I need to be convinced this
> happens.
>
>> Other points are that the maintenance burden is really small, and that
>> i386 machines are all over the place; there's like a huge supply of
>> them, every flea market one goes to, for instance, is bound to have at
>> least some.
>
> I can tell you from personal experience, as the guy that builds ports
> packages, system compilers, and bootstraps compilers, that maintenance
> on i386 is not a small burden.  How can you judge the burden on
> developers?  Do you see everything that's going on behind the scenes?
>
> Personally, I don't care about the flea market crowd.  That's not the
> DragonFly mission as I see it.  I am happy to let souk-fodder go to
> NetBSD, OpenBSD, FreeBSD or Linux.  (again, my personal view)
>
>
>> At the end I think that the only wise choice for the DragonFly project
>> is to keep supporting the i386 architecture, at most what could be
>> done instead of removing support is moving the i386 architecture to a
>> "second tier" place. That way you would show that i386 support is not
>> your focus and that people better expect to make up for the lack of
>> focus themselves (like building the ports themselves, instead of using
>> premade precompiled packages).
>
> I can't tell you how much this idea is distasteful to me.
> 1. The 2nd tier platforms on NetBSD and FreeBSD are in bad shape as one
> might reasonably expect.
> 2. This is "wishy-washy".  You need to be all in or all out.  This is
> sort of the "Option 3" idea that Sam put forth but I hate it, and I
> think it's unprofessional (even for FOSS).  If you sign up for
> something, do it well.  Or don't sign up.
> 3. You can advertise all day long that you "fend for yourself" but
> you'll still get the complaints and criticisms.  Calling it "second
> tier" doesn't free you from that.  it would be much more peaceful just
> to kill it and not deal with the headache that will bring.
>
>> You never see projects like NetBSD and OpenBSD removing support for
>> architectures, just because they think they're not as used as they
>> once were; when they discontinue architectures, it's because they
>> really have problems at maintenance.
>
> I believe I have seen NetBSD contract architectures.  I'd have to
> double-check, but it's not material.  This is DragonFly.  We have a
> different mission.  By the way, there was an article this week on Arch
> Linux stating that it is a matter of "when", not "if" they contract
> i386, and they think it could be only a year away.  So we aren't alone
> in thinking about it.
>
>> In fact, the second tier approach I suggested is just like what NetBSD
>> did.
>> Removing i386 support? For me it is a sure no-no and it can only hurt
>> DragonFly at the end.
>
> Concentrating resources on one platform isn't going to hurt DragonFly;
> it will free x86-64 development from the shackles of i386 support.
>
>> In before I get replies like "go use another *BSD flavor": that's
>> pretty amusing.
>>
>> Giuseppe Gatta
>
> Well, I wouldn't say it in disdain or malice, but my first suggestion
> would be: Use DragonFly Release 3.4 (or the last supported i386
> release).  If the person found that unacceptable, I don't know what else
> to suggest than "well, put another flavor of BSD on your flea-market
> box."  All the BSDs are good, I don't see that as an insulting thing to
> say.
>
> Kind regards,
> John
>