On 2024-08-29, Elie Le Vaillant <eolien55@disroot.org> wrote:
> Hello,
>
> I'm currently daily-driving a 2008 i386 machine on
> -current. Earlier this month, I tried out ungoogled-chromium,
> which was available as a package at the time. I've
> tried again today, and though the ports tree still
> lists i386 as a valid platform, the different mirrors
> I've tried do not provide ungoogled-chromium as a
> package. The same appears to be true for pandoc,
> and chromium: listed in ports as a valid target, but
> not available as a package.
imho you should really be looking for a 64 bit machine if you want to
run a web browser.
> Is this due to a change of policy on i386 packages
> which I've missed? Is this a known issue?
No change of policy - those simply aren't getting built.
pandoc depends on ghc, which is amd64 only.
When attempting to build chromium and friends on i386, it usually fails
for various reasons.
In the most recent attempt, iridium and ungoogled-chromium fail with this
In file included from ../../v8/src/compiler/turboshaft/int64-lowering-phase.cc:9:
../../v8/src/compiler/turboshaft/int64-lowering-reducer.h:295:24: error: call to member function 'Word32Constant' is a
mbiguous
295 | new_index = __ Word32Constant(sizeof(int32_t));
| ~~~^~~~~~~~~~~~~~
and chromium fails earlier (I suspect typescript probably runs out of
memory).
FAILED: gen/third_party/devtools-frontend/src/front_end/panels/screencast/screencast-tsconfig.json gen/third_party/dev
tools-frontend/src/front_end/panels/screencast/InputModel.js gen/third_party/devtools-frontend/src/front_end/panels/sc
reencast/InputModel.js.map gen/third_party/devtools-frontend/src/front_end/panels/screencast/InputModel.d.ts gen/third
_party/devtools-frontend/src/front_end/panels/screencast/ScreencastApp.js gen/third_party/devtools-frontend/src/front_
end/panels/screencast/ScreencastApp.js.map gen/third_party/devtools-frontend/src/front_end/panels/screencast/Screencas
tApp.d.ts gen/third_party/devtools-frontend/src/front_end/panels/screencast/ScreencastView.js gen/third_party/devtools
-frontend/src/front_end/panels/screencast/ScreencastView.js.map gen/third_party/devtools-frontend/src/front_end/panels
/screencast/ScreencastView.d.ts
python3 ../../third_party/devtools-frontend/src/third_party/typescript/ts_library.py --tsconfig_output_location gen/th
ird_party/devtools-frontend/src/front_end/panels/screencast/screencast-tsconfig.json --deps ../../core/common/bundle-t
sconfig.json ../../core/host/bundle-tsconfig.json ../../core/i18n/bundle-tsconfig.json ../../core/sdk/bundle-tsconfig.
json ../../generated/protocol-tsconfig.json ../../ui/components/icon_button/bundle-tsconfig.json ../../ui/legacy/bundl
e-tsconfig.json --front_end_directory ../../third_party/devtools-frontend/src/front_end/panels/screencast --reset_time
stamps --sources ../../third_party/devtools-frontend/src/front_end/panels/screencast/InputModel.ts ../../third_party/d
evtools-frontend/src/front_end/panels/screencast/ScreencastApp.ts ../../third_party/devtools-frontend/src/front_end/pa
nels/screencast/ScreencastView.ts
TypeScript compilation failed. Used tsconfig gen/third_party/devtools-frontend/src/front_end/panels/screencast/screenc
ast-tsconfig.json
...
Last time the chromium code was actually compilable on i386, linking
failed about 80% of the time due to running into memory limits on a
32-bit platform (we do native builds on i386, not cross compiles from
amd64).
Browsers still built on i386:
(w3m, lynx, links, links+, elinks)
netsurf
dillo
seamonkey
webkitgtk-based ones (epiphany, luakit, vimb, surf, badwolf)
qtwebengine-based ones (qutebrowser, otter-browser) - though there's
a fairly good chance that future updates will break i386
Also we are also having problems with programs written in rust, the
compiler started using more memory in some more recent release, and
seeing quite a few random build failures there, so some of those will
drop in and out of package snapshots depending on whether they worked
in any particular build.
Many projects are simply not interested in resource requirements during
compilation.
Taking amd64 as 100%, here's how other archs compare in number of
packages in the latest snapshots:
arm 65
powerpc64 68
mips64 69
sparc64 70
powerpc 81
riscv64 84
i386 85
aarch64 98
amd64 100
I'm all for running hardware for a long time to get as much use out
of it as possible. But a new machine costing around GBP/EUR/USD
175 (mini desktop, with 16GB ram / 500GB SSD included in that
price) will run rings round a 2008 i386, use significantly less
electricity, and if it's an intel >= 11th gen (e.g. intel n100
which is common in this class of machines - look for "Control-
Flow Enforcement Technology" in the cpu specs) have a feature
https://en.wikipedia.org/wiki/Indirect_branch_tracking which is well
supported by OpenBSD/amd64 (used in the majority of packages) that
makes some classes of attack very much more difficult. (Though
simply going to a 64-bit arch with the increased address space,
on an OS that does ASLR well, is already a big improvement).
--
Please keep replies on the mailing list.
No comments:
Post a Comment