[gentoo-dev] Re: Packages up for grabs

[gentoo-dev] Re: Packages up for grabs

[Felix Janda]

I'd like become a proxy-maintainer for app-editors/nvi.

--Felix

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Felix Janda wrote:
> I'd like become a proxy-maintainer for app-editors/nvi.

Sweet! If there are some open bugs then please upload patched ebuilds
and other neccessary files to the bugtracker, ideally as output by
git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
to get someone to proxy them into the tree for you.

https://anongit.gentoo.org/git/repo/gentoo.git


//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Sat, 6 Aug 2016 16:04:08 +0000
Peter Stuge <peter@stuge.se> wrote:

> Felix Janda wrote:
> > I'd like become a proxy-maintainer for app-editors/nvi.  
> 
> Sweet! If there are some open bugs then please upload patched ebuilds
> and other neccessary files to the bugtracker, ideally as output by
> git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
> to get someone to proxy them into the tree for you.
> 
> https://anongit.gentoo.org/git/repo/gentoo.git

Or file a pull request @ https://github.com/gentoo/gentoo/pulls. That's
the most convenient solution for most of proxy-maint team members.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Michał Górny wrote:
> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> That's the most convenient solution for most of proxy-maint team members.

How can I help improve that problematic situation?

It's not cool to gravitate the project towards GitHub Inc.


//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge <peter@stuge.se> wrote:
> Michał Górny wrote:
>> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
>> That's the most convenient solution for most of proxy-maint team members.
>
> How can I help improve that problematic situation?
>
> It's not cool to gravitate the project towards GitHub Inc.
>

I'm sure everybody would love to have a non-github alternative.  The
problem is that they all tend to be Java-based and infra doesn't want
to go near them (that isn't intended to imply anything other than the
state of things).

So, it sounds like we either need a non-Java-based alternative, or a
way to host Java applications.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Sat, 6 Aug 2016 16:47:09 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge <peter@stuge.se> wrote:
> > Michał Górny wrote:  
> >> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> >> That's the most convenient solution for most of proxy-maint team members.  
> >
> > How can I help improve that problematic situation?
> >
> > It's not cool to gravitate the project towards GitHub Inc.
> 
> I'm sure everybody would love to have a non-github alternative.  The
> problem is that they all tend to be Java-based and infra doesn't want
> to go near them (that isn't intended to imply anything other than the
> state of things).
> 
> So, it sounds like we either need a non-Java-based alternative, or a
> way to host Java applications.

No. The problem is that alternatives suggested so far have been crap,
and people focused on preaching and/or implementing random crap-based
solutions without even stopping for a few minutes to consider what we
exactly need.

GitHub works for us. GitHub works for our contributors. GitHub boosts
our productivity, unlike those vain discussions. We don't have time for
all this tin foil hat nonsense.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sat, Aug 6, 2016 at 4:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> GitHub works for us. GitHub works for our contributors. GitHub boosts
> our productivity, unlike those vain discussions. We don't have time for
> all this tin foil hat nonsense.
>

Then just ignore it.  If somebody wants to work on an alternative,
nobody can stop them.  Nobody is suggesting putting the github
solution on hold in the interim.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Peter Stuge wrote:
> How can I help improve ..?

Michał Górny wrote:
> people focused on preaching and/or implementing random crap-based
> solutions without even stopping for a few minutes to consider what
> we exactly need.

You could interpret my question as "what exactly do we need" ?


> GitHub works for us. GitHub works for our contributors. GitHub
> boosts our productivity, unlike those vain discussions.

Windows works for me. Windows works for my customers. Windows
boosts my business, unlike vain discussions about open source
and free software. ;) Maybe you get my point?


> We don't have time for all this tin foil hat nonsense.

I think we have all the time in the world, and I think it's important
for us to innovate also in this field if neccessary, as we have and
continue to do in other distro-development-related fields.


Thanks

//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

Dnia 6 sierpnia 2016 23:12:55 CEST, Peter Stuge <peter@stuge.se> napisał(a):
>Peter Stuge wrote:
>> How can I help improve ..?
>
>Michał Górny wrote:
>> people focused on preaching and/or implementing random crap-based
>> solutions without even stopping for a few minutes to consider what
>> we exactly need.
>
>You could interpret my question as "what exactly do we need" ?

If you really want to know...

For a start, something that would satisfy the performance, maintainability and security needs of infra. I haven't heard of anything like that, so you'll probably have to start a new project. I suggest high quality C/C++ since other languages are either completely unreliable, slow and/or designed to be a security nightmare.

Once again, bear performance in mind. Most of the existing tools can't handle big repos. It ain't productive when every small action takes 5 seconds.

Accessibility is also important, but without hurting convenience. Probably accessible web interface with optional ES booster and a reasonably stable API (i.e. not pybugz-style 'XMLRPC is not cool anymore, so we instantly kill all the API you ever used').

That's it for the generic requirements. Now for the specific workflow:

1. Preferably no custom registration. Some kind of SSO via Bugzilla, OpenID or GitHub would work. No additional passwords, thank you.

2. Ability to conveniently post branches for review. Git push is most preferable, but I guess we can live with mails if done sanely).

3. Ability to conveniently get branches for merging. Again, git pull is the best option here. No 'click and download this dozen patches'.

4. No need for remote merge. The thing's not going to push anything directly to git.g.o.

5. Fast review with per-line and general comments. Ability to hide threads as resolved. Lightweight so that people don't have to put multiple remarks in a single comments. Readable so it's easy to note remarks made by others.

6. Good support for updating commits. Preferably being able to reapply (move) comments as appropriate.

7. Some kind of nice assignment/CC system with notifications that covers all developers without explicit signup.

>> GitHub works for us. GitHub works for our contributors. GitHub
>> boosts our productivity, unlike those vain discussions.
>
>Windows works for me. Windows works for my customers. Windows
>boosts my business, unlike vain discussions about open source
>and free software. ;) Maybe you get my point?

Does Microsoft let you use Windows for free? But yes, I generally agree. I regularly use Windows to print after many hours wasted on trying to get printing working on Linux. Having to print three pages a month, my business is much happier with it.

>
>
>> We don't have time for all this tin foil hat nonsense.
>
>I think we have all the time in the world, and I think it's important
>for us to innovate also in this field if neccessary, as we have and
>continue to do in other distro-development-related fields.

Sure we do. In the meantime, nobody uses gentoo anymore because it still can't deal with accepting contributions and in the meantime the few last developers retired, and users long ago switched to the comparatively recent distribution of Debian stable.


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Re: Packages up for grabs

[Consus]

On 08:48 Sun 07 Aug, Michał Górny wrote:
> Sure we do. In the meantime, nobody uses gentoo anymore because it
> still can't deal with accepting contributions and in the meantime the
> few last developers retired, and users long ago switched to the
> comparatively recent distribution of Debian stable.

Finally the voice of reason.

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 02:38 AM, Consus wrote:
> On 08:48 Sun 07 Aug, Michał Górny wrote:
>> Sure we do. In the meantime, nobody uses gentoo anymore because it
>> still can't deal with accepting contributions and in the meantime the
>> few last developers retired, and users long ago switched to the
>> comparatively recent distribution of Debian stable.
>
> Finally the voice of reason.

Reasonable?  Are you kidding?
<rolling on the floor with laughter, uncontrollably >

In this day and age, quick installs are the mantra, either for VMs or
containers or workstations, particularly for 
application-specific-servers or a variety of security apparatus. 
Although the 'handbook' is an excellent reference guide and noob-filter, 
the simple fact of the matter is most (nix) professionals consider the 
gentoo install system to be arcane and an incredible 'cost barrier to 
entry'. THAT, the lack of a well thought out, smooth, quick/easy install 
which is intentionally not  available, because it  is seen as a satanic 
idea, is the 800 pound gorilla on why folks passionately avoid gentoo.....


As a team, we could have a simple default program for a simple default
disk format, and a variety of 'stage-4' images, maybe updated every 3 
months, to get a gentoo system up, quickly. Not an anything you want it 
to be, but a few, common choices. Perhaps a security apparatus, commonly 
needed, built on the hardened project? (like a bridge or a firewall)?


Then index the noob questions received from  the jentoo-users ML,  into 
the handbook or companion documents, in a hyperlinked FAQ. Folks could 
then work the question/support board of jentoo-user before being 
accepted into jproxy-maint.  JProxy-maint would then need to become a 
collection of docs to read, a half dozen ebuilds to update and then 
bang, junior-dev status where folks can work on non-critical parts of 
the jentoo tree.  And there could be a 'bypass exam' that if you know 
the basics of *nix and shell, you could jump straight into contributing 
on jentoo. Or better yet:: (Fork the tree for the jproxy-maint and 
junior-devs to run themselves. That fork could be limited to a few 
security appliance(s) system, and an embedded jentoo system (rasp. pi) 
and a firewall/bridge. Let them use java* codes, as that is what all the 
universities are teaching and promoting. I agree with gentoo proper on 
severely restricting java*,  on gentoo-proper, but that sort of thing is 
killing gentoo and just appears to the open world as a filter mechanism 
to keep out and go elsewhere, snoot. There are just too many exciting 
and useful codes out there running java.


After 12 years of using gentoo, the gentoo install semantics, still are 
abysmal, imho. I just fundamentally disagree with forcing folks to first 
endure the handbook before getting any gentoo (working gentoo system) 
gratification. That is why 'Debian/buntu' has market share over us. Here 
is a very useful "canned" install that, if emulated, would give gentoo 
reams of "kudos" or "atta-boys" should we publish (provide) something 
like this.[1]

[1] http://blog.securityonion.net/


"Security Onion is a Linux distro for intrusion detection, network 
security monitoring, and log management. It's based on Ubuntu and 
contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, 
NetworkMiner, and many other security tools. The easy-to-use Setup 
wizard allows you to build an army of distributed sensors for your 
enterprise in minutes!"


We could even call it "jentoo", as it could be labeled to indicate it
is for junior developers to experiment, learn, grow and then become a 
fleeting-gentoo-dev found @ gentoo-dev proper. And yes enjoy the latest 
of from the (insecure) java world.


Restated:: the current (lack) of a slick, simple & quick install 
semantic, is what's killing gentoo, if it is dying. What I run into are 
reams of deeply accomplished technical folks that use gentoo regularly 
and like the current filters that run off the less astute, imho. YMMV.
Most all other rolling distros have a much simpler installation 
semantic, if not a variety of easy install options and ways to participate.

Perhaps a well defined OS model, where gentoo can run (secure) VMs or 
containers from jentoo?   That would expand the model of usage and 
encourage inclusion, provide a pathway to the ultimate gentoo-dev status
and encourage innovation (and failure) all in a secure model?

Heaven forbid that we put up a few dozen (unsupported) jentoo VMs,
container-images or stage-4 (specifically purposed) choices where
folks could only get support from jentoo-user. No sir, we cannot make 
jentoo fun and enjoyable and quick (and sleazy) can we?


And yes allow java, the way it is available on most other distros...
The current process of requiring all the java codes to be broken down 
into 100% discernable codes is a tremendous barrier. After all, most of 
the codes that use that stuff, are full of holes anyway; that's the very 
nature of open, fast, exciting new codes. They only become secure
after years of vetting (fuzzing) anyway. So make the host gentoo image 
very secure and allow jentoo projects to be a VM, or container or such
construct, without all the hassles of gentoo proper. Let the purist 
ensure that gentoo is secure and isolated and let the multitude play 
with java, however they like (in a VM, or a container image or a stage-4).

You have to look at CoreOS and conclude that even folks with deep 
expertise and deep pockets want an easy install (even roll-back) OS.



hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 4566 bytes --]

On Sun, 7 Aug 2016 08:24:51 -0500
james <garftd@verizon.net> wrote:

> 
> As a team, we could have a simple default program for a simple default
> disk format, and a variety of 'stage-4' images, maybe updated every 3 
> months, to get a gentoo system up, quickly. Not an anything you want
> it to be, but a few, common choices. Perhaps a security apparatus,
> commonly needed, built on the hardened project? (like a bridge or a
> firewall)?

I for one miss the days where Stage-1 was the defacto install, and
Stage-3 was "For lazy people who just wanted to use something".

When we transitioned to making Stage 3 the default, it was like, heresy.

Stage 4? :)

I highly encourage people to randomly hurt themselves by attempting an
unsupported Stage 1 install, just to find what breaks.

> Let them use java* codes, as that is what all the universities are
> teaching and promoting. I agree
> with gentoo proper on severely restricting java*,  on gentoo-proper,
> but that sort of thing is killing gentoo and just appears to the open
> world as a filter mechanism to keep out and go elsewhere, snoot.
> There are just too many exciting and useful codes out there running
> java.

"All" ? Some. And the dominance and focus on Java is itself telling of
the quality and type of the education provider.

Some education providers may not touch Java at all, and focus
predominantly on C.

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*

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.

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.

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.

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.

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.

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.

And even then, I think if you did OK, it would be striving for the
wrong thing.

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.

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.

Sacrificing our primary benefit to chase after some other market
half-assedly ... I can't see that panning out well myself.

Personally, I think we need to double down on what we're good at,
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.

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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Alan McKinnon]

On 07/08/2016 15:32, Kent Fredric wrote:
>> Let them use java* codes, as that is what all the universities are
>> > teaching and promoting. I agree
>> > with gentoo proper on severely restricting java*,  on gentoo-proper,
>> > but that sort of thing is killing gentoo and just appears to the open
>> > world as a filter mechanism to keep out and go elsewhere, snoot.
>> > There are just too many exciting and useful codes out there running
>> > java.
> "All" ? Some. And the dominance and focus on Java is itself telling of
> the quality and type of the education provider.
> 
> Some education providers may not touch Java at all, and focus
> predominantly on C.
> 
> You can't satisfy everyone out of the box.
> 


I have no idea where James gets his information from, but I suspect it's
a niche market where uni students do "clustering" - whatever that is.

The interesting apps out there are mostly running python, go and
(sometimes) lua. And that's what I observe in my day job -
business/mobile ISP.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: Packages up for grabs

[Alec Ten Harmsel]

On 8/7/2016 10:06 AM, Alan McKinnon wrote:
> I have no idea where James gets his information from, but I suspect it's
> a niche market where uni students do "clustering" - whatever that is.

Many of the new frameworks/servers that are developed for running or 
managing clusters are written in Java, which is what he's referring to 
as far as I can tell. Hadoop, spark, hive, pig, marathon, cloudstack, 
zookeeper, and many more (see http://www.apache.org for plentiful 
examples) are all JVM-based languages.

University students do not touch on anything related to clustering until 
graduate level courses (I just graduated from the University of 
Michigan), unless they work on that stuff as a job or in their spare time.

> The interesting apps out there are mostly running python, go and
> (sometimes) lua. And that's what I observe in my day job -
> business/mobile ISP.
>

Yes and no, depending on what you find interesting. Plenty of web 
applications are written in python or ruby, but I think it's safe to 
assume that most high-traffic organizations have mounds of Java and 
C/C++ services on the backend for various reasons.

Alec

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 09:06 AM, Alan McKinnon wrote:
> On 07/08/2016 15:32, Kent Fredric wrote:
>>> Let them use java* codes, as that is what all the universities are
>>>> teaching and promoting. I agree
>>>> with gentoo proper on severely restricting java*,  on gentoo-proper,
>>>> but that sort of thing is killing gentoo and just appears to the open
>>>> world as a filter mechanism to keep out and go elsewhere, snoot.
>>>> There are just too many exciting and useful codes out there running
>>>> java.
>> "All" ? Some. And the dominance and focus on Java is itself telling of
>> the quality and type of the education provider.
>>
>> Some education providers may not touch Java at all, and focus
>> predominantly on C.
>>
>> You can't satisfy everyone out of the box.
>>
>
>
> I have no idea where James gets his information from, but I suspect it's
> a niche market where uni students do "clustering" - whatever that is.

I spend a lot of time "hooping" with college kids in a variety of 
venues. College kids and adults, from around the world visit the hoop 
venues in Central Florida. Lots of kids who are not CS majors are 
involved in coding, and java reigns supreme, imho, as the most often 
cited programming language they use, because professors and employers 
alike dictate that on them.

Also Just look at the job boards and the new projects springing up on 
github. Sure python is very popular. But, I cannot think of a single 
distro that offer java and precludes python, so why not have both.

Yes java is popular in rich environments where jobs in the cloud or on 
an internal cluster contain java codes. Most kids only use the cloud and 
are not 'full stack' aware or part of the foundation of the resources 
they code for.


> The interesting apps out there are mostly running python, go and
> (sometimes) lua. And that's what I observe in my day job -
> business/mobile ISP.


Look at the job listing on stackoverflow and elsewhere (java) is very 
popular when they list several programming languages to meet the 
requirements. I'm not promoting java, at all, but just stating that it 
is very popular, on new projects (but not all) and it is a large and 
frequent requirement, dictating by employers. Kids coming out of college 
want a job, more than anything, and most are having java crammed down 
their throats. So we should  find a way to robustly
support those that need java. Nothing is precluding other languages
in my message. Personally I avoid java, unless it is critical to
a code or family of codes I need to run.


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Alan McKinnon]

On 07/08/2016 19:36, james wrote:
>> The interesting apps out there are mostly running python, go and
>> (sometimes) lua. And that's what I observe in my day job -
>> business/mobile ISP.
> 
> 
> Look at the job listing on stackoverflow and elsewhere (java) is very
> popular when they list several programming languages to meet the
> requirements. I'm not promoting java, at all, but just stating that it
> is very popular, on new projects (but not all) and it is a large and
> frequent requirement, dictating by employers. Kids coming out of college
> want a job, more than anything, and most are having java crammed down
> their throats. So we should  find a way to robustly
> support those that need java. Nothing is precluding other languages
> in my message. Personally I avoid java, unless it is critical to
> a code or family of codes I need to run.


I recommend Java as a teaching language at university level.

You get all the benefits of a C-like syntax without the overhead of
learning to deal with C and/or C++. You don't have to deal with the
toolchain (much), you can easily show correct implementations of OOP
style without getting into generics (or, you can avoid Java generics
altogether at this level and pretend they don't exist).

In short, what's not to like for teaching? All win not much lose.

Well OK some kids come away thinking Java is the one and only, but they
will have that too if Python is the teaching language. Realizing there
are other things out there is part of the learning process.

But, despite all that, Java is not special. It should run on Gentoo for
anyone who wants it, just like things starting with P.

You volunteering to do the grunt work?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: Packages up for grabs

[Patrick Lauer]

On 08/07/2016 10:04 PM, Alan McKinnon wrote:
> On 07/08/2016 19:36, james wrote:
>>> The interesting apps out there are mostly running python, go and
>>> (sometimes) lua. And that's what I observe in my day job -
>>> business/mobile ISP.
>>
>>
>> Look at the job listing on stackoverflow and elsewhere (java) is very
>> popular when they list several programming languages to meet the
>> requirements. I'm not promoting java, at all, but just stating that it
>> is very popular, on new projects (but not all) and it is a large and
>> frequent requirement, dictating by employers. Kids coming out of college
>> want a job, more than anything, and most are having java crammed down
>> their throats. So we should  find a way to robustly
>> support those that need java. Nothing is precluding other languages
>> in my message. Personally I avoid java, unless it is critical to
>> a code or family of codes I need to run.
> 
> 
> I recommend Java as a teaching language at university level.

I've seen the fallout from trying to do that.

It's a horribly bad idea ...

> You get all the benefits of a C-like syntax without the overhead of
> learning to deal with C and/or C++. You don't have to deal with the
> toolchain (much), you can easily show correct implementations of OOP
> style without getting into generics (or, you can avoid Java generics
> altogether at this level and pretend they don't exist).

Java and OOP ? If you want to do things right, best to use something
proper like Eiffel or Oberon. And Java will be most excellent at
teaching about pointers (but there are no pointers!) to maximize the
learning curve gradient ...

On the upside your students will learn useless incantations along the
lines of "publicstaticvoidmain!" that they can't explain and copypasta :)

I've found these two a long time ago, and they still amuse me:

http://gentooexperimental.org/~patrick/keywords.java.txt
http://gentooexperimental.org/~patrick/helloworld.java.txt


> In short, what's not to like for teaching? All win not much lose.
> 
> Well OK some kids come away thinking Java is the one and only, but they
> will have that too if Python is the teaching language. Realizing there
> are other things out there is part of the learning process.
> 
> But, despite all that, Java is not special. It should run on Gentoo for
> anyone who wants it, just like things starting with P.
> 
> You volunteering to do the grunt work?
> 

Java works pretty well on Gentoo, I'm not quite sure what needs to be
fixed ... I mean, apart from our insane idea to "build from source"
which doesn't fit with the existing structures in the java ecosystem

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 03:48 PM, Patrick Lauer wrote:

> Java works pretty well on Gentoo, I'm not quite sure what needs to be
> fixed ... I mean, apart from our insane idea to "build from source"
> which doesn't fit with the existing structures in the java ecosystem

Wow!. Patrick, you are my hero. I have an old couple of (java-centric) 
bugs in bgo that maybe you could take a quick look at the attached 
ebuilds and either fix them or send me a guildline how to fix them? Both 
have ebuilds attached. But if you can fix them, it'd be trivial to also 
get the latest stable release of those cluster centric java 
nightmares.... I would not even care if they reside in an overlay 
somewhere, as gentoo tree acceptance is often a pilgrimage.

They are very popular codes, just so you know, so you are talking about
becoming gentoo-legend......   I'd even be willing to proxy them after 
they are fixed, or with a mentor that knows more about java than I. 
(that's not difficult at all).


BGO-510912 (Apache-Mesos)   and BGO-523412 (Apache-Spark)

Publicly or privately, you'd get much more than my gratitude...
(seriously).

I also use euscan frequently (just so you know).


curiously,
James

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 03:04 PM, Alan McKinnon wrote:
> On 07/08/2016 19:36, james wrote:
>>> The interesting apps out there are mostly running python, go and
>>> (sometimes) lua. And that's what I observe in my day job -
>>> business/mobile ISP.
>>
>>
>> Look at the job listing on stackoverflow and elsewhere (java) is very
>> popular when they list several programming languages to meet the
>> requirements. I'm not promoting java, at all, but just stating that it
>> is very popular, on new projects (but not all) and it is a large and
>> frequent requirement, dictating by employers. Kids coming out of college
>> want a job, more than anything, and most are having java crammed down
>> their throats. So we should  find a way to robustly
>> support those that need java. Nothing is precluding other languages
>> in my message. Personally I avoid java, unless it is critical to
>> a code or family of codes I need to run.
>
>
> I recommend Java as a teaching language at university level.
>
> You get all the benefits of a C-like syntax without the overhead of
> learning to deal with C and/or C++. You don't have to deal with the
> toolchain (much), you can easily show correct implementations of OOP
> style without getting into generics (or, you can avoid Java generics
> altogether at this level and pretend they don't exist).
>
> In short, what's not to like for teaching? All win not much lose.

I guess folks do not prototype new hardware (dev boards) and sit with an 
EE to exercise hardware and peripherals to get them burned in, working 
and basic drive code working, or yall do that is java at your U?

This sort of thing in done on a fpga too, at your U? Are you on the 
engineering side or the business side of the campus? (just curious).


>
> Well OK some kids come away thinking Java is the one and only, but they
> will have that too if Python is the teaching language. Realizing there
> are other things out there is part of the learning process.
>
> But, despite all that, Java is not special. It should run on Gentoo for
> anyone who wants it, just like things starting with P.
>
> You volunteering to do the grunt work?
>

I'm actually too stupid work on java. I need a new java-moral-compass.
Besides,  I'm knee deep into automating a way to put  minimal, hardened 
gentoo onto a variety of platforms, with a few keystrokes (guidance, 
suggestions and leadership are appreciated). Most of the pieces exist, 
but I fear I have installa-dyslexia syndrome.


After that feat is accomplished, then a  similar deployment of a gentoo 
cluster on a those just installed gentoo minimal images, via a few 
keystrokes (I am flexible on the cluster codes that comprise the 
cluster). Then (only after those 2 things are robustly accomplished) I 
do intend to return to my java travails (search out bgo, as I have a 
long love-hate relationship with java on gentoo).....


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

On Sun, 7 Aug 2016 16:49:01 -0500
james <garftd@verizon.net> wrote:

> After that feat is accomplished, then a  similar deployment of a
> gentoo cluster on a those just installed gentoo minimal images, via a
> few keystrokes (I am flexible on the cluster codes that comprise the 
> cluster). Then (only after those 2 things are robustly accomplished)
> I do intend to return to my java travails (search out bgo, as I have
> a long love-hate relationship with java on gentoo).....

I think its probably worth mentioning that there are likely problems
Gentoo faces around Java that are of a legal manner, not merely
technical.

Like for instance, the fact you can't install the official Orcale/Sun
JDK/JRE automatically is due to the fact:

- They prohibit replication/mirroring
- Their website requires a license agreement acceptance to download

And the latter of these is /plausible/ to automate via curl and some
"Set cookies" magic ( apparently arch do this ), but falls into a legal
grey area.


If this is a problem we have simply downloading and installing, I'd
imagine there are other problems we face having it on ready-to-go media.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 10:22 PM, Kent Fredric wrote:
> On Sun, 7 Aug 2016 16:49:01 -0500
> james <garftd@verizon.net> wrote:
>
>> After that feat is accomplished, then a  similar deployment of a
>> gentoo cluster on a those just installed gentoo minimal images, via a
>> few keystrokes (I am flexible on the cluster codes that comprise the
>> cluster). Then (only after those 2 things are robustly accomplished)
>> I do intend to return to my java travails (search out bgo, as I have
>> a long love-hate relationship with java on gentoo).....
>
> I think its probably worth mentioning that there are likely problems
> Gentoo faces around Java that are of a legal manner, not merely
> technical.
>
> Like for instance, the fact you can't install the official Orcale/Sun
> JDK/JRE automatically is due to the fact:
>
> - They prohibit replication/mirroring
> - Their website requires a license agreement acceptance to download
>
> And the latter of these is /plausible/ to automate via curl and some
> "Set cookies" magic ( apparently arch do this ), but falls into a legal
> grey area.
>
>
> If this is a problem we have simply downloading and installing, I'd
> imagine there are other problems we face having it on ready-to-go media.
>

So the minimal default automated installs would not carry java code; OK.
Yep, traversing the install semantics, so it is paused for a licensed 
download, as necessary, is not a show stopper. I'm pretty sure I  used
maven, sbt, icedtea and  curl for these cluster ebuilds in question; 
Apache-Mesos and Apache-Spark. There are hacked ebuilds in BGO. I'm 
pretty sure Mesos was reorganized so all the third party stuff  are 
modular  in such a fashion that the issues you point out have legal 
install solution. In fact Mesos is purported to almost all C++ code
now and the other languages issue are not part ot the core of Mesos,
or something to that effect I read somewhere.


I'm no java expert, so surely a dev with that sort of expertise could 
take a look, and fix them or give me guidance. Mesos installs. My 
Apache-spark ebuild needed some manual fiddling with sbt, during the 
install to get it to install to Spark, so it is a bit broken. 
Apache-Spark is a bit more complex, but it has progressed to version 
2.0, since I hack an ebuild for 1.5. Tons of folks ((big opensource 
projects) use them, so surely there is a way to solve these issues, for 
devs with that sort of knowledge and meet gentoo standards?

BGO-510912 (Apache-Mesos)   and BGO-523412 (Apache-Spark)


Thanks,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Mon, 8 Aug 2016 00:26:01 -0500
james <garftd@verizon.net> wrote:

>  so it is paused for a licensed 
> download, as necessary, is not a show stopper

The problem is that download requires a Browser with JavaScript
support, because it requires JavaScript to set a cookie, and that
cookie activates the download working.

Which means if your installer is for instance, Curses based, you're
pretty much out-of-luck.

"Please open browser at this point, but we don't have a working desktop
environment yet to do this" is a bit of a hard problem.

"You need 2 computers to install this" is also a bit of a problem.

So installing Java would have to be done /after/ the install.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Mon, 8 Aug 2016 16:33:15 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> >  so it is paused for a licensed 
> > download, as necessary, is not a show stopper  
> 
> The problem is that download requires a Browser with JavaScript
> support, because it requires JavaScript to set a cookie, and that
> cookie activates the download working.
> 
> Which means if your installer is for instance, Curses based, you're
> pretty much out-of-luck.
> 
> "Please open browser at this point, but we don't have a working
> desktop environment yet to do this" is a bit of a hard problem.
> 
> "You need 2 computers to install this" is also a bit of a problem.
> 
> So installing Java would have to be done /after/ the install.

Scratch this.

Just use iced-tea JDK by default. People who want oracle can do the
extra work.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 08:32 AM, Kent Fredric wrote:
> On Sun, 7 Aug 2016 08:24:51 -0500
> james <garftd@verizon.net> wrote:
>
>>
>> As a team, we could have a simple default program for a simple default
>> disk format, and a variety of 'stage-4' images, maybe updated every 3
>> months, to get a gentoo system up, quickly. Not an anything you want
>> it to be, but a few, common choices. Perhaps a security apparatus,
>> commonly needed, built on the hardened project? (like a bridge or a
>> firewall)?
>
> I for one miss the days where Stage-1 was the defacto install, and
> Stage-3 was "For lazy people who just wanted to use something".
>
> When we transitioned to making Stage 3 the default, it was like, heresy.
>
> Stage 4? :)
>
> I highly encourage people to randomly hurt themselves by attempting an
> unsupported Stage 1 install, just to find what breaks.
>
>> Let them use java* codes, as that is what all the universities are
>> teaching and promoting. I agree
>> with gentoo proper on severely restricting java*,  on gentoo-proper,
>> but that sort of thing is killing gentoo and just appears to the open
>> world as a filter mechanism to keep out and go elsewhere, snoot.
>> There are just too many exciting and useful codes out there running
>> java.
>
> "All" ? Some. And the dominance and focus on Java is itself telling of
> the quality and type of the education provider.
>
> Some education providers may not touch Java at all, and focus
> predominantly on C.

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


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

No one but you is talking about any limitations.


hth,
James


>
>

Re: [gentoo-dev] Re: Packages up for grabs

[Ciaran McCreesh]

On Sun, 7 Aug 2016 12:24:37 -0500
james <garftd@verizon.net> wrote:
> >> Let them use java* codes, as that is what all the universities are
> >> teaching and promoting. I agree
> >> with gentoo proper on severely restricting java*,  on
> >> gentoo-proper, but that sort of thing is killing gentoo and just
> >> appears to the open world as a filter mechanism to keep out and go
> >> elsewhere, snoot. There are just too many exciting and useful
> >> codes out there running java.  
> >
> > "All" ? Some. And the dominance and focus on Java is itself telling
> > of the quality and type of the education provider.
> >
> > Some education providers may not touch Java at all, and focus
> > predominantly on C.  
> 
> 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).

You all appear to be missing the point of education. If you are learning
technologies, your skills will be obsolete in five years. If you are
learning general principles and problem solving, the particular
language being used is much less important.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 11:21 AM, Ciaran McCreesh wrote:
> On Sun, 7 Aug 2016 12:24:37 -0500
> james <garftd@verizon.net> wrote:
>>>> Let them use java* codes, as that is what all the universities are
>>>> teaching and promoting. I agree
>>>> with gentoo proper on severely restricting java*,  on
>>>> gentoo-proper, but that sort of thing is killing gentoo and just
>>>> appears to the open world as a filter mechanism to keep out and go
>>>> elsewhere, snoot. There are just too many exciting and useful
>>>> codes out there running java.
>>>
>>> "All" ? Some. And the dominance and focus on Java is itself telling
>>> of the quality and type of the education provider.
>>>
>>> Some education providers may not touch Java at all, and focus
>>> predominantly on C.
>>
>> 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).
>
> You all appear to be missing the point of education. If you are learning
> technologies, your skills will be obsolete in five years. If you are
> learning general principles and problem solving, the particular
> language being used is much less important.
>

I agree, but if you do not know of C and or Assembler, how can you 
comprehend what goes on in firmware or with an embedded system?
The bootstapped state machine, teach grasshoppers to appreciate an RTOS. 
Likewise, the linux kernel become a great thing of beauty, when one has 
spend some time with an Rtos.

If you don not know of those things, how can these kids comprehend that 
illicit codes are in hardware, or the lower layers of the stack and thus 
fuzzing the code they wrote is pointless. I guess you could write 
firmware in Go,  but that would be quite a stretch to the EE that work 
with the CE that builds the basis of a product or a system. They lack 
fundamental understanding  of the fundamentals because these kids are 
being moved further and further away from how hardware and low level 
codes actually work. They are clueless, imho, and that is a fundamental 
fault-line in their education, imho.

I do not know of a single hacker on the gentoo embedded channel that 
struggles to run a basic gentoo server, but the opposite is quite a 
common occurrence,  sysadms that know little of low level issues, imho. 
That's my point; and gentoo is possible part of the solution to change 
this, imho.


hth,
James

Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 13248 bytes --]

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


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

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.

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

[james]

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

Re: Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

[Jason Zaman]

On Sun, Aug 07, 2016 at 02:57:14PM -0500, james wrote:

You should take a look at Blueness' Gentoo Reference stuff
https://wiki.gentoo.org/wiki/Project:RelEng_GRS
https://blogs.gentoo.org/blueness/2015/07/31/the-gentoo-reference-system-suite-a-new-release-engineering-tool/

Re: [gentoo-dev] Re: Packages up for grabs

[Consus]

On 08:24 Sun 07 Aug, james wrote:
> On 08/07/2016 02:38 AM, Consus wrote:
> > On 08:48 Sun 07 Aug, Michał Górny wrote:
> > > Sure we do. In the meantime, nobody uses gentoo anymore because it
> > > still can't deal with accepting contributions and in the meantime the
> > > few last developers retired, and users long ago switched to the
> > > comparatively recent distribution of Debian stable.
> > 
> > Finally the voice of reason.
> 
> Reasonable?  Are you kidding?
> <rolling on the floor with laughter, uncontrollably >
> 
> In this day and age, quick installs are the mantra, either for VMs or
> containers or workstations, particularly for application-specific-servers or
> a variety of security apparatus. Although the 'handbook' is an excellent
> reference guide and noob-filter, the simple fact of the matter is most (nix)
> professionals consider the gentoo install system to be arcane and an
> incredible 'cost barrier to entry'. THAT, the lack of a well thought out,
> smooth, quick/easy install which is intentionally not  available, because it
> is seen as a satanic idea, is the 800 pound gorilla on why folks
> passionately avoid gentoo.....

Err... On that one I agree. How the hell does it change the fact that
GitHub improved contributions?

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 09:09 AM, Consus wrote:
> On 08:24 Sun 07 Aug, james wrote:
>> On 08/07/2016 02:38 AM, Consus wrote:
>>> On 08:48 Sun 07 Aug, Michał Górny wrote:
>>>> Sure we do. In the meantime, nobody uses gentoo anymore because it
>>>> still can't deal with accepting contributions and in the meantime the
>>>> few last developers retired, and users long ago switched to the
>>>> comparatively recent distribution of Debian stable.
>>>
>>> Finally the voice of reason.
>>
>> Reasonable?  Are you kidding?
>> <rolling on the floor with laughter, uncontrollably >
>>
>> In this day and age, quick installs are the mantra, either for VMs or
>> containers or workstations, particularly for application-specific-servers or
>> a variety of security apparatus. Although the 'handbook' is an excellent
>> reference guide and noob-filter, the simple fact of the matter is most (nix)
>> professionals consider the gentoo install system to be arcane and an
>> incredible 'cost barrier to entry'. THAT, the lack of a well thought out,
>> smooth, quick/easy install which is intentionally not  available, because it
>> is seen as a satanic idea, is the 800 pound gorilla on why folks
>> passionately avoid gentoo.....
>
> Err... On that one I agree. How the hell does it change the fact that
> GitHub improved contributions?

Ok, so I should have prune the post to focus my response::

"In the meantime, nobody uses gentoo anymore because"

My response is not about github, the past or the future of the Version 
Control, Contributions or such, espoused by github.

My responses are to why such a mature and wonderful distro, Gentoo 
specifically, is suffering::"nobody uses gentoo anymore". And in fact I 
mildly questioned if that is the case. I think we all agree that there 
is some mistery as to why gentoo is not grower more attractive, to folks 
not using gentoo, at a faster rate with greater uptake on a permanent 
commitment to gentoo (if I may politely be so bold?).

Git hub is fine. Sure, I'd like to see the tree run on something 
opensource, but, github is fine, for now. ymmv. The future, who knows.


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sun, Aug 7, 2016 at 9:24 AM, james <garftd@verizon.net> wrote:
>
> As a team, we could have a simple default program for a simple default
> disk format, and a variety of 'stage-4' images, maybe updated every 3
> months, to get a gentoo system up, quickly. Not an anything you want it to
> be, but a few, common choices. Perhaps a security apparatus, commonly
> needed, built on the hardened project? (like a bridge or a firewall)?
>

Sounds great.  What's stopping you?

>
> Heaven forbid that we put up a few dozen (unsupported) jentoo VMs,
> container-images or stage-4 (specifically purposed) choices where
> folks could only get support from jentoo-user. No sir, we cannot make jentoo
> fun and enjoyable and quick (and sleazy) can we?
>

Sounds great.  What's stopping you?

>
> And yes allow java, the way it is available on most other distros...
> The current process of requiring all the java codes to be broken down into
> 100% discernable codes is a tremendous barrier. After all, most of the codes
> that use that stuff, are full of holes anyway; that's the very nature of
> open, fast, exciting new codes. They only become secure
> after years of vetting (fuzzing) anyway. So make the host gentoo image very
> secure and allow jentoo projects to be a VM, or container or such
> construct, without all the hassles of gentoo proper. Let the purist ensure
> that gentoo is secure and isolated and let the multitude play with java,
> however they like (in a VM, or a container image or a stage-4).
>

Sounds great.  What's stopping you?

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 09:47 AM, Rich Freeman wrote:
> On Sun, Aug 7, 2016 at 9:24 AM, james <garftd@verizon.net> wrote:
>>
>> As a team, we could have a simple default program for a simple default
>> disk format, and a variety of 'stage-4' images, maybe updated every 3
>> months, to get a gentoo system up, quickly. Not an anything you want it to
>> be, but a few, common choices. Perhaps a security apparatus, commonly
>> needed, built on the hardened project? (like a bridge or a firewall)?
>>
>
> Sounds great.  What's stopping you?
>
>>
>> Heaven forbid that we put up a few dozen (unsupported) jentoo VMs,
>> container-images or stage-4 (specifically purposed) choices where
>> folks could only get support from jentoo-user. No sir, we cannot make jentoo
>> fun and enjoyable and quick (and sleazy) can we?
>>
>
> Sounds great.  What's stopping you?
>
>>
>> And yes allow java, the way it is available on most other distros...
>> The current process of requiring all the java codes to be broken down into
>> 100% discernable codes is a tremendous barrier. After all, most of the codes
>> that use that stuff, are full of holes anyway; that's the very nature of
>> open, fast, exciting new codes. They only become secure
>> after years of vetting (fuzzing) anyway. So make the host gentoo image very
>> secure and allow jentoo projects to be a VM, or container or such
>> construct, without all the hassles of gentoo proper. Let the purist ensure
>> that gentoo is secure and isolated and let the multitude play with java,
>> however they like (in a VM, or a container image or a stage-4).
>>
>
> Sounds great.  What's stopping you?
>

Why Rich, thanks for the triple compliments; is that a vote that the 
basic idea(s) have merit, or sarcasm?

We are all part of a village, so feedback is warmly received, regardless
of the nature of the  prose....

As you probably know, I have been working on many of these issues, for a 
variety of reason.


James

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sun, Aug 7, 2016 at 1:47 PM, james <garftd@verizon.net> wrote:
> On 08/07/2016 09:47 AM, Rich Freeman wrote:
>>
>> Sounds great.  What's stopping you?
>>
>
> Why Rich, thanks for the triple compliments; is that a vote that the basic
> idea(s) have merit, or sarcasm?
>

I'm just expressing that the typical blocker is somebody willing to
contribute.  I don't think anybody opposes Java support on Gentoo, or
having a canned installation.  It takes way longer than it should to
get a container running/etc.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 12:49 PM, Rich Freeman wrote:
> On Sun, Aug 7, 2016 at 1:47 PM, james <garftd@verizon.net> wrote:
>> On 08/07/2016 09:47 AM, Rich Freeman wrote:
>>>
>>> Sounds great.  What's stopping you?
>>>
>>
>> Why Rich, thanks for the triple compliments; is that a vote that the basic
>> idea(s) have merit, or sarcasm?
>>
>
> I'm just expressing that the typical blocker is somebody willing to
> contribute.  I don't think anybody opposes Java support on Gentoo, or
> having a canned installation.  It takes way longer than it should to
> get a container running/etc.
>


I agree with all you have stated, in this entire thread. I have/am 
working on many pieces of this this thread and many more all ready exist
as components, like stage-4 iso for gentoo. They are already in many 
mirrors. Yes they are very specific, but lack some install guidelines in 
the handbook; just exactly how to do a stage 4 install. Instructions do 
exist that are piecemeal or legacy, but not in the handbook, nor the 
wiki for stage-4 installs. One even struggle what docs to believe on how 
to construct a stage-4 file for install. If wisdom from gentoo-devs is 
these stage-4 issues are to be well hidden, at least there should 
likewise be accurate docs with those stage-4 iso, imho.


I agree about secure VM and containers. I still struggle with that too; 
hence the posting here. Today is my response to what ails gentoo; github
is such a minor, miniscule issue on that large question, imho.


My thesis:: github is not the blocker for faster and wider uptake of 
gentoo.  An easy install is the largest issue, followed by a way to 
robustly support/offer java, are about 95% of the blocker issues to 
gentoo update, imho. So I have suggested a variety of mechanism, for 
discussion on gentoo update (which would lead to more gentoo devs and 
contributions) even to the point of in a VM centric, or sister distro, 
as potentially plausible mechanisms to attract new users (and devs) to 
gentoo.


hth,
Jaems

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]

On Sat, 6 Aug 2016 19:28:19 +0000
Peter Stuge <peter@stuge.se> wrote:

> Michał Górny wrote:
> > Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> > That's the most convenient solution for most of proxy-maint team
> > members.  
> 
> How can I help improve that problematic situation?
> 
> It's not cool to gravitate the project towards GitHub Inc.

I kinda think this missed the point.  ( Though I did entirely expect a
complaint when he suggested it )

One avenue for contribution without Github: Patches by bugzilla, was
stated.

That will work, and is not restricting anyones freedom. It may however,
restrict convenience. But not freedom.

As far as I'm concerned, the statement about Github was a "oh, yeah,
and if you want, Github works too, so if you find that more convenient,
so do we, go right ahead, but you ain't gotta".

Everyone is free to, and encouraged to, create better solutions.

But there's no force to use Github.

If Github dies tomorrow, Gentoo will not drop dead. The convenience
will be lost, but people will still be completely able to send queues
of patches via bugzilla, or email, in the event that web browsers all
spontaneously die and cease to be free by some dark voodoo magic.

`git format-patch` is after all optimised for that latter case somewhat.

Maybe we should look into an Email Based submission service, create a
gentoo mailing list exclusively for 3rd party (proxy-maint) mail patch
queues, optimised for receiving and vetting patch sequences.

You don't need some fancy Java wank for that.

Then all we'd need is some alternative implementation of
dev-perl/Gentoo-App-Pram that can read a local mbox, and select
emails/email threads containing patch series, apply them, push them,
and then auto-reply to the email with a confirmation.

And then people could continue to use Github for their
easy-fast-non-free-workflow, and they could use some email submission
thing for the slightly-less-easy-but-free-as-hell workflow.

And for extra fun, we could support non-patch-queue emails that
contained references to public arbitrary git repositories and
automatically configured itself to pick a patch series from it, like
this example [1]: 

1: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU

I mean, What do the Linux Kernel use? It would be a shame if they were
happening to use the email based workflow like I suggested([2,3,4]), and
if only there was a Gentoo Staffer who knew how Linux Contributions
worked and had documented it (sarcasm: [5])

2: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU
3: https://news.ycombinator.com/item?id=3960876
4: https://github.com/torvalds/linux/pull/17#issuecomment-5663780
5:
https://github.com/gregkh/kernel-tutorial/blob/master/walkthrough#L47-L52




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]