SCIENTIFIC-LINUX-USERS Archives

February 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Mon, 2 Feb 2015 15:25:44 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (95 lines)
On 02/02/2015 11:35 AM, Connie Sieh wrote:
>
> On Fri, 30 Jan 2015, Yasha Karant wrote:
>
>> On 01/30/2015 10:32 AM, Brett Viren wrote:
>>> Yasha Karant <[log in to unmask]> writes:
>>>
>>>> For example, will a
>>>> legally licensed MS Win application that does not run under
>>>> Wine/CrossOver work under Docker under SL 7 the same as it would under
>>>> VirtualBox with a full install of say MS Win 8.1 (soon MS Win 10)?
>>> Docker containers run on Linux (the kernel) so, no, if your application
>>> requires honest-to-badness MicroSoft Windows don't plan on using 
>>> Docker.
>>>
>>>> Can one make a Docker application package on the target host (e.g., SL
>>>> 7) or does one need first a full install of the (virtual) base
>>> I don't know what "target" (host? guest?) means here.
>>
>> The application, say A, runs under environment (OS) X, not environment
>> Y.  One wants A under Y.  The target is Y.  Can one build A under Y
>> using the appropriate "chunks"
>> from X with Docker, or does one re-build ("dockerise") A under X for
>> target Y?  In the first event, one only needs to be running Y; in the
>> second event, one needs to be running X to build for Y.
>>>
>>> A Docker image is a full OS (minus the kernel).  To start you write one
>>> line in a Dockerfile like:
>>>
>>>    FROM fedora:20
>>>
>>> and do a "docker build"
>>>
>>> You can follow up this line with additional instructions (such as "yum
>>> install ...") to further populate.
>>>
>>> If you have a second image that shares some portion of these
>>> instructions, or as you add more instructions, any prior existing
>>> "layer" is reused.
>>>
>>>
>>> I don't find a lot of bases for SL but there are ways to add new base
>>> OSes from first principles (CMS has some scripts in github) and there
>>> are established ones for centos.
>>>
>>>
>>> -Brett.
>> Presumably, any application that will run under CentOS, in particular,
>> CentOS 7 that is the RHEL source release for other ports, such as SL 7,
>> should be able to run under SL.  My understanding is that SL 7 is not
>> built from the actual RHEL 7 source that is used to build RHEL 7 that is
>> licensed for fee, but from the RHEL packaged CentOS source (CentOS now
>> effectively being a unit of Red Hat, a for-profit corporation) that is
>> used to build CentOS 7 (that, as with SL 7, is licensed for free as a
>> binary installable executable system that requires no building from
>> source per se).
>>
>> Yasha
>>
>
> SL is built from the source that Red Hat has provided .  It is built 
> from the same source that all rebuilds can build from. There is no 
> such thing as "RHEL packaged CentOS source" .
>
> -- 
> Connie J. Sieh
> Computing Services Specialist III
>
> Fermi National Accelerator Laboratory
> 630 840 8531 office
>
> http://www.fnal.gov
> [log in to unmask]
>
Please correct me if I am in error.  RHEL, binary licensed for fee, is 
built from a source that RH does not seem to release.  Rather, RH 
releases, through the RH subsidiary CentOS and a GIT mechanism, a source 
for all rebuilds, supposedly including CentOS.  Thus, SL and CentOS are 
built from the same source, but the actual RHEL source may or not may in 
fact (claims to the contrary notwithstanding) be the same, as no one 
outside of RH or a RH licensee actually sees the source for RHEL.  If 
RHEL also is built through a GIT mechanism, I am assuming that the 
Internet path to the RHEL GIT is not the same as that to the "public" 
rebuildable CentOS GIT.  In the event that Fermilab or CERN has licensed 
the actual RHEL 7 source as a RHEL licensee, would personnel at either 
non-RH entity be allowed to comment if in fact there were non-trivial 
differences between the actual RHEL 7 source and the "rebuildable" 
CentOS 7 source?  Trivial differences would be the presence of RH logos 
and splash screens, each of which is replaced by whatever the rebuilder 
is using (SL for the SL rebuild) -- but all of the internal intellectual 
property references in the source code still (presumably) mentions RH in 
both the actual RHEL 7 source and the CentOS 7 rebuildable source.

Yasha Karant

ATOM RSS1 RSS2