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

[John Marino]

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