CentOS - Aug 2017 - Fedora bugs and EOL [was Re: CentOS users: please try and provide feedback on Fedora] Boltron

On 08/02/2017 10:57 AM, hw wrote:
>
> It probably makes sense under the assumption that you do pretty much
> everything in one container or another and that it doesn?t bother you
> having to switch between all the containers to do something.  That would
> require something like a window manager turned into a container manager,
> and it goes towards turning away from an operating system to some kind of
> BIOS to run containers and the container-window manager on.  You could 
> strip
> down the BIOS to no more than the functionality needed for that, 
> resulting
> in having less need for different software versions of the platform 
> (BIOS).
>
> Why hasn?t a BIOS like that already been invented?  Or has it?
>
> Since copyright issues were mentioned, please keep in mind that I am now
> the inventor of a container manager that is like a window manager,
> potentially showing programs running in whatever container as windows
> on your screen, bringing them together seamlessly with no further ado, as
> if they were running on the same OS:  A common window manager would 
> show an
> emacs frame besides an xterm; a container-window manager would 
> basically do
> the same, but emacs and xterm would be running in different containers.
>
> OS/2 already had something like that, but it didn?t have containers.
>
> Why hasn?t a container manager like that already been invented? Or has 
> it?
>
> Wouldn?t it be much better being able to do this without needing 
> containers? 
Sure there is such a thing.  It's a tiled console package (tilix is what 
I use).  In all honesty, I wouldn't want Libreoffice running in a 
container and I can't imagine why you'd want an xterm in its own 
container.  Most containers I've built have been RESTful API containers, 
NGINX proxies/web servers, etc.  I spend more time on the container host 
making changes, than in the containers themselves.  If an API change has 
been made, I throw a new container up with that change and test, rarely, 
if ever, do I need access the container directly.  And that's the idea 
behind containers if you ask me.




-- 
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney at neonova.net
www.neonova.net

On Wed, 2 Aug 2017, Mark Haney wrote:
> Sure there is such a thing.  It's a tiled console package (tilix is
what I
> use).  In all honesty, I wouldn't want Libreoffice running in a
container and
> I can't imagine why you'd want an xterm in its own container.  Most
> containers I've built have been RESTful API containers, NGINX
proxies/web
> servers, etc.  I spend more time on the container host making changes, than
> in the containers themselves.  If an API change has been made, I throw a
new
> container up with that change and test, rarely, if ever, do I need access
the
> container directly.  And that's the idea behind containers if you ask
me.
Lots of people think of containers being for servers, as you say.  It's what
Docker lives off, and really does feel like the focus of Docker.

Singularity lets you think somewhat differently, and has proved very useful in
areas like HPC, where you want to let a user bring a software environment to a
machine.  You get people like OpenFOAM releasing their software as a Docker
container:

https://openfoam.org/download/4-1-linux/

I've also used it to run Ubuntu packaged software on CentOS without having
to
jump through hoops trying to repackage it or otherwise rebuild a million
dependencies in just the right way.

jh

On 08/02/2017 11:13 AM, John Hodrien wrote:
> On Wed, 2 Aug 2017, Mark Haney wrote:
>
>> Sure there is such a thing.  It's a tiled console package (tilix is
>> what I use).  In all honesty, I wouldn't want Libreoffice running
in
>> a container and I can't imagine why you'd want an xterm in its
own
>> container.  Most containers I've built have been RESTful API 
>> containers, NGINX proxies/web servers, etc.  I spend more time on the 
>> container host making changes, than in the containers themselves.  If 
>> an API change has been made, I throw a new container up with that 
>> change and test, rarely, if ever, do I need access the container 
>> directly.  And that's the idea behind containers if you ask me.
>
> Lots of people think of containers being for servers, as you say. It's 
> what
> Docker lives off, and really does feel like the focus of Docker.
>
> Singularity lets you think somewhat differently, and has proved very 
> useful in
> areas like HPC, where you want to let a user bring a software 
> environment to a
> machine.  You get people like OpenFOAM releasing their software as a 
> Docker
> container:
>
> https://openfoam.org/download/4-1-linux/
>
> I've also used it to run Ubuntu packaged software on CentOS without 
> having to
> jump through hoops trying to repackage it or otherwise rebuild a million
> dependencies in just the right way.
>
I honestly had forgotten about Singularity.  Mainly because it's been a 
couple of years since I managed any HPC equipment.  But seriously, I 
think of containers the same way I do linux tools. Unlike MS, a linux 
does does one thing, and that thing very well, whereas MS has tried to 
be everything to everyone and is so-so at all of them.  Perhaps that was 
the original intention of container and it's morphed into something else 
over time, which, if true, means I need to adjust how I define it rather 
than trying to beat that square peg into the round hole in my head.

On a side note, as I write this, Pandora decided to toss 
'Misunderstading' by Phil Collins into my playlist. It's playing as
I
type.  Go figure.


-- 
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.haney at neonova.net
www.neonova.net

Mark Haney wrote:
> On 08/02/2017 10:57 AM, hw wrote:
>>
>> It probably makes sense under the assumption that you do pretty much
>> everything in one container or another and that it doesn?t bother you
>> having to switch between all the containers to do something.  That
would
>> require something like a window manager turned into a container
manager,
>> and it goes towards turning away from an operating system to some kind
of
>> BIOS to run containers and the container-window manager on.  You could
strip
>> down the BIOS to no more than the functionality needed for that,
resulting
>> in having less need for different software versions of the platform
(BIOS).
>>
>> Why hasn?t a BIOS like that already been invented?  Or has it?
>>
>> Since copyright issues were mentioned, please keep in mind that I am
now
>> the inventor of a container manager that is like a window manager,
>> potentially showing programs running in whatever container as windows
>> on your screen, bringing them together seamlessly with no further ado,
as
>> if they were running on the same OS:  A common window manager would
show an
>> emacs frame besides an xterm; a container-window manager would
basically do
>> the same, but emacs and xterm would be running in different containers.
>>
>> OS/2 already had something like that, but it didn?t have containers.
>>
>> Why hasn?t a container manager like that already been invented? Or has
it?
>>
>> Wouldn?t it be much better being able to do this without needing
containers?
>
> Sure there is such a thing.  It's a tiled console package (tilix is
what I use).
I think I?ll check that out.
> In all honesty, I wouldn't want Libreoffice running in a container and
I can't imagine why you'd want an xterm in its own container.
It was only an example.  The point of doing that is to use different versions of
xterm and of emacs as come by default.  How else would I do that when
non-default
versions of packages require their own container each?
> Most containers I've built have been RESTful API containers, NGINX
proxies/web servers, etc.  I spend more time on the container host making
changes, than in the containers themselves.  If an API change has been made, I
throw a new container up with that change and test, rarely, if ever, do I need
access the container directly.  And that's the idea behind containers if you
ask me.
Really?  It?s a lot of work to set up a container.

When you run things like emacs or Libreoffice in a container, how do you use
them
without accessing the container?  How do you change the applications you?re
programming
that are residing in your webserver container without accessing the container?

Why wouldn?t you run Libreoffice in a container?  You might want to use the
latest version
rather than the default one.  So you?d install the version you want, and since
it runs
in a container, it?s what you get.

On Thu, Aug 03, 2017 at 03:25:36PM +0200, hw wrote:
> >In all honesty, I wouldn't want Libreoffice running in a container
> >and I can't imagine why you'd want an xterm in its own
container.
> It was only an example.  The point of doing that is to use different
versions of
> xterm and of emacs as come by default.  How else would I do that when
non-default
> versions of packages require their own container each?
I think what you're looking for here is Flatpak.

-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader