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

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In message <[hidden email]>, Wojciech
Puchar wr
ites:
> >> .
> >>
> >> FreeBSD should aim for that room, rather than become "Linux-sans-GPL"
> >
> > We should try to fit into the datacentre.
> >
> To whose gain?

To our gain. Look at illumos, a hobbyists O/S. Do we want to become
that?

We should aim for the broadest base possible. The desktop is not
enough. Neither is a tinkerers toy either.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Wojciech
Puchar wr
ites:

> >>> A) FreeBSD needs to become a platform that can host current and
> >>> evolving virtualization technologies.
> >>>
> >>> B) FreeBSD should be able to play in the container space similarly to
> >>> Linux. Unfortunately I believe that this horse has left the barn and it
> >>> may be too late. Then again maybe there is something we can redeem.
> >>
> >> C) Make FreeBSD like others. So why making FreeBSD?
> >
> > Because we offer some technologies the others do not. Unfortunately
> > inferior and incompatible approaches (similarly: VHS vs BETA, Blue Ray
> > vs HD) have left us on the outside. Try porting Kubernetes to FreeBSD.
> no need to.
>
> >
> > The technologies used today are more than just fads. They are building
> > blocks onto which future technologies will be built.
> >
> and this is really sad.

Sure. What is really sad is that the world has moved on. I would love
to still do kernel programming on the IBM mainframe. That's not
possible. There used to be half a dozen IBM mainframe datacentres in my
home town and two in the city I currently live in when I moved here.
Now there are none in both places. We can cry the blues that life isn't
what it used to be or we can move on.

One person I once worked with attempted suicide because his beloved
mainframe here was no more.

Old technologies aren't as relevant as they used to be. Nostalgia for
days gone by isn't going to make those days come back. Only supporting
old hardware and only maintaining old paradigms will announce, FreeBSD
is dying. Do you want that? Get over it and move on.

>
> >>
> >> Not everyone needs the same.
> >
> > Niche. We should be more than simply a desktop O/S (which BTW I use as
> > my primary desktop) and we should be more than a simple bare metal O/S.
>
> Simple bare metal O/S is what is really needed.

They all do that. What else can we bring to the table?

One of the questions to be answered is where do we want to be in five
years? Stuck in the past?

This sub-thread was meant to have us consider importing rust in the
bigger scheme of things. My point is, before we do anything, like add a
shiny new feature or cull some old code, does this align with where we
want to be in two or five years?


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Enji Cooper
In reply to this post by Wojciech Puchar-8
On Jan 5, 2019, at 07:07, Wojciech Puchar <[hidden email]> wrote:

>>>> A) FreeBSD needs to become a platform that can host current and
>>>> evolving virtualization technologies.
>>>>
>>>> B) FreeBSD should be able to play in the container space similarly to
>>>> Linux. Unfortunately I believe that this horse has left the barn and it
>>>> may be too late. Then again maybe there is something we can redeem.
>>>
>>> C) Make FreeBSD like others. So why making FreeBSD?
>>
>> Because we offer some technologies the others do not. Unfortunately
>> inferior and incompatible approaches (similarly: VHS vs BETA, Blue Ray
>> vs HD) have left us on the outside. Try porting Kubernetes to FreeBSD.
> no need to.

Actually, not having Docker/Kubernetes support makes it more difficult to ride the CI/distributed system wave, requiring FreeBSD to reinvent the wheel to do CI, and force various groups to write their own homegrown distributed systems infrastructures instead of leveraging existing technologies.

>> The technologies used today are more than just fads. They are building
>> blocks onto which future technologies will be built.
>>
> and this is really sad.

Not really. It’s a sign of maturity as most things now run on a “cloud based” infrastructure, or small embedded OSes running embedded Linux (not FreeBSD).

>>> Not everyone needs the same.
>>
>> Niche. We should be more than simply a desktop O/S (which BTW I use as
>> my primary desktop) and we should be more than a simple bare metal O/S.
>
> Simple bare metal O/S is what is really needed.

Not really. As Cy pointed out, in order to ensure that FreeBSD is well-supported by large companies (Dell, Facebook via WhatsApp, Juniper, and Sony were some of the large contributors over the past couple years, along with a host of other smaller storage companies), so it continues to exist in a healthy way, it needs to be dynamic and customizable to meet the needs from embedded development up to large-scale distributed systems. A number of these companies have considered switching away from FreeBSD to Linux because FreeBSD is niche (see Microsoft with Hotmail, Yahoo, etc). Let’s not give developers willing to make the switch more ammunition to do so.

Cheers,
-Enji
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Enji Cooper
In reply to this post by Wojciech Puchar-8
On Jan 5, 2019, at 07:16, Wojciech Puchar <[hidden email]> wrote:

>>> .
>>>
>>> FreeBSD should aim for that room, rather than become "Linux-sans-GPL"
>>
>> We should try to fit into the datacentre.
>>
> To whose gain?

See my previous reply: Dell (Isilon, etc), Juniper, Panasas (sp?), Sandvine, WhatsApp (Facebook), etc.

Example: Facebook has toyed around with converting their entire WhatsApp fleet away from FreeBSD in the datacenter to FB Linux. Let’s give them less ammo to do so. They were a major financial contributor to the FreeBSD project back a couple years ago, so like it or not, having FreeBSD be a compelling project is helping finance your “hobby OS”.

Cheers,
-Enji
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Enji
Cooper writes
:

> On Jan 5, 2019, at 07:07, Wojciech Puchar <[hidden email]> wrote:
>
> >>>> A) FreeBSD needs to become a platform that can host current and
> >>>> evolving virtualization technologies.
> >>>>
> >>>> B) FreeBSD should be able to play in the container space similarly to
> >>>> Linux. Unfortunately I believe that this horse has left the barn and it
> >>>> may be too late. Then again maybe there is something we can redeem.
> >>>
> >>> C) Make FreeBSD like others. So why making FreeBSD?
> >>
> >> Because we offer some technologies the others do not. Unfortunately
> >> inferior and incompatible approaches (similarly: VHS vs BETA, Blue Ray
> >> vs HD) have left us on the outside. Try porting Kubernetes to FreeBSD.
> > no need to.
>
> Actually, not having Docker/Kubernetes support makes it more difficult to rid
> e the CI/distributed system wave, requiring FreeBSD to reinvent the wheel to
> do CI, and force various groups to write their own homegrown distributed syst
> ems infrastructures instead of leveraging existing technologies.

I'm puttering around with Kubernetes and Docker. However there are
other things on my plate that IMO are more urgent. Multitasking.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Enji
Cooper writes
:

>
>
> > On Jan 3, 2019, at 14:51, Alan Somers <[hidden email]> wrote:
> >
> >> On Thu, Jan 3, 2019 at 3:29 PM Cy Schubert <[hidden email]> wro
> te:
> >>
> >> In message <[hidden email]>, 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 <[hidden email]>
> >> FreeBSD UNIX:  <[hidden email]>   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 Fa
> cebook and Google use being out of step with the BSDs (backwards compatibilit
> y to the degree that BSD wants is generally a lower priority item).

It's not a port yet but it will be. I prefer a smaller base relying on
ports instead.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Enji
Cooper writes
:

> On Jan 5, 2019, at 07:07, Wojciech Puchar <[hidden email]> wrote:
>
> >>>> A) FreeBSD needs to become a platform that can host current and
> >>>> evolving virtualization technologies.
> >>>>
> >>>> B) FreeBSD should be able to play in the container space similarly to
> >>>> Linux. Unfortunately I believe that this horse has left the barn and it
> >>>> may be too late. Then again maybe there is something we can redeem.
> >>>
> >>> C) Make FreeBSD like others. So why making FreeBSD?
> >>
> >> Because we offer some technologies the others do not. Unfortunately
> >> inferior and incompatible approaches (similarly: VHS vs BETA, Blue Ray
> >> vs HD) have left us on the outside. Try porting Kubernetes to FreeBSD.
> > no need to.
>
> Actually, not having Docker/Kubernetes support makes it more difficult to rid
> e the CI/distributed system wave, requiring FreeBSD to reinvent the wheel to
> do CI, and force various groups to write their own homegrown distributed syst
> ems infrastructures instead of leveraging existing technologies.
>
> >> The technologies used today are more than just fads. They are building
> >> blocks onto which future technologies will be built.
> >>
> > and this is really sad.
>
> Not really. It’s a sign of maturity as most things now run on a “cloud ba
> sed” infrastructure, or small embedded OSes running embedded Linux (not Fre
> eBSD).
>
> >>> Not everyone needs the same.
> >>
> >> Niche. We should be more than simply a desktop O/S (which BTW I use as
> >> my primary desktop) and we should be more than a simple bare metal O/S.
> >
> > Simple bare metal O/S is what is really needed.
>
> Not really. As Cy pointed out, in order to ensure that FreeBSD is well-suppor
> ted by large companies (Dell, Facebook via WhatsApp, Juniper, and Sony were s
> ome of the large contributors over the past couple years, along with a host o
> f other smaller storage companies), so it continues to exist in a healthy way
> , it needs to be dynamic and customizable to meet the needs from embedded dev
> elopment up to large-scale distributed systems. A number of these companies h
> ave considered switching away from FreeBSD to Linux because FreeBSD is niche
> (see Microsoft with Hotmail, Yahoo, etc). Let’s not give developers willing
>  to make the switch more ammunition to do so.

This has everything to do with relevance. Look at where illumos and all
the other *BSDs are. They're pretty much hobbyist operating systems.
The discussion on an illumos developers mailing list has given me that
impression as well.

At $JOB my customers are migrating from AIX, Solaris and even Windows
to Linux and from traditional Linux to microservices run under
OpenShift. As I told my manager at $JOB those many years ago, the
operating system will become a stub. We are now realizing this.

The other thing I see at $JOB is the network is now being virtualized
using NSX. Our Checkpoint firewalls are no longer physical but virtual.
FreeBSD with jails and VIMAGE is in a great position to play in this
space as well. An example might be, at $JOB we are using vRO and vRA
but it could be as easily done using Kubernetes and ansible to
centrally manage network of virtual and physical FreeBSD based
firewalls.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Poul-Henning Kamp
In reply to this post by freebsd-hackers mailing list
--------
In message <[hidden email]>, Alexander Leidinger via freebsd-hackers writes:

>> Data-centers are booooring!
>
>Which means that x developers with commit bits in FreeBSD are free to  
>develop whatever they want.

No, *all* developers with or without commit bits in FreeBSD are free to
develop whatever they want.

Some of them care about datacenters, and thats *fine*, some of them care
about embedded, and thats *fine* and some of them care about laptops,
and thats *fine* and so on.

The FreeBSD releases contain exactly, and no more or no less, than what
people put into them, for whatever reason they put it in.

Now, can we drop this inane thread, and check the "At least one
Bikeshed" box on the 2019 TODO list, and get back to coding ?

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Wojciech Puchar-8
In reply to this post by Cy Schubert-4
> At $JOB my customers are migrating from AIX, Solaris and even Windows
> to Linux and from traditional Linux to microservices run under
why this "microservices" - which are simply complete programs without
dependencies (or should be) - cannot be run simply as processes on
different user accounts?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Alan Somers-2
On Sun, Jan 6, 2019 at 11:31 AM Wojciech Puchar <[hidden email]> wrote:
>
> > At $JOB my customers are migrating from AIX, Solaris and even Windows
> > to Linux and from traditional Linux to microservices run under
> why this "microservices" - which are simply complete programs without
> dependencies (or should be) - cannot be run simply as processes on
> different user accounts?

Several reasons:
1) Separate accounts don't provide as much security as separate
containers.  Capsicum does, but people aren't used to using Capsicum
yet.  And who can blame them?  Writing a Capsicum program is harder
than writing a normal program and deploying it in a container.
2) Fragmentation.  The Linux world is much more fragmented than the
FreeBSD world.  It's hard to write a program that will work correctly
on every Linux distro without modification.  So people bundle their
applications with entire userlands as a container image.  That reduces
its external dependencies to just the Linux kernel.  Bloated, yes.
But easy.
3) Fashion.  You may not care about the latest IT craze, but a lot of
IT departments do.  And you can't change their minds all by yourself.

If FreeBSD is to be used by people who deploy microservices, then it
needs to do what they want.  That means it needs Docker or something
similar (IT admins won't want to learn ezjail if they're already
comfortable with Docker), or we need to convince people to use
CloudABI.  CloudABI has the potential to outperform containers.  It
just hasn't gained traction yet.
-Alan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Wojciech Puchar-8
>> why this "microservices" - which are simply complete programs without
>> dependencies (or should be) - cannot be run simply as processes on
>> different user accounts?
>
> Several reasons:
> 1) Separate accounts don't provide as much security as separate
> containers.  Capsicum does, but people aren't used to using Capsicum

I use separate processes and don't feel the lack of security. I don't use
capsicum too.

Could you explain it more precisely why standard process and user/group
separation is insufficient?

Simply access rights and setting
security.bsd.see_other_uids=0

is enough for me.

If something could be added then it would be limiting what ports can each
user open. But it's not really a problem.

> 2) Fragmentation.  The Linux world is much more fragmented than the
> FreeBSD world.  It's hard to write a program that will work correctly

That's what i agree with you.

Anyway if these microservices would be statically linked this argument
would be irrevelant. And from what i've read it's how microservices should
be made.

> 3) Fashion.  You may not care about the latest IT craze, but a lot of
> IT departments do.  And you can't change their minds all by yourself.

I don't even try to change their minds. I don't discuss with such people.
You can discuss and present arguments to people that don't think.

> If FreeBSD is to be used by people who deploy microservices, then it
> needs to do what they want.  That means it needs Docker or something
> similar (IT admins won't want to learn ezjail if they're already
> comfortable with Docker), or we need to convince people to use
> CloudABI.  CloudABI has the potential to outperform containers.  It
> just hasn't gained traction yet.
> -Alan

Docker is already in ports. If someone want to use it - what a problem?

Anyway if they prefer linux let they use linux.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Wojciech
Puchar wr
ites:
> > At $JOB my customers are migrating from AIX, Solaris and even Windows
> > to Linux and from traditional Linux to microservices run under
> why this "microservices" - which are simply complete programs without
> dependencies (or should be) - cannot be run simply as processes on
> different user accounts?

Because each is a jail, not a full blown jail like but a lite-jail.

Think of it this way. When I first got into this business everything
was run on a huge machine, a mainframe. Later applications were moved
from the mainframe to individual machines, databases to database
servers, applications to application servers, front end processes to
web or proxy servers. Now these services are run on microservices.

You are suggesting we go back to the 1960's and 1970's mainframe model.
As much as you and I want mainframes back, those days are gone.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Igor Mozolevsky-2
In reply to this post by Wojciech Puchar-8
On Sun, 6 Jan 2019 at 19:09, Wojciech Puchar <[hidden email]> wrote:

<snip>

> If something could be added then it would be limiting what ports can each
> user open. But it's not really a problem.

Actually what would be really great is to be able to limit IP
addresses or VLANs to UIDs/GIDs.

--
Igor M.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Wojciech
Puchar wr
ites:

> >> why this "microservices" - which are simply complete programs without
> >> dependencies (or should be) - cannot be run simply as processes on
> >> different user accounts?
> >
> > Several reasons:
> > 1) Separate accounts don't provide as much security as separate
> > containers.  Capsicum does, but people aren't used to using Capsicum
>
> I use separate processes and don't feel the lack of security. I don't use
> capsicum too.

Really? Explain, please.

>
> Could you explain it more precisely why standard process and user/group
> separation is insufficient?

Why then did the industry move from mainframes to the client/server
model?

>
> Simply access rights and setting
> security.bsd.see_other_uids=0
>
> is enough for me.

This is nearsighted.

>
> If something could be added then it would be limiting what ports can each
> user open. But it's not really a problem.

The UNIX security model, even with ACLs, POSIX.1e, and capsicum, sucks.
Again, we had that kind of model on the mainframe. Not quite TCP/IP
ports but Google RACF and ACF2.

>
> > 2) Fragmentation.  The Linux world is much more fragmented than the
> > FreeBSD world.  It's hard to write a program that will work correctly
>
> That's what i agree with you.
>
> Anyway if these microservices would be statically linked this argument
> would be irrevelant. And from what i've read it's how microservices should
> be made.

They're self contained, linked against libraries in the container.

>
> > 3) Fashion.  You may not care about the latest IT craze, but a lot of
> > IT departments do.  And you can't change their minds all by yourself.
>
> I don't even try to change their minds. I don't discuss with such people.
> You can discuss and present arguments to people that don't think.

When you do your own thing you become irrelevant. Lucky for me I'm
close enough to retirement it doesn't matter however if I was younger
I'd have to go with the times. Having said that, I choose to learn new
technologies because I intend to continue to contract after retirement
for the travel money.

You have to realize that the choices made by the industry do make sense
when you view them from the point of view of big capital. The idea is
to reduce money spent on developers, sysadmins, computers and
resources. Not that I say this is good but it is the world we live in.

>
> > If FreeBSD is to be used by people who deploy microservices, then it
> > needs to do what they want.  That means it needs Docker or something
> > similar (IT admins won't want to learn ezjail if they're already
> > comfortable with Docker), or we need to convince people to use
> > CloudABI.  CloudABI has the potential to outperform containers.  It
> > just hasn't gained traction yet.
> > -Alan
>
> Docker is already in ports. If someone want to use it - what a problem?

CloudABI is an attempt to offer an alternative. It didn't have the
momentum that Docker and CR-IO (which will replace Docker) do. One day
we will need to implement Linux namespaces and cgroups (which IMO are
inferior to jails) but apps which intimately interface with those
facilities should be able to port over to FreeBSD relatively easily.

>
> Anyway if they prefer linux let they use linux.

And 95% of the UNIX-like world does. Should we give up and become a
hobby O/S, like some other examples we can think of?

Linuxisms suck but that's the world we live in.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Wojciech Puchar-8
>> I use separate processes and don't feel the lack of security. I don't use
>> capsicum too.
>
> Really? Explain, please.

What to explain. I run program A as user A and program B as user B.
Access rights on user A $HOME is 700 as well as user B.

Both programs (it may be apache server) listens to some port on localhost

One proxy servers presents them to outer world as webpage A and B.

That's all.

>> Could you explain it more precisely why standard process and user/group
>> separation is insufficient?
>
> Why then did the industry move from mainframes to the client/server
> model?
>
I don't understand what your question have to running programs on
different users under unix.

Mainframes are IBM System z or earlier computers. Very expensive.

>> If something could be added then it would be limiting what ports can each
>> user open. But it's not really a problem.
>
> The UNIX security model, even with ACLs, POSIX.1e, and capsicum, sucks.

No explanation why.

For me it's the best model i know.

>> be made.
>
> They're self contained, linked against libraries in the container.

So it should be possible to just put them on user account with all their
files and run them. Unless author assumed it needs root privileges which
is plain wrong.

>
> When you do your own thing you become irrelevant. Lucky for me I'm
> close enough to retirement it doesn't matter however if I was younger

Strange that you are not young and don't see that all of today
"inventions" are solutions to nonexisting problems.

>>
>> Anyway if they prefer linux let they use linux.
>
> And 95% of the UNIX-like world does. Should we give up and become a
> hobby O/S, like some other examples we can think of?

The alternative is to become the same as linux which doesn't make sense.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Wojciech Puchar-8
In reply to this post by Cy Schubert-4
>> dependencies (or should be) - cannot be run simply as processes on
>> different user accounts?
>
> Because each is a jail, not a full blown jail like but a lite-jail.
>
> Think of it this way. When I first got into this business everything
> was run on a huge machine, a mainframe. Later applications were moved
> from the mainframe to individual machines, databases to database

and this was wrong. under unix system it could just run in separate user
accounts.

The latter virtualization or jails is just wrong attempt to solve a
problem that was created. Instead of simply doing it right.

> web or proxy servers. Now these services are run on microservices.
>
> You are suggesting we go back to the 1960's and 1970's mainframe model.

Something. just without overpriced IBM hardware and strange IBM software -
using instead cheap hardware and good unix system.

This is the solution that works. All others only create problems while
solving others.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Poul-Henning Kamp
--------
In message <[hidden email]>, Wojciech Puchar writes:

>and this was wrong. under unix system it could just run in separate user
>accounts.
>
>The latter virtualization or jails is just wrong attempt to solve a
>problem that was created. Instead of simply doing it right.

Ok, that is my que...

Jails have one important property which as far as I know is unique to
all other virtualizations:  You can reach into the jail, unseen.

That means that if your jail has been compromised, you can study
the running processes while they run, without entering the jail
through any mechanism the attacker controls. (trojaned sshd(8) and
so forth.)

I have a mailbox full of anecdotes about how people have been having
fun with attackers in jails that way:  Moving files around, changing
modes on files, killing processes, and the winner so far: swapping
emacs(1) and vi(1) randomly.

As far as I know, that is a uniqu security feature of jais?

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Wojciech Puchar-8
>> problem that was created. Instead of simply doing it right.
>
> Ok, that is my que...
>
> Jails have one important property which as far as I know is unique to
> all other virtualizations:  You can reach into the jail, unseen.

I don't mean jails are bad. They are very useful.

But are NOT needed for most cases.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Cy Schubert-4
In reply to this post by Cy Schubert-4
In message <[hidden email]>, Wojciech
Puchar wr
ites:

> >> problem that was created. Instead of simply doing it right.
> >
> > Ok, that is my que...
> >
> > Jails have one important property which as far as I know is unique to
> > all other virtualizations:  You can reach into the jail, unseen.
>
> I don't mean jails are bad. They are very useful.
>
> But are NOT needed for most cases.

I give up. I'm sorry I started this sub-thread.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

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



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Strategic Thinking

Russell L. Carter
On 1/6/19 2:06 PM, Cy Schubert wrote:

> In message <[hidden email]>, Wojciech
> Puchar wr
> ites:
>>>> problem that was created. Instead of simply doing it right.
>>>
>>> Ok, that is my que...
>>>
>>> Jails have one important property which as far as I know is unique to
>>> all other virtualizations:  You can reach into the jail, unseen.
>>
>> I don't mean jails are bad. They are very useful.
>>
>> But are NOT needed for most cases.
>
> I give up. I'm sorry I started this sub-thread.
>
>

You should have no regrets.  I paid quite close attention because I
have similar inclinations as Wojciech, but Poul and Alan's POV was
liberating.  Collateral damage, it seems.

Russell

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12