Not a bad idea. I tried NetBSD 10 RC 32-bit for some days. One of the limitations is that they don't have latest firefox on 32-bit on 10 RC (at least yet). Only version ESR 102 on i386. Some of the software I want is not on repos. Some of them don't build (due to unsolved Issues in either project source or dependencies on NetBSD platform).
# pkg_admin -K /usr/pkg/pkgdb fetch-pkg-vulnerabilities
# pkg_admin audit
Package perl-5.38.2 has a symlink-attack vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2011-4116
Package perl-5.38.2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-31484
Package perl-5.38.2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-31486
Package libxml2-2.10.4nb6 has a use-after-free vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-45322
Package gnutls-3.8.2 has a timing-side-channel vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2023-0553
Package pcre-8.45 has reached end-of-life (eol), see http://cdn.NetBSD.org/pub/NetBSD/packages/vulns/eol-packages
Package libssh2-1.11.0nb2 has a integer-overflow vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2019-17498
Package gnupg2-2.4.3nb2 has a out-of-bounds-write vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2022-3219
Package wget-1.21.4nb2 has a sensitive-information-disclosure vulnerability, see https://nvd.nist.gov/vuln/detail/CVE-2021-31879
rg ONLY_FOR_ARCHS= /usr/ports/ | rg --invert-match i386 > /tmp/not_for_i386.lst
rg NOT_FOR_ARCHS= /usr/ports/ | rg i386 >> /tmp/not_for_i386.lst
cat /tmp/not_for_i386.lst | cut -f 1 -d : | sort | uniq | wc -l
rg
is textproc/ripgrep. (rg(1))I still have a 32-bit only Intel Atom machine. It is incredibly low power. Still runs for an hour without plugged in on its original ~10 yr old battery. It has a faulty screen, so I can't give it to someone else. So I'm using it mainly as a server. I don't want to throw it away and contribute to the increasing problem of tech trash.
I honestly did not expect FreeBSD to do this. If this is final, I am not interested to invest any more time on FreeBSD as I did not get any solution to the issues I have on i386 and am fearful that I will not be able to run it even on x86_64 on older hardware in future (which is probably the case already due to MESA changes).
FreeBSD doesn't even have a MESA Amber port. Debian (by extension Devuan) has one. Arch has one too. Devuan runs very well on i386 without bloated systemd that Debian has. Devuan/Debian have challenges supporting i386 but the good thing is that they did not give up.
It seems like FreeBSD has chosen its path. I don't know if the decision will change. If it doesn't, time to say goodbye to FreeBSD then. Seriously disappointed at FreeBSD as a project.
Not a Apple user. But I read from people that Apple is contributing to tech trash and many other nasty things willingly and unnecessarily. Apple pushes proprietary software and does not respect user freedom. If FreeBSD follows Apple to bring ease of use, I'd be understanding. But I don't think FreeBSD should follow Apple's example in deprecating hardware.Apple is doing it much much more drastic by eliminating support for older macs that are 5+ years old and they also killed 32 bit support not long ago.
Even on Void and Devuan/Debian I noticed there are some packages that had issues and had to provide older versions for a while. This is not the fault of the OS, but rather those software projects. Once they are solved, latest versions are included back in. This is normal in 32-bit OSs I have used.Maybe not accurate, but currently 282 ports are not for i386 at git ports 7d889afc8a3d9fef336b5c1601b69837aa52521a on main branch.
The number is incleaseng as time goes by.
Marty McFly asks, what is a Gigawatt? Answer: savings to get with new Green hardware.And don’t forget ports - it might not be “just” the OS.
Newer hardware may also be more power efficient so *may* be “greener”. But then you get into the discussion about being even greener not using resources to build new machines etc so maybe not a compelling argument.
Not a Apple user. But I read from people that Apple is contributing to tech trash and many other nasty things willingly and unnecessarily. Apple pushes proprietary software and does not respect user freedom. If FreeBSD follows Apple to bring ease of use, I'd be understanding. But I don't think FreeBSD should follow Apple's example in deprecating hardware.
32-bit time_t is difficult to circumvent. And if it's changed to 64-bit, all legacy i386 apps break. There is no easy way forward without breaking something i386.You can install either NetBSD or OpenSolaris. They have a 32-bit userland. Oracle quietly extends Solaris 11.4 support until 2037, just one year short of y2k38. Makes you wonder...
Legacy 32-bit architectures are a massive headache when trying to work out solutions for legacy API's that use 32-bit time, sizes, etc. while trying at the same time not to break ABI, etc.
Read the first 3 entries on this blog to get an idea why: https://www.thkukuk.de/blog/
Really?To roll my sleeves is easy. To fix bugs is Hello Columbus. MyGCC
is awfull.
A modern browser barely fits in 4 GB of memory. Anyway, NetBSD is a good choice for retrocomputing enthusiasts, it works poorly, but the important part is that it works poorly on every arch, so they don't feel singled out.
For code respecting the C standard (recap:The hard part is third party apps that are not part of ports that that need to be rebuilt, that someone must reach out to all the unknown number of vendors out the to get them to update their code, or at the very least recompile.
time_t
representation format and size are completely unspecified, you should only ever use it to store time in memory and process it with time.h functions), rebuilding is really all that's needed.We did this, about 20 years ago, for off_t, when we allowed file sizes (offsets) to go from 32 to 64 bits. It worked, and at no point in the middle was everything broken. It was incredibly tedious and painful (and expensive), but it can be done.32-bit time_t is difficult to circumvent. And if it's changed to 64-bit, all legacy i386 apps break. There is no easy way forward without breaking something i386.
It worked, yes. But some ports broke. While other third party apps also broke. At the time I maintained the Digital Mars D language in FreeBSD ports. This broke DMD D because the DMD upstream maintained copies of FreeBSD library calls and internal structures in their library in order that D calls appear native to the D language. Perl, python and other languages do the same. It was more of a problem with D which was a low level C-like language with classes, vaguely similar to C++. The versioned symbols worked great with C and C++ apps but languages that needed to duplicate what we did, didn't work so well. To this day DMD D developers still haven't managed to figure out versioned symbols for DMD D and thus 32-bit and 64-bit off_t. It worked great for us but third party apps such as languages, not so much. This is why DMD D is no longer in ports.We did this, about 20 years ago, for off_t, when we allowed file sizes (offsets) to go from 32 to 64 bits. It worked, and at no point in the middle was everything broken. It was incredibly tedious and painful (and expensive), but it can be done.
But I don't disagree with your conclusion: At this point, for a mainstream production OS (such as FreeBSD), it is no longer efficient to keep i386 operating. For other OSes, or for products with lots of extra money or manpower, the answer might be different.
And a lot of things "optimized" IPV4 addresses as uint32_t and had to rewrite everything to deal with IPV6.The backward compatibility problem is a much larger issue. Remember how badly 64 bit inodes went? This would be worse. Much worse.
One can't control everything nor can one force others to do the right thing.It worked, yes. But some ports broke. While other third party apps also broke.
You can install either NetBSD 𡀦…
It may be a problem when porting a C library to a high-level programming language. A typical case that can and will cause issues is the size ofWhy’s that? Could you elaborate? In a high-level programming language I use built‑in data types likepointer
orinteger
and then I don’t have to care about how many bits each comprises.
long int
, which is 4 bytes in 32-bit systems and 8 bytes in 64-bit (while normal int
has the same size). And that's just a quick example. C actually has means to make this more portable with headers such as stdint.h
- but good luck finding a C library that uses them.As of February 2018, support for 32-bit x86 hardware was removed from illumos. This only affects the kernel; 32-bit applications are still supported.
In practice, 32-bit hardware support hasn't been well-tested for a while, and most illumos distributions haven't supported 32-bit hardware for a while.
However, you can still run older Tribblix on 32-bit hardware, with certain caveats. The biggest caveat is that this is unsupported, and you'll be 5 years out of date.
(...)
With 32-bit hardware, you're often looking at hardware that is resource constrained in other ways. Tribblix is the best illumos distribution for such resource constrained systems, allowing a more minimal install, and supporting installation to ufs rather than zfs. (If you have less than 1G of RAM, ufs is recommended, and should be comfortable on even a 512M system.)
Note that while Tribblix is happy to allow for 32-bit hardware, some modern applications may be aimed at 64-bit hardware. For example, golang is only available for 64-bit illumos, as will be any applications written in Go. Java 8 is 64-bit only, so you're limited to Java 7. Many new languages, runtimes, and applications, will only be 64-bit.
The Computer History Museum in Mountain View is operating an IBM 1401, which was built in 1961. That makes it 63 years old. It runs every Wednesday and Saturday. The oldest functioning disk drive is in the same museum, the 1957 RAMAC; that's nearly 70 years old. To be honest, it's not fully functioning: While the data on disk can be read, they do not allow new data to be written. I think the electronics on this drive has been replaced with modern emulation. Supposedly there is another disk drive the same age in a different museum, which has the original electronics, but it doesn't function fully. I think the RAMAC is also run for demonstration once or twice a week.
I (with a little sadness) agree with the decision for FreeBSD to drop support for the i386. I can imagine that it takes quite a bit of extra work to support, the project is short on humans, and it's not worth it. Even if it forced me to re-install my OS a few weeks ago.
… We anticipate FreeBSD 15.0 will not include the armv6, i386, and powerpc platforms, and FreeBSD 16.0 will not include armv7. …
Useless link
Welcome back!
We're so excited to see you again!
Perhaps because we ask too much of them? (3 major branches times N architectures?)FreeBSD is struggling with a decreasing base of developers. Fluctuation is high especially among port maintainers.
Even on Void and Devuan/Debian I noticed there are some packages that had issues and had to provide older versions for a while. This is not the fault of the OS, but rather those software projects.