Re: [gentoo-user] Re: Get off my lawn?
On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target. It's not necessarily a fast moving target. RHEL 7 uses an upstream-maintained 208 stable (and AFAIR Debian 8 will also use it). For embedded systems that never used sysvinit, systemd is unlikely ever to be an option but for others anyone can claim either that systemd is the best choice possible or that it's the worst choice possible without any proof either way.
Re: [gentoo-user] Re: Get off my lawn?
Hi, Rich. On Sat, Jan 24, 2015 at 12:58:48PM -0500, Rich Freeman wrote: On Sat, Jan 24, 2015 at 12:27 PM, Alan Mackenzie a...@muc.de wrote: On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote: Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. systemd-183's velocity is unchanged from the day it was released, and it isn't slow. You'll have to define what you mean by velocity here, not that it really matters since we can quibble over definitions all day long. systemd-183 today is identical to systemd-183 the day it was released. It is a snapshot in time. When you take a photograph (a snapshot) of a fast moving thing, the photo may give the false appearance of the thing being stationary, whereas it is in reality a fast moving object. That is my feeling about systemd. But I agree, the point is not worth quibbling over. The fast-moving target bit is only an issue if you want to keep updating it. Quite the contrary - the fast-moving bit is an issue if you _can't_ update it, or if updating is expensive, which is frequently the case for embedded systems. Fast-moving software is likelier to be buggy than well established traditional software. You do test your embedded devices before you release them, right? Absolutely. They are tested most searchingly, both by us and by the customer. However software not written by us is assumed to be fully tested by its suppliers, hence is only tested by us at the System Integration level. Generally, that's a safe assumption when speaking about proprietary embedded OSs. Clearly, SW which incorporates GPL bits must itself be GPL, and I have no experience of working on any such embedded SW. That said, systemd doesn't change THAT much between versions as far as the key interfaces go. But busybox changes even less. It is also used far less. Are you sure? I had the impression that busybox was very widely used on embedded devices, such as routers, which are made in very large numbers. Do you really think that you're less likely to have problems with busybox mdev and busybox init than with whatever version of backported version of systemd RHEL is using six months after release? Yes, I do, certainly on an embedded system. Even on a desktop, mdev works well. I've used it. The only reason I gave up on it was because a package I use (I can't remember which one any more) suddenly acquired a hard dependency on udev. :-( -- Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Get off my lawn?
On Sat, Jan 24, 2015 at 12:27 PM, Alan Mackenzie a...@muc.de wrote: On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote: Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. systemd-183's velocity is unchanged from the day it was released, and it isn't slow. You'll have to define what you mean by velocity here, not that it really matters since we can quibble over definitions all day long. systemd-183 today is identical to systemd-183 the day it was released. It is a snapshot in time. The fast-moving target bit is only an issue if you want to keep updating it. Quite the contrary - the fast-moving bit is an issue if you _can't_ update it, or if updating is expensive, which is frequently the case for embedded systems. Fast-moving software is likelier to be buggy than well established traditional software. You do test your embedded devices before you release them, right? That said, systemd doesn't change THAT much between versions as far as the key interfaces go. But busybox changes even less. It is also used far less. Do you really think that you're less likely to have problems with busybox mdev and busybox init than with whatever version of backported version of systemd RHEL is using six months after release? -- Rich
Re: [gentoo-user] Re: Get off my lawn?
On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target. Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. The fast-moving target bit is only an issue if you want to keep updating it. That said, systemd doesn't change THAT much between versions as far as the key interfaces go. -- Rich
Re: [gentoo-user] Re: Get off my lawn?
Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target.
Re: [gentoo-user] Re: Get off my lawn?
Hello, Rich. On Sat, Jan 24, 2015 at 11:37:00AM -0500, Rich Freeman wrote: On Sat, Jan 24, 2015 at 10:34 AM, Marc Stürmer m...@marc-stuermer.de wrote: Am 22.01.2015 um 19:06 schrieb Tom H: Sure. My point was that anyone can claim that systemd is (un)popular in the embedded space. I don't know if it is popular; in embedded systems though the last thing you need are fast moving targets IMHO, you want to use proven, reliable tools. If systemd is reliable or not, this depends on your decision, but it is a fast moving target. Do you regularly update the software on your embedded system? systemd-183 hasn't changed a bit since the day it was released. systemd-183's velocity is unchanged from the day it was released, and it isn't slow. The fast-moving target bit is only an issue if you want to keep updating it. Quite the contrary - the fast-moving bit is an issue if you _can't_ update it, or if updating is expensive, which is frequently the case for embedded systems. Fast-moving software is likelier to be buggy than well established traditional software. That said, systemd doesn't change THAT much between versions as far as the key interfaces go. But busybox changes even less. -- Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Get off my lawn?
On Thu, Jan 22, 2015 at 1:16 PM, Rich Freeman ri...@gentoo.org wrote: On Thu, Jan 22, 2015 at 1:06 PM, Tom H tomh0...@gmail.com 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! :)
Re: [gentoo-user] Re: Get off my lawn?
On Thu, Jan 22, 2015 at 3:42 PM, Alan Mackenzie a...@muc.de wrote: Just as a data point, the last project I worked on was an automotive system, whose controller was a 32-bit Power PC with 768k/64k code/data flash, and 64k RAM. It did not run systemd! Rather than Linux, it ran Autosar (a special, and somewhat wierd, OS specially for automotive products). I wonder how small linux can actually get in such a world, assuming you still needed the multitasking, drivers, etc (which would be the main benefits of running an OS vs just embedding a single program written in C that directly talks to the hardware). You can trim a lot of stuff out of linux that we all take for granted, but I'm not sure if you can really get it into the 100kb range. I couldn't really find hard numbers anywhere for the actual minimum RAM requirements for a linux that contains the minimum features needed to provide a bit of hardware support and run init with almost nothing else exposed but the system call interface (no need for /proc, devfs, /sys, and so on). It sounds like you're still talking hundreds of kilobytes to 1-2MB of RAM use in most cases. So, dedicated embedded kernels are likely to stay around for a while to come. -- Rich
Re: [gentoo-user] Re: Get off my lawn?
On Thu, Jan 22, 2015 at 04:28:26PM -0500, Rich Freeman wrote I wonder how small linux can actually get in such a world, assuming you still needed the multitasking, drivers, etc (which would be the main benefits of running an OS vs just embedding a single program written in C that directly talks to the hardware). You can trim a lot of stuff out of linux that we all take for granted, but I'm not sure if you can really get it into the 100kb range. *BSD would be a better candidate, in terms of a smaller kernel to start with. And I'm sure that legal would be a lot happier about not having to supply source code. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: Get off my lawn?
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
Re: [gentoo-user] Re: Get off my lawn?
On Thu, Jan 22, 2015 at 1:36 PM, Tom H tomh0...@gmail.com 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
Re: [gentoo-user] Re: Get off my lawn?
On Tue, Jan 20, 2015 at 2:58 PM, Marc Stürmer m...@marc-stuermer.de wrote: Zitat von Tom H tomh0...@gmail.com: 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. :(
Re: [gentoo-user] Re: Get off my lawn?
On Thu, Jan 22, 2015 at 1:06 PM, Tom H tomh0...@gmail.com 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
Re: [gentoo-user] Re: Get off my lawn?
Hello Rich, and everybody else, Happy New Year! On Thu, Jan 22, 2015 at 01:16:53PM -0500, Rich Freeman wrote: On Thu, Jan 22, 2015 at 1:06 PM, Tom H tomh0...@gmail.com 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. Just as a data point, the last project I worked on was an automotive system, whose controller was a 32-bit Power PC with 768k/64k code/data flash, and 64k RAM. It did not run systemd! Rather than Linux, it ran Autosar (a special, and somewhat wierd, OS specially for automotive products). The sensors in the system were even more constrained, using a special low-power processor with 16k flash and 1.5k RAM. They didn't run Linux either! In fact, they didn't have an OS - they were coded directly to the metal, in a single-tasked loop. My impression is that the embedded world is split roughly equally between large systems (like smart phones or infotainment systems where RAM is measured in gigabytes, and full scale OSs are used) and small systems (such as my automotive system, microwave ovens, TV zappers, elevator controllers, where special OSs, if any, are used, and RAM is measured in kilobytes). 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 -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Get off my lawn?
On Mon, Jan 19, 2015 at 1:03 PM, James wirel...@tampabay.rr.com 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.
Re: [gentoo-user] Re: Get off my lawn?
Zitat von Tom H tomh0...@gmail.com: 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.
Re: [gentoo-user] Re: Get off my lawn?
On Mon, 19 Jan 2015 18:03:44 + (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 pgpaUDKvZUjwG.pgp Description: PGP signature
Re: [gentoo-user] Re: Get off my lawn?
On Tue, Jan 20, 2015 at 2:58 PM, Marc Stürmer m...@marc-stuermer.de wrote: Zitat von Tom H tomh0...@gmail.com: 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
Re: [gentoo-user] Re: Get off my lawn?
On Mon, Jan 19, 2015 at 5:32 PM, James wirel...@tampabay.rr.com 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
Re: [gentoo-user] Re: Get off my lawn?
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
Re: [gentoo-user] Re: Get off my lawn?
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 waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: Get off my lawn?
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 pgpIL0spPvaY8.pgp Description: PGP signature
Re: [gentoo-user] Re: Get off my lawn?
On Mon, Jan 19, 2015 at 11:00 AM, Andrew Savchenko birc...@gentoo.org 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
Re: [gentoo-user] Re: Get off my lawn?
On Mon, Jan 19, 2015 at 1:03 PM, James wirel...@tampabay.rr.com 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
Re: [gentoo-user] Re: Get off my lawn?
On 18/01/2015 04:04, Rich Freeman wrote: On Jan 17, 2015 1:56 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2015-01-16, Paul B. Henson hen...@acm.org wrote: 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? No, it's because we're practical and view computers as means to get things done rather than ends in themselves to be put inside transparent cases with fans that light up. 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. For years I've felt Gentoo excels if you need to do something that deviates from what mainstream binary distros do, and this is because we have a fully functional toolchain that is built to handle deviations from default with ease. This is what USE is all about. A few examples come to mind: 1. You have a large server farm, all identical, and setting them up that way on a binary distro is difficult 2. You need to build on big hardware and deploy on small hardware 3. You need specific features enabled in the system that a binary distro doesn't provide So I'm not quite in agreement with your last sentence; Gentoo is very very good at giving you exactly what you want :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Get off my lawn?
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.
Re: [gentoo-user] Re: Get off my lawn?
On Fri, Jan 16 2015, Alan McKinnon wrote: On 17/01/2015 03:35, Philip Webb wrote: 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! Paper tape, bendix G15 and IBM 650 (1962). allan
Re: [gentoo-user] Re: Get off my lawn?
On Jan 17, 2015 1:56 PM, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2015-01-16, Paul B. Henson hen...@acm.org wrote: 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? No, it's because we're practical and view computers as means to get things done rather than ends in themselves to be put inside transparent cases with fans that light up. 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. -- Rich
Re: [gentoo-user] Re: Get off my lawn?
On Fri, 16 Jan 2015 20:35:55 -0500, Philip Webb wrote: OTOH I suspect most of us here starting computing with punched cards ... And some of you admit it... -- Neil Bothwick Confucius say : He who play in root, eventually kill tree! pgpmll75FfnZh.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Get off my lawn?
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 ... -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
RE: [gentoo-user] Re: Get off my lawn?
From: walt Sent: Friday, January 16, 2015 5:18 PM I'd love to see a bar-chart of the age distribution of gentoo devs. And then compare it to a similar chart of the people who hang out in this mailing list :) I'm only a proxy maintainer, not a dev, but in the spirit of data analysis I will admit to being 41 ;).
Re: [gentoo-user] Re: Get off my lawn?
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! -- Alan McKinnon alan.mckin...@gmail.com
