i386 / 32 bit GhostBSD

[ASX]

Anyway I use a trusty old IBM/Lenovo T60. It was running PCLinuxOS (which I still like a lot) but they gave-up on 32 bit..

Hmmm ... may be we met there too in a past life.
And knowing that and their level of support, I can fully understand your frustration in the BSD world.

PCLinuxOS is supported from a small developer's team, GhostBSD's team is even smaller, and maintaining an old architecture (i386) is something we can't afford anymore. Additionally no developer is going to perform tests on i386 hardware which is slow and time consuming.

GhostBSD is sometimes an introductory step, in that, allow people to enter the FreeBSD world, and later they succeed to install and manage FreeBSD directly, and FreeBSD has no plan to drop 32 bit support.

I have to add that, unlike linux, PAE support in FreeBSD is at a non-existent level.

SSE2 feature is (was ?) also a strict requirement to run some binary application, usually closed source, like flash-player, skype, and may be google-earth too, just can't remember now.

[ASX]

A few data, just to make clearer what is behind producing multiple arch ISOs

we actually support 10.x and 11.x, so far for both i386 and amd64,
it means we have to build 4 pkgs repositories 10-i386, 10-amd64, 11-1386, 11-amd64, each one provide approx. the whole FreeBSD ports tree (27000+ pkgs), and each final repo require approx 70 GB of storage.

(a weekly update will rebuild approx half of those packages.)

we are running two builders (one for i386 and one for amd64) and building a full repo require approx 60 hours, that means we already require 120 hours to build all 4 repos. (builders Xeon 6c/12t, 32 GB RAM, 2x2TB)

Once the repos are built they are transferred from the builder to the pkg server, a separate machine, that amount to a total of 280 GB transfer for each series of repo builds.

The above is about pkgs repos, then there is the ISOs build process, which is much faster, say 15 minutes for each ISO, that means the ISOs can be ready in one hour or so.

Now think at the consequent testing, which means install and test, possibly on multiple machine with different hardware/graphics/network-adapter, say we discover a malfunctioning package, we then need to fix the app. rebuild-update the pkg-repos, re-transfer the repos, re-build the ISOs ... and so on, until we are satisfied with the final results.

Do we really need to spend all that time our free time for a die-ing 32 bit arch ?

[kraileth]

For those who care about the i386 arch and GhostBSD:

I proposed a "middle ground" solution a while ago: Reduce i386 to one desktop spin (Xfce is certainly the better choice here), don't install our repo config there (so that it uses the mainline FreeBSD repository like we did before) and make that ISO "unsupported". That would allow us to get rid of the i386 repo building altogether and building one more ISO per release surely wouldn't hurt that much. It would continue to be what GhostBSD was for a lot of people: A simple to install FreeBSD distribution with a nice pre-configured GTK+ desktop.

However the team has not yet reached any consensus an that matter so nobody knows if the "hard cut" (laying i386 to rest completely) is final or not.

[ASX]

For those who care about the i386 arch and GhostBSD:

I proposed a "middle ground" solution a while ago: Reduce i386 to one desktop spin (Xfce is certainly the better choice here), don't install our repo config there (so that it uses the mainline FreeBSD repository like we did before) and make that ISO "unsupported". That would allow us to get rid of the i386 repo building altogether and building one more ISO per release surely wouldn't hurt that much. It would continue to be what GhostBSD was for a lot of people: A simple to install FreeBSD distribution with a nice pre-configured GTK+ desktop.

However the team has not yet reached any consensus an that matter so nobody knows if the "hard cut" (laying i386 to rest completely) is final or not.

Well, if that is the case, all is needed is to clone github/ghostbsd-build, change a couple of parameters and build an ISO, those who want a i386 ISO can easily build it themselves.

Then you can talk to ericbsd about eventually hosting the ISO along with the others ... or something like that.

[KC_386]

@ ASX

Thank-you for the reply, on re-reading my post I feel I was a bit harsh there -- sorry everyone, probably a symptom of my disappointment at not being able to get the show running again after the update (and my frustration [at myself] in not being able to get to grips with how to fix it).
I didn't say in the comment but I was trying 10.3 version; certainly the initial install held a lot of promise, it was all looking so good and working just as I expected it to . It's a shame it wouldn't work after the first upgrade.

Anyway I'll be trying GhostBSD again soon and hopefully I can get to grips with it. And yes I true appreciate all the hard work that goes into making a distro, everyone who makes it happen here are to be highly commended on their efforts. I hope you guys keep supporting the very useful i386 platform.
Thank-you all.

[ASX]

@ ASX

Thank-you for the reply, on re-reading my post I feel I was a bit harsh there -- sorry everyone, probably a symptom of my disappointment at not being able to get the show running again after the update (and my frustration [at myself] in not being able to get to grips with how to fix it).
I didn't say in the comment but I was trying 10.3 version; certainly the initial install held a lot of promise, it was all looking so good and working just as I expected it to . It's a shame it wouldn't work after the first upgrade.

Anyway I'll be trying GhostBSD again soon and hopefully I can get to grips with it. And yes I true appreciate all the hard work that goes into making a distro, everyone who makes it happen here are to be highly commended on their efforts. I hope you guys keep supporting the very useful i386 platform.
Thank-you all.

The problem related to X failing to start after the update is known and has its root in an update of Xorg server, where some hw detection code was changed, I have experienced it myself back then. In GhostBSD 10.3 we were using FreeBSD pkg repositories, specifically the "quarterly" repository.

We were already planning our own repository, and that failure is really macroscopic, (considering that quarterly repository exists for the only reason to provide "better" stability), one question we had at the time was: should we base our repo on quarterly or latest ? Considering what happened (update issues while using "quarterly" repo), we decided to go straight away for "latest".

We will provide however a fallback in case something bad will happen in future, and it is implemented thru a "previous" repository, say something like 15 days to 1 month old.

more info here: http://ghostbsd.org/UpcomingGhostBSD11. ... positories

Our own repos are already working, and those user of 10.3 who want to switch from FreeBSD to GhostBSD repos can do easily by following the instructions we already published here: viewtopic.php?f=69&t=715

[ernbsd]

Hey there, I'm new around here!

I don't agree that they are considering giving up 32-bit support, understanding that the BSD family is compatible with most older 32-bit architecture computers that have less RAM memory and more software.

The same would happen what happened to PC-BSD that only supported 64 bits with a tremendously slow system full of errors that ate all the memory of 4 GB of RAM at least for its installation, and 50 GB of hard disk that in the end ended up renouncing PC-BSD that never uploaded in its usability in the DistroWatch and exchanged it for TrueOS.

[ASX]

Hey there, I'm new around here!

Yes, we are very aware of that,

I don't agree that they are considering giving up 32-bit support, understanding that the BSD family is compatible with most older 32-bit architecture computers that have less RAM memory and more software.

Excuse me, what is the BSD family ?
DragonflyBSD ? amd64 only.
TrueOS ? amd64 only.
HardenedBSD ? amd64 only
GhostBSD ? soon amd64 only

OpenBSD, NetBSD and FreeBSD are still supporting i386 arch, you might want to choose one of them for your ancient hardware.

The same would happen what happened to PC-BSD that only supported 64 bits with a tremendously slow system full of errors that ate all the memory of 4 GB of RAM at least for its installation, and 50 GB of hard disk that in the end ended up renouncing PC-BSD that never uploaded in its usability in the DistroWatch and exchanged it for TrueOS.

As an independent project they have the full right to do exactly what they like.
And, by the way, it is not elegant to complain about an operating system in a unrelated forum, this speak about you anyway.

[ernbsd]

And, by the way, it is not elegant to complain about an operating system in a unrelated forum, this speak about you anyway.

I'm not complaining, it's just to report what they've stopped support for 32 bits and the possible impacts on users.

[KC_386]

Thank-you all for your replies.
I have reviewed the situation and come to the conclusion the GhostBSD is not the way for me.
Unfortunately mostly this is due to the apparent lack of commitment about maintaining a 32bit distro. This is a shame as there is nothing wrong with the hardware (indeed I would buy another IBM T60 or T61 in a heartbeat), it is the software maintenance and developments that are the stumbling point.
It would appear that the attraction of the working on the latest wiz-bang hardware offering, (and being chained to the hardware manufacturer's release cycles drives) holds more attention than just maintaining a well functioning and reliable distribution. This is a pity.

So again everyone thanks but no thanks. Keep enjoying BSD, no doubt I will return to it when I have to move to 64bit computing.