Get off my lawn?

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Peter Humphrey-3
On Saturday 17 January 2015 07:59:18 Alan McKinnon wrote:

> On 17/01/2015 03:35, Philip Webb wrote:
> > 150116 walt wrote:
> >> I'd love to see a bar-chart of the age distribution of gentoo devs
> >> & compare it to a chart of the people who hang out in this mailing list
> >> :)>
> > New devs usually seem to describe themselves as
> > "I live in a town in Germany with my wife & 2-year-old daughter ;
> > I am finishing my MSc in computer science ;
> > my hobbies are playing the guitar & riding my mountain bike".
> >
> > OTOH I suspect most of us here starting computing with punched cards ...
>
> Can't say I had that pleasure :-)
>
> I did start with teletype terminals, punched paper tape and a Sinclair
> Research Mk14 though!

Mine was ASR33 & KSR35 (even went on the two-day maintenance course for
those), 24-bit Ferrranti Argus 500, 8-hole tape, 16KB core store and 2MB
disk. That was in closed-loop control of the reactors of an AGR power
station! 40 years ago and hardly seems a day.

--
Rgds
Peter.


Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Marc Stuermer
In reply to this post by Paul B. Henson
Am 17.01.2015 um 00:25 schrieb Paul B. Henson:

> http://www.linuxvoice.com/interview-lennart-poettering/
>
> So it seems the reason (in Lennart Poettering's imagination at least)
> that Gentoo hasn't embraced systemd as our default init system is
> because we're all old and conservative? Not like those young Arch Linux

He should just move on and accept the fact that not everybody likes his
new, shiney toys.

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Andrew Savchenko
In reply to this post by Rich Freeman
On Sat, 17 Jan 2015 21:04:44 -0500 Rich Freeman wrote:
> Speak for yourself. :)  I did comment on my thoughts in this area in
> Donnie's thread.  Gentoo (IMHO) tends not to be the best distro for
> doing anything in particular.  I find that its best feature is that it
> is reasonably good at doing just about anything - it is a
> jack-of-all-trades.

I can't agree with you here, though your position have a rationale.
I see Gentoo as a Universal Constructor (UC) which may be used to
whatever specific needs Linux can be used at all.

In general UC pros is ability to create setup suitable for every
specific need, but cons is maintenance cost to create and update
such setup. Also creating and maintaining UC-powered setups rises
general professional level of system architect or amdin doing the
job.

So everything comes to how much user needs deviate from what
already existing binary distributions provide. If user needs are
perfectly satisfied with some binary distro, using Gentoo will only
raise maintenance costs. But if users demands something hardly
achievable with other (binary) distributions, then this is a good
place for Gentoo.

From my own experience I can point three directions where Gentoo
was and is reasonably the best choise for our needs (mine or my
colleagues):

1) HPC. When it comes to scalable tasks and large amount of
hardware, even small performance gain results into huge saving of
costs. On our first cluster we replaced CentOS by carefully
tuned Gentoo and performance gain was about 30-50% depending on
scientific application (please note I'm talking about real
applications and not about synthetic tests like linpack). With
hardware costs about million of dollars, 30% performance gain
results in a great saving. Price for that was much longer time for
initial setup (many weeks instead of many days), but it was
still less then time required to setup hardware itself and all
auxiliary engineering systems.

An interesting observation here is that average software update
cost of Gentoo is smaller that one of RH-based systems we used
before. While it is easier to update RH-based solution within the
same branch, then Gentoo setup, it is a complete nightmare to
upgrade from one branch to another, e.g. from RHEL4 to RHEL5. I've
gone through such update in the past an it is much worse than remove
everything and install from scratch, including all user
applications. As for Gentoo, all updates are equal: they bring some
build failures, runtime issues and compatibility problems, but to
a limited extent, which is handleable easy enough by prepared team.

2) High security servers. We have some systems dedicated to a very
specific needs where security demands are extreme. Hardened Gentoo
is the best solution here, since we can strip down such system close
to an absolutely possible minimum and protect that minimum by all
means (hardened toolchain and flags, PaX, SELinux and so on). Of
course, on top of then containers may be use to isolate different
daemons and so on...

3) Individual interested in getting every bit of performance
possible from own hardware. Frankly this was the reason why I
switched to Gentoo from RH about 8 years ago. I just tired to
rebuild each time a significant part of packages with custom flags
and configure options. Gentoo is much better suited for this task.
And as a result 13 years old hardware is still usable to watch 720p
and most of 1080p videos (without GPU hardware decoding). A
byproduct of such interest is a deep understanding of system
internals, which is a great result on its own.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Grant Edwards-6
In reply to this post by Rich Freeman
On 2015-01-18, Rich Freeman <[hidden email]> wrote:

> Speak for yourself. :)  I did comment on my thoughts in this area in
> Donnie's thread.  Gentoo (IMHO) tends not to be the best distro for
> doing anything in particular.  I find that its best feature is that it
> is reasonably good at doing just about anything - it is a
> jack-of-all-trades.

Well put.  With Ubuntu, it's trivial to install one of the 2 or 3
pre-set configurations and then do the set of N things that the Ubuntu
developers thought you would want to do.  As soon as you stray from
that pre-cooked set of configurations and tasks, things quickly get a
_lot_ more difficult.

With Gentoo, it's a little more work, but you can do what _you_ want
to and and you don't have to stick to the configurations and tasks
that the developers have already thought of.

--
Grant Edwards               grant.b.edwards        Yow! An air of FRENCH FRIES
                                  at               permeates my nostrils!!
                              gmail.com            


Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

James-2
In reply to this post by Andrew Savchenko
Andrew Savchenko <bircoph <at> gentoo.org> writes:


> On Sat, 17 Jan 2015 21:04:44 -0500 Rich Freeman wrote:
> > Speak for yourself. :)  I did comment on my thoughts in this area in
> > Donnie's thread.  Gentoo (IMHO) tends not to be the best distro for
> > doing anything in particular.  I find that its best feature is that it
> > is reasonably good at doing just about anything - it is a
> > jack-of-all-trades.


I think the fundamental flaw with systemd is the fact that the duality
of support for systemd and other init solutions is so quickly abondoned.
If they were allowed (encouraged) to run side by side for a few years,
let folks decide then; as it is a major abandonment of principal, imho.

Lot of folks in the embedded linux world, are scratching their heads
at systemd; the conclusion from most of what I read is "no thanks anyway".


> I can't agree with you here, though your position have a rationale.
> I see Gentoo as a Universal Constructor (UC) which may be used to
> whatever specific needs Linux can be used at all.

+1, and more. It encourages folks to "dream". As a mostly hardware
base guy, gentoo has inspired many things in the embedded realm,
minimized systems and the future of 64bit embedded systems. Gentoo
is at the heart of the embedded-distro collision and will manifest
as 64 bit arm solutions reach street pricing.


> In general UC pros is ability to create setup suitable for every
> specific need, but cons is maintenance cost to create and update
> such setup. Also creating and maintaining UC-powered setups rises
> general professional level of system architect or amdin doing the
> job.

I post a thread a while back, from a current forum where I was surprised
at just how many folks are maintaining hundreds if not thousands
of (gentoo systems) as a superior solution for their needs. The one
thing I took from that posting from literally dozens of folks is those
that go down the massive gentoo deployment path are (1) very compentant
to say the least (2) rarely contributed back to the gentoo distro.
The fact that they do not contribute back, is not due to selfishness,
but the "cost barrier to entry" for them to contributed back.


Maybe a second gentoo wiki is needed for folks to just "put their ideas
and files and scant directions up, without such a rigorous formality to
contribute back? This, for me is the saddest part of the entire gentoo
echo_system, ymmv.


> So everything comes to how much user needs deviate from what
> already existing binary distributions provide. If user needs are
> perfectly satisfied with some binary distro, using Gentoo will only
> raise maintenance costs. But if users demands something hardly
> achievable with other (binary) distributions, then this is a good
> place for Gentoo.

I think you drasitcally over_estimate the number of those happy linux
distro users. I think if there was an easy way to perform a few typical
gentoo installs (workstation, mail-server, web server, dns server,
hardended*) then folks would migrate heavily towards gentoo.

I think Alan and his ansible_installs has the mindset for an experimentail
gentoo-ansible install engine; not for all possible tweaked installs but
certainly some of more (amd64) common installs. The questions is will
someone who get anisble_based_gentoo_install working be afforded an
"encouraging mechanism" to set up such a limited experimental installation
semantic for new gentoo installs?


> From my own experience I can point three directions where Gentoo
> was and is reasonably the best choise for our needs (mine or my
> colleagues):

> 1) HPC. When it comes to scalable tasks and large amount of
> hardware, even small performance gain results into huge saving of
> costs. On our first cluster we replaced CentOS by carefully
> tuned Gentoo and performance gain was about 30-50% depending on
> scientific application (please note I'm talking about real
> applications and not about synthetic tests like linpack). With
> hardware costs about million of dollars, 30% performance gain
> results in a great saving. Price for that was much longer time for
> initial setup (many weeks instead of many days), but it was
> still less then time required to setup hardware itself and all
> auxiliary engineering systems.

Donny alluded to this recently too in his planet gentoo posting.
I am just saddened that HPC/Distributed herd/project has become so
inactive. Yes, I am working in this area, but it has become vast with
codes to test, split among systemd and other init components
and the landscape is very noisy from the vendors offerings of
"half_baked" open source musings and offerings. For me alone, it
is a bit daunting, to say the least.


> An interesting observation here is that average software update
> cost of Gentoo is smaller that one of RH-based systems we used
> before. While it is easier to update RH-based solution within the
> same branch, then Gentoo setup, it is a complete nightmare to
> upgrade from one branch to another, e.g. from RHEL4 to RHEL5. I've
> gone through such update in the past an it is much worse than remove
> everything and install from scratch, including all user
> applications. As for Gentoo, all updates are equal: they bring some
> build failures, runtime issues and compatibility problems, but to
> a limited extent, which is handleable easy enough by prepared team.

Continuous Integration (CI) is one of the keen areas of development for
one of gentoo's derivative distros (Zentoo). Another area where Gentoo
seems to be out front of the other linux distros, imho.


> 2) High security servers. We have some systems dedicated to a very
> specific needs where security demands are extreme. Hardened Gentoo
> is the best solution here, since we can strip down such system close
> to an absolutely possible minimum and protect that minimum by all
> means (hardened toolchain and flags, PaX, SELinux and so on). Of
> course, on top of then containers may be use to isolate different
> daemons and so on...

+1


> 3) Individual interested in getting every bit of performance
> possible from own hardware. Frankly this was the reason why I
> switched to Gentoo from RH about 8 years ago. I just tired to
> rebuild each time a significant part of packages with custom flags
> and configure options. Gentoo is much better suited for this task.
> And as a result 13 years old hardware is still usable to watch 720p
> and most of 1080p videos (without GPU hardware decoding). A
> byproduct of such interest is a deep understanding of system
> internals, which is a great result on its own.

Yes, additionally:
This is identical in embedded systems; except is it mission critical.
Getting a lower cost microP to run a collection of codes (for a product
or service) often means the difference in profitability and failure
for an embedded project. Gentoo accels in this mode of deployment.
Yet our embedded public presence seems to be very quite the past few years.

The shear number of cool, new gentoo derivative distros does not
only suggest that it is strong, but that it is a platform of supremacy
for innovation; and that my friend is the very lifeblood of Unix->BSD->Linux
 imho. Gentoo does have a high cost of expertise to become useful to
a *nix admin/hack/coder. Maybe with the new wiki and some of the newer
developments, we can offer up rapid install solutions for many folks
in the linux world. That is my hope.

I think Alan is a pioneer for suggesting ansible cookbooks etc for gentoo
specific installation needs. I hope he posts his works for us all to follow?
Interestingly, Bircoph has solve many of the problems that seem  to be in my
path of discovery. Very, very cool and encouraging.  I think Sven is giving
gentoo new life, by his heroic efforts to create excellent documentation in
everything he touches!


> Best regards,
> Andrew Savchenko

peace,
James






Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Mon, Jan 19, 2015 at 1:03 PM, James <[hidden email]> wrote:
>
> I think the fundamental flaw with systemd is the fact that the duality
> of support for systemd and other init solutions is so quickly abondoned.
> If they were allowed (encouraged) to run side by side for a few years,
> let folks decide then; as it is a major abandonment of principal, imho.

That isn't a flaw with systemd - it is just how some distros (well,
95% of them) choose to implement it.  As long as somebody maintains
it, openrc will be around indefinitely.

> Lot of folks in the embedded linux world, are scratching their heads
> at systemd; the conclusion from most of what I read is "no thanks anyway".

Lots of folks everywhere are saying "no thanks anyway."  I'd be
shocked if embedded was any different.  Lots of distros want nothing
to do with it, and lots of distros are switching over wholeheartedly.
I'm not really sure what this has to do with Gentoo though.

I do agree that it would be nice to see more documentation on using
Gentoo with Ansible.  I plan to spend some time tinkering with it
myself.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
In reply to this post by Andrew Savchenko
On Mon, Jan 19, 2015 at 11:00 AM, Andrew Savchenko <[hidden email]> wrote:

> On Sat, 17 Jan 2015 21:04:44 -0500 Rich Freeman wrote:
>> Speak for yourself. :)  I did comment on my thoughts in this area in
>> Donnie's thread.  Gentoo (IMHO) tends not to be the best distro for
>> doing anything in particular.  I find that its best feature is that it
>> is reasonably good at doing just about anything - it is a
>> jack-of-all-trades.
>
> I can't agree with you here, though your position have a rationale.
> I see Gentoo as a Universal Constructor (UC) which may be used to
> whatever specific needs Linux can be used at all.

I suspect you're misunderstanding me then, because you basically went
on to repeat what I was trying (perhaps unsuccessfully) to say...  :)

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Stefan G. Weichinger-3
In reply to this post by James-2
Am 19.01.2015 um 19:03 schrieb James:

> I think you drasitcally over_estimate the number of those happy linux
> distro users. I think if there was an easy way to perform a few typical
> gentoo installs (workstation, mail-server, web server, dns server,
> hardended*) then folks would migrate heavily towards gentoo.
>
> I think Alan and his ansible_installs has the mindset for an experimentail
> gentoo-ansible install engine; not for all possible tweaked installs but
> certainly some of more (amd64) common installs. The questions is will
> someone who get anisble_based_gentoo_install working be afforded an
> "encouraging mechanism" to set up such a limited experimental installation
> semantic for new gentoo installs?

I learned my first steps with ansible around these ansible-playbook(s):

https://github.com/jameskyle/ansible-gentoo

Based on that I have done some changes and enhancements for my
(learning) needs and it was rather *easy* ...

For example changing init to systemd if you want to ... I plan writing
some patches to install to plain partitions instead of running LVM under
the hood as the original roles do (should be rather simple afaik)

The script(s) logs into the started VM (booted from live-media and with
a running sshd) ... partitions the disk, pulls latest stage3 ... does
the chroot-stuff etc etc / you define some settings in a file and let it
run.

The playbook and roles take up some MB here and it took about 30min to
install a full ~amd64 gentoo onto a VM that booted at first time (use
more recent hardware to improve ... I used an i7-2600 and KVM for the
VM). And this is *automated* ... so (nearly no ... my patches aren't
perfect yet) no manual intervention needed. And you can point it to some
physical machine as well, sure.

As the gentoo-installation is CLI-based and basically scriptable this is
really an interesting approach.

It definitely is worth more than only one thought to write some more
playbooks for specific use cases here.

And I am sure that if you gentoo-users with all your experience
contribute to such a project we would be able to get some cool
installation-playbooks cooked rather quickly ;-)

These installations would get people up and running within shorter time,
from there gentoo is still configurable as we know and like it.

Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Walter Dnes
In reply to this post by Andrew Savchenko
On Mon, Jan 19, 2015 at 07:00:52PM +0300, Andrew Savchenko wrote

> 3) Individual interested in getting every bit of performance
> possible from own hardware. Frankly this was the reason why I
> switched to Gentoo from RH about 8 years ago. I just tired to
> rebuild each time a significant part of packages with custom flags
> and configure options. Gentoo is much better suited for this task.
> And as a result 13 years old hardware is still usable to watch 720p
> and most of 1080p videos (without GPU hardware decoding). A
> byproduct of such interest is a deep understanding of system
> internals, which is a great result on its own.

  Me too <G>. I have have a Dell Dimension 530 with Intel Core2 and 3
gigs of RAM that's over 7 years old.  I installed the 32-bit option
because, at that time, there were a few programs I wanted that did not
run in 64-bit mode.  When I had done the initial install, the generic
i686 code from the install was not capable of rendering even the lowest
bandwidth version of NHL Game Centre Live (400 kbps), without
stuttering.  After "emerge system" and "emerge world", it handles HD
Youtube fine, and keeps up with NHL Game Centre "best" mode (4500 kbps).
I'm still using that system today.  The Dell simply keeps on going.

--
Walter Dnes <[hidden email]>
I don't run "desktop environments"; I run useful applications

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

James-2
In reply to this post by Rich Freeman
Rich Freeman <rich0 <at> gentoo.org> writes:


> Lots of folks everywhere are saying "no thanks anyway."  I'd be
> shocked if embedded was any different.  Lots of distros want nothing
> to do with it, and lots of distros are switching over wholeheartedly.
> I'm not really sure what this has to do with Gentoo though.

Many distros are forking or contemplating forks:

https://devuan.org/

So your all or nothing scenario is a bit more complex; and
many users will migrate  to other distros, with systemd or not
being one of the key elements in their decision, imho.


> I do agree that it would be nice to see more documentation on using
> Gentoo with Ansible.  I plan to spend some time tinkering with it
> myself.

I think many of us here at Gentoo have "Ansible Fever". It is my latest
solution to many of my current admin kludges.... I think if the more
advanced members of our Gentoo community would donate a wee_bit of time
in the form of some Ansible recipes (cookbooks) it would go a very long
way to close the gap between the gentoo handbook and a happy (shiney?)
new Gentoo install; imho.


Lots of folks are using Anible with their clusters.


peace,
James



Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Mon, Jan 19, 2015 at 5:32 PM, James <[hidden email]> wrote:

> Rich Freeman <rich0 <at> gentoo.org> writes:
>> Lots of folks everywhere are saying "no thanks anyway."  I'd be
>> shocked if embedded was any different.  Lots of distros want nothing
>> to do with it, and lots of distros are switching over wholeheartedly.
>> I'm not really sure what this has to do with Gentoo though.
>
> Many distros are forking or contemplating forks:
>
> https://devuan.org/
>
> So your all or nothing scenario is a bit more complex; and
> many users will migrate  to other distros, with systemd or not
> being one of the key elements in their decision, imho.

What all or nothing scenario would that be?  I certainly didn't speak
of one.  Should I have added "lots of distros are using both, and lots
of distros are doing something else" as well?

My point really was that "lots of people do foo" really doesn't mean
much of anything.  There are lots of distros out there, so there are
likely to be lots of distros doing anything.  And, in any case this is
really just talking about popularity, which is nice, but not really
all that important.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Tom H-4
In reply to this post by James-2
On Mon, Jan 19, 2015 at 1:03 PM, James <[hidden email]> wrote:


> I think the fundamental flaw with systemd is the fact that the duality
> of support for systemd and other init solutions is so quickly abondoned.
> If they were allowed (encouraged) to run side by side for a few years,
> let folks decide then; as it is a major abandonment of principal, imho.

The problem is logind. Various apps defaulted to depending on it
rather than on consolekit and logind isn't a standalone systemd
executable. The Linux world could've been saved a lot aggravation if a
differmt choice had been made...


> Lot of folks in the embedded linux world, are scratching their heads
> at systemd; the conclusion from most of what I read is "no thanks anyway".

Lennart claims that the embedded world loves systemd. I suspect that,
as in other corners of the Linux world, there are lovers and haters of
systemd.

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Marc Stuermer
Zitat von Tom H <[hidden email]>:

> Lennart claims that the embedded world loves systemd. I suspect that,
> as in other corners of the Linux world, there are lovers and haters of
> systemd.

Embedded systems also quite often means low on resources, CPU power,  
memory, space.

If you are using hard space constrained systems, the sheer size of  
systemd in the file system can be a valid reason not to use it at all.

So it does depend on the type of embedded system you are looking at.

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Tue, Jan 20, 2015 at 2:58 PM, Marc Stürmer <[hidden email]> wrote:

> Zitat von Tom H <[hidden email]>:
>
>> Lennart claims that the embedded world loves systemd. I suspect that,
>> as in other corners of the Linux world, there are lovers and haters of
>> systemd.
>
>
> Embedded systems also quite often means low on resources, CPU power, memory,
> space.
>
> If you are using hard space constrained systems, the sheer size of systemd
> in the file system can be a valid reason not to use it at all.
>
> So it does depend on the type of embedded system you are looking at.
>

True.  I've actually started comparing the direction systemd is moving
in with busybox.  The latter is of course already popular in embedded
environments for the reasons you state.

If you really want something super-minimal busybox is probably more of
what you're looking for.  On the other hand, if you want something
more functional but still generally integrated then systemd might be
the right solution.

RAM use for systemd (plus its deps) seems to be on the order of maybe
2MB or so depending on what features you have resident (journal/etc).
Most systemd utilities do not run continuously.  Some of the shared
memory use for systemd deps may be consumed already depending on what
else is running on the system.  Many systemd components would not
necessarily need to be installed on-disk for an embedded system.  For
example, command-line utilities used by administrators to control
their system might not need to be installed for systemd to still
function (you don't need to manually change the runlevel of an
embedded device, start/stop modules, etc - and all these tasks can be
controlled over dbus without using the binaries on disk so your
embedded application can still manage things).  I'm not sure how
systemd works with glibc alternatives, etc.

If you can dispense with a shell entirely by moving to systemd then
there could actually be some savings on that end, and performance will
certainly be better.

This page seems to be a fairly neutral/factual exploration of this issue:
https://people.debian.org/~stapelberg/docs/systemd-dependencies.html

This isn't really intended as a "systemd is the right tool for every
embedded solution" or "systemd is a horrible tool for embedded"
argument.  It just is a tool and in the embedded world you should
weigh its pros/cons as with anything else.  Most likely an embedded
environment is going to be highly-tailored in any case, so you'll be
wanting to seriously consider your options for every component.  If
your embedded device is more like a phone with (relatively larger)
gobs of RAM then systemd may be advantageous simply for its ubiquity.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Andrew Savchenko
In reply to this post by James-2
On Mon, 19 Jan 2015 18:03:44 +0000 (UTC) James wrote:
> Interestingly, Bircoph has solve many of the problems that seem  to be in my
> path of discovery.

If you have any questions about particular issues, we may discuss
them. Out of my memory for all setups we use nothing really special
— standard Gentoo software, some custom scripts (for sync and/or
HA) — and one really beatiful solution we wrote: clsync. In short
this is lsyncd replacement in C which is much faster and have
much more functionality (at least for our needs). Right now this
software is not in tree, but can be found in my dev overlay. New
clsync version was recently released and I plan to push it to tree
after some testing.

Best regards,
Andrew Savchenko

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Tom H-4
In reply to this post by Marc Stuermer
On Tue, Jan 20, 2015 at 2:58 PM, Marc Stürmer <[hidden email]> wrote:

> Zitat von Tom H <[hidden email]>:
>>
>> Lennart claims that the embedded world loves systemd. I suspect that,
>> as in other corners of the Linux world, there are lovers and haters of
>> systemd.
>
> Embedded systems also quite often means low on resources, CPU power, memory,
> space.
>
> If you are using hard space constrained systems, the sheer size of systemd
> in the file system can be a valid reason not to use it at all.
>
> So it does depend on the type of embedded system you are looking at.

Sure. My point was that anyone can claim that systemd is (un)popular
in the embedded space.

Samsung's starting to release Tizen-driven phones, TVs, white goods,
etc. Tizen uses systemd and, given the size of Samsung, the number of
systemd embedded devices is going to skyrocket in the next few years.
Samsung wouldn't have chosen systemd for Tizen if it were too resource
hungry for its use case.

There might be devices where systemd's too fat to be wedged in but
it's unfortunately going to be difficult to know whether this is
really the case or whether that determination's shaded by an
anti-systemd bias. :(

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
On Thu, Jan 22, 2015 at 1:06 PM, Tom H <[hidden email]> wrote:
>
> Samsung's starting to release Tizen-driven phones, TVs, white goods,
> etc. Tizen uses systemd and, given the size of Samsung, the number of
> systemd embedded devices is going to skyrocket in the next few years.
> Samsung wouldn't have chosen systemd for Tizen if it were too resource
> hungry for its use case.
>

Embedded is a pretty broad term, and it impacts all aspects of a
device's design.  You can't really put a smartphone and a microwave in
the same category.

Phones actually have plenty of storage, RAM, and CPU by most embedded
standards.  The main issue is battery use, which is mostly about
ensuring that your software isn't constantly waking up the CPU.  If
systemd is well-behaved in this regard I'd expect it to work on a
phone just fine.

The thing is that most devices that couldn't run systemd would
probably be hard-pressed to run any kind of generic linux distro in
any case.  They might not even run linux, or if they did it might be a
super-stripped-down build with an embedded initramfs containing
nothing but a single executable built in C which runs as PID 1 (no
need for even filesystem support, let alone stuff like /proc and so
on).

I'm genuinely curious as to how systemd and competing solutions are
adopted in the embedded world, including phones but especially getting
beyond this (huge) niche.

I'm also curious as to where ChromeOS ends up going.  It is based on
Gentoo, but runs Upstart (which isn't used by just about anybody else
now, and which isn't even in Gentoo's portage).

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Tom H-4
On Thu, Jan 22, 2015 at 1:16 PM, Rich Freeman <[hidden email]> wrote:
> On Thu, Jan 22, 2015 at 1:06 PM, Tom H <[hidden email]> wrote:


>> Samsung's starting to release Tizen-driven phones, TVs, white goods,
>> etc. Tizen uses systemd and, given the size of Samsung, the number of
>> systemd embedded devices is going to skyrocket in the next few years.
>> Samsung wouldn't have chosen systemd for Tizen if it were too resource
>> hungry for its use case.
>>
>
> Embedded is a pretty broad term, and it impacts all aspects of a
> device's design.  You can't really put a smartphone and a microwave in
> the same category.
>
> Phones actually have plenty of storage, RAM, and CPU by most embedded
> standards.  The main issue is battery use, which is mostly about
> ensuring that your software isn't constantly waking up the CPU.  If
> systemd is well-behaved in this regard I'd expect it to work on a
> phone just fine.
>
> The thing is that most devices that couldn't run systemd would
> probably be hard-pressed to run any kind of generic linux distro in
> any case.  They might not even run linux, or if they did it might be a
> super-stripped-down build with an embedded initramfs containing
> nothing but a single executable built in C which runs as PID 1 (no
> need for even filesystem support, let alone stuff like /proc and so
> on).

ACK to all the above!


> I'm genuinely curious as to how systemd and competing solutions are
> adopted in the embedded world, including phones but especially getting
> beyond this (huge) niche.

Same here. I'd really like to see whether systemd'll be used beyond
Tizen/Sailfish/UbuntuTouch.


> I'm also curious as to where ChromeOS ends up going.  It is based on
> Gentoo, but runs Upstart (which isn't used by just about anybody else
> now, and which isn't even in Gentoo's portage).

I'm also curious about the future ChromeOS init. Upstart is, sadly,
walking dead (IIUC Ubuntu'll stop using it in 2019 once 14.04 is
EOLd). It's going to be systemd or Android init, isn't it? AIUI Google
wants to have Android and ChromeOS converge somewhat so it's more
likely to be Android init. Speculation! :)

Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Stefan G. Weichinger-3
In reply to this post by Stefan G. Weichinger-3
On 19.01.2015 22:49, Stefan G. Weichinger wrote:

> I learned my first steps with ansible around these ansible-playbook(s):
>
> https://github.com/jameskyle/ansible-gentoo

Here my changes in a fork of the mentioned ansible-role:

https://github.com/stefangweichinger/ansible-gentoo

Maybe someone is interested to join in and improve this.

Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Get off my lawn?

Rich Freeman
In reply to this post by Tom H-4
On Thu, Jan 22, 2015 at 1:36 PM, Tom H <[hidden email]> wrote:
>
> I'm also curious about the future ChromeOS init. Upstart is, sadly,
> walking dead (IIUC Ubuntu'll stop using it in 2019 once 14.04 is
> EOLd). It's going to be systemd or Android init, isn't it? AIUI Google
> wants to have Android and ChromeOS converge somewhat so it's more
> likely to be Android init. Speculation! :)
>

Interesting, I hadn't thought about Android init.  Neither ChromeOS
nor Android support user-supplied daemons or anything else traditional
along those lines (anything running in the background is run at a
higher level in the framework).  However, I think a key difference
here is suspend/hibernate.  Android doesn't do that, and ChromeOS
does.  Android goes into lower-power mode all the time, but I don't
think that is the same as a traditional desktop sleep mode, and
Android definitely doesn't do suspend-to-disk.  ChromeOS tends to hide
this stuff from the user, but I believe it does both.  That seems
likely to greatly favor an event-driven init, though the fact that you
aren't running tons of arbitrary daemons might help to mitigate that
need.

--
Rich

123