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

[Warner Losh]

On Thu, Jan 3, 2019, 3:53 PM Alan Somers <asomers at freebsd.org wrote:

> 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.
>

We already have. The boot loader uses the latest, almost stock version. ZFS
uses it's weird, hacked version to send down config programs. The build
glue to get a luac is pretty small at this point :)

Warner

>
> -Alan
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>