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
