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:
Connie Sieh <[log in to unmask]>
Reply To:
Connie Sieh <[log in to unmask]>
Date:
Mon, 2 Feb 2015 18:17:47 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (114 lines)
On Mon, 2 Feb 2015, Yasha Karant wrote:

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

I compared all of the RHEL 7 RC src.rpm's that were available on 
ftp.redhat.com with the reconsituted src.rpm's from git.centos.org and 
they were the same.


--

Connie J. Sieh
Computing Services Specialist III

Fermi National Accelerator Laboratory
630 840 8531 office

http://www.fnal.gov
[log in to unmask]

ATOM RSS1 RSS2