On 02/02/2017 01:01 PM, Rich Freeman wrote:
On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <m...@gentoo.org>
wrote:
If (base == minimal), then all of the upstream defaults need to
be added
to package.use for the upstream-defaults profile. That's bad,
I'll go further and say that it is unacceptably bad.
but if
(base == upstream-defaults), then the important IUSE defaults
need to be
copy/pasted from our ebuilds into the minimal profile. The latter
is
more spiritually damning =)
So, I'll admit I've never been one that cared a great deal about
minimalism so I appreciate that I may not be the best one to judge
this, so let's go ahead and embrace your statement for the purpose
of
debate.
Is there a better way we can have our cake and eat it too? I'll
admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.
Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite? Does anybody care to
actually suggest one?
I think that unikernels are something everyone should be aware of
as they purport to be the latest trend in securing all sorts of
systems.
(a brief read).
http://unikernel.org/
Perhaps we should not have a 'minimal profile', as it means so many
different things to so many different people. We have not even
surveyed
the user base...
So if we think of all the possible profiles and sub-profiles as being
organized in a tree structure, it is better to figure out logical
organization of all profiles, imho.
So how about profiles that are either under the embedded or basic
'moniker' in the profile tree. So embedded is the least number of
packages possible, regardless of upstream, where folks build up
from
there to what they want as a finished system. Embedded, clusters,
HPC,
and such are compatible enough for what I'm building to be under the
same branch of the profile tree. If other folks want their cluster
works
under the basic part of the profile tree that is concerned with
upstream, then they have their part of the profile tree located
there.
And the 'basic' part of the tree is similar to what we now call
'default' and the names build up in whatever schema those target
builds
desire, like basic+headless, basic+kde, basic+?+whatever..... ?
And is there any reason, if necessary that other needs cannot be
branched off, as necessary form the profile tree? Perhaps the main
root
is a state diagram of what is need and has links to relevant
documents.
That way the profile tree is a live system that can be enhance or
modified to serve all of Gentoo's diverse visions.
I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults. There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a
lot
of rope to hang themselves with.
This is only the case because profiles are in general in a mess and
there are little in the way of conventions. What is so sacrosanct
about
upstream for a truly embedded gentoo system or a gentoo based IoT
device? How many of the gentoo-embedded devs even bother to read
gentoo-dev? Your vision seems to me to be tainted by the major
distros
and their visions, not be impolite, but they are way off course for h
ttp://www.easyjet.com/en/
secure systems, embedded systems, IoT, HPC and numerous other active
areas of Linux, imho.
Think about it, if upstream is so brilliant, and has our needs 'at
heart' then why have not the kernel-geniuses bothered to build a
logical, coherent semantic for kernel configurations, management,
security testing and such? If fact, if I were to be critical of
upstream, I'd say those and many other issues should have been
addressed
before the adventures of systemd were dictated upon the larger user
base. Upstream is an 'ad-hoc' mess, in the old days we called such
entities a clusterF*.
So those of us going back to minimal and basics and such venues, even
with clusters, could not care less about Mozilla, systemd and
thousands
of other upstream folks that have lost their pathway forward.
(deepest
apologies, but I have very strong feelings about "upstream*".
Many of the profiles in this and other recent threads, are just 'ad-
hoc'
naming structures and locations, and that historical flexibility
extend
to the devs is fantastic. This enhance/cleaning need of gentoo
profiles
needs to be well thought out and as flexible semantically as
possible.
It is absolutely a superior approach to not care at all what
upstream
does, to provide a pathway for embedded gentoo. That is a
fundamental
characteristic of what an embedded system is. Thanke the code, purge
90+ percent of this, and then install it on a embedded system so
only what is needed is encluded. On a distro, you can pile on tons
of uncessary codes, for convenience and not care, but embedded,
it does matter. That is why so much of Iot is hacked and owned
by folks with nefarious intentions. Much of 'upstream' is growing
dumber by the day, and corporate manager and government interlopers
are just loving the cruft of 'upstream'.
Minimal is a close cousin to embedded, and now unikernels and
aggressive
HPC clusters are going that direction too in the name of
performance,
sane-management and reducing attack surfaces for the cloud or HPC
cluster (not all, but many).
Surely a branch of the gentoo profiles tree, could rigorously be
focused
on compatibility with upstream, but that inflexibility, if imposed
on everyone else, will only serve to further alienate gentoo-
embedded
and serve as a unnecessary wedge between some minimal, HPC and
unikernel
types of gentoo builds.
It is like building a kernel
answering no to the largest number of questions possible while
still
actually building something. I'd actually be curious as to what
that
kernel would even be capable of doing (there are a lot of fairly
essential things you can turn off in the kernel).
This is a whole other area of valid concern. Their was a GSoC project
last summer to work on organizing gentooish kernel builds, but that
is a
very big topic. Perhaps the profiles will have to be proposed but not
formalized until folks go out and do some kernel builds and testing
associated with a proposed profile organization?
In the same way, we shouldn't be too quick to deviate from upstream
defaults ourselves (#4 in your example), beyond actual integration
work.
I'll admit the current state is a bit of a compromise, but I don't
think we should change it unless we're changing it to something
significantly better. This is a pretty big-impact change.
Just formalize some new parts of the profile tree to not be required
to
be upstream compliant. Isn't that part of being a 'meta-
distribution'?
In my future (and the future of many others) there will be
minimalistic
builds on clusters where any number to constructs including
compatibility which will all be solved, at the framework level, not
the
base distro level, to the extent possible. Folks are now running a
myriad of windows OS versions on linux (&clusters), so I have just
read
about a few days ago. So I'm proposing and working on gentoo
heterogeneous cluster where one can partition part to be for systemd
stuffage, part to be HPC, part to be extraordinarily secure, part to
be
aligned with a particularly commercial linux distro, and many other
differing needs based frameworks.
The minimal (lowest level) should be clear of all of those distro
encumbrances. CoreOS is taking this approach, as their bare metal
bootstrapping occurs completely and well before systemd or any other
PID1 schema is invoked or becomes a defacto requirement. Gentoo is
all
about freedom, right?
hth,
James
