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

[Enji Cooper]

> On Jan 3, 2019, at 14:51, 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.

+1. Kubernetes should remain as a port, given the development process that Facebook and Google use being out of step with the BSDs (backwards compatibility to the degree that BSD wants is generally a lower priority item).

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

Sidenote: not wanting to do an rc(8) replacement. More like a system monitor of sorts, paralleling what devd does with device events and such.

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

Lua’s already in base — the bootloader is being rewritten from forth to 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.

And Linux kernel for that matter, iirc. It’s a wonderful, stripped down language. It’s just a bit awkward to write because its lexicography/grammar matches pure mathematics as opposed to many other C-like languages.

Thanks :),
-Enji