Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

On 02/02/2017 04:05 PM, Rich Freeman wrote:
> On Thu, Feb 2, 2017 at 3:35 PM, james <garftd@×××××××.net> wrote:
>
>>
>> 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).
>>
>
> Not really for all sorts, more for servers.  Otherwise I get it, and
> at this point now that I run almost everything in containers I tend to
> be more inclined to run different distros in those containers.
>
>> 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?
>
> Nothing, in that space.
>
> The problem is the new user experience.  When somebody is new to
> Gentoo and not super-knowledgeable the first thing they're going to do
> is set up a desktop.  Now, they might not call it a desktop.  They
> might not even run X11 on it.  But, they're basically falling into
> that desktop user experience where whatever they do install "just
> works" and is feature-complete.

Wow, I'm shocked. Perhaps you have forgotten that is was "I" that 
bemoaned and protested ad nauseam for a simple, basic desktop
for the noob moving to or just testing gentoo? Needless to say the
majority of long term folks on gentoo-user, prefer to run those noobs 
off. (Remember I was on gentoo-user for 12 years, by the hour.)
Now our gentoo distro is catering and concerned about these folks?
(excuse me but I haft to roll around on the floor a bit to get some
belly laughter out....) ok, I'm back now. Nobody give a damn about the
gentoo noob; that's why it is gentoo policy not to have an installer.



> It is true that we also attract advanced users who are looking for
> something different.  They have no issues getting any distro to dance
> for them, and they're picking Gentoo because it is best suited for
> their specific need.  These users are much more likely to be
> interested in minimal configurations, embedded systems, the hardened
> profiles, and so on.

This pool is growing and many are contributing.... hardened on top
of minimal.... very very cool.

> However, the problem is that if we optimize mainly for the second
> group we basically lose the first group entirely, and I suspect that
> is overall going to be the bigger group.

Nope, sorry, I have to disagree. Please explain why we cannot, in the 
profiles, support both groups. The (minimal) embedded profile pathway 
need not be mentioned in the handbook. But, perhaps in the 
gentoo-embedded-handbook it could be introduced ? If the embedded devs are
offended, then it could be unser it's own profile:: spartan, monopod,
minimized or any self identifying moniker.


> If what you want is a "unikernel profile" for Gentoo then you're going
> to be changing a LOT of assumptions.

Oops, hit the brakes! Unikernels the way that unikerel.org describes
them is more of a enhanced state machine boot_code or an executive
or a linux kernel plus one lib. Sorry but that's not the only vision
and mine is to build highly targeted 'minimal' gentoo systems that can 
dynamically shed and load new frameworks (groups of packages and codes 
and such) on top of the 'default set' or embedded set of packages. So it 
can become a full blown mail server or a singular monotonic device, just 
sniffing ethernet, without a reboot. I'm betting the farm that my vision 
of minimal/embedded gentoo will be far more successful than those folks 
pushing proprietary Unikernel products. Still the generic moniker 
'unikernel' is the closest commonly used moniker to where I'm driving 
too, I so 'lifted' it from those folks. Goals are similar but mine is a 
minimized gentoo, at it's core and dynamically flexible without reboot.



> Forget openrc vs systemd, there
> is no reason to have any init implementation on the thing.  Forget
> linux vs bsd, there is also no reason to have a kernel in a container.
> We don't need any editor because you're probably going to do any
> config file editing from outside of the container.  And that @system
> set that has all that bootstrapping stuff is probably way overkill if
> all you ultimately need is a single package to work (and maybe not all
> of that package).  Heck, your overall install approach also should be
> questioned.  Rather than build your unikernel from inside its own
> container, you should be building from a more complete image and just
> installing the minimum RDEPENDs in the production container (as with
> catalyst or the chromiumos builds).  And you probably wouldn't be
> upgrading such things in place either, you'd just be creating newer
> instances and cutting over from the old.

I agree with you on this, absolutely. But you are far off from my
branch of the profile tree and my pathway forward, so it's accurate
but completely uncharacteristic to what I'm developing.


> I don't question that it would be great for Gentoo to support all of
> this stuff.  I just think that we need to be careful not to destroy
> the experience of somebody who just wants a "typical" install in order
> to do it.  Somebody who doesn't want to take the time to tweak how
> their java implementation works probably wants the default install to
> be something that meets the Oracle standard.  Now, somebody who is
> into tailoring can look at their application and tweak the living
> daylights out of it, but that shouldn't be what you get when you run
> "emerge icedtea" or whatever.


I just do not see your 'either or scenario' as the only possibility. For 
example, in a recent gentoo-dev thread,  those profile owners (devs) 
were asked to step forward and state the  viability going forward of a 
profile review thread. If one of those devs wants one of those itemized 
profiles to continue to exist, is it going to be forcibly deleted?  (no)

So all I have to do is convince  (beg?) one dev to have a place in the 
profile tree that is not subservient to upstream dictates? Perhaps
another way forward for my work? (Glep-70?)


> Sure, you could do all that with a profile, but the problem is:
> 1.  Maintainers aren't going to necessarily invest in that profile.

Can I proxy-maintain a profile for minimized gentoo clusters?
Can I share a profile with another compatible (need) profile ?


> 2.  New users won't necessarily use that new profile.

That would be excellent. That's why there are many choices for profiles, 
right?


> And when those things doesn't happen users look at Gentoo as the OS
> that nothing works right on.

Non-sequitur....
user's will be on a handbook delineated profile choice; capable users
will be able to navigate handbook choices and other available profiles,
or seek (neddy?) guidance. The profile I'm talking about could
be logically under the old branch of 'experimental' if that survives 
too.  But would be best as close to the root of the profile tree, as 
possible.  The least amount of packages installed, is best, and located 
in a different branch than the default or whatever the new name is where 
a plethora of upstream issues exit. None of this would be a burden
to ebuilds, if they do not work, so be it, I can and will fix what I 
need from upstream. Every week, that list grows shorter and shorter, 
particularly for the minimal builds.


Hopefully I have justified and succinctly stated my vision, is 
accommodation not possible? All I really need is a minimized (a least or 
very low set of packages) profile that is not so concerned with most of 
the upstream projects and the noise found therein.


hth,
James