Mailing List Archive

gentoo alternatives
I'm looking for a gentoo alternative and am surprised to see that google
chrome os is based on gentoo.

Does anybody have any experience with this?

Do they support multi-media and basic modern desktop capabilities?  I
see that there's some concentration on a special browser, but I'd be
running Firefox and FVWM anyway.

Do they use /portage/ and source packages?

Do they push down every single upstream modification, like gentoo does,
or maybe have a bit of hysteresis?

I updated on May first and built firefox 78.10.*0*.  2+ days of
building.  I updated on June first and built firefox  78.10.*1*. and
spent 2+ days building.  I updated today because of the same old slot
collision problems I've run into over a year

dev-python/setuptools:0
dev-python/setuptools_scm:0
dev-python/toml:0
dev-python/certifi:0
dev-python/jinja:0
dev-python/markupsafe:0

and now, on the 7th, I'm building firefox 78.11.   I just don't have the
time for this.  It impacts my machines too much.

Yes, I know, there are binary versions, but if I wanted to use binary, I
wouldn't use gentoo.  And anyway, there's always rust and gcc and ...
Re: gentoo alternatives [ In reply to ]
On 6/7/21 10:10 AM, n952162 wrote:
>
> I'm looking for a gentoo alternative and am surprised to see that
> google chrome os is based on gentoo.
>
> Does anybody have any experience with this?
>
> Do they support multi-media and basic modern desktop capabilities?  I
> see that there's some concentration on a special browser, but I'd be
> running Firefox and FVWM anyway.
>
> Do they use /portage/ and source packages?
>
> Do they push down every single upstream modification, like gentoo
> does, or maybe have a bit of hysteresis?
>
> I updated on May first and built firefox 78.10.*0*.  2+ days of
> building.  I updated on June first and built firefox 78.10.*1*. and
> spent 2+ days building.  I updated today because of the same old slot
> collision problems I've run into over a year
>
> dev-python/setuptools:0
> dev-python/setuptools_scm:0
> dev-python/toml:0
> dev-python/certifi:0
> dev-python/jinja:0
> dev-python/markupsafe:0
>
> and now, on the 7th, I'm building firefox 78.11.   I just don't have
> the time for this.  It impacts my machines too much.
>
> Yes, I know, there are binary versions, but if I wanted to use binary,
> I wouldn't use gentoo.  And anyway, there's always rust and gcc and ...
>
>

Okay, I guess I got it, at least for the worst offenders, firefox and
thunderbird: not have them in my world file and every quarter update
them manually.  Would that work?
Re: gentoo alternatives [ In reply to ]
On Mon, 7 Jun 2021 11:10:13 +0200, n952162 wrote:

> > Yes, I know, there are binary versions, but if I wanted to use binary,
> > I wouldn't use gentoo.  And anyway, there's always rust and gcc and
> > ...
> >
> >
>
> Okay, I guess I got it, at least for the worst offenders, firefox and
> thunderbird: not have them in my world file and every quarter update
> them manually.  Would that work?

Not really, because you wouldn't get security updates. Also, because they
aren't in your world set, depclean would try to remove them and their
dependencies.

A somewhat less clunky, but still far from perfect, option would be to
use package.mask to block updates beyond the current version.

Using stable rather than testing, I don't know which you are currently
using, would reduce the number of updates significantly. This laptop runs
testing, but I have Chromium set to use stable to avoid the situation of
a rebuild completing just in time to start the next one :(

You could also look at using distcc if you have more than one machine to
spread the load.


--
Neil Bothwick

There are only 10 types of people in the world:
those who understand binary and those who don't.
Re: gentoo alternatives [ In reply to ]
On 6/7/21 11:16 AM, Neil Bothwick wrote:
> On Mon, 7 Jun 2021 11:10:13 +0200, n952162 wrote:
>
>>> Yes, I know, there are binary versions, but if I wanted to use binary,
>>> I wouldn't use gentoo.  And anyway, there's always rust and gcc and
>>> ...
>>>
>>>
>> Okay, I guess I got it, at least for the worst offenders, firefox and
>> thunderbird: not have them in my world file and every quarter update
>> them manually.  Would that work?
> Not really, because you wouldn't get security updates. Also, because they
> aren't in your world set, depclean would try to remove them and their
> dependencies.
>
> A somewhat less clunky, but still far from perfect, option would be to
> use package.mask to block updates beyond the current version.


Hmmm.  That's interesting ...


>
> Using stable rather than testing, I don't know which you are currently
> using, would reduce the number of updates significantly. This laptop runs
> testing, but I have Chromium set to use stable to avoid the situation of
> a rebuild completing just in time to start the next one :(


:-)))  That's exactly what I have (almost) with stable.


>
> You could also look at using distcc if you have more than one machine to
> spread the load.
>
>

Ah, that's also interesting  ... that's like an alternative to a local
binary server (which I'm currently doing) - the compilations are
distributed on all nodes in the network - and then, presumably are also
available to all nodes?  ...
Re: gentoo alternatives [ In reply to ]
Maybe use firefox-bin instead of firefox?
Re: gentoo alternatives [ In reply to ]
On Mon, Jun 7, 2021 at 4:10 AM n952162 <n952162@web.de> wrote:
>
> I'm looking for a gentoo alternative and am surprised to see that google chrome os is based on gentoo.

Uh, you might want to read up more on what ChromeOS is. While you can
in theory run it on anything, it is designed basically to power
Chromebooks. It is closer to something like Android than something
like Ubuntu/etc.

> Do they support multi-media and basic modern desktop capabilities?

Yes. Emphasis on "basic."

> I see that there's some concentration on a special browser, but I'd be running Firefox and FVWM anyway.

If you want to run anything other than Chrome, good luck. Maybe you
could get Firefox to run. Running fvwm is going to be much harder to
pull off. Really at that point I'm not sure why you'd even start with
ChromeOS since running Chrome with their special DE is the entire
point of the distro.

> Do they use portage and source packages?

Yes and yes. However, the build system doesn't install portage, so
you can't do updates using portage. The OS is designed to be packaged
as a read-only system image and updates are performed by updating the
system image. It is a completely non-traditional distro.

> Do they push down every single upstream modification, like gentoo does, or maybe have a bit of hysteresis?

I imagine the upstream repo has a big emphasis on security updates,
but probably doesn't stay current on every little library. Just look
at Chrome and the state of its own bundled libs if you use the
upstream repo (which Gentoo goes to a lot of work to strip out).

Really, if you want to run ChromeOS just go buy a Chromebook for $150.
Trying to roll your own is great if you want to experiment, but it
definitely isn't doing things "the easy way."

--
Rich
Re: gentoo alternatives [ In reply to ]
On 6/7/21 2:03 PM, Rich Freeman wrote:
> On Mon, Jun 7, 2021 at 4:10 AM n952162 <n952162@web.de> wrote:
>> I'm looking for a gentoo alternative and am surprised to see that google chrome os is based on gentoo.
> Uh, you might want to read up more on what ChromeOS is. While you can
> in theory run it on anything, it is designed basically to power
> Chromebooks. It is closer to something like Android than something
> like Ubuntu/etc.
>
>> Do they support multi-media and basic modern desktop capabilities?
> Yes. Emphasis on "basic."
>
>> I see that there's some concentration on a special browser, but I'd be running Firefox and FVWM anyway.
> If you want to run anything other than Chrome, good luck. Maybe you
> could get Firefox to run. Running fvwm is going to be much harder to
> pull off. Really at that point I'm not sure why you'd even start with
> ChromeOS since running Chrome with their special DE is the entire
> point of the distro.
>
>> Do they use portage and source packages?
> Yes and yes. However, the build system doesn't install portage, so
> you can't do updates using portage. The OS is designed to be packaged
> as a read-only system image and updates are performed by updating the
> system image. It is a completely non-traditional distro.
>
>> Do they push down every single upstream modification, like gentoo does, or maybe have a bit of hysteresis?
> I imagine the upstream repo has a big emphasis on security updates,
> but probably doesn't stay current on every little library. Just look
> at Chrome and the state of its own bundled libs if you use the
> upstream repo (which Gentoo goes to a lot of work to strip out).
>
> Really, if you want to run ChromeOS just go buy a Chromebook for $150.
> Trying to roll your own is great if you want to experiment, but it
> definitely isn't doing things "the easy way."
>

Okay, good info, thank you.
Re: gentoo alternatives [ In reply to ]
On Mon, 7 Jun 2021 11:25:55 +0200, n952162 wrote:

> > You could also look at using distcc if you have more than one machine
> > to spread the load.
> >
> >
>
> Ah, that's also interesting  ... that's like an alternative to a local
> binary server (which I'm currently doing) - the compilations are
> distributed on all nodes in the network - and then, presumably are also
> available to all nodes?  ...

The compilation is distributed but the result is only available to the
host running emerge. However, if you set FEATURES=buildpkg and set
$PKGDIR to a shared directory, you could use the same binaries on other
systems, provided they are set up the same.


--
Neil Bothwick

I've got a mind like a... a... what's that thing called?
Re: gentoo alternatives [ In reply to ]
On 07/06/21 14:11, Neil Bothwick wrote:
> On Mon, 7 Jun 2021 11:25:55 +0200, n952162 wrote:
>
>>> You could also look at using distcc if you have more than one machine
>>> to spread the load.
>>>
>>>
>>
>> Ah, that's also interesting ... that's like an alternative to a local
>> binary server (which I'm currently doing) - the compilations are
>> distributed on all nodes in the network - and then, presumably are also
>> available to all nodes? ...
>
> The compilation is distributed but the result is only available to the
> host running emerge. However, if you set FEATURES=buildpkg and set
> $PKGDIR to a shared directory, you could use the same binaries on other
> systems, provided they are set up the same.
>
>
That's roughly what I did - with two systems, they were set up to build
compatible packages, and store all the gentoo stuff on shared drives. So
depending on which one I rebuilt when, they often upgraded from binary
packages built by the other machine.

Cheers,
Wol
Re: gentoo alternatives [ In reply to ]
On 6/7/21 1:10 AM, n952162 wrote:
> I'm looking for a gentoo alternative and am surprised to see that google
> chrome os is based on gentoo.
>
> Does anybody have any experience with this?
>
> Do they support multi-media and basic modern desktop capabilities?  I
> see that there's some concentration on a special browser, but I'd be
> running Firefox and FVWM anyway.
>
> Do they use /portage/ and source packages?
>
> Do they push down every single upstream modification, like gentoo does,
> or maybe have a bit of hysteresis?
>
> I updated on May first and built firefox 78.10.*0*.  2+ days of
> building.  I updated on June first and built firefox  78.10.*1*. and
> spent 2+ days building.  I updated today because of the same old slot
> collision problems I've run into over a year
>
>    dev-python/setuptools:0
>    dev-python/setuptools_scm:0
>    dev-python/toml:0
>    dev-python/certifi:0
>    dev-python/jinja:0
>    dev-python/markupsafe:0
>
> and now, on the 7th, I'm building firefox 78.11.   I just don't have the
> time for this.  It impacts my machines too much.
>
> Yes, I know, there are binary versions, but if I wanted to use binary, I
> wouldn't use gentoo.  And anyway, there's always rust and gcc and ...
>
>
>

Firefox 78.10[1], 78.10.1[2], and 78.11[3] are all upstream releases
that fix security errata. Promptly pushing through security fixes from
upstream is the responsible thing for package maintainers to do.

How web browsers came to be so complex and whether it is worth it is
another topic entirely, but suffice to say I think your problems are
more caused by upstream than Gentoo.

As long as you are using a source distribution, you will pay the price
of long compiles for such complicated software, and it will happen
frequently because of how many security flaws crop up (again due to the
sheer scope and complexity of the thing), and if you do this on old
hardware it will be slow (although 2 days to compile Firefox seems
excessive, what hardware are you building this on?).

Regarding rust, personally I just gave up and installed rust-bin. Again
it's not Gentoo's fault that upstream's product is so bloated.

cal

[1] https://www.mozilla.org/en-US/security/advisories/mfsa2021-15/
[2] https://www.mozilla.org/en-US/security/advisories/mfsa2021-18/
[3] https://www.mozilla.org/en-US/security/advisories/mfsa2021-24/
Re: gentoo alternatives [ In reply to ]
Chrome OS is made by Google to run specifically on the Chromebooks. I
don't think it is intended for general computing and there is no
enthusiast community around it like around other distros.

The closest cousin to Gentoo would be Funtoo. It used to be that Gentoo
Portage could only use rsync, while Funtoo Portage could use git which
is much faster, but since then Gentoo Portage has also gained the
functionality to use git for this purpose.

My biggest problem with Gentoo was not so much the time needed to
compile huge ebuilds like Firefox, Thunderbird, or Chromium, but that
say if you neglected doing updates for a while and then decided to start
again, then you'd have serious problems. This is because, at least the
way I understood it, after some time old ebuilds would get deleted from
the Portage servers to conserve space there, but some of those now
deleted ebuilds would still be needed as dependencies to do iterative
updates. The sure-way to resolve this problem would be to re-emerge the
whole @world set, which of course would take way-longer than just
Firefox, and might work differently because the '/etc/' configuration
schema might have changed.

In my case I had some weird problem either emerging some ebuild or
keeping an old version of an ebuild to keep the functionality or the
'/etc/' schema removed in the new versions. I just let things sit, and
moved on to other projects. But when later on I tried to go back to the
original issue, I had even more trouble because now I was even further
behind @world, and more ebuilds would not upgrade because of deleted
dependencies.

So to sum it up, my problem with Gentoo was that you could not just do
iterative updates after long periods of inactivity. You pretty much had
to emerge daily and if you had some problem then drop everything and fix
it right away, or else you'll fall even further behind and eventually
might have to rebuild @world. And so because constant attention
intervention and trial and error was required you could not just compile
huge ebuilds overnight and go about your life during the day.

The distro I would recommend to look at now is NixOS -- it is also
source-based, but if you have problems with one package that will not
prevent you from keeping the rest of the system up to date. Upstream
changes are pulled pretty regularly. And even though it is
source-based, you download most packages pre-compiled. However if you
want to you can tweak the source and re-compile locally. You can also
keep multiple versions of the same package. You also do not mess
directly with the '/etc/' files for individual packages, instead you
specify a global configuration "recipe" in
'/etc/nixos/configuration.nix', which is used to generate the
package-specific '/etc/' files. This layer of abstraction improves
reliability and allows easy config cloning across machines.

The down-side is that NixOS has a radically-different paradigm that
takes a while to wrap your head around, requires learning the Nix
Expression Language (which is radically-different too), and is not yet
that "mature" so theoretically things can break, but I would still
recommend it over Chrome OS.


-- Marat


On 6/7/21 1:10 AM, n952162 wrote:
> I'm looking for a gentoo alternative and am surprised to see that google
> chrome os is based on gentoo.
>
> Does anybody have any experience with this?
>
> Do they support multi-media and basic modern desktop capabilities?  I
> see that there's some concentration on a special browser, but I'd be
> running Firefox and FVWM anyway.
>
> Do they use /portage/ and source packages?
>
> Do they push down every single upstream modification, like gentoo does,
> or maybe have a bit of hysteresis?
>
> I updated on May first and built firefox 78.10.*0*.  2+ days of
> building.  I updated on June first and built firefox  78.10.*1*. and
> spent 2+ days building.  I updated today because of the same old slot
> collision problems I've run into over a year
>
> dev-python/setuptools:0
> dev-python/setuptools_scm:0
> dev-python/toml:0
> dev-python/certifi:0
> dev-python/jinja:0
> dev-python/markupsafe:0
>
> and now, on the 7th, I'm building firefox 78.11.   I just don't have the
> time for this.  It impacts my machines too much.
>
> Yes, I know, there are binary versions, but if I wanted to use binary, I
> wouldn't use gentoo.  And anyway, there's always rust and gcc and ...
>
>
Re: gentoo alternatives [ In reply to ]
>My biggest problem with Gentoo was not so much the time needed to
>compile huge ebuilds like Firefox, Thunderbird, or Chromium, but that
>say if you neglected doing updates for a while and then decided to start
>again, then you'd have serious problems. This is because, at least the
>way I understood it, after some time old ebuilds would get deleted from
>the Portage servers to conserve space there, but some of those now
>deleted ebuilds would still be needed as dependencies to do iterative
>updates. The sure-way to resolve this problem would be to re-emerge the
>whole @world set, which of course would take way-longer than just
>Firefox, and might work differently because the '/etc/' configuration
>schema might have changed.
>
>In my case I had some weird problem either emerging some ebuild or
>keeping an old version of an ebuild to keep the functionality or the
>'/etc/' schema removed in the new versions. I just let things sit, and
>moved on to other projects. But when later on I tried to go back to the
>original issue, I had even more trouble because now I was even further
>behind @world, and more ebuilds would not upgrade because of deleted
>dependencies.
>
>So to sum it up, my problem with Gentoo was that you could not just do
>iterative updates after long periods of inactivity. You pretty much had
>to emerge daily and if you had some problem then drop everything and fix
>it right away, or else you'll fall even further behind and eventually
>might have to rebuild @world. And so because constant attention
>intervention and trial and error was required you could not just compile
>huge ebuilds overnight and go about your life during the day.

It's funny how different two people can perceive the same thing.

One of the very reason I like Gentoo is the fact that I *don't* have to do daily, or even weekly updates. I'm rather busy with life right now and I just love how little love Gentoo requires to work, and how reliable it is. I have never had any issues with postponing updates for longer periods of time.

--
Hund
Re: gentoo alternatives [ In reply to ]
Hund wrote:
>> My biggest problem with Gentoo was not so much the time needed to
>> compile huge ebuilds like Firefox, Thunderbird, or Chromium, but that
>> say if you neglected doing updates for a while and then decided to start
>> again, then you'd have serious problems. This is because, at least the
>> way I understood it, after some time old ebuilds would get deleted from
>> the Portage servers to conserve space there, but some of those now
>> deleted ebuilds would still be needed as dependencies to do iterative
>> updates. The sure-way to resolve this problem would be to re-emerge the
>> whole @world set, which of course would take way-longer than just
>> Firefox, and might work differently because the '/etc/' configuration
>> schema might have changed.
>>
>> In my case I had some weird problem either emerging some ebuild or
>> keeping an old version of an ebuild to keep the functionality or the
>> '/etc/' schema removed in the new versions. I just let things sit, and
>> moved on to other projects. But when later on I tried to go back to the
>> original issue, I had even more trouble because now I was even further
>> behind @world, and more ebuilds would not upgrade because of deleted
>> dependencies.
>>
>> So to sum it up, my problem with Gentoo was that you could not just do
>> iterative updates after long periods of inactivity. You pretty much had
>> to emerge daily and if you had some problem then drop everything and fix
>> it right away, or else you'll fall even further behind and eventually
>> might have to rebuild @world. And so because constant attention
>> intervention and trial and error was required you could not just compile
>> huge ebuilds overnight and go about your life during the day.
> It's funny how different two people can perceive the same thing.
>
> One of the very reason I like Gentoo is the fact that I *don't* have to do daily, or even weekly updates. I'm rather busy with life right now and I just love how little love Gentoo requires to work, and how reliable it is. I have never had any issues with postponing updates for longer periods of time.
>
> --
> Hund
>
>


Depending on what you consider a longer period of time, you may have
just been lucky.  There's been a couple threads in the past year or so
where people didn't update for a while and had to jump through hoops to
get their system updated.  I think one just did a reinstall because it
was faster and easier.  Another did the upgrade just as a learning
experience.  I seem to recall that a reinstall would have been faster. 
I'm not sure what was learned tho. 

In the past, others have had this same problem.  It is recommended by
long term users not to go longer than 3 or 4 months for a pretty easy
upgrade path in most cases.  Sometimes depending on changes, that can
stretch to 6 months.  That said, during some major changes, even going a
couple months can cause some serious bumps in the upgrade path.  It may
be doable but certainly more difficult.

Gentoo supports updates up to a year old.  Thing is, that means Gentoo
and the package manager does, it doesn't mean the packages upstream
won't cause some issues or that you won't run into hard blocks that have
to be handled manually. 

I been using Gentoo since 2003.  I've read some horror stories on
waiting to update for a year or more.  It's no fun.  Many years ago, it
would be almost impossible. 

Dale

:-)  :-)