ARM64 port
by A. Wilcox
Hi all,
Packet.net has generously sponsored hardware to make our ARM64 port a
reality. We now need to discuss what optimisations and minimum
architecture we want to have for our ARM64 port.
My personal preference would be:
-O2
=> I think that even on the SoCs, memory is not so cramped that speed
should be sacrificed in the name of -Os. More than likely, people
running on SoCs will have swap anyway if they really need it, and with
uksm and musl it should already have better memory characteristics than
Raspbian et al.
-mfix-cortex-a53-835769
=> Work around a CPU erratum in the A53 core. This is the CPU used in
the RPi3, Pine A64, Roku, odroid-C2, and some Snapdragons.
-mfix-cortex-a53-843419
=> Likewise.
-mcpu=armv8-a
=> Generic, all ARMv8 cores are supported.
-mtune=cortex-a53
=> This will make the code run a little faster on these CPUs, at the
expense of potentially running slightly slower on ThunderX, XGene, and
Exynos. I don't think we will ever have any Exynos chips and if we went
with -mtune=generic it would be slower on ThunderX than -mtune=thunderx
anyway. Using A53 as our tune target will give us a small perf boost
where, in my humble opinion, we need it most: the tiny SoCs.
Note for -mtune, quoting the GCC manual:
> -mtune=name
> Specify the name of the target processor for which GCC
> should tune the performance of the code. Permissible values for this
> option are: generic, cortex-a35, cortex-a53, cortex-a57, cortex-a72,
> exynos-m1, qdf24xx, thunderx, xgene1.
Once we have set up the build settings, it will be officially tier 3
(experimental). I am hoping since this donated build hardware is 96
cores, we will be able to bring it to tier 2 very quickly.
Regards,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
2 years, 11 months
Impending deprecation of syslinux
by A. Wilcox
Hello,
This is a notice to all Adélie Linux developers that we will be
deprecating syslinux as of beta1, and it will not be shipping with 1.0.
There are many reasons for this:
* syslinux is not so maintained any more
* syslinux does not work right on most (U)EFI machines, including actual
Tiano machines, in addition to Apple machines
* syslinux only boots x86 computers
* GRUB 2 has better support for older BIOSes with finicky hard disk
controllers / CD drives (for pmmx)
* GRUB 2 is more customisable
* GRUB 2 allows us to have actual menus on the boot CD, instead of
potentially confusing "boot:" prompt or very limited syslinux menu.c32
If someone is aware of a computer that is bootable on syslinux and not
GRUB 2, please reply ASAP so that we can either debug it and fix GRUB 2,
or review our other options for such computers. Thank you.
Regards,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
2 years, 11 months
Nice-to-haves for 1.0
by A. Wilcox
Hi all,
I'd like to have a discussion on whether or not it would be worth it to
invest actual time and resources into the following projects before we
release 1.0. Perhaps we could even delay 1.0's release slightly, if
they are deemed critical enough.
PackageKit Plugin for APK
=========================
This would allow us to have graphical UIs for installing, removing, and
updating packages with APK for "free". One thing that bothers me is
that APK doesn't yet have tagging or category support, so every package
would be in a single, large, unwieldy list. It'd be very nice if we
could add tagging first.
Of course, writing the plugin and then adding tagging to APK later is
another option.
Note that both KDE (Muon) and Gnome (gnome-packagekit) have GUI tools
built on top of PackageKit, so we would not need to write any GUIs.
Parcel
======
This is the Web and CLI UI for determining package availability,
version, and architectures. Similar to Alpine's pkgdb or Gentoo's
Package Home for the Web UI, and similar to eix on the CLI.
I still think this is a very worthy endeavour, but time is a precious
commodity and I don't know if we have the time to build it before 1.0
unless 1.0 is delayed.
Register
========
This is the popcon-like system that will let us explore and inspect
packages that are popular (and not popular) with the user community at
large. Cadey on IRC has been writing a prototype.
This, too, seems like a very important feature for 1.0.
Steam with gcompat
==================
I still have been unable to test the Steam binary on gcompat because it
requires 32-bit x86 and I don't have a 32-bit x86 installation with
gcompat anywhere. (The only 32-bit x86 install I have of Adélie,
outside of the builders, is a 500 MHz Pentium III laptop. Hardly an
amazing gaming system, that.)
I don't know if that is important enough to work on for 1.0, since you
can just use an Ubuntu chroot to play Steam games (this also prevents
the icky binary blobs from touching your rootfs). However, I will defer
to the community for that decision.
MIPS
====
We desired MIPS support in 1.0 before the Alpine rebase. I do have a
MIPS32 CI20 and a MIPS64 Indy, but I don't think either one of them
would be able to compose the entire distro in any decent amount of time.
We could still likely have a bootable image before 1.0 release if we
start now. Again, I'm not sure if the community desire is high enough
to warrant that as a "distraction" when it can wait for 1.5 or 2.0.
GNOME 3
=======
I believe aerdan@ has a partially working GNOME 3 tree in his
elementary-os branch of packages.git. I know that some packages were
requiring Python 2 (if I recall) and that was the end of that.
I would not mind putting in some effort to try and port those packages
to Python 3 if GNOME 3 is still a desktop we want to offer in 1.0.
Horizon
=======
There has been renewed interest in Horizon since the linux-wiiu team has
joined us. We could likely spin partitioning out to KDE Partition
Manager (https://www.kde.org/applications/system/kdepartitionmanager).
Since the linux-wiiu would like Horizon to use PackageKit (so that it
can handle any future pivots, if desired), it'd be a great idea to have
an APK PackageKit backend before we go back to Horizon.
Others?
=======
If anyone has any other 1.0 goals that aren't covered in the current
roadmap (https://wiki.adelielinux.org/wiki/Project:Roadmap), let's
discuss them here.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
2 years, 11 months