Strategic Thinking (was: Re: Speculative: Rust for base system components)

Cy Schubert Cy.Schubert at cschubert.com
Thu Jan 3 23:10:19 UTC 2019


In message <CAOtMX2jdDSUwtifm=a_nqJWg_5yCOoe4BYGmO4QkbysRZ8UCrg at mail.gmail.com>
, Alan Somers writes:
> On Thu, Jan 3, 2019 at 3:29 PM Cy Schubert <Cy.Schubert at cschubert.com> wrote:
> >
> > In message <alpine.BSF.2.20.1901032030260.40635 at puchar.net>, Wojciech
> > Puchar wr
> > ites:
> > > >> That's precisely how ideas that most people disagree with get *pushed*
> > > >> through by evangelists with confirmation bias! Like someone said
> > > >> earlier in the discussion: does Rust add anything? The answer is a
> > > >> resounding NO, save for bloat.
> > > >
> > > > And this is why one reason people say FreeBSD is dying.
> > > >
> > > dying for whom?
> >
> > Not to answer this question but to think strategically:
> >
> > I come from the corporate/government environment, having spent most of
> > my time there. Large datacentres (Canadian spelling), large machines,
> > large networks of machines, large networks. In this environment, today,
> > virtualization in all forms are the platforms of business. Migrations
> > from physical platforms running AIX, Solaris and Linux to either Linux
> > on VMware or Linux containers is where they are putting 100% of their
> > effort. The language of choice is mostly Java. Much of the Java is
> > canned too. What used to be implemented on LAMP stacks is now being
> > implemented using microservices. The platform of choice for
> > microservices is Linux. Stripped down Linux primarily capable of
> > supporting microservices. And now at $JOB we're talking about running
> > microservices on Linux VMs -- virtualization on virtualization, on a
> > virtual network (NSX). My customers are working on microservices and
> > containers that can be migrated from their private cloud to the public
> > cloud and back again easily.
> >
> > Even Microsoft is working on a container strategy. The future is
> > containers. The desktop platform isn't nearly as important any more.
> > And, the physical server, its location, what it runs on and who runs it
> > are also less important. What is important is the speed and cost
> > effectiveness of standing up applications.
> >
> > IMO we have strengths that can immediately be capitalized on, like the
> > Linuxulator. If anything could be in base it might be go, the language
> > Kubernetes is written in -- don't get me wrong, I'm not advocating
> > importing go into base. Having said that, transforming FreeBSD into a
> > PaaS platform, tying it all together using Kubernetes would position
> > FreeBSD for the future to come. Maybe I'm talking myself into go and
> > Kubernetes in base but maybe this could just as easily be done in ports.
> >
> > Think about this: Kubernetes in base or ports, using the Linuxulator
> > and jails (or an implementation of cgroups and namespaces constructs in
> > addition to jails). Bhyve and jails provide the enterprise with other
> > virtualization options such that a FreeBSD host could host Linux or
> > FreeBSD containers, Windows or other VMs, and FreeBSD jails, all on one
> > or a cluster of FreeBSD hosts, possibly part of a heterogeneous cluster.
> >
> > This IMO would position FreeBSD for the future.
> >
> > Maybe go and Kubernetes? Let's not be left behind.
> >
> >
> > --
> > Cheers,
> > Cy Schubert <Cy.Schubert at cschubert.com>
> > FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org
> >
> >         The need of the many outweighs the greed of the few.
>
> FreeBSD support in Kubernetes would be great, but I don't think
> there's any reason to put it into base.  The interesting thing about
> Rust is that it's so good at low-level work.  As we discussed,
> Johannes Lundberg has written a device driver in Rust.  And Fabian
> Freyer is working on jail(3) and jail(8) replacements in Rust.  Enji
> is thinking about writing an rc(8) replacement in Rust.  These are the
> kind of projects that make sense to do in base, apart from the
> language barrier.  Go, I think, would be just fine remaining in ports.
> If I were to pick any language other than Rust to add to the base
> system, it might be Lua.  Though high level, its embeddable and nicely
> complements C and Rust.  That's why it's used internally in Kyua, and
> it even in the NetBSD kernel.

I didn't specifically suggest it had to be in base, hence "or ports."
(My preference is almost always ports.) My point was, let's step back
and lay out a roadmap. If rust is in the roadmap, fine. Rust, which is
already in ports, and other things we might want should align with
that direction.

Meta ports such as a PaaS, OpenShift, or cloud-server metaports could
tie it all together for users.

pkgbase would add flexability and in so doing solve some issues too.

>
> -Alan
>

Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.


More information about the freebsd-hackers mailing list