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 <[email protected]> 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 >
