Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics. Is
it at least "not as bad" as amd64, with Intel's Management Engine and
AMD's equivalent? Or is something like a System76 or Puri.sm
amd64-based machine better / just as good?

Do you have specific "ready to buy" (even if lead times are months,
not year+) computers to recommend for that? For a laptop? For a
"beefy" but quiet desktop that won't shy away from compiling
e.g. LibreOffice?

Will popular Debian software "generally work" or will I run into
"many" situations like e.g. Firefox WebRTC doesn't work on Power and
QT 5 doesn't work on Sparc64 (!!!)?

I don't particularly want to get deep into being a porter, but I want
a good desktop to run XFCE, emacs, mutt, gdal, Firefox ESR, etc,
developing my pet software, maybe get back into LibreOffice (a beast
to compile...) development and/or become active as Debian package
maintainer again, flashing LineageOS to my Android pocket computers (smartphones) until a better alternative becomes usable, ...

Thanks in advance for your advice,

--
Lionel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Raspberrys have to me a reputation of being small cheap "slower"
hackable mini-computers, not "workhorses". Have they scaled up that
much since they were introduced?

Is even the Raspberry Pi 4 even close to 'a beefy but quiet desktop
that won't shy away from compiling e.g. LibreOffice'? I don't know
what hardware it runs, but the buildd for arm64 took 17 hours to build LibreOffice https://buildd.debian.org/status/logs.php?pkg=libreoffice&ver=4%3A7.4.5-2&arch=arm64
and from https://db.debian.org/machines.cgi
the hardware seems to be sponsored by Ampere Computing, so maybe it
uses one of their CPUs?


Also, I'm worried about the memory. My current desktop has as 8.7GB to
10GB memory used when running "nothing in particular", no compilation,
just Exim4 (+ bayesian spam filtering software when an email comes
in), XFCE, Firefox, Emacs, terminal emulator / shell windows, mutt and
a few instant messaging clients. And a Raspberry Pi 4 tops at 8GB?


Or are you saying I should run that as a silent "terminal" to SSH into
my real work machine? Which begs the question of what the work machine
would be :)


And any idea for a laptop?

On Mon, Mar 20, 2023 at 08:16:26PM -0400, Alan Corey wrote:

This is a non-technical barely qualified opinion but yes. An easy
start is a Raspberry Pi, about a 3B ($35), it's what I'm typing on.
I've got 4 of them. And this one is running Debian, not Raspbian AKA Raspberry Pi OS. The differences are tiny. Just get a monitor and
keyboard, a couple of SD cards about 32 GB or larger and a Pi. It's
easy to download your first image and get it booted, from there you
can experiment. Install Synaptic the package manager, after that you
search for applications and click on them to install.

There is a Raspberry Pi 4 which is considerably better but relatively
rare due to the infamous chip shortage. I have other ARM machines too
but the Pi 3B is super reliable and straight forward. Try a $10 Zero
for a single core version, but have fun.

On 3/20/23, Lionel Élie Mamane <lionel@mamane.lu> wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics. Is
it at least "not as bad" as amd64, with Intel's Management Engine and
AMD's equivalent? Or is something like a System76 or Puri.sm
amd64-based machine better / just as good?

Do you have specific "ready to buy" (even if lead times are months,
not year+) computers to recommend for that? For a laptop? For a
"beefy" but quiet desktop that won't shy away from compiling
e.g. LibreOffice?

Will popular Debian software "generally work" or will I run into
"many" situations like e.g. Firefox WebRTC doesn't work on Power and
QT 5 doesn't work on Sparc64 (!!!)?

I don't particularly want to get deep into being a porter, but I want
a good desktop to run XFCE, emacs, mutt, gdal, Firefox ESR, etc,
developing my pet software, maybe get back into LibreOffice (a beast
to compile...) development and/or become active as Debian package maintainer again, flashing LineageOS to my Android pocket computers (smartphones) until a better alternative becomes usable, ...

Thanks in advance for your advice,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a non-technical barely qualified opinion but yes. An easy
start is a Raspberry Pi, about a 3B ($35), it's what I'm typing on.
I've got 4 of them. And this one is running Debian, not Raspbian AKA
Raspberry Pi OS. The differences are tiny. Just get a monitor and
keyboard, a couple of SD cards about 32 GB or larger and a Pi. It's
easy to download your first image and get it booted, from there you
can experiment. Install Synaptic the package manager, after that you
search for applications and click on them to install.

There is a Raspberry Pi 4 which is considerably better but relatively
rare due to the infamous chip shortage. I have other ARM machines too
but the Pi 3B is super reliable and straight forward. Try a $10 Zero
for a single core version, but have fun.

On 3/20/23, Lionel Élie Mamane <lionel@mamane.lu> wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics. Is
it at least "not as bad" as amd64, with Intel's Management Engine and
AMD's equivalent? Or is something like a System76 or Puri.sm
amd64-based machine better / just as good?

Do you have specific "ready to buy" (even if lead times are months,
not year+) computers to recommend for that? For a laptop? For a
"beefy" but quiet desktop that won't shy away from compiling
e.g. LibreOffice?

Will popular Debian software "generally work" or will I run into
"many" situations like e.g. Firefox WebRTC doesn't work on Power and
QT 5 doesn't work on Sparc64 (!!!)?

I don't particularly want to get deep into being a porter, but I want
a good desktop to run XFCE, emacs, mutt, gdal, Firefox ESR, etc,
developing my pet software, maybe get back into LibreOffice (a beast
to compile...) development and/or become active as Debian package
maintainer again, flashing LineageOS to my Android pocket computers (smartphones) until a better alternative becomes usable, ...

Thanks in advance for your advice,

--
Lionel

--
-------------
Education is contagious.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Well, I said barely qualified. I retired in 2009 from an IT job
(using and installing Windows) at a local college. With very few
exceptions I've run only Linux on my Pi 3bs since. When I can get a
Pi4 I'll be glad of the extra RAM and buy a few but I do everything on
these Pis. They won't compile something like Firefox, even with much
fiddling with swap.

I had a Pinebook Pro https://www.pine64.org/pinebook-pro/ until it had
a hinge failure and the spare parts situation is dubious but mine is
apart in a box. It would compile Firefox (rock64 also), a couple
other machines would too. I have a rock64 https://www.pine64.org/devices/single-board-computers/rock64/ These
are both Chinese, no Ampere Computing involved. But the RAM size on
every ARM machine I've had is limited to what's built into the SOC,
maybe some use an SODIMM or something now.

None of my computers have a fan, the Pis (and Zeros) will run on a
single 186500 lithium cell. Learning to program the GPU was goal of
mine but that's not portable. I don't have a 400 watt computer
anymore, my latest project is streaming MLB baseball games (on a Pi
3B).

On 3/20/23, Lionel Élie Mamane <lionel@mamane.lu> wrote:

The Raspberrys have to me a reputation of being small cheap "slower"
hackable mini-computers, not "workhorses". Have they scaled up that
much since they were introduced?

Is even the Raspberry Pi 4 even close to 'a beefy but quiet desktop
that won't shy away from compiling e.g. LibreOffice'? I don't know
what hardware it runs, but the buildd for arm64 took 17 hours to build LibreOffice https://buildd.debian.org/status/logs.php?pkg=libreoffice&ver=4%3A7.4.5-2&arch=arm64
and from https://db.debian.org/machines.cgi
the hardware seems to be sponsored by Ampere Computing, so maybe it
uses one of their CPUs?

Also, I'm worried about the memory. My current desktop has as 8.7GB to
10GB memory used when running "nothing in particular", no compilation,
just Exim4 (+ bayesian spam filtering software when an email comes
in), XFCE, Firefox, Emacs, terminal emulator / shell windows, mutt and
a few instant messaging clients. And a Raspberry Pi 4 tops at 8GB?

Or are you saying I should run that as a silent "terminal" to SSH into
my real work machine? Which begs the question of what the work machine
would be :)

And any idea for a laptop?

On Mon, Mar 20, 2023 at 08:16:26PM -0400, Alan Corey wrote:

This is a non-technical barely qualified opinion but yes. An easy
start is a Raspberry Pi, about a 3B ($35), it's what I'm typing on.
I've got 4 of them. And this one is running Debian, not Raspbian AKA
Raspberry Pi OS. The differences are tiny. Just get a monitor and
keyboard, a couple of SD cards about 32 GB or larger and a Pi. It's
easy to download your first image and get it booted, from there you
can experiment. Install Synaptic the package manager, after that you
search for applications and click on them to install.

There is a Raspberry Pi 4 which is considerably better but relatively
rare due to the infamous chip shortage. I have other ARM machines too
but the Pi 3B is super reliable and straight forward. Try a $10 Zero
for a single core version, but have fun.

On 3/20/23, Lionel Élie Mamane <lionel@mamane.lu> wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics. Is
it at least "not as bad" as amd64, with Intel's Management Engine and
AMD's equivalent? Or is something like a System76 or Puri.sm
amd64-based machine better / just as good?

Do you have specific "ready to buy" (even if lead times are months,
not year+) computers to recommend for that? For a laptop? For a
"beefy" but quiet desktop that won't shy away from compiling
e.g. LibreOffice?

Will popular Debian software "generally work" or will I run into
"many" situations like e.g. Firefox WebRTC doesn't work on Power and
QT 5 doesn't work on Sparc64 (!!!)?

I don't particularly want to get deep into being a porter, but I want
a good desktop to run XFCE, emacs, mutt, gdal, Firefox ESR, etc,
developing my pet software, maybe get back into LibreOffice (a beast
to compile...) development and/or become active as Debian package
maintainer again, flashing LineageOS to my Android pocket computers
(smartphones) until a better alternative becomes usable, ...

Thanks in advance for your advice,

--
-------------
Education is contagious.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics.

It depends on what you mean by freedom-respecting. All of the major
ARM SoC vendors now have libre GPU drivers (inc IMGTEC). There may be
various minor drivers that aren't free though depending on devices.
For example sometimes GPS on smartphones uses a proprietary daemon.

Firmware on the other hand is a different matter and quite varied.

For example, the RPi devices start the VideoCore GPU first, proprietary firmware then starts the ARM cores, then starts the ARM boot process.
The LibreRPi folks are reverse engineering this firmware and maybe also
the other cores on the SoC, which are all different ISAs. In addition
there is some DRM but that turns out to be easily bypassed.

https://github.com/librerpi/lk-overlay/ https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt

On lots of other devices (esp SBCs), the ARM core starts first and its
bootrom loads libre bootloaders like u-boot, which load Linux.

On other devices, especially laptops, use UEFI, which is usually a
vendor fork of TianoCore EDK2, possibly not published. There are some
devices that can run mainline libre edk2+edk2-platforms, but the latter
is not available in Debian yet so you would need to package it.

https://github.com/tianocore/edk2-platforms/

Outside boot firmware, most firmware will be proprietary on ARM, just
as it is on x86 or any other platform except the ones where there have
been intensive reverse engineering efforts like RaptorCS POWER devices.

On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform,
other devices have less mainline Linux support or worse freedom issues.

https://wiki.debian.org/Mobile

On laptops, probably the Apple ARM devices are the fastest, but
mainline Linux isn't yet suitable but is gaining ground quickly.
I think there might be some blobs during the boot or something and
the different page size for Apple ARM devices might be a challenge.
Otherwise Lenovo and other vendors have some ARM laptops. Or
there is the PineBook or MNT Reform for more esoteric devices.

https://asahilinux.org/

Not sure about ARM desktops. ARM servers seem problematic, IIRC the
arm64 ones Debian uses for buildds are unstable and the potential
replacements are way too expensive. Not sure of the status here.

Will popular Debian software "generally work"

There aren't many open bugs tagged as affecting ARM ports and most of
them look like build related failures rather than not working. Probably
folks don't bother to usertag their ARM-only bug reports though.

https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-arm%40lists.debian.org
https://wiki.debian.org/Teams/Debbugs/ArchitectureTags

There are of course various build/test issues on ARM ports too.

https://buildd.debian.org/status/architecture.php?a=arm64 https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=arm64 https://ci.debian.net/status/failing/?arch[]=arm64

I don't particularly want to get deep into being a porter

Personally I think users of every non-amd64 port should consider doing
porting work to keep their ports viable, since your personal package
set might not be on the radar of vendors like ARM or other users.

In case you do, we now have a document about the different ways to
contribute to creating new ports (it applies to existing ports too).
Some of the steps may be missing for existing ports, for example all
of the ARM ports are missing a page based on the status template.

https://wiki.debian.org/PortsDocs/New
https://wiki.debian.org/PortTemplate

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmQZIdsACgkQMRa6Xp/6 aaMDaQ/+LBJ+WvEJDwa5Ch9R67MPJhUpL0YSgMVJHrDLLX8jmlGBfaxT7a9To/nU 1jahvuNb9YWZveGjJO48vCo9yOSEdEqcyEM3t5wZQYCCMFoTfem5kLfXij+Voqa8 amiVUvVUDuUNvv2W7T3e//Z4ipL0G+lymHdMvdsvGLE2IQQc9PH1XfZYUt1I96wY G4yPSFQi2Up+5GEVISsEa5+8ZLfPGn8G1GREhtK3R8i0/PdcM+tOWqWVsP7Rjviw nK9S97b9VTrp20Zr062dhpTPF4YKVRghP47rKI7bDTbGtJUBw4oFby6ZFtx5WUXU pvzfT7CyWBpUvG70vhDE7J7NATD2ok6mOzbqeFnWGVgUMyqsQO2glW6N60eosDyi tjWEFajHwqgfmaxNWUXruP8UUwpDuNnz6RySVXNMrptRzbslrSfGC84a+rGmp1ln gzdI8GYcRZZmPo8UKnbYMvapVMd9bzm5bz2xvCzh8OTTEzRabWL16n6sXXlukmdd xCcrJylIKwfSqzVAIsCUganPiov5dJBKwyhSDwMuJ6S7MVr0UdeyfJZSo+kLQhun YAui/Wa1Tn+LsylLOX9GI8wxmqT9Cv+YQZRty5XFcknw48LVjeQhaD6eb0pzUCGZ U/ojDiMnM+9af2MtsuwDN+J3fx+ngkP2Mi2zXFnA30y/KIJAyHI=
=dbnV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I also have an Acer Chromebook that's aarch64, bought because it was Arm to replace the Pinebook. Chromebooks are weird but it does a little Debian Bullseye running under Chrome OS. It runs for days on a battery charge,
quite fun compared to the usual Intel/AMD power hungry beasts.

On Mon, Mar 20, 2023 at 11:21 PM Paul Wise <pabs@debian.org> wrote:

On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics.

It depends on what you mean by freedom-respecting. All of the major
ARM SoC vendors now have libre GPU drivers (inc IMGTEC). There may be
various minor drivers that aren't free though depending on devices.
For example sometimes GPS on smartphones uses a proprietary daemon.

Firmware on the other hand is a different matter and quite varied.

For example, the RPi devices start the VideoCore GPU first, proprietary firmware then starts the ARM cores, then starts the ARM boot process.
The LibreRPi folks are reverse engineering this firmware and maybe also
the other cores on the SoC, which are all different ISAs. In addition
there is some DRM but that turns out to be easily bypassed.

https://github.com/librerpi/lk-overlay/

https://github.com/librerpi/rpi-open-firmware/blob/master/docs/cracking-rpi4-hmac.txt

On lots of other devices (esp SBCs), the ARM core starts first and its bootrom loads libre bootloaders like u-boot, which load Linux.

On other devices, especially laptops, use UEFI, which is usually a
vendor fork of TianoCore EDK2, possibly not published. There are some
devices that can run mainline libre edk2+edk2-platforms, but the latter
is not available in Debian yet so you would need to package it.

https://github.com/tianocore/edk2-platforms/

Outside boot firmware, most firmware will be proprietary on ARM, just
as it is on x86 or any other platform except the ones where there have
been intensive reverse engineering efforts like RaptorCS POWER devices.

On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform,
other devices have less mainline Linux support or worse freedom issues.

https://wiki.debian.org/Mobile

On laptops, probably the Apple ARM devices are the fastest, but
mainline Linux isn't yet suitable but is gaining ground quickly.
I think there might be some blobs during the boot or something and
the different page size for Apple ARM devices might be a challenge.
Otherwise Lenovo and other vendors have some ARM laptops. Or
there is the PineBook or MNT Reform for more esoteric devices.

https://asahilinux.org/

Not sure about ARM desktops. ARM servers seem problematic, IIRC the
arm64 ones Debian uses for buildds are unstable and the potential replacements are way too expensive. Not sure of the status here.

Will popular Debian software "generally work"

There aren't many open bugs tagged as affecting ARM ports and most of
them look like build related failures rather than not working. Probably
folks don't bother to usertag their ARM-only bug reports though.

https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-arm%40lists.debian.org
https://wiki.debian.org/Teams/Debbugs/ArchitectureTags

There are of course various build/test issues on ARM ports too.

https://buildd.debian.org/status/architecture.php?a=arm64 https://udd.debian.org/cgi-bin/ftbfs.cgi?arch=arm64 https://ci.debian.net/status/failing/?arch[]=arm64

I don't particularly want to get deep into being a porter

Personally I think users of every non-amd64 port should consider doing porting work to keep their ports viable, since your personal package
set might not be on the radar of vendors like ARM or other users.

In case you do, we now have a document about the different ways to
contribute to creating new ports (it applies to existing ports too).
Some of the steps may be missing for existing ports, for example all
of the ARM ports are missing a page based on the status template.

https://wiki.debian.org/PortsDocs/New
https://wiki.debian.org/PortTemplate

--
bye,
pabs

https://wiki.debian.org/PaulWise

--
-------------
Education is contagious.

<div dir="ltr">I also have an Acer Chromebook that&#39;s aarch64, bought because it was Arm to replace the Pinebook.  Chromebooks are weird but it does a little Debian Bullseye running under Chrome OS.  It runs for days on a battery charge, quite 
fun compared to the usual Intel/AMD power hungry  beasts.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 20, 2023 at 11:21 PM Paul Wise &lt;<a href="mailto:pabs@debian.org">pabs@debian.org</a>&gt; wrote:<br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:<br>

&gt; Would an ARM-based machine be a good freedom-respecting computer to<br> &gt; run Debian on? I read the Raptor/Power guys saying modern ARM has<br>
&gt; freedom problems in a, but I haven&#39;t seen them go into specifics.<br>

It depends on what you mean by freedo

On Tue, Mar 21, 2023 at 11:17:50AM +0800, Paul Wise wrote:

On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics.

It depends on what you mean by freedom-respecting.

Mostly, I wanted to understand the main alternatives and their level
of freedom. In an ideal world, I'd like every bit of software,
drivers, firmware, etc to be FLOSS. Pragmatically, I won't reject a
platform that is "less bad" than the amd64 I'd get from the store.

Thank you for the good overview!

For example, the RPi devices start the VideoCore GPU first,
proprietary firmware then starts the ARM cores, then starts the ARM
boot process.

Oh. So less good than I expected.

On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform,
other devices have less mainline Linux support or worse freedom
issues.

Mobile... let's say I consider this a different subject, sadly. we've
been having different projects for a long time (I remember OpenMoko /
GTA0x, also some early Compaq PDAs??) but IMO nothing I can use in
daily life. I have a Librem 5, I ordered it... I think in 2017. I
don't consider it usable for daily life, at least "out of the box +
install available OS upgrades".

On laptops, probably the Apple ARM devices are the fastest, but
mainline Linux isn't yet suitable but is gaining ground quickly. I
think there might be some blobs during the boot or something and the different page size for Apple ARM devices might be a challenge.

Yes, I've been excited about it since they started; recently I took a
look at
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon
they say "somewhere between x86 PCs and a libre-first system like the
Talos II in terms of freedom to replace firmware and boot components;
while a number of blobs are required in order to boot the system, none
of those have the ability to take over the OS or compromise it
post-boot", but also:

* Brick recovery / total system flash (DFU) requires phoning home

Which I understand an Apple account, tying the hardware to the Apple
account, and Apple's permission to do a "total system flash". Err...
feels like jumping out of the frying pan into the fire?

Otherwise Lenovo and other vendors have some ARM laptops.

Oh, I'll try to find them.

Or there is the PineBook or MNT Reform for more esoteric devices.

The PineBook shop page explicitly says "don't order if you are looking
for a substitute for your x86 laptop" :-|

I don't particularly want to get deep into being a porter

Personally I think users of every non-amd64 port should consider
doing porting work to keep their ports viable, since your personal
package set might not be on the radar of vendors like ARM or other
users.

"Some work", like submitting patches to fix that-or-that package for
the architecture, yes, that's part of FLOSS developer / enthusiast
life, and I'd probably enjoy the work. Even running a buildd, if
that's what lacking. But I don't want it to be the majority of my
"free software time" either. And I need a machine that works to do the
work, obviously.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/23 03:45, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 11:17:50AM +0800, Paul Wise wrote:

On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics.

It depends on what you mean by freedom-respecting.

Mostly, I wanted to understand the main alternatives and their level
of freedom. In an ideal world, I'd like every bit of software,
drivers, firmware, etc to be FLOSS. Pragmatically, I won't reject a
platform that is "less bad" than the amd64 I'd get from the store.

Thank you for the good overview!

For example, the RPi devices start the VideoCore GPU first,
proprietary firmware then starts the ARM cores, then starts the ARM
boot process.

Oh. So less good than I expected.

On mobile devices, look at PinePhone, Librem 5 or MNT Pocket Reform,
other devices have less mainline Linux support or worse freedom
issues.

Mobile... let's say I consider this a different subject, sadly. we've
been having different projects for a long time (I remember OpenMoko /
GTA0x, also some early Compaq PDAs??) but IMO nothing I can use in
daily life. I have a Librem 5, I ordered it... I think in 2017. I
don't consider it usable for daily life, at least "out of the box +
install available OS upgrades".

On laptops, probably the Apple ARM devices are the fastest, but
mainline Linux isn't yet suitable but is gaining ground quickly. I
think there might be some blobs during the boot or something and the
different page size for Apple ARM devices might be a challenge.

Yes, I've been excited about it since they started; recently I took a
look at
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon
they say "somewhere between x86 PCs and a libre-first system like the
Talos II in terms of freedom to replace firmware and boot components;
while a number of blobs are required in order to boot the system, none
of those have the ability to take over the OS or compromise it
post-boot", but also:

* Brick recovery / total system flash (DFU) requires phoning home

Which I understand an Apple account, tying the hardware to the Apple
account, and Apple's permission to do a "total system flash". Err...
feels like jumping out of the frying pan into the fire?

Otherwise Lenovo and other vendors have some ARM laptops.

Oh, I'll try to find them.

Or there is the PineBook or MNT Reform for more esoteric devices.

The PineBook shop page explicitly says "don't order if you are looking
for a substitute for your x86 laptop" :-|

I don't particularly want to get deep into being a porter

Personally I think users of every non-amd64 port should consider
doing porting work to keep their ports viable, since your personal
package set might not be on the radar of vendors like ARM or other
users.

"Some work", like submitting patches to fix that-or-that package for
the architecture, yes, that's part of FLOSS developer / enthusiast
life, and I'd probably enjoy the work. Even running a buildd, if
that's what lacking. But I don't want it to be the majority of my
"free software time" either. And I need a machine that works to do the
work, obviously.

.

If I can chime in here, the 3d printer world has embraced the arms quite
well. I have a half assembled voron kit, comes with an orange pi to run
klipper and octoprint. And I am also running the same recipe on a 4 pack
of banana pi m5's, with 4G of dram, using the armbian version of
bullseye. The only failures so far have been the gnome screenblanker and printing to cups shared printers. The bpi is a 4 core running at 2 ghz
and otherwise runs everything else nicely.

Adding a $5 pi case, and a separate 5 volt 5 amp supply, it runs a 27"
hp monitor just as well as this asus mobo with 32g of dram and a 6 core
i5. The big monitor actually costs a little more but a working system
here was about $240. And stability? Power failure to power failure has
been my experience. A ups and a standby in the back yard that makes
power failures an 8 second thing renders that moot.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 21, 2023 at 08:45:13AM +0100, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 11:17:50AM +0800, Paul Wise wrote:

On Tue, 2023-03-21 at 00:34 +0100, Lionel Élie Mamane wrote:

Would an ARM-based machine be a good freedom-respecting computer to
run Debian on? I read the Raptor/Power guys saying modern ARM has
freedom problems in a, but I haven't seen them go into specifics.

It depends on what you mean by freedom-respecting.

If you can get a Raspberry Pi 4 - it woill work as a small desktop, more
or less silently. To fit extra disks you'll need an add on case - something like the Argon which will take NVME. There are bottlenecks. It's still essentially a phone SOC. It's not *free* because blobs and if you
want peripherals, you more or less are tied to running Raspberry Pi OS.

I'm not sure I'd build Libreoffice on anything ARM unless you can
find an Ampere server or similar.

Debian folks I know run on ex-business Thinkpads or older Apple Macbooks.
If you can swallow using Intel, the Thinkpads are good but not as robust
as they once were - and you really need a T series. One stick of RAM
is almost always soldered (unless you get the P series workstation replacements).

The suggestion of someone like QuietPC to just build you a box with
as much RAM as you can get is not a bad one. The AMD Threadrippers
work well for grunt work but run hot.

Mostly, I wanted to understand the main alternatives and their level
of freedom. In an ideal world, I'd like every bit of software,
drivers, firmware, etc to be FLOSS. Pragmatically, I won't reject a
platform that is "less bad" than the amd64 I'd get from the store.

Oh, I'll try to find them.

These are like unicorns: you might need to talk to Mark Pearson of Lenovo.
A couple of Yoga devices were released a few years ago.

Personally I think users of every non-amd64 port should consider
doing porting work to keep their ports viable, since your personal
package set might not be on the radar of vendors like ARM or other
users.

I feel as if it's only Debian that keeps non-x86 / arm64 alive.

"Some work", like submitting patches to fix that-or-that package for
the architecture, yes, that's part of FLOSS developer / enthusiast
life, and I'd probably enjoy the work. Even running a buildd, if
that's what lacking. But I don't want it to be the majority of my
"free software time" either. And I need a machine that works to do the
work, obviously.

Hope this helps - it's probably off topic for Debian ARM now so I'll
disappear.

Andy Cater

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 21, 2023 at 08:33:26AM +0000, Andrew M.A. Cater wrote:

If you can get a Raspberry Pi 4 - it woill work as a small desktop,
more or less silently. To fit extra disks you'll need an add on case
- something like the Argon which will take NVME. There are
bottlenecks. It's still essentially a phone SOC. It's not *free*
because blobs and if you want peripherals, you more or less are tied
to running Raspberry Pi OS.

What ties me into Raspberry Pi OS for peripherals? Non-free drivers
and/or firmware that cannot get into Debian, or just "it is not
packaged for Debian because nobody did the work but could be"?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/21/23 12:11, Andrew M.A. Cater wrote:

On Tue, Mar 21, 2023 at 11:59:08AM +0100, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 08:33:26AM +0000, Andrew M.A. Cater wrote:

If you can get a Raspberry Pi 4 - it woill work as a small desktop,
more or less silently. To fit extra disks you'll need an add on case
- something like the Argon which will take NVME. There are
bottlenecks. It's still essentially a phone SOC. It's not *free*
because blobs and if you want peripherals, you more or less are tied
to running Raspberry Pi OS.

What ties me into Raspberry Pi OS for peripherals? Non-free drivers
and/or firmware that cannot get into Debian, or just "it is not
packaged for Debian because nobody did the work but could be"?

The Raspberry Pi packaged kernel and dtb and the Pi "hat" ecosystem.

The peripheral drivers thing is particularly annoying because the dtb's
are not that much - I have a GPS hat for which there is no obvious
driver except in Raspberry Pi forked kernel, for example.

I'm in a similar situation: I'm using SPI to talk to a peripheral, and
the Raspberry Pi's SPI master is not available in Debian because of
missing DTB support (the kernel driver is there but the hardware is
disabled by the stock kernel.org DTB).

Both Raspberry Pi OS and Ubuntu ship updated (optional) DTBs that enable
the SPI port.


--
Sebastian Kuzminsky

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 21, 2023 at 11:59:08AM +0100, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 08:33:26AM +0000, Andrew M.A. Cater wrote:

If you can get a Raspberry Pi 4 - it woill work as a small desktop,
more or less silently. To fit extra disks you'll need an add on case
- something like the Argon which will take NVME. There are
bottlenecks. It's still essentially a phone SOC. It's not *free*
because blobs and if you want peripherals, you more or less are tied
to running Raspberry Pi OS.

What ties me into Raspberry Pi OS for peripherals? Non-free drivers
and/or firmware that cannot get into Debian, or just "it is not
packaged for Debian because nobody did the work but could be"?

The Raspberry Pi packaged kernel and dtb and the Pi "hat" ecosystem.

The peripheral drivers thing is particularly annoying because the dtb's
are not that much - I have a GPS hat for which there is no obvious
driver except in Raspberry Pi forked kernel, for example.

Andy Cater

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lionel Élie Mamane dijo [Tue, Mar 21, 2023 at 02:04:55AM +0100]:

The Raspberrys have to me a reputation of being small cheap "slower"
hackable mini-computers, not "workhorses". Have they scaled up that
much since they were introduced?

No.

They scaled up quite a bit; I would not dare do this same experiment
on a RPi0 or 1 (armel)... But still, they are far, far apart from
other ARM systems.

This discussion prompted me to make this into a blog post:

https://gwolf.org/2023/03/impact-of-parallelism-and-processor-architecture-while-building-a-kernel.html?

Is even the Raspberry Pi 4 even close to 'a beefy but quiet desktop
that won't shy away from compiling e.g. LibreOffice'? I don't know
what hardware it runs, but the buildd for arm64 took 17 hours to build LibreOffice https://buildd.debian.org/status/logs.php?pkg=libreoffice&ver=4%3A7.4.5-2&arch=arm64
and from https://db.debian.org/machines.cgi
the hardware seems to be sponsored by Ampere Computing, so maybe it
uses one of their CPUs?

My main personal laptop nowadays is an ARM machine; you can see that
with "-j 8" I built a Linux kernel in ~25.5 minutes (and ~100 minutes
with no parallelization). The Raspberry achieved ~101 minutes with its
four cores working towards the build. A decently-new and
decently-beefy small server my workplace bought in early 2021 got 21.5
minutes single-core and got down to less than three minutes when
building with its 8 cores, hyperthreading enabled (so "-j 16").

Also, I'm worried about the memory. My current desktop has as 8.7GB to
10GB memory used when running "nothing in particular", no compilation,
just Exim4 (+ bayesian spam filtering software when an email comes
in), XFCE, Firefox, Emacs, terminal emulator / shell windows, mutt and
a few instant messaging clients. And a Raspberry Pi 4 tops at 8GB?

Keep in mind a great part of that memory can be mapped but not active
— mapped libraries and executables, or even data that's sent "down" to virtual memory. Not all of it hurts. FWIW, my previous machine at home
had 12GB, and I switched for a 8GB system with a newer SSD. It feels
much better.

Or are you saying I should run that as a silent "terminal" to SSH into
my real work machine? Which begs the question of what the work machine
would be :)

And any idea for a laptop?

There are several decently supported ARM laptops -- however, not
everybody has the same definition of decency.

I'm very happy with the performance of my C630. I bought it
second-hand for US$300 (IIRC it started roughly at twice that price in
2019); I installed with a _modified_ Debian installer¹; it requires
several bits of firmware that it "borrows" from the Windows
installation, and several bits of hardware are not supported (i.e. I
have two sets of kernels, one that's mainline and works "mostly fine"
and IIRC even has audio support, but does not support external video,
and one that carries some patches to enable external video; given I
use this laptop to teach my classes, I almost always use this patched
kernel).

Nowadays, many people report good support with Lenovo's high-range ARM
system, the Thinkpad X13S. I'd jump for mine if I wanted to buy a

US$1500 laptop (which I don't, of course!)

Good luck switching over to ARM! 😉

¹ https://github.com/aarch64-laptops/debian-cdimage

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRNFAUGU6QC1zaHBJ0kBMlUbhRTYAUCZBoDmwAKCRAkBMlUbhRT YEzKAP9wkHYJMxZ4HYpU+hNl2rEbRBJK8KSLbNM+X8EzCjUjvQEArHJAIT4fVfR0 vhbcXlzHJ2O4Dr1j9sUFy/D23azqCQs=
=qBCf
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 21, 2023 at 01:21:04PM -0600, Gunnar Wolf wrote:

Nowadays, many people report good support with Lenovo's high-range ARM system, the Thinkpad X13S. I'd jump for mine if I wanted to buy a

US$1500 laptop (which I don't, of course!)

It has a trackpoint! Killer feature. It seems to have decent
performance; the press says it compares favourably to Intel's mobile
offering in December 2021 for less power draw, even though... really
slower than Apple M1 (like 2× to 2.5×...). But if it actually works
like right now (while GNU/Linux on Apple Silicon is still very, very
rough), and again, it has a trackpoint.

I think I've decided :) Thanks for the pointer!

Funnily it "start at" 994.95 USD "special discount, but value is 1809
USD" on the USA store and 1 829 EUR (1511.57 EUR without VAT, maybe a
better comparison) on the Belgium/Luxembourg store :-| However, that's
in most part because Belgium only has higher-spec stuff available,
makes some higher spec stuff the default (can be selected down) and
has three years warranty (1 year for USA).

If one actually configures them similar, the USA is between 1306.80
USD to 1475.80 USD and Belgium 1546.28 EUR (without VAT). They same
"without VAT" price for Luxembourg instead of (like others...) just
raising the price to match the same "total price".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2023-03-21 at 20:57 +0100, Lionel Élie Mamane wrote:

I think I've decided :) Thanks for the pointer!

Please note the Lenovo discount for Debian members:

https://wiki.debian.org/MemberBenefits#Lenovo

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmQaQ30ACgkQMRa6Xp/6 aaPoOA/8CmZsmqHw25PIRvT3bsOxe1VXVT1wnMFN/8HSO+cdbGpEmvWIhhVAp2hn HWb2r9LBjJfJQg6xSdBA3ck2u2VUE2cl+QSPa6j0KFloSMkLOvv7N0SH4hA6fNEb u0/aIt99XUmxKZOC3CpGeMvfrrQbmxy6pF4YWMJyRzMmar9L31EgPRDQYrZlF9j3 NoSQQKedR2Fp4hblfjrC3P0mOgb+Wp4bDo3V9ANb7AI61yP/4bLvLDdoPQO23IlR +umijHIhHaLJ4OxgCbArCu/BX610qljuVxDt199qrJzJzXTpj6Mc11jYx9HTGqAs tj/Af2JngeHKwrOSV14suNikW3cMOB6K+j8KoslooXMxO+EVo7IaJgKb/RH6smtd WlhBIFw3gthvnH/vj8ZTEkhhC2NwaOuW5gfKiVZVVqaJ87MlsiYRSueRn2IBxLmc PZM4wGme0rwMFcA3aot0WL/JEi0Lr+FgsakGabkIktot+0hxH3Njjq0YCe7SmYH4 eZF2eN3teaj8ZCINjPmQnWLTc1cqcOmGjioYgnyxpq5FEJRg5W8RkVZmugG7ZnUI FEekGAH8t41/8grDLEDKU9WYTTN/wmKUWFEZt5TmKztVMDk9LVepzdASv6t497pR 0bjuMvY46lRsJVgZUQ9I6u0piOf9XVqJy8T3ANbLi0Z5ZqqPdJE=
=L5mb
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Mar 22, 2023 at 07:53:36AM +0800, Paul Wise wrote:

Please note the Lenovo discount for Debian members:

https://wiki.debian.org/MemberBenefits#Lenovo

Oh, schweet, thanks indeed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-21 20:57 +0100, Lionel Élie Mamane wrote:

On Tue, Mar 21, 2023 at 01:21:04PM -0600, Gunnar Wolf wrote:

Nowadays, many people report good support with Lenovo's high-range ARM system, the Thinkpad X13S.

It has a trackpoint! Killer feature. It seems to have decent
performance; the press says it compares favourably to Intel's mobile
offering in December 2021 for less power draw, even though... really
slower than Apple M1 (like 2× to 2.5×...). But if it actually works
like right now (while GNU/Linux on Apple Silicon is still very, very
rough), and again, it has a trackpoint.

The X13s is nice hardware, but AIUI there are still various things
that need upstreaming to the mainline kernel before everything works properly.

The one major downside you do need to be aware of is that you cannot
run VMs - the machine boots linux in EL1 instead of EL2 so a
hypervisor cannot get control at the right level. There is a
proprietary BIOS mechanism for Windows to get hypervisor authority so
VMs work fine on Windows.

This is Qualcomm's fault, but they don't want to fix it. Lenovo do, so probably/hopefully some solution will become available eventually, but
right now you are knackered on this front.

I think I've decided :) Thanks for the pointer!

If the above is not a problem for you then it is indeed nice hardware.

Asahi linux on Apple M1 hardware is also viable. It's also very nice
hardware (faster than the x13 I believe), and the bootloader is not
crippled. But Apple do not co-operate at all so everything is reverse-engineered. Which means currently most stuff works but power
management is significantly lacking. I have the july 2022 release and
it runs debian very nicely indeed, but the machine doesn't sleep - I
have to reboot every time. And I have no GPU acceleration, although it's
more than fast enough for my purposes anyway, but I guess it's not power-efficient doing software rendering.

I understand that both those things are fixed with the current release. https://asahilinux.org/blog/

Those two machines are the only currently available candidates for
decent performance laptops, just as good as X86. There are also
expensive server-grade machines, and a range other devices which make
adequate computers. like the Pi4, and various rockchip, allwinner,
marvell etc devices.

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmQc4FoACgkQ+4YyUahv nkfliRAAutZ1Hj90vGxLBPbm3KLZDkKE6JXvFgThidP+aXtyFg2E1O265rjOxfSA g69emB6q5SaeB3Z9Gm9eg7anmlrcaLfbFElu1VEFh7LcTfCOYMIbXP/P2Upc6Y1K NzRV8ImKZsswpQiKhYedcvey38Bfere0qtYhbwR1ZDlF+eyjRaGV1QUWJoBtJZai 29aLGGFvntphpsbFZtdddMBtdGHGs27v9oly/CL6y+Z7mfXWwKVLm//DRTcPpPV6 JqdqDjn/dNnTjdrRB98DiGq5kKNZJwMkCtpWWgJvFR5f3T6czfelL8197wxZ8f09 PB3hmaZfyUiZI+OAkAK/DDz5tfB4PMqyxsbSUrlFt5vto93UHZQCfIwA8WQEwyL/ tviM7J0QF11/yYpq6RpWW0+fEVaFb798oSybAD3jepCpxoT3YpPg35m7vat3XX1l n0jtyiH5ZcuL4EQKF/u1yfXyLPYeb5ZrmbYw7RVpMWCcUjsgcIwuctAwHbSGcHhH jwB2mgWIyy+EcU/ACnpfqZxZ7gVLL7s3gVMzefv1J2q44jL30GiEw610oGd2Z0Vt wjdLNKxekh8S4nEzOhpbH7fMyMlIDFQfPWH4WgNGJ/X+cp5XTHXnXv9pkb+lYYjG PjPpmNmrIv7D5S8gA/xeDfgmBKFkbG/H1wyJngdKU+wSF55Xu88=
=ybMz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-21 11:17 +0800, Paul Wise wrote:

Not sure about ARM desktops. ARM servers seem problematic, IIRC the
arm64 ones Debian uses for buildds are unstable and the potential replacements are way too expensive. Not sure of the status here.

The arm64 servers debian uses for buildds are fine. We have a number
of Ampere and Applied Micro boxes.

You are probably thinking of the marvell 78000 32-bit hardware which
is getting pretty old and somewhat flaky and has mostly been retired
except for porter boxen.

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmQc4bgACgkQ+4YyUahv nkfT4Q/9EG1Yjjjd+RKJYFxCUvDRIgMZ+X2/VGOlDAxSxIIL0CVSlCSRkMW9CF4W JOjDSEzHuwqefWGK39MwowDCrTsMIvPFHx/Db2atvGSHLsjtqEUrOEyINjadB74u v7TmWXZQ2hhn/w7nWW0SjZF8OZwK9GdVo8ol+efmJhLJdJOkch2euV4fuSB/eYPM a3fiYftchmwejRGldyQhkrHTGqx5Ox2fEZkto9UG79sHVYkLtNc2ug1wyW8YRDy/ p+dqawcd3IZVa6nNC3Bw1b1tK2OYxWuJJR1fXWuIZd2e3FiXtVz4lxCK6qVii5Jm SV469xfaamrxGwyyfxYlKRX2u5ESKQRUsXiZuI1eUhdSzZuwSpqjNhlG5neBQ/gl TylFzxdeDImZoLBrJBWPDeMMTtzbX9U1f1NU6x263XAXPYLSipCssp5yrPi5riky sOh4ecgvKL6AtcogP5yTNBUkgzksCX84WKo4MFqWjjJ8mtxOJQOGUeGGJxzGR3hp b100XPBP8iUb/F8rSPH/oZltfJYMynrAggJMbP3LCvavh18IbQ821KKbY01QB0Jb x3jA6fKp/NTmXblpC06JOGsMLw2LSqBRrNOb2D3PdnEvD5IzH9Zg9uZ7irjryaQU bHFAUfEzx9EEr+fAvJCqDBQsnYxpjVkIVKltaPmKLsZhAMdSPeo=
=ZeMj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2023-03-23 at 23:33 +0000, Wookey wrote:

The arm64 servers debian uses for buildds are fine.

DSA often complain on #debian-admin about how flaky they are and often
have to reset them, there were a few jokes about rebooting from cron,
also the release team arch qualifications have a note about this:

 * concerns-dsa: arm64/armhf/armel: yes: unstable and ageing hardware

https://release.debian.org/bookworm/arch_qualify.html

PS: DSA recently added a requirement for ports to publicly document how
they plan to meet DSA's hardware requirements. While this was initially
just for riscv64 (as a proposed official port), it would be good if all existing ports, including the ARM ones, had such a document too.

https://dsa.debian.org/ports/hardware-requirements/ https://wiki.debian.org/HardwareQualification

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmQeirIACgkQMRa6Xp/6 aaNvfA/+LpNGh4GgGbJbpKNNVqvVd0LvKbBwC17yuPiK7jdK+x1k/NS9IIgudZ2/ dekFHu19PhnJi7j5VKGR1+SnOJOp5E9NQti5U2GIXKFWRhKo8LOO9T60cJuweUwa 2/6pUsslDvUFQBkGrMz7szVQRDzbe53qOgQkinr/PBZYJ7mtMIcEhLYzlhnVGVzz /MadKEioP3B0utSkfPXwY2Xi7adw5zNTSIIRWNGLXB27WDBZF1g6SepVRtN3n89/ XnQgaAfH9XJsAyZs/w5mgyJyL2Dl9tXM80QyNdFe2vQfwXw/oqL6CdkBL4j+cMj8 AQ0IlCp6KILIwqJn7N1eoXtMC7F0IYaY8SKujUzCinNPWFG9qde6Nqu3EK+o6JdG 9q72Oj88QVM1uVHrVaximZNWJoqKETghVNI1KPvhWqGkwqoRMpoAE8E0BuL2Ozvt 9wusbpwlQWDTF1Kx7r6xyazPl2Gr8x/KCpUysWt3fG1HsLP233F99sXcLIE93BDp +78+Q8nmWxKTqji2qZSZkOu59PYHqyIAMvGzyNkfEFICx3+0P8QU8W1vbPomsFef 8UQ02xsYRvystMmdC5irOUGEDH+ZddjqwWnfb/Z631MSwuDR5ttwNUahhoWC9wK1 rf9aFSFvpvHhPftUa3qTcSf4gmE7WK5pwKYcD+wPCdl7bvzii6U=
=EqMA
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-25 13:46 +0800, Paul Wise wrote:

On Thu, 2023-03-23 at 23:33 +0000, Wookey wrote:

The arm64 servers debian uses for buildds are fine.

DSA often complain on #debian-admin about how flaky they are and often
have to reset them, there were a few jokes about rebooting from cron,
also the release team arch qualifications have a note about this:

 * concerns-dsa: arm64/armhf/armel: yes: unstable and ageing hardware

I still think that's referring to the 32-bit machines. I'm a buildd
admin for those ports and the machines on this site and I'm not aware
of problems with the 64-bit machines, and I don't get Nagios messages
about them having gone down/back up, like I do about the armhf/armel
hardware. Perhaps they are happenning but I'm not on the right
alias/list so don't see them? I thought I was getting all monitoring
messages for machines on this site

So if there is an issue there we have a communications problem as well
as a hardware problem. I'm sure we can get new arm64 buildds if we
need them.

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmQe5rkACgkQ+4YyUahv nkdFfg//R2rrMPIGoL0kY3Tg81H0rdKBpxUIey8agMEGKvKmsFT92QbjbRCoo1il oT60710/38GiWiopHYqolXr3UZpERI1Gg0P9c6g8irmRIQvqZb0+ITjphUJvI/hj ZstWWZFoPkvtpWgjJjGgPEd6WRYR1RV41bdrp8oR7AhSiufa17FJxD5RYfqDUMB5 v+94sCnV9nLsnJuaznV0n6iHoIJK7LojyK2vIdud9OTlBXuhWXBGqnwCyuVHyllF TcdjP7htYJT1VEz5AV9BKjnc21cldLsRBIg8+lAz2CNdbPPRTA8eiTjX9WpDGWGi A89ltLi4ur+gY1IAF+ex2JQKvBLHdC1F2iHp5unLhk2fJQuOfJ7qLD8MS1iNQWad Q8WKXFroJ5kDgQe/pB1b0WRw2ierwboXkIHppvFmfexFqEAyTgwvl7ksysjjVOIq 1Gi6rSAMccseAzvWPef7zrb2vCOS5FgImGooHar3OZQl/VMVjHKOceFCH/P7rh7L dp+Lr/6z8ZLOoBbJF114RSt3SyCrSZxhUZIFjnFZNlSB+aYgAqfDQjMKhABfdqwe EdPx7727lkkX5lelEnYEyiDCR0lBKu4xakWUoIoUvUT8fdUYlteVW7vx6m4sVw20 B7dMVScEMaXpgLdKh+ZBRJbatiDga1EDAd1EaE93sDJECrpUmNI=
=fMIx
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Let me answer that with both my wanna-build and DSA hats.

On 2023-03-25 12:19, Wookey wrote:

On 2023-03-25 13:46 +0800, Paul Wise wrote:

On Thu, 2023-03-23 at 23:33 +0000, Wookey wrote:

The arm64 servers debian uses for buildds are fine.

DSA often complain on #debian-admin about how flaky they are and often
have to reset them, there were a few jokes about rebooting from cron,
also the release team arch qualifications have a note about this:

 * concerns-dsa: arm64/armhf/armel: yes: unstable and ageing hardware

I still think that's referring to the 32-bit machines. I'm a buildd

The 32-bit buildds are running quite stable besides a few disks dying,
given their age.

However they are difficult to manage remotely (they don't start
automatically after power cycle) and more importantly they are slow,
only have 4GB of RAM and are limited to 3GB address space.

We were using them until recently, but given that the kernel has gotten
support for building armel and armhf in a chroot, they are currently
disabled, although they are not yet decommissioned.

admin for those ports and the machines on this site and I'm not aware
of problems with the 64-bit machines, and I don't get Nagios messages
about them having gone down/back up, like I do about the armhf/armel hardware. Perhaps they are happenning but I'm not on the right
alias/list so don't see them?

The 3 arm64 boards running at ARM are pretty fine, we do not have any
issues with them, however they start to be old.

On the other hand we have many issues with the Ampere servers hosted at
UBC and the Applied Micro servers hosted at Conova. All of them crash
regularly (a few times per week in total) and need a powercycle. In
addition the bullseye kernel does not work on Applied Micro servers, so
we are currently stuck with buster on them :(.

I thought I was getting all monitoring
messages for machines on this site

My guess is that you don't receive any notification as the buildds
running on arm64 hardware are VMs on the above hosts. From that point of
view, the buildds are running fine, however the underlying hosts are
not.

So if there is an issue there we have a communications problem as well
as a hardware problem. I'm sure we can get new arm64 buildds if we
need them.

Yes please. It's becoming urgent to get new ARM64 hardware to overcome
all those issues, and we (DSA) failed to find new hardware to buy at a
decent price.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmQgHbAACgkQE4jA+Jno M2vHyA//fpMv+5zv02QRslbD5p7rE+kBS31ioRiyZ/WjqYPSlE2fvPaRFGRgbx7+ A0djAmF4DtEdbxT5T2Hmm2VW5zcuTenQ0fEB1P1GynupBEvM4F+NMTIQBOpX7T0V htXIQMmxe0Fgxn8v5VG1OZ5JFFYwnz3L8G8pFPhqskDv7uxHKAmlu16l+EKxytNz vp2hLLE101mRqcZml7Rrn8KaCULRYtM8v/orFnq8INMIP4TC65Le+lgr9SyMXyTE 9nX30gLEVD3luajK08QoNOn2jvNwdsDjlae9MC3p88gURvzt4hgfQhakzmFgKnS8 X+UktLJV3/JwRpGcD1UxmRDptiQPl7u3Jq3EBhCmbWd6QtqtJgrblmAhpbe78N3n nZXBzL2W13/oSz8mEvqAVJ87jnm+lxoB/cFnV27gBslwrj8MYXyJsa0T8A70CyDl jqy0QD93Ug4F+6G+ADgSoq1Fo8vX/75PlzCDNuUUYamTTfCUeWetCNe3+3cKC2Uo LGcX/Up3/y8rc/VKTi9Q88brecy0FP/bAF0XhPmtkavs7MyhCwXwtLoUngH6U91l bDcWUT/7lGXdX39Ij6c3qido0pz4nsUUG37UKTrVOtKRwypQ5My7pNPkHW5utkQI RZbe1Ornox/FzQew5QdwTeAFz7ZiYTk3q45x1PJLdKztelkFAO4=
=bQwf
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet

On 2023-03-26 12:25 +0200, Aurelien Jarno wrote:

The 3 arm64 boards running at ARM are pretty fine, we do not have any
issues with them, however they start to be old.

On the other hand we have many issues with the Ampere servers hosted at
UBC and the Applied Micro servers hosted at Conova. All of them crash regularly (a few times per week in total) and need a powercycle. In
addition the bullseye kernel does not work on Applied Micro servers, so
we are currently stuck with buster on them :(.

OK. That's not good. Can you say which hardware those machines are?
Our buildd database does not say what actual kit is in use (just the manufacturer), and I don't have rights to read the detailed buildd
admin info on the UBC and conova sites.

[ Aside: what would it take to put an extra field into our machine
database to specify what hardware each machine was? It can sometimes
be tricky to separate Model/motherboard/CPU as the required bit of
info but it would be really useful to write something more detailed
down both for issues like this and debugging. ]

My guess is that all the Conova machine are Mustangs, and the UBC machines
are emags? Is that right?

Some enquiries tell me that both these machines types are reliable
(although the mustangs are slow) at OBS and Yocto, so they can be OK,
but there is certainly much faster kit available now (Ampere Altra).

Is there a bug about the boot failure on the Applied Micro machines? I
just failed to find one. If we know what hardware it is we can
investigate, because that does seem like something that should be
fixed.

I'm sure we can get new arm64 buildds if we need them.

Yes please. It's becoming urgent to get new ARM64 hardware to overcome
all those issues, and we (DSA) failed to find new hardware to buy at a
decent price.

OK. I'll see what can be done. I see Altra servers are from
$7000-$53000 on https://store.avantek.co.uk/arm-servers.html.

What does DSA consider 'decent'? I guess we'd prefer the resilience of
a couple of reasonable machines over one ridiculously manly one. A bit
of configury on the Aventek site suggests that basic ARM Altra servers
cost about twice as much as AMD ones for similar specs
(cores/RAM/disk), but then the power consumption is less than half. I
don't know how the performance actually compares for buildd purposes
(nor what sort of spec we prefer in terms of
nodes/cores/RAM/Disk/networkIF), but people describe the Altra's as
'fast'. I'll try and collect some more details to quantify that.

Does Debian run to a policy on packages/Wh for buildds yet, I wonder
(efficient hardware lowers emissions, for a given workload)? It's
worth paying something for more power-efficient kit, possibly quite a
lot for hardware like this that will run hard for years.

Are we running debian CI on this hardware or is that all done in the
cloud?

Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmQl3AgACgkQ+4YyUahv nkc6DBAAj556mEkbG7B5TyUtnggVud92MsgS50Cr0wegU7PYDWWb6UZvuXn6WXbY xdjC34b+Cegvj2j1dj0FztIy5qzdFJNf1cX+dfihVduWplfGddlccz2yr7wkbA9t A1XyTDJZMDrUXeV94nUBd0rylS8bInHbyq0hB0ZZicwjD58V4aurjOEUjyJeMxLB 3mE+BRlAere3Hg6GW8+hOS6p/6IqzkYRNIUxdcy6xGyk0u3tgjVkWp9YAWfW6sr1 ctLREjOyVJ2PT6mZiMB1Bx8dgxY4x1JHjxSCz9EPfWWKpdHLe1zj1RJWB+MyWvMi qMes1SFqlN781ZjLXvKa+EqDQeNPYV9dd7gFpMhidIqecCSOifetOzSAk2Q7OMsz UZotsj6ivvFcWWajHhCiNst0NMKkJqz8T/cklNglm9xt7AxhpdyP5ihc0F9s8Mxe jYqM8xg0BlWNdfeK6+4paBRxl31CEGqjRsInXPqgji09KoBCsHMg+2Czo0+ecLvL WBMQZvQ2/pDGJkP6DNmIdgI+4FOhiRYpHbkpNULtQ8ICFIbLMvDHqrqD9U0M1Buj fBW16589opI7NCdhjY9n7kpgp/0GJpG5tsPx4efRPtrzhtlC7UqVgXhe7J6SknGO STGVvruoGYZIiOZbs9BJ6jFHTYxk199cNceeAJ4hmWP64Oe8Isg=
=0lHG
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-30 19:59, Wookey wrote:

On 2023-03-26 12:25 +0200, Aurelien Jarno wrote:

The 3 arm64 boards running at ARM are pretty fine, we do not have any issues with them, however they start to be old.

On the other hand we have many issues with the Ampere servers hosted at
UBC and the Applied Micro servers hosted at Conova. All of them crash regularly (a few times per week in total) and need a powercycle. In addition the bullseye kernel does not work on Applied Micro servers, so
we are currently stuck with buster on them :(.

OK. That's not good. Can you say which hardware those machines are?
Our buildd database does not say what actual kit is in use (just the manufacturer), and I don't have rights to read the detailed buildd
admin info on the UBC and conova sites.

[ Aside: what would it take to put an extra field into our machine
database to specify what hardware each machine was? It can sometimes
be tricky to separate Model/motherboard/CPU as the required bit of
info but it would be really useful to write something more detailed
down both for issues like this and debugging. ]

This kind of info is usually specified in the Processor field, but only for physical hosts.

My guess is that all the Conova machine are Mustangs, and the UBC machines are emags? Is that right?

Unfortunately we don't have a lot of informations about the Conova
machines, that is conova-node01 and conova-node02. The boot log of the
Conova machines mentions "Machine model: Gigabyte X-Gene MP30-AR0
board".

The UBC machines are ubc-node-arm04, ubc-node-arm05 and ubc-node-arm06.
There are Lenovo HR330A, and according to db.debian.org the CPU are
Ampere eMAG 8180 64-bit Arm @ 3.3GHz.

Feel free to give us some instructions about how to get more details
about the hardware.

Some enquiries tell me that both these machines types are reliable
(although the mustangs are slow) at OBS and Yocto, so they can be OK,
but there is certainly much faster kit available now (Ampere Altra).

Is there a bug about the boot failure on the Applied Micro machines? I
just failed to find one. If we know what hardware it is we can
investigate, because that does seem like something that should be
fixed.

No, we failed to track the issue, we just have a note in the DSA RT
ticket about the replacement of these hosts as they are quite old (~7
years old).

I will try to boot the bullseye kernel again (last time was 1.5 years
ago) and come back to you.

I'm sure we can get new arm64 buildds if we need them.

Yes please. It's becoming urgent to get new ARM64 hardware to overcome
all those issues, and we (DSA) failed to find new hardware to buy at a decent price.

OK. I'll see what can be done. I see Altra servers are from
$7000-$53000 on https://store.avantek.co.uk/arm-servers.html.

Thanks for the pointer, it's not something we have studied yet.

What does DSA consider 'decent'? I guess we'd prefer the resilience of
a couple of reasonable machines over one ridiculously manly one. A bit
of configury on the Aventek site suggests that basic ARM Altra servers
cost about twice as much as AMD ones for similar specs
(cores/RAM/disk), but then the power consumption is less than half. I
don't know how the performance actually compares for buildd purposes
(nor what sort of spec we prefer in terms of
nodes/cores/RAM/Disk/networkIF), but people describe the Altra's as
'fast'. I'll try and collect some more details to quantify that.

What we consider decent, is in the same range than similar x86 hardware.
It seems that you also found that the ARM64 hardware is way more
expensive.

Given we need to support 3 architectures (armhf, armel, arm64) with the
same hardware, we run buildds and porterboxes as VM using ganeti, on two
nodes per side, to allow live migration for maintenance (including
software upgrades) and failure of one node. We currently run 6 buildds
at UBC, and 3 buildds + 1 porterbox at Conova. If we want to be able to eventually retire the buildds at ARM (but so far they work quite well),
we need to be able to run 6 VMs on each side.

So in term of specification, that probably means something around 24 cores
per node, 96GB RAM, and 2TB disk. Maybe a tad more so that they can be
used for the next 5 to 7 years.

Does Debian run to a policy on packages/Wh for buildds yet, I wonder (efficient hardware lowers emissions, for a given workload)? It's
worth paying something for more power-efficient kit, possibly quite a
lot for hardware like this that will run hard for years.

As we struggle with buying hardware, we are not picky about that.
However from my understanding the arm64 hardware is supposed to be more efficient than x86 one.

Are we running debian CI on this hardware or is that all done in the
cloud?

debian CI is not ran by DSA, so not on this hardware, but I don't know
exactly where it is run.

Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmQ0AsEACgkQE4jA+Jno M2tIyQ/6A6MGI2nWqq/4crA47tc8/b+gRYIOVif7FefLiihatzb29qD+INXpqBJr m4hH2UpZRae/BF3IvSk5+ycdRTLch8g10UheXxyhxs3JDBhIJIGlbOZx1fjIrFzN 4wuUCraA9l5LpvP4nNOX7eQIiNuE7o/+k64zIc4i7GPdNuFyhPCGx3UPUwAnzakz lQGR4YGHuR90ciGHlHurEsRr2+BxT9rn3dO+99ney/ADAau9fMmv6aUhwBqPq/dH 4zKNtPUCZIhwCfLTuADOZ99q2ssv/fsBSXGK1qUtVDyntB+hjT7QGWMpnF2rYP/l XkEzxPc+EHfvk7YwZwoFYIURbsqzre07YyllqFjN6BZOsPNtMR7c6/jxbEBZIzT8 8ZPfWXcPtNJ1bWXi+iBYAdCEvT8KXcqyVu86FXm4VO+pLxtYcDQV6sj8Sxq2Jxi+ Y5khlXcQdR3py1UIXOnGB62xh7k3p+X2xqD8nZXYen3auFjeX7/ik+xRhwiRfJPo ShFlOu3n8RBJc0A+Gc8btJXk9SLhmI/gTNaeBb05UzoWYRxN7mEFFI68jKQvB8xE tdgyHn5l9t5Gru2MfhAb1WOotcuLOBNJ/2m2zL1r97/yYfF01PcuDH3aTIMPd+uk 59CNZLDmWv+JcZ/zoGOI0q7NtrXOoizr8B7HK2+26TaUqRiVAoA=
=pR27
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet

W dniu 10.04.2023 o 14:36, Aurelien Jarno pisze:

On 2023-03-30 19:59, Wookey wrote:

My guess is that all the Conova machine are Mustangs, and the UBC machines >> are emags? Is that right?

Unfortunately we don't have a lot of informations about the Conova
machines, that is conova-node01 and conova-node02. The boot log of the
Conova machines mentions "Machine model: Gigabyte X-Gene MP30-AR0
board".

So they are X-Gene 1 like Mustangs.

The UBC machines are ubc-node-arm04, ubc-node-arm05 and ubc-node-arm06.
There are Lenovo HR330A, and according to db.debian.org the CPU are
Ampere eMAG 8180 64-bit Arm @ 3.3GHz.

HR330A are eMags.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 30/03/2023 19:59, Wookey wrote:

OK. I'll see what can be done. I see Altra servers are from
$7000-$53000 on https://store.avantek.co.uk/arm-servers.html.

What does DSA consider 'decent'? I guess we'd prefer the resilience of
a couple of reasonable machines over one ridiculously manly one. A bit
of configury on the Aventek site suggests that basic ARM Altra servers
cost about twice as much as AMD ones for similar specs
(cores/RAM/disk), but then the power consumption is less than half. I
don't know how the performance actually compares for buildd purposes
(nor what sort of spec we prefer in terms of
nodes/cores/RAM/Disk/networkIF), but people describe the Altra's as
'fast'. I'll try and collect some more details to quantify that.

I'm not DSA, but the problem i've found when looking at such hardware
has always been that the "cost of entry" is so high. To me $7K is a
lot of money to put down "on spec".



It may well be worth approaching them to see if they would sponsor
some hardware, or at least provide a steep discount from list prices.
Debian is after-all one of the top Linux distros (and probablly the
top "community" distro).

Also can anyone confirm if these machines support arm32? or if they
are arm64 only?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-04-10 14:36, Aurelien Jarno wrote:

On 2023-03-30 19:59, Wookey wrote:

Some enquiries tell me that both these machines types are reliable (although the mustangs are slow) at OBS and Yocto, so they can be OK,
but there is certainly much faster kit available now (Ampere Altra).

Is there a bug about the boot failure on the Applied Micro machines? I
just failed to find one. If we know what hardware it is we can
investigate, because that does seem like something that should be
fixed.

No, we failed to track the issue, we just have a note in the DSA RT
ticket about the replacement of these hosts as they are quite old (~7
years old).

I will try to boot the bullseye kernel again (last time was 1.5 years
ago) and come back to you.

I just give it a try, and it now boots fine. I guess the issue got fixed
in the meantime. Let's hope those nodes will run more stable on the
bullseye kernel than the buster kernel.

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmQ8aKkACgkQE4jA+Jno M2uFaxAAlk77y4Na53276TpzpWlUrmxEbgkrrWWwdV5jEuTdGVgKeYiGBH3K6Hn9 OHIX0Co3iF5ep5P6okFsOCbGJ2diEEhbct3LeY5ebOvPfbD9wVYb9F3gtePba+6v mfHF123Hu7Cw6uzK0r1YuaYbiGBvf7GLJEZyopGqhPyY+Ol7atPFAofTYzPzJxkN YbZ5MVlbCyNRPv+I9X2LGj23vB1CdwImgDuR/aX89J/Pul5YFUdFoQD+HwIFRKWq ohDnNPZxeJbdQy0cMrBbjHxotEDnBJ5t04bgt0W92DF2t+23J5tdLGQIG/W0iny+ zMTb5RK7w0YTUrE61uExxL8dZGP+oCziad6+2r69eyhvPB251gn7wkZWEpOktSVX RTdV8hQiswJ2mENqCWHJ3q1wwSwueEptq1uyA6Pe7RcEseSX+t1p6YkDtPWHrihp sokFbrbWsJ4n5Y5nO1QGgFsNzViX8GtMxujnfUSvC+YMnot4m6BdMB7gAXARBgkq c8fZ76G9iGzQUd0tUlBFoZfeswsrBz4N45oQ7f3RHnNFyVMacCZC+va4lelXDt6c 8EIcRIrstMJJd6Znjq8e5Fn8BSMVzTOFb9GfFWWbg8nad5Wo/z6jH6WJafYTEoHu kxCx8S8lH/VS0M/XewcxhQhobaPWQWml8os0Bp/wZ0f/QUnGuRU=
=qMWI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet