Mailing List Archive

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

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

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

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

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)

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.

On Sun, Aug 7, 2016 at 9:56 AM, Deven Lahoti <deywos@mit.edu> wrote:
> What's the policy on maintaining a package if I'm not (yet, hopefully) an
> official dev? I'd like to take on transmission-remote-gtk since I use it
> fairly often.

That would be great!

I think you want to start by looking at proxy maintenance:

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

Cheers,

Dirkjan

On 08/07/2016 10:12 AM, Dirkjan Ochtman wrote:
> On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>> This packages are now up for grabs:
>> app-portage/euscan
>
> Patrick,
>
> Are you still keeping euscan running?
>

Yes. It's not in the best shape, but for now it works well enough to
keep it around.

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

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

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

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?

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

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

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

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


>
>

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

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

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

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

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

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

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

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.

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.