Re: [Astlinux-devel] Astlinux base system

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

My interest was triggered recently when I came across NanoPi R2S (
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_R2S and
https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=282)
$25 with case, 2x Gbps 1GB RAM.  Of course no sooner had word got out than
they sold out.  I almost did an impulse buy but hesitated.  I think you can
get from China for a little more money through AliExpress.  You can also
google for "<pick a fruit> pi dual ethernet". Try orange or banana :-)

David

On Tue, Apr 7, 2020 at 5:44 AM Michael Keuter <li...@mk...>
wrote:

>
>
> > Am 06.04.2020 um 21:57 schrieb David Kerr <da...@ke...>:
> >
> > Kernel 4.19 has been selected by the linux foundation for Super LTS
> which means that it should have some support structure for many many
> years.  I'll back off my previous proposal to adopt an off-the-shelf
> underlying platform... the points about piecemeal package updates
> potentially causing stability issues is valid.
> >
> > I'll add one more potentially controversial suggestion... in addition to
> x86_64 how about ARM64 as well?
>
> Hi David,
> do you have any specific ARM64 device with multiple gigabit NICs in mind?
> I couldn't find boards either from Ubiquiti (MIPS) or Mikrotik (MIPS +
> ARM32).
> If you find some that are significantly cheaper than a Qotom or APU2 then
> please report.
>
> > For the build system/tools I think we should update to the current
> buildroot.  While we have been keeping individual package versions
> up-to-date, we have not been keeping the build system up-to-date
> (crosstools, config files, etc.)  And it is this that is causing problems
> when underlying build hosts are updated.  And I am NOT in favor of
> mandating and/or supporting only one host OS for the build system, be it
> CentOS, Ubuntu, whatever.
> >
> > David.
> >
> >
> >
> > On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> > Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully
> Ben Hutchings, but unknown as of yet.
> >
> > Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
> >
> > Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two
> before that kernel is tested enough for production.
> >
> > CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project
> ... until 2029 !
> >
> > Lonnie
> >
> >
> >
> > > On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...>
> wrote:
> > >
> > > Only the latest 4.x + 5 kernels are supported.
> > > So 4.14 is out.
> > >
> > > http://aufs.sourceforge.net/
> > >
> > > Sent from a mobile device.
> > >
> > > Michael Keuter
> > >
> > > Anfang der weitergeleiteten Nachricht:
> > >
> > >> Von: Lonnie Abelbeck <li...@lo...>
> > >> Datum: 2. April 2020 um 17:40:23 MESZ
> > >> An: AstLinux Developers Mailing List <
> ast...@li...>
> > >> Betreff: Aw:  [Astlinux-devel] Astlinux base system
> > >> Antwort an: AstLinux Developers Mailing List <
> ast...@li...>
> > >>
> > >> My short list for AstLinux 1.4.x would be:
> > >>
> > >> - Kernel bump to 4.x
> > >> - Switch from unionfs to Aufs
> > >> - Support x86_64 only
> > >> - Update the toolchain using a newer gcc and glibc
> > >> - RUNNIX runnix-0.6.0 would be x86_64 only
> > >>
> > >> As for Buildroot, our version is quite up to date for x86_64 and the
> packages we use.  We have packages and fixes that are not upstream.
> > >>
> > >> As for Linux build systems, I would prefer to pick a common basic
> distro version, CentOS or Debian, and instruct users to only use that
> version in a VM for building AstLinux.  This would add a level of
> consistency for the HOST and simplicity for the documentation.  There is no
> extra-credit for making our build system work with any distro.
> > >>
> > >> As for toolchains, it would be ideal to find a supported, trusted,
> x86_64 pre-built toolchain we could use (like a package) with the kernel
> version we decide to use.  Crosstool-NG is also an option, which if we use
> a common build HOST we could possibly create our own x86_64 pre-built
> toolchain which could be downloaded instead of rebuilt for every build
> system install.
> > >>
> > >> Finally, the simultaneous equations that need to be solved are,
> Kernel LTS version where Aufs is actively supported and works with a
> toolchain we like.
> > >>
> > >> Lonnie
> > >>
> > >>
> > >>
> > >>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> > >>>
> > >>> Changed subject to be more relevant to the discussion.
> > >>>
> > >>> I thought more about this and realized that my itch is not really
> that we should use a standard distribution, but that we should be thinking
> about bringing AstLinux more up-to-date and discussing how to go about it.
> Yes the kernel 3.16.x works fine and will do for some time.  But the day
> will come when we must move.  In addition our base system is built from a
> very old version of buildroot, toolchains, libraries, etc. and we run into
> issues as underlying hosts change... mostly simple things like version
> checks failing and we have been able to work around them.  But it is
> getting harder... the most recent one being when I tried the ZFS file
> system on Ubuntu 19.10.
> > >>>
> > >>> Maybe if we changed how we build AstLinux to start from a
> standard/stable version of buildroot (rather than essentially copying all
> of buildroot into our own source tree).  I'm not even sure what I mean by
> that, but I think we should look for a way to stay closer aligned and be
> able to easily update with Buildroot versions.
> > >>>
> > >>> David.
> > >>>
> > >>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <
> mic...@ip...> wrote:
> > >>> After using  OpenWRT for a little while, I decided to abandon its
> use for two reasons, 1) Wifi driver support but also 2) packages. It was so
> difficult to maintain a standard image across all my routers and I never
> knew what package was going to affect what and what would break when I
> upgraded and then how I would revert. Although I hate Mikrotik's UI and
> command structure, I decided to suck it up and move to them because of a
> single firmware image amongst other things.
> > >>>
> > >>> Although I am not that knowledgeable in the area, I believe the
> stability of Astlinux is because of the minimalist approach taken to what
> is included and enabled.
> > >>> I therefore really like the current approach and certainly would not
> want to move to 'a series of entangled package upgrades'.
> > >>>
> > >>> Thanks David for asking these questions as its really important that
> we understand what we are doing and why.
> > >>>
> > >>> Regards
> > >>> Michael Knill
> > >>>
> > >>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> > >>>
> > >>>    Hi David, et.al,
> > >>>
> > >>>    Brainstorming ideas are always appreciated.
> > >>>
> > >>>    Though I think our "AstLinux Principles" still apply today, as
> much as ever:
> > >>>
> > >>>    AstLinux Principles:
> > >>>    https://www.astlinux-project.org/about.html
> > >>>
> > >>>    Our current 3.16.x kernel has been getting backported fixes from
> upstream [1] for quite some time by Ben Hutchings ... some would argue that
> the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> > >>>
> > >>>    Correct me if you disagree, but since we use i586/x86_64
> architecture much of the newer kernel hardware support does not apply to
> us.  This is even more true for AstLinux running as VM Guests.
> > >>>
> > >>>    Additionally, a big sticking point upgrading beyond the 3.16.x
> kernel is our current unionfs kernel patches are no longer supported in
> 4.x.  Looks like we will need to switch to Aufs, which we have been giving
> some thought, making it backward compatible is a concern.
> > >>>
> > >>>    Some might argue we should stick with a rock-solid 3.16.x kernel
> for another year or so, others might suggest 4.x (unclear which is best) is
> warranted.  I think 5.x is too new to consider IMO, not enough testing.
> > >>>
> > >>>    Finally, packages vs. firmware-image.  I'm convinced the
> firmware-image approach is ideal for an appliance like AstLinux.  I've
> played with OpenWrt on an EdgeRouter-X, and found the package upgrade
> approach leaves much to be desired compared with a firmware-image approach.
> > >>>
> > >>>    Please discuss ...
> > >>>
> > >>>    Lonnie
> > >>>
> > >>>    [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> > >>>>
> > >>>> Moving to devel list.
> > >>>>
> > >>>> This once again prompts the question as to what to do about
> AstLinux kernel version.  It feels that we are getting further and further
> behind and should maybe even skip 4.x and go straight to a 5.x.
> > >>>>
> > >>>> Or... get out of the business of providing the low level OS
> components and develop on top of a standard "lightweight" distribution.
> When AstLinux started up there was a need for a tight, small, integrated
> system that would work on typical network gateway hardware of the time.
> But today's typical network gateway hardware is very capable of running a
> standard linux distribution.  And if we moved all the AstLinux-unique
> features over to installable packages I think we would benefit greatly.
> > >>>>
> > >>>> Just thought I would throw this out there and see what people think.
> > >>>>
> > >>>> David.
> > >>>>
> > >>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <
> li...@lo...> wrote:
> > >>>> Greetings,
> > >>>>
> > >>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
> > >>>>
> > >>>> My favorite VPN type (as well as many of you reading this) has
> achieved a major milestone.  Additionally, an outside security audit of
> WireGuard has been performed.
> > >>>>
> > >>>> For those previously concerned about the non-official status of
> WireGuard, those concerns should now be minimized.
> > >>>>
> > >>>> Lonnie
> > >>>>
> > >>>>
> > >>>> ================
> > >>>> Begin forwarded message:
> > >>>>
> > >>>> From: "Jason A. Donenfeld" <Ja...@zx...>
> > >>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> > >>>> Date: March 29, 2020 at 9:16:43 PM CDT
> > >>>> To: WireGuard mailing list <wir...@li...>
> > >>>>
> > >>>> Hi folks,
> > >>>>
> > >>>> Earlier this evening, Linus released [1] Linus 5.6, which contains
> our
> > >>>> first release of WireGuard. This is quite exciting. It means that
> > >>>> kernels from here on out will have WireGuard built-in by default.
> And
> > >>>> for those of you who were scared away prior by the "dOnT uSe tHiS
> > >>>> k0de!!1!" warnings everywhere, you now have something more stable to
> > >>>> work with.
> > >>>>
> > >>>> The last several weeks of 5.6 development and stabilization have
> been
> > >>>> exciting, with our codebase undergoing a quick security audit [3],
> and
> > >>>> some real headway in terms of getting into distributions.
> > >>>>
> > >>>> We'll also continue to maintain our wireguard-linux-compat [2]
> > >>>> backports repo for older kernels. On the backports front, WireGuard
> > >>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> > >>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also
> maintaining
> > >>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y
> [7],
> > >>>> and we'll see where those wind up; 5.4.y is an LTS release.
> > >>>>
> > >>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> > >>>> Fedora 32 will be getting WireGuard automatically by virtue of
> having
> > >>>> 5.6, and I expect these to increase in number over time.
> > >>>>
> > >>>> Enjoy!
> > >>>> Jason
> > >>>>
> > >>>>
> > >>>> [1]
> https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> > >>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
> > >>>> [3]
> https://lore.kernel.org/netdev/202...@zx.../
> > >>>> [4]
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> > >>>> [5]
> https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> > >>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> > >>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Astlinux-users mailing list
> > >>>> Ast...@li...
> > >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> > >>>>
> > >>>> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >>>> _______________________________________________
> > >>>> Astlinux-devel mailing list
> > >>>> Ast...@li...
> > >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>>
> > >>>
> > >>>
> > >>>    _______________________________________________
> > >>>    Astlinux-devel mailing list
> > >>>    Ast...@li...
> > >>>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Astlinux-devel mailing list
> > >>> Ast...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>> _______________________________________________
> > >>> Astlinux-devel mailing list
> > >>> Ast...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Astlinux-devel mailing list
> > >> Ast...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> >
> >
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>