Ring 2: "option(al) stacks" == x/wayland/gnome/kde/xfce, mysql/postgres/mariadb, perl5/perl6/py2/py3/ruby1/ruby2/oraJava/openJdk
Ring 3: "enduser applications" == gedit/vim, libreoffice/thunderbird/pidgin, eclipse/netbeans/subversion/emacs... the proposal suggests being able to install straight from git repo (at enduser/spin option), not just from yum repo
Where do I find the actual list of those 430-named-3915-actual packages? No hyperlinks in his talk or his email to current fedora packaging-documentation....
Also, at first glance, I'm against non-RPM packaging like RubyGems, because (as the author of the slides points out) they don't even do simple anti-malware verification. Better to have 99% of ruby gems automagically-available inside an rpm-wrapper... with fedoraProject digisig and fedora quality-standards applied to all 'approved' gems... than to "extend the trust boundary" wholesale to 100% of rubygems.org website contents, as the proposal suggests. Haven't looked into this problem deeply though, so take this paragraph with a grain of salt. (Have also never heard of CoreOS, for that matter.)
Re: CoreOS as an alternative
http://mattdm.org/fedora/next/#20
http://mattdm.org/fedora/next
https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html
Ring 0: "just enough OS" == not self-hosting aka minimal-cloud-slash-vGuest-fedora
Ring 1: "fedora neo-core" == @standard + @core, 330-or-430 'named'-SRPMs-or-pkgs (1800-or-3915 actual)
Ring 2: "option(al) stacks" == x/wayland/gnome/kde/xfce, mysql/postgres/mariadb, perl5/perl6/py2/py3/ruby1/ruby2/oraJava/openJdk
Ring 3: "enduser applications" == gedit/vim, libreoffice/thunderbird/pidgin, eclipse/netbeans/subversion/emacs... the proposal suggests being able to install straight from git repo (at enduser/spin option), not just from yum repo
Where do I find the actual list of those 430-named-3915-actual packages? No hyperlinks in his talk or his email to current fedora packaging-documentation....
Also, at first glance, I'm against non-RPM packaging like RubyGems, because (as the author of the slides points out) they don't even do simple anti-malware verification. Better to have 99% of ruby gems automagically-available inside an rpm-wrapper... with fedoraProject digisig and fedora quality-standards applied to all 'approved' gems... than to "extend the trust boundary" wholesale to 100% of rubygems.org website contents, as the proposal suggests. Haven't looked into this problem deeply though, so take this paragraph with a grain of salt. (Have also never heard of CoreOS, for that matter.)