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

John Marino dragonflybsd at
Wed May 1 13:05:55 PDT 2013

On 5/1/2013 21:27, Francois Tigeot wrote:
> On Wed, May 01, 2013 at 09:01:57PM +0200, Just a Normal Person wrote:
>> 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.

It's too bad you feel this way as I honestly attempted to respond to 
every point you made.  The whole discussion is about a long term "view" 
and you think looking ahead is "short-sighted".

It is not clear how limiting old boxes to DragonFly 3.4 release 
"seriously harms" the project.  Why isn't this support good enough? 
What assets are being risked?  Why do you think this is a "market" that 
DragonFly should be seeking?

> I think it's time to clarify a few things.
> - No decision has been made to kill i386
> - There are no people "in charge" of this kind of decision; as long as
>    there are volonteers willing to make sure DragonFly runs on 32-bit
>    machines and build ISO images, new i386 releases will keep coming.

Correct, no decision has been made.
Also, FULL support for i386 will stay (none of this 2-tier support) 
until EOL occurs.

However, I disagree with the last bit.  There should be a project-wide 
decision on when EOL should be.  Not making a decision at all would be 
disappointing.  I don't want to see a situation where developers are 
marching to different drums.  *THAT* is what causes harm to the project.

> I can see the i386 architecture receiving less and less attention as time
> goes by and its number of users dwindle but there's no reason to kill it
> prematurely.

"Premature" is in the eye of the beholder.  Some think the time has 
already past, others will argue 2025 is too soon.  It's also dismissive 
of all the previous arguments of why there is reason to do it.


More information about the Kernel mailing list