From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F1C1413832E for ; Sun, 7 Aug 2016 12:16:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A97A121C0A9; Sun, 7 Aug 2016 12:16:41 +0000 (UTC) Received: from omr-m019e.mx.aol.com (omr-m019e.mx.aol.com [204.29.186.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C6EF621C01D for ; Sun, 7 Aug 2016 12:16:40 +0000 (UTC) Received: from mtaout-mcd01.mx.aol.com (mtaout-mcd01.mx.aol.com [172.26.223.205]) by omr-m019e.mx.aol.com (Outbound Mail Relay) with ESMTP id D39BA380008B for ; Sun, 7 Aug 2016 08:16:39 -0400 (EDT) Received: from [192.168.1.52] (0x5b3139322e3136382e312e35325d [71.122.242.106]) by mtaout-mcd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id 7A5B138000089; Sun, 7 Aug 2016 08:16:36 -0400 (EDT) Subject: Re: [gentoo-dev] Re: Packages up for grabs To: gentoo-dev@lists.gentoo.org References: <20160806211255.GI12988@foo.stuge.se> <49994385-FEB7-4951-B324-ED1BC66899D4@gentoo.org> <20160807073824.GA1030@daphne> From: james Message-ID: Date: Sun, 7 Aug 2016 08:24:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160807073824.GA1030@daphne> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit x-aol-global-disposition: G x-aol-sid: 3039ac1adfcd57a726a45a05 X-AOL-IP: 71.122.242.106 X-Archives-Salt: 0b9dc4d2-c6d3-40e7-96b3-a51e071190f2 X-Archives-Hash: dc1fe0472dc9737d3632da56f125d2c4 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? 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