the future of funtoo - the funtooture
Daniel Robbins
As the title states, I've been thinking about the future of Funtoo and
wanted to post some of my ideas here, so you can offer feedback. These
ideas are pretty complex so take some time to reflect on them.
What does the future of Funtoo hold? Basically, more of a fork,
supporting MacOS X and other platforms if we want, while maintaining
Gentoo compatibility in all areas possible.
Well, first, let me share some of my ideas for the future of Funtoo/
Gentoo:
1) I'd like to have Funtoo under MacOS X. Not in a prefix
configuration. Basically, it would be in a hybrid mode where some
packages like gcc, perl, python would be provided by Apple and would
be "immutable" (you can't upgrade them) while others can be emerged
like normal.
2) I want to have a simpler Linux core system. Everything in a stage3
these days is quite complex. So I would like to rewrite ~250 ebuilds
of the core system. I would like to make all "wrappers" optional.
Nearly all of the Gentoo-centric features would be in optional packages.
3) I want to start using the 3-clause BSD license for future Funtoo
work. This would keep things more consistent with OpenRC, openresolv,
and dhcpcd and give us more opportunities in the BSD direction.
I am also considering using a dual license of the 3-clause BSD license
and the Ms-PL (Microsoft public license - OSI approved) which is very
similar to BSD but provides additional patent protections, a good
thing. When I was at Microsoft, I worked with some people authoring
the license and it is a very good license (despite the stigma of its
name and origin.) The dual-license with BSD would allow full freedoms
of a BSD license and GPL compatibility, plus the patent protection of
the more modern Ms-PL.
http://www.opensource.org/licenses/ms-pl.html
If I go this route, the Microsoft Ms-PL license will be forked so I
can rename it to the "Funtoo-PL". So if I do this, then we are forking
Microsoft stuff too, so hopefully sticking it to them will compensate
for the stigma of using something that came from Microsoft. It is a
good license so without the Microsoft name in its title it will be
more useful to people.
4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
Move to a traditional release model. The Linux core system would be
more stable and things would change it in a lot less often. New stuff
would go in new point releases. Anything requiring perl-cleaner or
other crappy cleaner runs would be saved for an official major release
and require an explicit upgrade with upgrade instructions or an
official upgrade script. You can keep using your old system without
getting "pulled into the cleaner" and getting screwed :)
5) Move away from Portage for the core system, to a very minimal light-
weight build system. The idea here is to allow more of an LFS-inspired
core system -- very simple, and get rid of all the Gentoo-specific
cruft that has been created, such has the horde of eclasses, etc.
Maintain full Portage compatibility (Portage would be able to discover
the versions of packages installed in the core system.) I see this re-
engineering as necessary to really get the core system simplified and
more LFS-like (more like how Gentoo was in the beginning.) Core system
packages would be immutable (non-upgradeable) until you decided to
upgrade the core system, and this may require "cleaner" runs.
What does all this accomplish?
1) true MacOS X support
2) Funtoo becoming a true BSD-style distribution:
a) real releases
b) stability - escape from the "-cleaner" hell
c) properly managed and maintained core system
3) Licensing
a) BSD-compatible
b) possible additional patent protections
c) fork Microsoft PL - rename to Funtoo-PL
d) existing Portage tree, Metro, and Gentoo tools would still be
under GPLv2
4) Lightweight Build System
a) /usr/src and /usr/ports split
b) simple, better suited for educational purposes (ie. LFS)
c) Portage compatible (portage can "see" our packages)
d) Gentoo-centric things (wrappers) are *optional*. Our system works
with or without them.
What is the net overall impact? Well, we move in a more *BSD direction
in terms of the distribution. We have real, mature, maintainable
releases. We make Gentoo-isms (gcc-config, eselect, etc.) optional
extensions rather than the default, making the system clean and simple
if desired, like the old days. For licensing, we get a more permissive
and simpler license (BSD) and possibly fork Microsoft's public
license. This is a much more liberal licensing model than GPLv2, and
compatible with *BSD. MacOS X support moves Funtoo beyond just a
distribution - it is also an environment, that can exist on other
operating systems. Gentoo compatibility is still maintained when the
Funtoo Linux core system is used with the Funtoo Portage tree.
Obviously, this is a lot of change, but let me know what you think. I
am pretty comfortable with this direction as I think it really solves
hundreds of issues with Gentoo and opens up a lot more potential for
the future.
-Daniel
Matthew McCormick
> work. This would keep things more consistent with OpenRC, openresolv,
> and dhcpcd and give us more opportunities in the BSD direction.
>
> I am also considering using a dual license of the 3-clause BSD license
> and the Ms-PL (Microsoft public license - OSI approved) which is very
> similar to BSD but provides additional patent protections, a good
> thing. When I was at Microsoft, I worked with some people authoring
> the license and it is a very good license (despite the stigma of its
> name and origin.) The dual-license with BSD would allow full freedoms
> of a BSD license and GPL compatibility, plus the patent protection of
> the more modern Ms-PL.
>
> http://www.opensource.org/licenses/ms-pl.html
>
I went to this talk
http://www.archive.org/details/Bioslevel-OLF2009LegalitiesOfFOSSTomCallawaymovh264480p302-2
And this pushes one more towards MIT than BSD.
Also, patent protections are mentioned there as existing in an Apache
license, which does not have the stigma of MS.
> 4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
> Move to a traditional release model. The Linux core system would be
> more stable and things would change it in a lot less often. New stuff
> would go in new point releases. Anything requiring perl-cleaner or
> other crappy cleaner runs would be saved for an official major release
> and require an explicit upgrade with upgrade instructions or an
> official upgrade script. You can keep using your old system without
> getting "pulled into the cleaner" and getting screwed :)
This may be a good goal (or may not, I don't know), but some smaller
baby steps should be made before trying to make that leap. That is,
have a consistent 'stable' and 'unstable' tree. This means stable is
not so crusty that users are forced to keyword some packages as
unstable. You should not have to unmask packages that are masked in
order to upgrade your system. This is what caused the perl mess.
> 5) Move away from Portage for the core system, to a very minimal light-
> weight build system. The idea here is to allow more of an LFS-inspired
> core system -- very simple, and get rid of all the Gentoo-specific
> cruft that has been created, such has the horde of eclasses, etc.
> Maintain full Portage compatibility (Portage would be able to discover
> the versions of packages installed in the core system.) I see this re-
> engineering as necessary to really get the core system simplified and
> more LFS-like (more like how Gentoo was in the beginning.) Core system
> packages would be immutable (non-upgradeable) until you decided to
> upgrade the core system, and this may require "cleaner" runs.
....
> operating systems. Gentoo compatibility is still maintained when the
> Funtoo Linux core system is used with the Funtoo Portage tree.
>
I think the above statement is key to making things
maintainable/workable if following that route.
Daniel Robbins
> I went to this talk
> http://www.archive.org/details/Bioslevel-OLF2009LegalitiesOfFOSSTomCallawaymovh264480p302-2
> And this pushes one more towards MIT than BSD.
>
> Also, patent protections are mentioned there as existing in an Apache
> license, which does not have the stigma of MS.
Of all the ideas, the licensing one is the one that I am least sure
of. I need to seriously consider the pragmatic and ideological impact
of moving away from a copyleft license. My initial impression is that
Linux distributions are a commodity these days and a non-copyleft
license for Linux distro internals is not a threat to the freeness of
the distribution.
I can't imagine a proprietary linux based on Funtoo having any
success, since there is strong, strong community opposition to a
proprietary Linux! So I think moving away from copyleft may present
more opportunities without any significant negative. But I will
continue to research it.
-Daniel
Matthew McCormick
>
> On Oct 12, 2009, at 12:19 PM, Matthew McCormick wrote:
>
>> I went to this talk
>> http://www.archive.org/details/Bioslevel-OLF2009LegalitiesOfFOSSTomCallawaymovh264480p302-2
>> And this pushes one more towards MIT than BSD.
>>
>> Also, patent protections are mentioned there as existing in an Apache
>> license, which does not have the stigma of MS.
>
> Of all the ideas, the licensing one is the one that I am least sure
> of. I need to seriously consider the pragmatic and ideological impact
> of moving away from a copyleft license. My initial impression is that
> Linux distributions are a commodity these days and a non-copyleft
> license for Linux distro internals is not a threat to the freeness of
> the distribution.
I agree that moving away from copyleft is the way to go.
>
> I can't imagine a proprietary linux based on Funtoo having any
> success, since there is strong, strong community opposition to a
> proprietary Linux!
Well, there are a lot of proprietary Linuxes in the embedded world.
Because of the from-source nature and customizability of
gentoo/funtoo, it has a lot of potential for embedded adoption.
However, the support for cross-compiling and building a nice rootfs is
hard to do with the current set of tools/tree.
Pablo E. González
I would like to be as forthcoming as possible. I like changes, and I really
like the adventure, that's why I'm here, using GNU/Linux, then gentoo, then
funtoo.
I really liked the idea of leading the gentoo deevevelopment to a BSD-style,
and i'd like to test it (since I feel very curious to this), but I can't
imagine you going away from copyleft. I'm not communist (and I feel like
expressing that I've got some kind of prejudice about Microsoft-anything) but
I still want to understand the reason of what are you looking for going away
from copyleft. I think that the phylosophical core of what GNU/Linux means is
opposed to what you have in mind (in terms of licensing, of course). Again, i
want to understand, nothing else. In the other hand, GPLv3 doesn't fit your
needs? (I think I could answer myself after reading your explanation).
Best regards,
Paul.
-
El Monday 12 October 2009 a las 13:40:41 Daniel Robbins
<drob...@funtoo.org>,escribió:
Daniel Cordero
> 4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
> Move to a traditional release model. The Linux core system would be
> more stable and things would change it in a lot less often. New stuff
> would go in new point releases. Anything requiring perl-cleaner or
> other crappy cleaner runs would be saved for an official major release
> and require an explicit upgrade with upgrade instructions or an
> official upgrade script. You can keep using your old system without
> getting "pulled into the cleaner" and getting screwed :)
>
I am not familiar with BSD, so I can't imagine what would go into
either directory.
My personal preference is to choose software which won't destroy itself
and everything with it when it upgrades, but that is impossible for
some people, tasks and programs.
> 2) I want to have a simpler Linux core system. Everything in a stage3
> these days is quite complex. So I would like to rewrite ~250 ebuilds
> of the core system. I would like to make all "wrappers" optional.
> Nearly all of the Gentoo-centric features would be in optional packages.
>
> 5) Move away from Portage for the core system, to a very minimal light-
> weight build system. The idea here is to allow more of an LFS-inspired
> core system -- very simple, and get rid of all the Gentoo-specific
> cruft that has been created, such has the horde of eclasses, etc.
> Maintain full Portage compatibility (Portage would be able to discover
> the versions of packages installed in the core system.) I see this re-
> engineering as necessary to really get the core system simplified and
> more LFS-like (more like how Gentoo was in the beginning.) Core system
> packages would be immutable (non-upgradeable) until you decided to
> upgrade the core system, and this may require "cleaner" runs.
>
> 2) Funtoo becoming a true BSD-style distribution:
> a) real releases
> b) stability - escape from the "-cleaner" hell
> c) properly managed and maintained core system
> 4) Lightweight Build System
> a) /usr/src and /usr/ports split
> b) simple, better suited for educational purposes (ie. LFS)
> c) Portage compatible (portage can "see" our packages)
> d) Gentoo-centric things (wrappers) are *optional*. Our system works
> with or without them.
>
I am all for a smaller core system, by which I mean kernel/boot/init.
Having these do simple jobs should allow them to be updated rarely and
relatively painless.
There are a lot of hoops to jump through to get Linux booted.
For bigger programs (out of our control) that have many versions, they
should be installed apart, rather than on top of each other e.g.
/perl/5.10.1/bin and /perl/5.8.6/bin.
It may seem like your PATH will get a lot more confusing, but I'm hoping
an upcoming addition to the kernel too make this so much easier.
> Obviously, this is a lot of change, but let me know what you think. I
> am pretty comfortable with this direction as I think it really solves
> hundreds of issues with Gentoo and opens up a lot more potential for
> the future.
>
I just wonder about the human cost...
> -Daniel
Daniel Robbins
Hi Daniel,
I would like to be as forthcoming as possible. I like changes, and I really
like the adventure, that's why I'm here, using GNU/Linux, then gentoo, then
funtoo.
I really liked the idea of leading the gentoo deevevelopment to a BSD-style,
and i'd like to test it (since I feel very curious to this), but I can't
imagine you going away from copyleft. I'm not communist (and I feel like
expressing that I've got some kind of prejudice about Microsoft-anything) but
I still want to understand the reason of what are you looking for going away
from copyleft. I think that the phylosophical core of what GNU/Linux means is
opposed to what you have in mind (in terms of licensing, of course). Again, i
want to understand, nothing else. In the other hand, GPLv3 doesn't fit your
needs? (I think I could answer myself after reading your explanation).
Oleg
Oleg.
William Tetrault
would be many, many details to be laboriously worked out, but an
overall simplification cannot be a negative, especially considering
the way Gentoo was originally. I started with Gentoo in April of '02
when v1.1 had just been released, and have been generally dismayed
with the degree of complexity Gentoo has acquired since that time.
Andrew D Kirch
RMS's whim. This seems generally unwise. I liked the GPLv2, not a huge
fan of the v3, and I doubt the v4 will be better. Licenses, as Daniel
pointed out, should not include a sermon. With that said I'll reserve
the rest of this post to chide Daniel for bottom-posting against
convention. :)
Andrew
Martin 'golodhrim' Scholz
Hi Daniel, hi List,
I think these changes are the right steps, as complexity will always lead
to inconsistency, a more clearer and cleaner system would be nice to work
with.
According to the license question, I only can agree with you, we should
use a free license, that is simple to read and would not take tons of
pages as I haven't read the ms-pl up to know I can't say anything about
it, but I will read it tomorrow, but a patent protection part would be a
real nice solution. So we also could work out a even more simpler and
better handbook in the next steps when the changes to licenses and system
are done.
Greetings
Martin "golodhrim" Scholz
james cook
regards to the license change I am whole heartedly behind you in this.
The GPLv2 was perfectly acceptable however v3 has gone over the line
as far as being a license goes and RMS's ideas can only get stranger.
As for tracking Apple, I can see the logic but I am unsure if it would
be wise to hand them the keys in this fashion. We can discuss that
later though.
~Az
Pablo E. González
what's the matter with a long preamble :P -- just joking. Being serious,
taking as a startpoint what you say about complexity (it is a fact: lawyers
and ITs will never understand each other! but we could just make an effort...)
and the need for a new light and easy-to-understand license, the need to ask
you (and the list) a ultimate question arises:
The new licensed software (licensed under whatever-you-want-pl) will respect
the four basic freedoms?
If it's the case, I'm done and happy.
-
El Monday 12 October 2009 a las 18:51:35 Daniel Robbins
<drob...@funtoo.org>,escribió:
Daniel Robbins
>
> I have been pondering this for a while, and to be honest, I can't imagine
> what's the matter with a long preamble :P -- just joking. Being serious,
> taking as a startpoint what you say about complexity (it is a fact: lawyers
> and ITs will never understand each other! but we could just make an effort...)
> and the need for a new light and easy-to-understand license, the need to ask
> you (and the list) a ultimate question arises:
>
> The new licensed software (licensed under whatever-you-want-pl) will respect
> the four basic freedoms?
>
> If it's the case, I'm done and happy.
Yes, these licenses we're talking about are all OSI-approved "open
source" licenses and meet the FSF definition of a free software
license.
-Daniel
1 2
You know what you are doing and this below could help as well.
Might be a big effort but would think it would be better to make a big jump and start a whole new tree and possibly still have old gentoo / funtoo style in the background or parallel until it is safe enough for most to jump ship to new Funtoo.
Might even stop current Funtoo and start from new but might upset a few users not sure.
This parallel might give you more freedom to make radical changes from day 1. Maybe start of with something small / compact similar to tinycore / microcore / busybox / embedded and build from there.
I can see several modules or parts, like a house if the kitchen basin/sink has a problem you would not need to rebuild the house or the kitchen but just fix the leak more or less similar to what you mentioned original post
Example of modules:
1. Base system like tiny/microcore
2. 2nd stage booting / networking / basics
3. general text login and handover to gui desktop
4. gui and it's tantrums
5. desktop environment
6. addons / gimmicks like compiz / games etc
Obviously this is a bit whacky but you get a idea and then as it breaks or needs attention you only need to deal with that module and not a whole new distro release to fix 5 bugs. Similar to a house building process except with unlinking or something to fix that what needs to be fixed + re-assembled and continue with the normal system.
IE: boot then suspended and sandbox chroot, fix then re-assemble and continue on to normal boot or normal linux process.
New kernels can even be replaces in 0.07secs while running without rebooting for server. Should be able to do the same here = no downtime needed or similar.
Not sure how you would deal with new from scratch tree for portage or similar and would likely have to go bin packages initially and later once all is on the same page = stage3 + source.
I think you have a idea of the man hours this will take and changing all the source to new structure and testing this will involve.
LFS and SourceMage is a good start and have to borrow a lot from several distro's.
We all support you and will help where we can. You did it before this time it will even be greater.
Martin Scholz
Hi Daniel, hi List,
Jacob Todd
> 3) I want to start using the 3-clause BSD license for future Funtoo
> work. This would keep things more consistent with OpenRC, openresolv,
> and dhcpcd and give us more opportunities in the BSD direction.
--
Jake Todd
// If it isn't broke, tweak it!
Aniruddha
4) More of a move to a FreeBSD-style /usr/src and /usr/ports split. Move to a traditional release model. The Linux core system would be more stable and things would change it in a lot less often. New stuff would go in new point releases. Anything requiring perl-cleaner or other crappy cleaner runs would be saved for an official major release and require an explicit upgrade with upgrade instructions or an official upgrade script. You can keep using your old system without getting "pulled into the cleaner" and getting screwed :)
Dominik Riva
> Hey everyone,
>
> As the title states, I've been thinking about the future of Funtoo and
> wanted to post some of my ideas here, so you can offer feedback. These
> ideas are pretty complex so take some time to reflect on them.
>
> What does the future of Funtoo hold? Basically, more of a fork,
> supporting MacOS X and other platforms if we want, while maintaining
> Gentoo compatibility in all areas possible.
>
> Well, first, let me share some of my ideas for the future of Funtoo/
> Gentoo:
>
> 1) I'd like to have Funtoo under MacOS X. Not in a prefix
> configuration. Basically, it would be in a hybrid mode where some
> packages like gcc, perl, python would be provided by Apple and would
> be "immutable" (you can't upgrade them) while others can be emerged
> like normal.
As a user and past administrator of a OS X server and workstations I
have to say that I don't care for the mess that is OS X. It looks nice
but things are documented badly and halve finished (intranet server
stuff). I don't understand what you would like to archive with funtoo
being available under OS X? I understand that there are 2 systems to get
software installed from source under OS X, so why invest work to add a 3th?
> 2) I want to have a simpler Linux core system. Everything in a stage3
> these days is quite complex. So I would like to rewrite ~250 ebuilds
> of the core system. I would like to make all "wrappers" optional.
> Nearly all of the Gentoo-centric features would be in optional packages.
I like the sound of this and think funtoo will have it easy in the
future because of the reduced complexity. But why would funtoo like to
offer and thus support the old gentoo cruft in optional funtoo specific
packages that are not in gentoo it self and thus we could expect no help
at all from the gentoo developers in fixing or not braking the funtoo
specific packages? To me it sounds like a world of pain with out much
gain. I would like the stuff that is not needed in the core system
removed completely to really profit from the KISS idea.
> 3) I want to start using the 3-clause BSD license for future Funtoo
> work. This would keep things more consistent with OpenRC, openresolv,
> and dhcpcd and give us more opportunities in the BSD direction.
>
> I am also considering using a dual license of the 3-clause BSD license
> and the Ms-PL (Microsoft public license - OSI approved) which is very
> similar to BSD but provides additional patent protections, a good
> thing. When I was at Microsoft, I worked with some people authoring
> the license and it is a very good license (despite the stigma of its
> name and origin.) The dual-license with BSD would allow full freedoms
> of a BSD license and GPL compatibility, plus the patent protection of
> the more modern Ms-PL.
>
> http://www.opensource.org/licenses/ms-pl.html
>
> If I go this route, the Microsoft Ms-PL license will be forked so I
> can rename it to the "Funtoo-PL". So if I do this, then we are forking
> Microsoft stuff too, so hopefully sticking it to them will compensate
> for the stigma of using something that came from Microsoft. It is a
> good license so without the Microsoft name in its title it will be
> more useful to people.
The idea of providing the infrastructure under a most permissive and
compatible license makes sense to me. The Ms-PL looks nice to me but I
am no lawyer and to make things worst I live in apart of the world where
ideas are not fit to be patented and software patents are void. Because
of this, I would like others to provide feedback about the license with
patent protection and possible bad implications it could have in the
future for funtoo.
> 4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
> Move to a traditional release model. The Linux core system would be
> more stable and things would change it in a lot less often. New stuff
> would go in new point releases. Anything requiring perl-cleaner or
> other crappy cleaner runs would be saved for an official major release
> and require an explicit upgrade with upgrade instructions or an
> official upgrade script. You can keep using your old system without
> getting "pulled into the cleaner" and getting screwed :)
I have no understanding of the FreeBSD-style /usr/src and /usr/ports
split. Would you like to explain what it is and why you like to
implement it?
I don't like the idea of going back to a traditional release model as I
like it to be as up to date as I like. But I would like to have a way to
see before I "emerge -avuDN @world" how likely it is that I need to
spend time fixing my system after the updates. So If the traditional
release model is used to present the possible updates that result in a
broken system that needs user interaction to fix it, I like the idea as
it could be easy to understand for most of the users that a version
upgrade needs more work and attention from them then the normal update
of the installed programs. But as soon as I need to backport ebuilds
(see ubuntu backports repository) to install a new version of a user
program because I am still on version X and not on version Y (because I
will not have the time to babysit the version upgrade till next weekend)
I loose the interest in the traditional release model and would rater
like some funtoo specific way of telling me that if I update this part
of the system I maybe better plan in some time to fix possible breakages
or to do other tasks that are not automated and give me a easy way to
update the rest of the system but hold back the problematic part for
later when I have time to deal with it in a proper way. Maybe I want the
tools to define and manage my own releases?
> 5) Move away from Portage for the core system, to a very minimal light-
> weight build system. The idea here is to allow more of an LFS-inspired
> core system -- very simple, and get rid of all the Gentoo-specific
> cruft that has been created, such has the horde of eclasses, etc.
> Maintain full Portage compatibility (Portage would be able to discover
> the versions of packages installed in the core system.) I see this re-
> engineering as necessary to really get the core system simplified and
> more LFS-like (more like how Gentoo was in the beginning.) Core system
> packages would be immutable (non-upgradeable) until you decided to
> upgrade the core system, and this may require "cleaner" runs.
> What does all this accomplish?
>
> 1) true MacOS X support
Why, what would funtoo gain by this move?
> 2) Funtoo becoming a true BSD-style distribution:
> a) real releases
> b) stability - escape from the "-cleaner" hell
> c) properly managed and maintained core system
Do you want funtoo to be BSD-style or do you like to raise the quality
to the level you know from BSD?
> 3) Licensing
> a) BSD-compatible
> b) possible additional patent protections
> c) fork Microsoft PL - rename to Funtoo-PL
> d) existing Portage tree, Metro, and Gentoo tools would still be
> under GPLv2
As long as I have the freedom to tinker with my system and have no
lawyers on my heels when I share my modifications with my peers I am ok
with what ever license you like to use.
> 4) Lightweight Build System
> a) /usr/src and /usr/ports split
> b) simple, better suited for educational purposes (ie. LFS)
> c) Portage compatible (portage can "see" our packages)
> d) Gentoo-centric things (wrappers) are *optional*. Our system works
> with or without them.
> What is the net overall impact? Well, we move in a more *BSD direction
> in terms of the distribution. We have real, mature, maintainable
> releases. We make Gentoo-isms (gcc-config, eselect, etc.) optional
> extensions rather than the default, making the system clean and simple
> if desired, like the old days. For licensing, we get a more permissive
> and simpler license (BSD) and possibly fork Microsoft's public
> license. This is a much more liberal licensing model than GPLv2, and
> compatible with *BSD. MacOS X support moves Funtoo beyond just a
> distribution - it is also an environment, that can exist on other
> operating systems. Gentoo compatibility is still maintained when the
> Funtoo Linux core system is used with the Funtoo Portage tree.
I think we would loose some of the good things in gentoo.
I like the rolling release as I see what problems real, mature,
maintainable releases can produce in the ubuntu systems I support. To
much changes at the same time is the biggest problem of traditional
releases.
I don't know if it would be to much work on the developers to keep up to
date with ebuilds and support older releases at the same time. Because
as I see it the problem that a lot of users feel about gentoo is that it
does not feel that much up to date like it did in the good old days and
that is mostly because of non existing ebuilds for exiting new software
or newer versions of popular programs.
There are other ways then maintaining releases and supporting them for a
defined time to get a distribution a professional mature touch. How
about setting a focus on quality, security and manageability and
especially provide mature tools for handling of security issues?
And once more I don't get the OS X environment idea. For me gentoo and
funtoo are distributions that let me build my systems like I want them
to be with out getting in my way every time I try something that is not
mainstream. They are about choice and flexibility. I understand OS X as
the exact opposite because to my understanding the strong visions of
Steve Jobs dictate how a user has to use and like it's MAC systems. I
like the apple hardware but not it's price tag, I like the design of the
GUI but not it's missing flexibility, I like that there are mainstream
games like World of Warcraft supported my the publishers. But why should
I like to install a funtoo environment on a MAC, what would I gain that
I could not get by installing fink or MacPorts?
> Obviously, this is a lot of change, but let me know what you think. I
> am pretty comfortable with this direction as I think it really solves
> hundreds of issues with Gentoo and opens up a lot more potential for
> the future.
>
> -Daniel
>
I think - I like to get my issues with gentoo fixed, that is why I
changed to funtoo.
* I want a distribution that is like gentoo but more fun to build
systems with.
* I want a stable quality base to build on and I want mature tools to
integrate the community and the work of my peers into my systems.
* I want to get a security fix or a new version of the programs I like
to use as fast as possible to test it out.
* I would like to mark a package as stable on my testing system and have
it available on my stable systems. I want to compile software on my
testing system and have the funtoo tools in place to distribute it to my
other systems.
* I want to rebrand the resulting systems with my name and sign or that
of my customer or employer.
* I want to get a new system up and running as fast as possible with me
being the slowest factor while I configure the partition layout, kernel,
useflags package list, bootloader, user rights, ....
* I want not only to build systems, I want to manage them and there
differences. I want a distribution that makes it easy to build systems
to my specs and that makes it easy to manage them if it is one or 1000.
* I want a distribution that is big into virtualization.
I think funtoo could be the most fun distribution to use for administrators.
We would have a unique target audience with that approach. This would
make us stand out from the sea of distributions and provide funtoo with
a bright future and a interesting user base.
Regards, Dominik
Jeff Mitchell
> As a user and past administrator of a OS X server and workstations I
> have to say that I don't care for the mess that is OS X. It looks nice
> but things are documented badly and halve finished (intranet server
> stuff). I don't understand what you would like to archive with funtoo
> being available under OS X? I understand that there are 2 systems to get
> software installed from source under OS X, so why invest work to add a 3th?
>
IMHO is the biggest problem with it; like traditional BSD ports, picking
what to compile in is a pain. I wonder if funtoo-on-OSX could work with
the MacPorts team and collaborate on something better.
>
> I like the rolling release as I see what problems real, mature,
> maintainable releases can produce in the ubuntu systems I support. To
> much changes at the same time is the biggest problem of traditional
> releases.
>
major infrastructure changes -- bumps in perl, python, xorg-server, and
the like. This gives you a predictable time to expect breakage from
package updates (not permanent breakage, but things requiring e.g.
revdep-rebuild), instead of updating and realizing that you currently
have breakage that was unplanned and super inconvenient. Other than
this, there would be the traditional rolling updates.
I would imagine that there could be two trees (git branches?) that users
could work from, similar to current funtoo stable and unstable. Unstable
would get the bumps first and test things out and work out the bugs;
stable would get them a release later when things are solid. This could
probably happen quarterly.
--Jeff
RijilV
> 1) I'd like to have Funtoo under MacOS X. Not in a prefix
> configuration. Basically, it would be in a hybrid mode where some
> packages like gcc, perl, python would be provided by Apple and would
> be "immutable" (you can't upgrade them) while others can be emerged
> like normal.
This is a cool idea. The two existing systems for getting opensource
software on OSX are unsatisfactory. That said, I don't have much
interest in it. I don't own or plan to run OSX. My concern is this
taking up a considerable amount of energy / time from other aspects of
funtoo (new features, updated packages, etc)
> 2) I want to have a simpler Linux core system. Everything in a stage3
> these days is quite complex. So I would like to rewrite ~250 ebuilds
> of the core system. I would like to make all "wrappers" optional.
> Nearly all of the Gentoo-centric features would be in optional packages.
This is fantastic, and I totally agree.
> 4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
> Move to a traditional release model. The Linux core system would be
> more stable and things would change it in a lot less often. New stuff
> would go in new point releases. Anything requiring perl-cleaner or
> other crappy cleaner runs would be saved for an official major release
> and require an explicit upgrade with upgrade instructions or an
> official upgrade script. You can keep using your old system without
> getting "pulled into the cleaner" and getting screwed :)
I'd like the package tree to continue to be a single entity, but
otherwise have no qualms with this. I don't think it's a good idea to
move the core components out of the same system that manages the rest
of the distro, regardless of how frequently they are updated.
Maintaining verions to match underlying components is something gentoo
should have done from the start, I'd rather plan when I take the time
to do an intrustive upgrade than have it sprung on me.
> 5) Move away from Portage for the core system, to a very minimal light-
> weight build system. The idea here is to allow more of an LFS-inspired
> core system -- very simple, and get rid of all the Gentoo-specific
> cruft that has been created, such has the horde of eclasses, etc.
> Maintain full Portage compatibility (Portage would be able to discover
> the versions of packages installed in the core system.) I see this re-
> engineering as necessary to really get the core system simplified and
> more LFS-like (more like how Gentoo was in the beginning.) Core system
> packages would be immutable (non-upgradeable) until you decided to
> upgrade the core system, and this may require "cleaner" runs.
The eclasses seem haphazard as they are now, and there is a definite
lack of comformity in how even simple tasks are accomplished (look at
how many different ways people adjust RC or beta tar-ball names to fit
in the ebuild). That being said, I rather like the ebuilds and the
portage toolset, so I'm interested in what exactly you're supposing to
replace it with. Again, I don't see the advantage of splitting out
the core packages from the rest in terms of how you mangae them, just
seems like then you have two ways of managing packages and thus have
to train developers / contributors twice and spend double the work on
building / maintaining your tools.
> What does all this accomplish?
>
> 1) true MacOS X support
It's somewhat worrying (to me) that this is the first "win" listed.
Is this to be the primary focus of the Funto distro in future days?
> 2) Funtoo becoming a true BSD-style distribution:
> a) real releases
> b) stability - escape from the "-cleaner" hell
> c) properly managed and maintained core system
a) As long as they're frequent and often, say every 6months.
b) Yah!
c) Yah!
> 4) Lightweight Build System
> a) /usr/src and /usr/ports split
> b) simple, better suited for educational purposes (ie. LFS)
> c) Portage compatible (portage can "see" our packages)
> d) Gentoo-centric things (wrappers) are *optional*. Our system works
> with or without them.
a) not such a fan, think it adds complexity and will take away developer time.
b) so it's going to be more work to install a system? That doesn't
sound exactly like win
c) that sounds more like a requirement and something that's going to
require more effort the further you move away from portage
d) Yah!
Seriously though, thanks for all this great work!
.r'
Víctor Román Archidona
Hi all,
> 1) I'd like to have Funtoo under MacOS X. Not in a prefix
> configuration. Basically, it would be in a hybrid mode where some
> packages like gcc, perl, python would be provided by Apple and would
> be "immutable" (you can't upgrade them) while others can be emerged
> like normal.
i'll return to it. But I prefer integrating this on other OS, like
Solaris. As a (Sun Certified) Solaris trainer, every time I should
explain that most packages are on sunfreeware.com and they have
dependencies, and that dependencies and other ones and so on and all
of them aren't automatically resolved, my students become frustrated.
> 2) I want to have a simpler Linux core system. Everything in a stage3
> these days is quite complex. So I would like to rewrite ~250 ebuilds
> of the core system. I would like to make all "wrappers" optional.
> Nearly all of the Gentoo-centric features would be in optional packages.
based on a minimal gentoo installation (well, since months ago based
on funtoo ;-), and from time to time the core system become a litle
complex to manage.
> 3) I want to start using the 3-clause BSD license for future Funtoo
> work. This would keep things more consistent with OpenRC, openresolv,
> and dhcpcd and give us more opportunities in the BSD direction.
code is always open. Anyway, every day I am more convinced that
licenses should respect the developer decisions about *his/her* code,
not only thet code itself.
> I am also considering using a dual license of the 3-clause BSD license
> and the Ms-PL (Microsoft public license - OSI approved) which is very
> similar to BSD but provides additional patent protections, a good
> thing. When I was at Microsoft, I worked with some people authoring
> the license and it is a very good license (despite the stigma of its
> name and origin.) The dual-license with BSD would allow full freedoms
> of a BSD license and GPL compatibility, plus the patent protection of
> the more modern Ms-PL.
is always a very good idea (tm)
> 4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
> Move to a traditional release model. The Linux core system would be
> more stable and things would change it in a lot less often. New stuff
> would go in new point releases. Anything requiring perl-cleaner or
> other crappy cleaner runs would be saved for an official major release
> and require an explicit upgrade with upgrade instructions or an
> official upgrade script. You can keep using your old system without
> getting "pulled into the cleaner" and getting screwed :)
and still have Gentoo systems, so learn new paths for things closely
related would not be beneficial for us.
> 5) Move away from Portage for the core system, to a very minimal light-
> weight build system. The idea here is to allow more of an LFS-inspired
> core system -- very simple, and get rid of all the Gentoo-specific
> cruft that has been created, such has the horde of eclasses, etc.
> Maintain full Portage compatibility (Portage would be able to discover
> the versions of packages installed in the core system.) I see this re-
> engineering as necessary to really get the core system simplified and
> more LFS-like (more like how Gentoo was in the beginning.) Core system
> packages would be immutable (non-upgradeable) until you decided to
> upgrade the core system, and this may require "cleaner" runs.
good idea at all. We can work on refine the system, but maintaining
two points:
1. Full system customization from scratch: Gentoo is about choice, I
can choose any logger, cron daemon, etc. And they are part of core
system.
2. Portage ease of use: It's trivial for new people (I spent some
time on my classes explaining portage) understand how it works
> 2) Funtoo becoming a true BSD-style distribution:
> a) real releases
to have. Corporate customers also loves put a new "version of X
product" instead having an actualized one with a new profile.
> b) stability - escape from the "-cleaner" hell
> b) simple, better suited for educational purposes (ie. LFS)
like a educative distro in a way "do it yoursefl", or we can it deploy
on servers? :-).
Regards,
--
Victor Roman Archidona
http://blog.daijo.org
Dave C
On Oct 12, 9:40 am, Daniel Robbins <drobb...@funtoo.org> wrote:
> 4) More of a move to a FreeBSD-style /usr/src and /usr/ports split.
> Move to a traditional release model. The Linux core system would be
> more stable and things would change it in a lot less often. New stuff
> would go in new point releases. Anything requiring perl-cleaner or
> other crappy cleaner runs would be saved for an official major release
> and require an explicit upgrade with upgrade instructions or an
> official upgrade script. You can keep using your old system without
> getting "pulled into the cleaner" and getting screwed :)
>
like the rolling release concept. It has a lot of advantages. OTOH,
I spent many years managing software and hardware validation groups,
so I know how to estimate the size of a test space. Gentoo is,
simply, impossible to properly QA. Can't happen. The test space is
just too huge when you cross versions by USE flags. But I hate having
to wait for a release to get something that I want just as much as
everyone else does.
Like many things in life, it all comes down to expectations
management. Gentoo has no way of setting an expectation of stability
that is at all consistent. Consider this middle ground, something
I'll call "sync points". The goal of a sync point is to have a
defined configuration that can be QA'd and therefore it is something
that you can set expectations around. I would expect a sync point to
be stable and come with an errata list from QA. I would expect that
if I am at at a stock release of sync point 7 and I emerge to sync
point 8, then everything goes flawlessly.
Yet, I should be able to emerge a specific package if I want an update
or to add something. OK, now I've just moved off a sync point package
contour. So emerging the whole world from some "in between" state is
not something I would expect to be QA'd, and I may have a hiccup. But
in general, my system should not get too distant from some kind of
stock sync point system, so it should be easier to debug.
Also, sync points provide a baseline to build (and QA) intermediate
package releases against. A between-sync's release of package X
should be built as much as possible against the previous sync-point
version of every dependency. Of course, there will be necessary
exceptions. But the dependency tree extends back to a well-known and
well-QA'd contour. A between-sync package should pull in a minimal
set of other between-sync packages.
The net result is still a rolling release system. But there are
mileposts along the way, and you can set expectations around each
milepost. You can provide tools to make a milepost to milepost update
smooth. A user that gets badly h0rk3d can drive toward a known
milepost configuration, verify that he has reached it, and (hopefully)
find a island of stability again from which to move forward.
> 5) Move away from Portage for the core system, to a very minimal light-
> weight build system. The idea here is to allow more of an LFS-inspired
> core system -- very simple, and get rid of all the Gentoo-specific
> cruft that has been created, such has the horde of eclasses, etc.
> Maintain full Portage compatibility (Portage would be able to discover
> the versions of packages installed in the core system.) I see this re-
> engineering as necessary to really get the core system simplified and
> more LFS-like (more like how Gentoo was in the beginning.) Core system
> packages would be immutable (non-upgradeable) until you decided to
> upgrade the core system, and this may require "cleaner" runs.
>
leave bugs around in a simple build script than in a complex one.
Daniel Robbins
all, so I'll offer some of my initial impressions...
Overall I am very surprised how generally supportive you all are of my
ideas, and even when you disagree you have respectfully explained your
position, which I greatly appreciate. I am also surprised by the
quality of the replies -- maybe I have become jaded in my expectations
due to my experiences on the Gentoo mailing lists, but it seems we
have a really awesome group of people here. And I'm not saying that to
flatter you -- I'm genuinely tickled :)
I am surprised how few concerns were raised regarding the potential
move away from a copyleft license to a non-copyleft model. This kind
of thing tends to be very controversial even to discuss. In my mind, I
am not yet settled on this decision and I will continue to reflect on
it.
I also see that there is some but not a high level of interest in Mac
OS X support. I think there is some concern that Mac OS X may distract
from Linux development. From my perspective, Mac OS X support will be
good for Funtoo, in that it will require certain features that Linux
users will benefit from - one of them being support for non-wrappered
environments. So I think it will actually accelerate some things, and
allow us to ensure some new approaches *actually work* in practice. So
I think this will improve the end result of all these changes, and
open up some new opportunities. (And be fun, too)
I've also noticed (and been surprised by) the large amount of support
for simplifying the core system, and rewriting ~250 or so ebuilds to
make them more straightforward. I think this is important and
something we can begin even now, as I continue my efforts to
streamline some ebuilds.
There seems to be support for real point releases. Yet there is also
support for continuing the rolling release model. I think we can do
both, more or less. We will always need a development branch, and we
will need users who will use this branch so we can get sufficient
testing and feedback.
This being said, I do not plan on making changes to the core system as
frequently as Gentoo does. I am hoping that there will be periods of
inactivity, paired with periods of relatively high activity in terms
of core system updates. I am a fan of testing a bunch of new core
system changes together - I think it saves time and results in more
effective QA than bumping the version of each package individually.
I think enough people would enjoy having point releases that they will
have a loyal following too.
There are a lot of really thought-provoking feedback in these posts
and I will continue to reflect on all your comments and suggestions.
Thanks for taking time to comment, and please continue to comment in
this thread.
-Daniel
Andrew D Kirch
> A lot of good comments, and I do not yet have time to reply to them
> all, so I'll offer some of my initial impressions...
>
> Overall I am very surprised how generally supportive you all are of my
> ideas, and even when you disagree you have respectfully explained your
> position, which I greatly appreciate. I am also surprised by the
> quality of the replies -- maybe I have become jaded in my expectations
> due to my experiences on the Gentoo mailing lists, but it seems we
> have a really awesome group of people here. And I'm not saying that to
> flatter you -- I'm genuinely tickled :)
>
don't recall you treating people with anything other than respect.
Also, I've quietly had all the non-hackers eliminated.
> I am surprised how few concerns were raised regarding the potential
> move away from a copyleft license to a non-copyleft model. This kind
> of thing tends to be very controversial even to discuss. In my mind, I
> am not yet settled on this decision and I will continue to reflect on
> it.
>
past. This has resulted, I think, in two groups of people in the
community. Hackers looking to have a structure where developing this
sort of system is fun again, where the red tape is gone, and where they
can be excellent, and a lot of Gentoo people looking to be more
productive in their project, and for a way forward. They say
Conservatives look to the past for our best days, that doesn't mean that
we can't bring those to the days ahead.
> I also see that there is some but not a high level of interest in Mac
> OS X support. I think there is some concern that Mac OS X may distract
> from Linux development. From my perspective, Mac OS X support will be
> good for Funtoo, in that it will require certain features that Linux
> users will benefit from - one of them being support for non-wrappered
> environments. So I think it will actually accelerate some things, and
> allow us to ensure some new approaches *actually work* in practice. So
> I think this will improve the end result of all these changes, and
> open up some new opportunities. (And be fun, too)
>
much longer standing set of core libraries. I'm about tired of
everything changing in 'system' once a day, and breaking something
higher up. It'd be nice if there was a stable 'system' which changed
less frequently (3 months?)
> I've also noticed (and been surprised by) the large amount of support
> for simplifying the core system, and rewriting ~250 or so ebuilds to
> make them more straightforward. I think this is important and
> something we can begin even now, as I continue my efforts to
> streamline some ebuilds.
>
between herd, sometimes it's better than last week, but next week is
going to be more painful than ever). Having these base packages
hammered down to a high degree of functionality would relieve a lot of
pain and suffering.
> I think enough people would enjoy having point releases that they will
> have a loyal following too.
>
correct me here, I tried and lost, and know first hand. Gentoo was the
teacher of the need for pesky things like "repeatability", "stability",
"dependability", because quite frankly it didn't have those things.
Andrew
Dave C
On Oct 15, 10:18 pm, Daniel Robbins <drobb...@funtoo.org> wrote:
> I am surprised how few concerns were raised regarding the potential
> move away from a copyleft license to a non-copyleft model. This kind
> of thing tends to be very controversial even to discuss. In my mind, I
> am not yet settled on this decision and I will continue to reflect on
> it.
>
about what it means to Funtoo, and haven't reached a coherent
conclusion.
In general, I advocate that people choose their license the way they
choose a screwdriver, not the way they choose a religion. IOW, a
license is a tool and should serve a rational objective. Is the
objective total world domination? As in: here is a nifty new
protocol, let's everyone put it into every computer system
everywhere. You can start with this reference implementation of the
protocol stack under a BSD license. OTOH, if the objective is to
avoid uncompensated commercial exploitation, or if the objective is
educational benefit through perpetual source access, then GPL is a
reasonable choice.
This is just a few possible paths of reasoning to a license choice.
First, clarify the objectives -- the choice of license will fall out
of that.
Just to pick on one potential objective: embedded applications. Of
course, all the developers of embedded products would tell you that
they want a BSD or MIT or similar no-strings-attached license. No
surprise there -- they get good stuff for free, with no legal worry.
But from the perspective of the code developer, a dual-license GPL/
proprietary strategy makes sense also. Poor students can use the GPL
version, a company building the next great portable media device can
pay for a proprietary license. This generates a revenue stream for
the developer.
There are, of course, practical issues with the dual-source license.
In the case of Funtoo, you have the copyright assignment issue -- the
strategy only works if all the copyright holders agree on how to
manage the code base WRT litigation and compensation, or if all assign
the copyright to a single holder. Even so, you are very likely to
have the code show up, unlicensed, in a product. Now you have a
choice -- is the litigation worth it or not? What are the mechanics
of enforcement? I once had some of my code go along on an FBI raid to
a large warehouse in the LA docks district. Thankfully, it was my
*code* and not *me* -- the guy that went along with the code was
handed a trench coat with 'FBI' in big letters on the back --
"wouldn't want to shoot you by accident" says a guy carrying an
AR-15. So anyway.... could Funtoo get the attention of the FBI if it
came to that? Good luck with that.