public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: james <garftd@verizon.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )
Date: Sun, 7 Aug 2016 14:57:14 -0500	[thread overview]
Message-ID: <a0421c61-7d97-ba74-49a2-28300c891cff@verizon.net> (raw)
In-Reply-To: <20160808045555.639b6770@katipo2.lan>

On 08/07/2016 11:55 AM, Kent Fredric wrote:
> Moving this to a higher visibility thread because I don't know how many
> people think such an intense discussion is happening in the tail of a
> package assignment ..... :P
>
> Most of my negativity/limitations are more about making sure we define
> where we aught to go.
>
> They're less "Limits", more "guides", often enough.
>
> On Sun, 7 Aug 2016 12:24:37 -0500
> james <garftd@verizon.net> wrote:
>> Sure, I agree here, but, statistically these "hi level" languages are
>> being taught, in lieu of C; and that is really sad. I'm sure there
>> are exceptions, would you have a few CS departments that push C over
>> java and the other, newer languages? (I'm curios).
>
>
> Here, the "Limitation" as such is that once you realise that "C" is not
> the only target, nor is Java, you realise there are going to be end
> users who want "easy mode" and have no intent on doing any immediate
> development work.
>
> Or we might have user bases who want ready-to-go media for python
> development.
>
> This is not a "limitation", because if you think about customization,
> we can very much provide all the choices.
>
> And theoretically, we can provide named sets of default good choices
> that are "reasonably good for the purpose they describe", and then
> people can pick and choose what they want, and then if they want to
> expert-mode it, they can hand craft their own "choice set", or progress
> to installing their base system like the rest of us.

You are diverging onto a very minor issue, about kids and college 
educations. But, we do have "sets" and they are very useful for a 
variety of goals with portage. Thanks for pointing that fact out.


>
>>
>>>
>>> You can't satisfy everyone out of the box.
>>>
>>>
>>> The rest of your response kinda rotates around a central axiom that
>>> makes other Linux distributions effective, and "Easy":
>>>
>>> The lack of choice, a tailored work flow, a target audience, and a
>>> narrow focus on what the vendor delivers.
>>>
>>> Gentoo is fundamentally unlike these things, because the Gentoo way
>>> has always been first and foremost about *user choice* and
>>> *maximising user choice*
>>
>> Noting in promoting an easy install semantic for a default, buildable
>> system, precludes choice after the system is installed and boot. For
>> examle a default install, using Calamares and ending up with KDE,
>> could easily then have kde removed and lxqt installed. That would be
>> up to the new user to figure out, via the handbook and the wiki....
>>
>>
>>> The reality is a giant hunk of the world are *not interested in
>>> choice* They want something that works and get out of their way.
>>
>> Quite true, but we're talking about increasing gentoo's update
>> amongst those linux leaners, not converting windows/mac users that
>> are not interested in alternatives....
>>
>>>
>>> That's why proprietary systems with deep, vertical architecture and
>>> product lock-in are still incredibly popular.
>>> They understand their market, and they focus on making things work
>>> for that market by tailoring it to a very narrow set of features
>>> that satisfies 95% of its target.
>>
>> Support is always a crowd pleaser, imho. So with fresh ideas, the
>> newest members support those right behind them in line with user
>> level issues. Noobs helping noobs. buntu has proven this works, if
>> nothing else.
>>
>>>
>>> Gentoo's target audience is decidedly that other 5%, the group of
>>> people who don't mind getting their hands dirty, the group who wade
>>> up to their elbows dealing with horrible problems because that's the
>>> consequence of the power of choice.
>>
>> What I proposed, models for easier install and a VM/Container system
>> that is secure and allow for experimentation with "jentoo" does not
>> limit, but, encourage choice and experimentation.
>>
>> Let's focus on the easy install. Once folks get a running gentoo
>> system, most figure out how to manage it and like the choices, build
>> from sources (and bin packages for the larger/complex).
>>
>>>
>>> You can promote pre-boxed Gentoo products if you want, I just think
>>> you're barking up the wrong tree if you think doing that will help
>>> anybody.
>>
>> You are misconstruing the message. It's a boxed, quick install that
>> would behave going forward, with the same (exact) semantics as a
>> grudge-filled traditional install. The only difference is that first
>> install is
>> quick, fast and easy. Nothing else changes, unless this fresh install
>> chooses to embrace additional packaging or alternative packages
>> compare to the default install. Nobody needs to make that decision.
>> Surely many will then go read the handbook and the wiki to move
>> forward. The install just becomes painless for a few basic or default
>> examples. We do currently provide an occasional 'liveDVD'. So just
>> image one of those, with an  easy install pathway.
>>
>>>
>>> As with most open source, it requires volunteer effort to make this
>>> happen, and its a hard sell to try to convince existing staff to
>>> spend more time on producing a thing that exists only to *reduce*
>>> user choice for the sake of convenience.
>>
>> Again, you are incorrectly suggesting that these easy installs will
>> preclude traditional gentoo semantics for adding, modifying, patching,
>> or any other form of currently available modifications or enhancement
>> from occurring. I'm not certain if you are twisting the focus here
>> intentionally, or you are just limited in your imagination? Nobody
>> wants that (artificial) limitation, so why would it me the semantic
>> going forward, after an easy install?
>>
>> Think of it like sex. All of the traditional would be wonderfully
>> available, but we're just adding a quickie (install) as an extra
>> option. No limitations, just *choice* on the install.
>>
>>
>>
>>> And I just think most of our devs have more interesting problems to
>>> solve than that, and you'd be simply weakening the core Gentoo
>>> development team by trying to steal existing Gentoo staff to
>>> engineer this carefully designed and polished "Just Works For
>>> Noobs" platform.
>>
>> Agreed. My idea is some encouragement and maybe receive a little bit
>> of positive advise. The noobs will help the noobs, and a few will
>> migrate down the maintainer--> dev pathway.
>>
>> On this list and elsewhere gentoo devs have admitted to using quickie
>> installs, and liked it. It's just frowned upon to document it and
>> encourage it. Like a wiki page on how to convert a calculate or
>> sabayon install to a traditional gentoo system.
>>>
>>> And even then, I think if you did OK, it would be striving for the
>>> wrong thing.
>>
>> An easy install, does not have to be detrimental. Over the years I
>> have taught quite a few 'youngsters' how to drive on rural flat land
>> in a big 4x4 with an automatic transmission and a booster seat. You
>> just put the transfer case into low, and they cannot go very fast and
>> the love the *power*, spinning tires and slinging mud and riding
>> around. Later on in life they all have matured into productive adults.
>>
>> Face it, gentoo is a power trip, we all know that. Letting folks feel
>> that, in a easy, but real, quick install default version, that
>> eventually hooks them into gentoo.
>>
>>
>>>
>>> If you're going to come to a competition that has existing major
>>> players ( such as the "noob friendly" linux desktop market ), you
>>> have to not be simply a "me too!" in order to hope for success.
>>
>> The power of Gentoo-traditional awaits them, soon after reading and
>> learning from the handbook and the wiki. Not all will use this, but,
>> it sure would put a more attractive face on taking gentoo for a test
>> drive.
>>
>>>
>>> You have to have something unique that blows all the competition
>>> out of the water in at least one way, that capitalises on an
>>> un-tapped need.
>>>
>>> Anything else will just be some pathetic copy-cat attempt.
>>>
>>> And for Gentoo, our "Unique Edge" *is* our configurability, our
>>> incredibly effective and convenient flexibility.
>>
>> Again, nothing in this idea inhibits the full power of gentoo from
>> being available; nothing. The begging of (their) journey is easier and
>> more appealing. Many will stay in the valley of the noobs, but other
>> will turn to the handbook and the wiki; just as grasshopper became
>> shaolin, imho. Monk my words.....
>>
>>
>>>
>>> Sacrificing our primary benefit to chase after some other market
>>> half-assedly ... I can't see that panning out well myself.
>>
>> You keep with this false choice, that is non-sequitur. The only
>> limiting here is your mind.
>>
>>
>>>
>>> Personally, I think we need to double down on what we're good at,
>>> flexibility, and configurability.
>>
>> No arguments there. Putting an experimental for of gentoo, complete
>> with questionable java, into a secure Gentoo hosted VM or Container,
>> is not flexibility and configurability?
>>
>>
>>>
>>> Find ways of building systems at the users behest that do exactly
>>> what they want easily, and not assume we know what is best for our
>>> users.
>>
>> You should go to any of the progressive job boards (stackoverflow
>> etc). Java is everywhere. It should not be mandated but a choice.
>> Sincere the are numerous issues java, secure it via a VM or a
>> container, if that can be done?
>>
>>
>>
>>>
>>> Anything else and Gentoo will go in the direction of the sad sorry
>>> state of the Linux Desktop, where neither GTK/Gnome or QT/KDE are
>>> very useable anymore, and they've become encumbered with horribly
>>> lethargic and bloated design, because they were all trying too hard
>>> to chase what they thought people wanted, the standard established
>>> by Windows and OSX for "Easy".
>>>
>> Agreed and that is not what I'm proposing, either. I'm proposing an
>> easy install for a few types of basic systems (that choice is open to
>> discussion). And, if possible, a way to put either a secure VM or a
>> secure container on a hardened gentoo system to put an
>> insecure/experimental form of jentoo into.
>
>
> Here is my incomplete idea of how I would see this working out in our
> favour.
>
> For one, some context: On Quora, I frequently see questions in the form
> "I have <blah> condition and <blah> requirements, what is the right
> linux for me and my hardware <blah>"
>
> There are literally so many such questions its mind-numbing.
>
> Explaining the nuance and benefits of lots of different alternatives is
> a pain in the ass, and it would be nicer to simply say "Gentoo" for
> each and every question, then tack onto it "Under configuration X"

True, but you miss my previous point on what you have just stated. WE do 
not have to try to offer a quickie install for every possible scenario; 
that's a fools errand, imho. Of the myriad of possibilities,


Gentoo cold offer but a single, robustly secure workstation running KDE
that is a quick install right off the liveDVD. Once it is running, they
can just read the handbook and the wiki pages for guidance on 
deviations. It would update just like a traditional gentoo installed 
system where after days a traditional install with hardened and kde just
happened to end up. Form that point forward, it's gentoo; caveat emptor.

One version iso, maybe updated every 3-6 months. That's it; all else is 
gentoo traditional.


>
>
> Here's what I think would be "Nice".
>
> 1. "Nice" Installer that did the grunt work, but which grunt work it did
> was not actually specified by that installer.
>
> 2. Instead, the "Nice" installer is fed a recipie file, and the recipie
> file glues user input and system configuration together, which the
> installer than "Makes happen".

Have you tried any of the ansible recipes from here?::


>
> 3. Recipie files would in part contain a SHA1 containing the git commit
> on repo/gentoo.git that it used to install from, and they would end up
> at the end of their execution provisioning /etc/portage and friends,
> and finialising an install.
>
> 4. The key part of relying on "Set of specified configuration and SHA1"
> is repeatability.
>
> Historically a lot of the headaches I've found with Gentoo was you
> tried to install your brand new system, and oops, the configuration you
> chose ran into some bug and you had to think about things, because the
> tree got updated between the time the instructions were written and the
> time you tried to do them.

experience folks are now creating their own stage-4's for some similar 
situations. I do think our routine usage of Stage-4 will organically 
increase; but I'm not sure we have semantics in place to share those
gains in wisdom. Individual choice to share must always be respected.


>
> And that kind of problem is bound to leak into any installer that
> installs "Fresh" from updated sources.
>
> This means with a "recipie + SHA1" combination you can either
>
> a) Download the recipie only and bootstrap that recipie into a full
> system downloading everything as you go
>
> b) Use that recipie to pre-build resources and assemble installation
> media that allows you to perform an identical implementation of a, sans
> internet access.
>
> Though doing both of these would be hard in some cases, because if the
> recipie is configuration-free in regards to compile flags, then both
> can be done. But if configuration needs to change compilation, 'b' gets
> a little trickier.
>
> Essentially, I'm kinda thinking beyond "Just a thing" and thinking in
> the direction more of "A meta thing".
>
> If you want to make people feel powerful, how much more can you get
> than doing what we've done with .ebuilds?
>
> Ebuild being bash may be a horrible format, but man, every day I use it
> and see what everyone else is doing, I just love it. You can get insane
> loads of stuff done with incredibly little effort.
>
> And if you want to give people power trips, what could be more powerful
> than empowering everyone to create their own flavour of
> gentoo-based linux just by tweaking a bash script?
>
> Then we'd just have a maintained repository of these recipies that are
> vetted by devs and signed.
>
> And you could even have a net-inst installer that starts out by syncing
> that repository and giving you a list of recipies to install from.
>
> Emerge yourself a whole gentoo :P

Sure that could work, but you are making the entire idea, way to 
cumbersome to implement. Loose the concept of everything; that will 
occur organically, over time, if validated by the user base. Focus on a 
singular, common need and simplify that so that noobs could use it to 
'feel the power' and all could use it for a baseline install. Then drive 
off what ever direction one chooses, with traditional gentoo semantics 
going forward.

The secure VM/Container/JuniorGentooDistro could wait and organically 
grow up later on, perhaps offered as a stage-4 install, with a basic 
doc, once folks figure that pathway out, manually.

Blueness has tremendously inspired my thoughts and has provided many of 
these pieces already. My struggles are good for me and I'm just perhaps 
sharing a bit too much of my aspirations and pathological pains as I 
trudge forward in my little world of hope and inspiration.

>
> NB: I'm really tired, so I'm in that "can't tell if this is brilliance
> or deranged rambling" mode.


I think that there is  synergy. At the very least (with Rich's blessing) 
I shall trudge forward, as I've been hacking and noodling with many of 
these ideas, and most have been culled from history in one form or another.


hth,
James




  reply	other threads:[~2016-08-07 18:49 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06 14:39 [gentoo-dev] Re: Packages up for grabs Felix Janda
2016-08-06 16:04 ` Peter Stuge
2016-08-06 16:22   ` Michał Górny
2016-08-06 19:28     ` Peter Stuge
2016-08-06 20:47       ` Rich Freeman
2016-08-06 20:55         ` Michał Górny
2016-08-06 22:32           ` Rich Freeman
2016-08-06 21:12       ` Peter Stuge
2016-08-07  6:48         ` Michał Górny
2016-08-07  7:38           ` Consus
2016-08-07 13:24             ` james
2016-08-07 13:32               ` Kent Fredric
2016-08-07 14:06                 ` Alan McKinnon
2016-08-07 14:46                   ` Alec Ten Harmsel
2016-08-07 17:36                   ` james
2016-08-07 20:04                     ` Alan McKinnon
2016-08-07 20:48                       ` Patrick Lauer
2016-08-07 22:29                         ` james
2016-08-07 21:49                       ` james
2016-08-08  3:22                         ` Kent Fredric
2016-08-08  5:26                           ` james
2016-08-08  4:33                             ` Kent Fredric
2016-08-08  5:43                               ` Kent Fredric
2016-08-07 17:24                 ` james
2016-08-07 16:21                   ` Ciaran McCreesh
2016-08-07 17:59                     ` james
2016-08-07 16:55                   ` Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs ) Kent Fredric
2016-08-07 19:57                     ` james [this message]
2016-08-08  5:14                       ` Jason Zaman
2016-08-07 14:09               ` [gentoo-dev] Re: Packages up for grabs Consus
2016-08-07 17:44                 ` james
2016-08-07 14:47               ` Rich Freeman
2016-08-07 17:47                 ` james
2016-08-07 17:49                   ` Rich Freeman
2016-08-07 19:33                     ` james
2016-08-07  4:04       ` Kent Fredric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0421c61-7d97-ba74-49a2-28300c891cff@verizon.net \
    --to=garftd@verizon.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox