Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
Best I can tell is learn it and use it. And if you have any services, fix them so that they work with systemd. I work with one that does not and it is very slow to complete its startup.
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
Seems a big revolution is being forced on Linux users when stability and the "same old familiar Linux" is desired by many, including me.
Best I can tell is learn it and use it. And if you have any services, fix them so that they work with systemd. I work with one that does not and it is very slow to complete its startup.
I was keenly waiting to upgrade to C7. Perhaps I'll upgrade to C6 and retain familiar Linux.
On 08/07/14 02:22, Always Learning wrote:
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
Seems a big revolution is being forced on Linux users when stability and the "same old familiar Linux" is desired by many, including me.
It's already started. Some configs have already moved from /etc to /usr under el7.
Whilst I'm as resistant to change as the next man, I've learned you can't fight it so best start getting used to it ;-)
Best I can tell is learn it and use it. And if you have any services, fix them so that they work with systemd. I work with one that does not and it is very slow to complete its startup.
I was keenly waiting to upgrade to C7. Perhaps I'll upgrade to C6 and retain familiar Linux.
On 07/08/2014 04:22 AM, Always Learning wrote:
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
err.. what? even on that wild fedora thread this did not come up!!!
i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..
Thanks! Adrian
On 08.07.2014 14:58, Adrian Sevcenco wrote:
On 07/08/2014 04:22 AM, Always Learning wrote:
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
err.. what? even on that wild fedora thread this did not come up!!!
i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..
There are no plans to "abolish" /etc and /var.
The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr. That way if you want to "factory reset" the system you can basically clear out /etc and you are back do the defaults. The same applies to /var. The idea is that /etc and /var become "site-local" directories that only contain the config you actually changed from the defaults for this system.
Since you already have experience with systemd you are already familiar with this system where it stores its unit files in /usr/lib/systemd and if you want to change some of them you copy them to /etc/systemd and change them there. Same principle.
/etc and /var will stay as valid as ever though and are not being "abolished".
Regards, Dennis
On 08/07/14 14:14, Dennis Jacobfeuerborn wrote:
On 08.07.2014 14:58, Adrian Sevcenco wrote:
On 07/08/2014 04:22 AM, Always Learning wrote:
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
err.. what? even on that wild fedora thread this did not come up!!!
i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..
There are no plans to "abolish" /etc and /var.
The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr. That way if you want to "factory reset" the system you can basically clear out /etc and you are back do the defaults. The same applies to /var. The idea is that /etc and /var become "site-local" directories that only contain the config you actually changed from the defaults for this system.
Since you already have experience with systemd you are already familiar with this system where it stores its unit files in /usr/lib/systemd and if you want to change some of them you copy them to /etc/systemd and change them there. Same principle.
/etc and /var will stay as valid as ever though and are not being "abolished".
That's not always true.
Some configs that were under /etc on el6 must now reside under /usr on el7.
Take modprobe blacklists for example.
On el5 and el6 they are in /etc/modprobe.d/
On el7 they need to be in /usr/lib/modprobe.d/
If you install modprobe blacklists to the old location under el7 they will not work.
I'm sure there are other examples, this is just one example I've happened to run into.
On 08.07.2014 15:53, Ned Slider wrote:
On 08/07/14 14:14, Dennis Jacobfeuerborn wrote:
On 08.07.2014 14:58, Adrian Sevcenco wrote:
On 07/08/2014 04:22 AM, Always Learning wrote:
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
err.. what? even on that wild fedora thread this did not come up!!!
i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..
There are no plans to "abolish" /etc and /var.
The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr. That way if you want to "factory reset" the system you can basically clear out /etc and you are back do the defaults. The same applies to /var. The idea is that /etc and /var become "site-local" directories that only contain the config you actually changed from the defaults for this system.
Since you already have experience with systemd you are already familiar with this system where it stores its unit files in /usr/lib/systemd and if you want to change some of them you copy them to /etc/systemd and change them there. Same principle.
/etc and /var will stay as valid as ever though and are not being "abolished".
That's not always true.
Some configs that were under /etc on el6 must now reside under /usr on el7.
Take modprobe blacklists for example.
On el5 and el6 they are in /etc/modprobe.d/
On el7 they need to be in /usr/lib/modprobe.d/
If you install modprobe blacklists to the old location under el7 they will not work.
I'm sure there are other examples, this is just one example I've happened to run into.
You might want to report this as a bug. The modprobe and modprobe.d man pages explicitly reference "/etc/modprobe.d/*.conf" for the configuration.
Regards, Dennis
On 08/07/14 18:36, Dennis Jacobfeuerborn wrote:
On 08.07.2014 15:53, Ned Slider wrote:
On 08/07/14 14:14, Dennis Jacobfeuerborn wrote:
On 08.07.2014 14:58, Adrian Sevcenco wrote:
On 07/08/2014 04:22 AM, Always Learning wrote:
On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote: > Reading about systemd, it seems it is not well liked and reminiscent of > Microsoft's "put everything into the Windows Registry" (Win 95 onwards). > > Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
err.. what? even on that wild fedora thread this did not come up!!!
i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..
There are no plans to "abolish" /etc and /var.
The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr. That way if you want to "factory reset" the system you can basically clear out /etc and you are back do the defaults. The same applies to /var. The idea is that /etc and /var become "site-local" directories that only contain the config you actually changed from the defaults for this system.
Since you already have experience with systemd you are already familiar with this system where it stores its unit files in /usr/lib/systemd and if you want to change some of them you copy them to /etc/systemd and change them there. Same principle.
/etc and /var will stay as valid as ever though and are not being "abolished".
That's not always true.
Some configs that were under /etc on el6 must now reside under /usr on el7.
Take modprobe blacklists for example.
On el5 and el6 they are in /etc/modprobe.d/
On el7 they need to be in /usr/lib/modprobe.d/
If you install modprobe blacklists to the old location under el7 they will not work.
I'm sure there are other examples, this is just one example I've happened to run into.
You might want to report this as a bug. The modprobe and modprobe.d man pages explicitly reference "/etc/modprobe.d/*.conf" for the configuration.
Regards, Dennis
Well, I stand corrected!
I was just running though the issue for a reply here, and what was broken in the rhel7rc is now fixed and indeed working as documented.
My issue looked like a regression of this bug:
I am sure now do not understand the bug end line. From Fedora 17 they modprobe.d moved from /etc to /var/lib ? if so why not just use a symlink from /etc to /var/lib if someone needs it there for any reason what so ever??
Eliezer
On 07/08/2014 09:12 PM, Ned Slider wrote:
Well, I stand corrected!
I was just running though the issue for a reply here, and what was broken in the rhel7rc is now fixed and indeed working as documented.
My issue looked like a regression of this bug:
On 7/8/2014 6:53 AM, Ned Slider wrote:
That's not always true.
Some configs that were under /etc on el6 must now reside under /usr on el7.
Take modprobe blacklists for example.
On el5 and el6 they are in/etc/modprobe.d/
On el7 they need to be in/usr/lib/modprobe.d/
If you install modprobe blacklists to the old location under el7 they will not work.
I'm sure there are other examples, this is just one example I've happened to run into.
this is insane. traditionally in Unix-like systems, /usr is supposed to be able to be read only and sharable between multiple systems, for instance in NFS boot scenarios. /var is specifically for host-specific complex configuration and status stuff like /var/logs /var/state /var/run and so forth.
On Tue, Jul 8, 2014 at 1:08 PM, John R Pierce pierce@hogranch.com wrote:
On 7/8/2014 6:53 AM, Ned Slider wrote:
That's not always true.
Some configs that were under /etc on el6 must now reside under /usr on el7.
Take modprobe blacklists for example.
On el5 and el6 they are in/etc/modprobe.d/
On el7 they need to be in/usr/lib/modprobe.d/
If you install modprobe blacklists to the old location under el7 they will not work.
I'm sure there are other examples, this is just one example I've happened to run into.
this is insane. traditionally in Unix-like systems, /usr is supposed to be able to be read only and sharable between multiple systems, for instance in NFS boot scenarios. /var is specifically for host-specific complex configuration and status stuff like /var/logs /var/state /var/run and so forth.
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
On Tue, Jul 08, 2014 at 01:22:54PM -0500, Les Mikesell wrote:
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Jonathan Billings wrote:
On Tue, Jul 08, 2014 at 01:22:54PM -0500, Les Mikesell wrote:
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Great. And it's from freedesktop... as opposed to, say, a system user, and which implies to me that it's for runlevel 5 GUI-only users....
mark
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Great. And it's from freedesktop... as opposed to, say, a system user, and which implies to me that it's for runlevel 5 GUI-only users....
perhaps you should read links before you make assumptions. and doubly so before you start following up.
On Tue, Jul 08, 2014 at 02:56:17PM -0400, m.roth@5-cent.us wrote:
I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Great. And it's from freedesktop... as opposed to, say, a system user, and which implies to me that it's for runlevel 5 GUI-only users....
This seems to be a common misconception.
To quote http://0pointer.de/blog/projects/the-biggest-myths.html:
- Myth: systemd is a freedesktop.org project.
Well, systemd is certainly hosted at fdo, but freedesktop.org is little else but a repository for code and documentation. Pretty much any coder can request a repository there and dump his stuff there (as long as it's somewhat relevant for the infrastructure of free systems). There's no cabal involved, no "standardization" scheme, no project vetting, nothing. It's just a nice, free, reliable place to have your repository. In that regard it's a bit like SourceForge, github, kernel.org, just not commercial and without over-the-top requirements, and hence a good place to keep our stuff.
So yes, we host our stuff at fdo, but the implied assumption of this myth in that there was a group of people who meet and then agree on how the future free systems look like, is entirely bogus.
freedesktop.org hosts a variety of software projects, not all of which are desktop-oriented. Just look at the list here:
http://www.freedesktop.org/wiki/Software/
It's worth noting that much of the software projects hosted there are desktop-oriented, but that doesn't mean that systemd is only for desktops. It just happens to be the site where the systemd documentation resides, and is a great place to peruse if you are interested in learning more about systemd.
On Tue, Jul 8, 2014 at 1:47 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Jul 08, 2014 at 01:22:54PM -0500, Les Mikesell wrote:
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Ummm, 'addressed' by pointing out that a whole bunch of the changes fedora has made break things that are expected to work in unix-like systems. I fail to see how that helps with the problem.
On Tue, Jul 08, 2014 at 02:34:49PM -0500, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 1:47 PM, Jonathan Billings billings@negate.org wrote> > I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Ummm, 'addressed' by pointing out that a whole bunch of the changes fedora has made break things that are expected to work in unix-like systems. I fail to see how that helps with the problem.
I'm not sure if I'm reading the same page as you are. I could sum up the response to your objection with two points:
1. systemd works fine with /usr on a separate file system that is not pre-mounted at boot.
2. Modern linux distributions currently don't work well when /usr is not pre-mounted at boot, and this has been the case for a while.
Fedora went through a process to try to clean up the mess that Linux has fallen into, by identifying all the executables in /bin, /sbin, /etc, /var (etc.) that aren't needed to boot the system, and migrating them into /usr.
This migration was put into place for reasons unrelated to systemd. Perhaps you have a valid complaint about this change, but don't lump it together with your issue with systemd.
On Tue, 8 Jul 2014 14:34:49 -0500 Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jul 8, 2014 at 1:47 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Jul 08, 2014 at 01:22:54PM -0500, Les Mikesell wrote:
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
I think that a lot of these objections are addressed here:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
Ummm, 'addressed' by pointing out that a whole bunch of the changes fedora has made break things that are expected to work in unix-like systems. I fail to see how that helps with the problem.
And the text contains several weaknesses. I've personally checked the statement for the 23 dependencies from udev rules to /usr in Fedora 15. Maybe my Fedora 15 was something strange but there was none dependency inside.
And for me it's ok to blame the small environment in / for some special udev rules they might exist somewhere. But a solution would be a staged Udev, which would be simple to solve.
A small problem, a small solution.
The other "arguments" have the same quality. To have a /usr on a central NFS server doesn't seem to be a case for such idiots.
The binary size of systemd is now more than 1.1 MB - for a central service which will kill your system if it's not rock solid. For a comparison: an apache web server is less than 500 kB.
Best Regards Oli
On Jul 8, 2014, at 1:22 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jul 8, 2014 at 1:08 PM, John R Pierce pierce@hogranch.com wrote:
On 7/8/2014 6:53 AM, Ned Slider wrote:
That's not always true.
Some configs that were under /etc on el6 must now reside under /usr on el7.
Take modprobe blacklists for example.
On el5 and el6 they are in/etc/modprobe.d/
On el7 they need to be in/usr/lib/modprobe.d/
If you install modprobe blacklists to the old location under el7 they will not work.
I'm sure there are other examples, this is just one example I've happened to run into.
this is insane. traditionally in Unix-like systems, /usr is supposed to be able to be read only and sharable between multiple systems, for instance in NFS boot scenarios. /var is specifically for host-specific complex configuration and status stuff like /var/logs /var/state /var/run and so forth.
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
This work is all about being able to boot a system with just a read-only /usr. Any foo you need to get to a complex filesystems, like NFS or encrypted software RAID needs to be in the initial ramdisk which the boot loader can access before the kernel loads and which tools like Dracut build based on what’s required for your particular setup. The seeds of that change basically existed from the time that initial ram disks were introduced as a feature a long time ago, now we’ve just widely acknowledged this reality.
— Mark Tinberg, System Administrator Division of Information Technology - Network Services University of Wisconsin - Madison mtinberg@wisc.edu
On Tue, Jul 8, 2014 at 3:01 PM, Mark Tinberg mtinberg@wisc.edu wrote:
And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?
This work is all about being able to boot a system with just a read-only /usr. Any foo you need to get to a complex filesystems, like NFS or encrypted software RAID needs to be in the initial ramdisk which the boot loader can access before the kernel loads and which tools like Dracut build based on what’s required for your particular setup. The seeds of that change basically existed from the time that initial ram disks were introduced as a feature a long time ago, now we’ve just widely acknowledged this reality.
Errr, I thought you only needed stuff on the ramdisk to access the root partition. Can't you mount /usr from a different disk controller or NFS from modules loaded from /lib/modules? Or was that already broken when user's home directories were kicked into /home? And if not, how did things get in that mess?
On Tue, 2014-07-08 at 15:14 +0200, Dennis Jacobfeuerborn wrote:
There are no plans to "abolish" /etc and /var.
The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr.
Exactly the same as Logwatch does now in C5 and C6.
On Tue, 2014-07-08 at 15:58 +0300, Adrian Sevcenco wrote:
On 07/08/2014 04:22 AM, Always Learning wrote:
http://www.phoronix.com/scan.php?page=news_topic&q=systemd
The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.
err.. what? even on that wild fedora thread this did not come up!!!
Please see the link above. I used it to find the 'stateless' item, and after selecting it clicked on
http://0pointer.de/blog/projects/stateless.html
On 07/08/2014 11:37 AM, Always Learning wrote:
Please see the link above. I used it to find the 'stateless' item, and after selecting it clicked on
There are many use cases involving servers where such a capability would be highly desirable. Most are cloud-oriented, where you want to spin up an instance rapidly (to deal with increased load, perhaps) and then spin it down, and having dynamically loaded /etc and /var content allows this in a smooth manner. Static servers have their uses, of course, but at least in my data center I find actual server load to be very dynamic, but power load to be rather static; why *shouldn't* the power used be proportional to the work load?
The real promise of 'cloud' technology is for us in in-house servers that can spin up only when needed, saving power and cooling costs in the process. Stateless is not the only way to go, of course, and nothing in the blog post to which you link is 'never again honor anything in /etc and /var' to be found, but rather, much like /etc serves as a fall-back for many programs who look first in a dot-file in ~, the content in /usr serves as an OS-default fallback to the per-system (or per-instance) configuration and state in /etc and /var.
It is a different way of looking at things, for sure, but I can definitely see a server use-case for this sort of thing, especially since there is significant budget pressure to reduce power costs.
And dynamic spinup of servers to handle increased load is a use case for systemd's rapid bootup. They go hand-in-hand.
The Unix philosophy unfortunately sometimes misses the forest for all of the trees. Sometimes tools need to actually be designed to work together, and sometimes a Swiss Army Knife is the right thing to have.
(And I'm an old Unix hack, too, having used Unix of several flavors since before Linux was even a gleam in Linus' eyes).
On Tue, Jul 8, 2014 at 10:58 AM, Lamar Owen lowen@pari.edu wrote:
And dynamic spinup of servers to handle increased load is a use case for systemd's rapid bootup. They go hand-in-hand.
Don't know about your servers, but ours take much, much longer for their boot-time memory and hardware tests and initialization than anything the old style sysvinit scripts do.
On 07/08/2014 12:06 PM, Les Mikesell wrote:
Don't know about your servers, but ours take much, much longer for their boot-time memory and hardware tests and initialization than anything the old style sysvinit scripts do.
Physical servers can be told to skip certain parts of their POST, especially the memory test. Memory tests are redundant with ECC. (I know; I have an older SuperMicro server here that passes memory testing in POST but throws nearly continuous ECC errors in operation; it does operate, though). If it fails during spinup, flag the failure while spinning up another server.
Virtual servers have no need of POST (they also don't save as much power; although dynamic load balancing can do some predictive heuristics and spin up host hypervisors as needed and do live migration of server processes dynamically).
To detect failures early, spin up every server in a rotating sequence with a testing instance, and skip POST entirely.
If you have to, spin up the server in a stateless mode and put it to sleep. Then wake it up with dynamic state.
There are alot of possibilities here, if you're willing to think outside the 1970's timesharing minicomputer box that gave rise to the historical Unix philosophy. And this has nothing to do with Windows; I have been a primarily-Linux user since 1997.
Long POSTs need to go away, with better fault tolerance after spinup being far more desirable, much like the promise of the old as dirt Tandem NonStop system. (I say the 'promise' rather than the 'implementation' for a reason.....).
Lamar Owen wrote:
On 07/08/2014 12:06 PM, Les Mikesell wrote:
<snip>
There are alot of possibilities here, if you're willing to think outside the 1970's timesharing minicomputer box that gave rise to the historical Unix philosophy. And this has nothing to do with Windows; I have been a primarily-Linux user since 1997.
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
mark
On 07/08/2014 01:19 PM, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/08/2014 12:06 PM, Les Mikesell wrote:
<snip> > There are alot of possibilities here, if you're willing to think outside > the 1970's timesharing minicomputer box that gave rise to the historical > Unix philosophy. And this has nothing to do with Windows; I have been a > primarily-Linux user since 1997. ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
Yes I can. I did/do both. There are many things I do not like about 'cloud' and the security ones are going to be tough nuts to work out. But it is the way computing is dividing up. I like the isolation of ownership and risks that 'cloud' enables.
I did time-sharing on a MARK-IV. I don't miss it.
On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
Those were the days.
On 07/08/2014 10:36 AM, Always Learning wrote:
On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
Those were the days.
110 and 300 Bps. (model 35 and 33)
75 and 50 Baud was 5 level code (model 15, 19, 28 and 32)
There was never a 1200 Bps gearset
I'm an ex teletype mechanic.... Springs, levers, cams and electromagnets. That was my door to telecom and ultimately to computers.
I personally used a 'portable' 300-baud TI Silent 700 which printed on thermal paper and had an acoustic coupler on the side of it for those old phone handsets with the two circular cups. We dialed in and waited with great anticipation to see the next word coming from the remote machine. You also quickly learned what Ctrl-R was for due to the delete key didn't work very well once the typed character was printed on thermal paper. Yes, 300 and 1200 baud were slow and taught us something about patience.
Original Message From: Bruce Ferrell Sent: Tuesday, July 8, 2014 12:57 PM To: centos@centos.org Reply To: CentOS mailing list Subject: Re: [CentOS] Cemtos 7 : Systemd alternatives ?
On 07/08/2014 10:36 AM, Always Learning wrote:
On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
Those were the days.
110 and 300 Bps. (model 35 and 33)
75 and 50 Baud was 5 level code (model 15, 19, 28 and 32)
There was never a 1200 Bps gearset
I'm an ex teletype mechanic.... Springs, levers, cams and electromagnets. That was my door to telecom and ultimately to computers.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/8/2014 11:13 AM, Richard Pierce wrote:
I personally used a 'portable' 300-baud TI Silent 700 which printed on thermal paper and had an acoustic coupler on the side of it for those old phone handsets with the two circular cups. We dialed in and waited with great anticipation to see the next word coming from the remote machine. You also quickly learned what Ctrl-R was for due to the delete key didn't work very well once the typed character was printed on thermal paper. Yes, 300 and 1200 baud were slow and taught us something about patience.
in college (early 1970s) my roommate had a GE Terminet 1200 which was a 120cps printer with plain paper and a ribbon, and an integral acoustic coupler. this was lightyears--er--12X faster than the defacto Teletype stuff most folks had. But, until circa 1980, most of my actual work was with punchcards and/or (later) direct connect VDTs at 9600 baud. I do still have a USR Courier 2400E somewhere in storage, which was a 2400 baud modem that had data compression and could send plain ascii at about 9600 bps, along with a couple Racal Vadic 9600-ish modems.
John R Pierce wrote:
On 7/8/2014 11:13 AM, Richard Pierce wrote:
<snip>
stuff most folks had. But, until circa 1980, most of my actual work was with punchcards and/or (later) direct connect VDTs at 9600 baud. I do still have a USR Courier 2400E somewhere in storage, which was a 2400 baud modem that had data compression and could send plain ascii at about 9600 bps, along with a couple Racal Vadic 9600-ish modems.
I think I still have my 56k modem. Unfortunately, I also think it's ISA....
mark
Always Learning wrote:
On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
Those were the days.
I was dialing in from work to upload homework at 300 baud, around '84. When I got my first modem for my first real PC (we'll skip the CoCo), *I* had 1200 baud. *nyah*
But between 1978, when I went back to college, and '81 or os, a year into my first programming job, I was on punch cards; then it was the shared three terminals in the hall. Originally, a 370-168 timeshare, then, after we won the lottery to get it nine months before most everyone, we had our 4300. And we had *real* line printers.....
But I say there *ain't* no differmenints. You'se is gots your share, we had VM regions.....
On 07/08/2014 01:56 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
Those were the days.
I was dialing in from work to upload homework at 300 baud, around '84. When I got my first modem for my first real PC (we'll skip the CoCo), *I* had 1200 baud. *nyah*
You were late to 1200 baud. I got one of the first Anderson/Jacobson accoustic boxes (before they invented the accoustic coupler). First at 300 baud, then 1200 baud on a DEC Writer II. It was '83. Then Bell head said I would never get 300 baud working on a non-conditioned line...
But again that is the point. We have moved on from there. We got the memories, so we know the edge cases. Like dealing with X.75 gateways...
But between 1978, when I went back to college, and '81 or os, a year into my first programming job, I was on punch cards; then it was the shared three terminals in the hall. Originally, a 370-168 timeshare, then, after we won the lottery to get it nine months before most everyone, we had our 4300. And we had *real* line printers.....
But I say there *ain't* no differmenints. You'se is gots your share, we had VM regions.....
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/8/2014 10:36 AM, Always Learning wrote:
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)
On Tue, 2014-07-08 at 11:10 -0700, John R Pierce wrote:
On 7/8/2014 10:36 AM, Always Learning wrote:
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)
110 baud definitely rings a bell. I saw my first Teletype in 1967/1968 at Scotland's National Engineering Laboratory (NEL). Chugging away, it seemed to be an exciting example of "real" computing - and it wasn't a bit like punched cards.
Always Learning wrote:
On Tue, 2014-07-08 at 11:10 -0700, John R Pierce wrote:
On 7/8/2014 10:36 AM, Always Learning wrote:
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)
110 baud definitely rings a bell. I saw my first Teletype in 1967/1968 at Scotland's National Engineering Laboratory (NEL). Chugging away, it seemed to be an exciting example of "real" computing - and it wasn't a bit like punched cards.
'Ey! What'cho got 'gainst punch cards?
mark "except the card punch in the lab that punched *other* than what it printed, that once...."
On Tue, 2014-07-08 at 16:32 -0400, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
Never used the Power Samas 36? column cards, just the plain boring 80's.
Was an excellent hand puncher. Could easily read cards by holding them up to the light and could fill-in the wrongly punched hole to avoid having to re-punch the entire card.
H-1250, H-120, H-L61, H-L66, H-L64, DPS 8 etc. + BBC Micro B & B+
Always Learning wrote:
On Tue, 2014-07-08 at 16:32 -0400, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
Never used the Power Samas 36? column cards, just the plain boring 80's.
Nope, just the normal 80 column punchs. All IBM, y'know.
Was an excellent hand puncher. Could easily read cards by holding them up to the light and could fill-in the wrongly punched hole to avoid having to re-punch the entire card.
Never heard of a hand puncher. All I ever used or saw were desk-sized machines.
H-1250, H-120, H-L61, H-L66, H-L64, DPS 8 etc. + BBC Micro B & B+
To catch that error, it took the lab assistant, the *only* time in my school career I needed one, to read the actual holes.
Nasty.
mark
On 07/08/2014 04:51 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Tue, 2014-07-08 at 16:32 -0400, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
Never used the Power Samas 36? column cards, just the plain boring 80's.
Nope, just the normal 80 column punchs. All IBM, y'know.
Was an excellent hand puncher. Could easily read cards by holding them up to the light and could fill-in the wrongly punched hole to avoid having to re-punch the entire card.
Never heard of a hand puncher. All I ever used or saw were desk-sized machines.
The read up on Grace Hopper and how she 'discovered' an unknown opcode when a mispunch she glued in with nail polish. They used hand punchers a lot on her programming team.
H-1250, H-120, H-L61, H-L66, H-L64, DPS 8 etc. + BBC Micro B & B+
To catch that error, it took the lab assistant, the *only* time in my school career I needed one, to read the actual holes.
Nasty.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2014-07-08 at 17:10 -0400, Robert Moskowitz wrote:
The read up on Grace Hopper and how she 'discovered' an unknown opcode when a mispunch she glued in with nail polish. They used hand punchers a lot on her programming team.
Not entirely unknown because the opcode must have been known to the technicians or computer designers but not actually documented for the programmers.
40 used to be NOP (no op) on Honeywells H-200 series.
And IBM assembler
(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)
On Jul 8, 2014, at 4:36 PM, Always Learning centos@u62.u22.net wrote:
On Tue, 2014-07-08 at 17:10 -0400, Robert Moskowitz wrote:
The read up on Grace Hopper and how she 'discovered' an unknown opcode when a mispunch she glued in with nail polish. They used hand punchers a lot on her programming team.
Not entirely unknown because the opcode must have been known to the technicians or computer designers but not actually documented for the programmers.
40 used to be NOP (no op) on Honeywells H-200 series.
-- Regards,
Paul. England, EU.
Centos, Exim, Apache, Libre Office. Linux is the future. Micro$oft is the past.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/08/14 21:45, Hal Wigoda wrote:
On Jul 8, 2014, at 4:36 PM, Always Learning centos@u62.u22.net wrote:
On Tue, 2014-07-08 at 17:10 -0400, Robert Moskowitz wrote:
The read up on Grace Hopper and how she 'discovered' an unknown opcode when a mispunch she glued in with nail polish. They used hand punchers a lot on her programming team.
Not entirely unknown because the opcode must have been known to the technicians or computer designers but not actually documented for the programmers.
40 used to be NOP (no op) on Honeywells H-200 series.
And IBM assembler
(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)
Anyone want to borrow my IBM assembly text from college? I will say, though, that if I could have gotten the republication rights, I'd have put all manufacturers of sleeping pills out of business....
mark
On Tue, 2014-07-08 at 16:51 -0400, m.roth@5-cent.us wrote:
Always Learning wrote:
Was an excellent hand puncher. Could easily read cards by holding them up to the light and could fill-in the wrongly punched hole to avoid having to re-punch the entire card.
Never heard of a hand puncher. All I ever used or saw were desk-sized machines.
The machines could be programmed by punching the programme onto another same-sized punch card which fitted around a small circular drum. Girls punched and verified my coding sheets and managed to insert more errors into my coding that I had written. Never understood how they managed to verify their own punching errors.
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
-- Arun Khan
On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
5 hole or 7 hole ?
On 07/10/14 06:42, Always Learning wrote:
On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
5 hole or 7 hole ?
Sorry, but when I hear that, I think of what my first wife used as the typesetter for an underground newspaper....
mark
On 07/10/2014 07:55 AM, mark wrote:
On 07/10/14 06:42, Always Learning wrote:
On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
5 hole or 7 hole ?
Sorry, but when I hear that, I think of what my first wife used as the typesetter for an underground newspaper....
I assume it was not a linotypewriter that put out lead letters ready for the printing presses?
My uncle worked for the Cleveland Press as a typesetter.
Robert Moskowitz wrote:
On 07/10/2014 07:55 AM, mark wrote:
On 07/10/14 06:42, Always Learning wrote:
On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
5 hole or 7 hole ?
Sorry, but when I hear that, I think of what my first wife used as the typesetter for an underground newspaper....
I assume it was not a linotypewriter that put out lead letters ready for the printing presses?
My uncle worked for the Cleveland Press as a typesetter.
They just had one office suite. She'd type the tape, and that would be sent off to the printers.
mark "we won't talk about the month I punch Addressograph plates...."
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
mark
On Thu, 2014-07-10 at 12:47 -0400, m.roth@5-cent.us wrote:
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
Saw the plates being used to emboss invoices. Power Sumas cards then produced the invoice details. Then along came a Honeywell 1250, a punch room, coding sheets, masses and masses of punched cards, manual hand punches, electric punching machines and verifiers and even an electric portable verifier too. Only had to wait for about 60 to 90 minutes for the results of a Cobol programme, meanwhile nothing else ran.
Wish I had photographed everything then.
On 07/10/2014 12:47 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
But the Linotype melted the lead and you pressed which key you wanted the lead to flow into. Kind of. It was cool to see that bar of lead slowly get lowered into the melting pot and finally out the other side came the lead on steel printing plate. Though one I saw only made rows of text that then had to be lined up on the steel plate. I guess it was for allowing inclusion of pictures and such.
Ah how xerography changed things.
And that is again the point. We do things one way because with a big enough hammer we can get it to work. Then new ways and new goals come along and the old stuff heads off for the big melting pot in the backyard.
Robert Moskowitz wrote:
On 07/10/2014 12:47 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
But the Linotype melted the lead and you pressed which key you wanted the lead to flow into. Kind of. It was cool to see that bar of lead slowly get lowered into the melting pot and finally out the other side came the lead on steel printing plate. Though one I saw only made rows of text that then had to be lined up on the steel plate. I guess it was for allowing inclusion of pictures and such.
Ah how xerography changed things.
And that is again the point. We do things one way because with a big enough hammer we can get it to work. Then new ways and new goals come along and the old stuff heads off for the big melting pot in the backyard.
But with a good hammer, you can force the lead into the new plates without melting....
mark (who's taken at least part of this offlist)
On Thu, Jul 10, 2014 at 12:47 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
Any picts or videos? I am just picturing a room with those thingies and a couple of Jacob's latters and a Van der Graff while on the background a table with a covered body is being slowly raised to the roof.
"No, not the third switch!"
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thu, 2014-07-10 at 14:48 -0400, Mauricio Tavares wrote:
On Thu, Jul 10, 2014 at 12:47 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
Any picts or videos? I am just picturing a room with those
thingies and a couple of Jacob's latters and a Van der Graff while on the background a table with a covered body is being slowly raised to the roof.
"No, not the third switch!"
Sorry mate. The programmers were all busy sitting around the table in the engineers' room playing Bridge (a card game) :-)
On 07/10/2014 07:17 PM, Always Learning wrote:
On Thu, 2014-07-10 at 14:48 -0400, Mauricio Tavares wrote:
On Thu, Jul 10, 2014 at 12:47 PM, m.roth@5-cent.us wrote:
Always Learning wrote:
On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:
mark "we won't talk about the month I punch Addressograph
plates...."
Addressograph plates? That is really ancient ! but they were incredible useful in those days.
Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM
Any picts or videos? I am just picturing a room with those
thingies and a couple of Jacob's latters and a Van der Graff while on the background a table with a covered body is being slowly raised to the roof.
"No, not the third switch!"
Sorry mate. The programmers were all busy sitting around the table in the engineers' room playing Bridge (a card game) :-)
Uker when we only had a short break. Pinochle when we had more time.
$1 a hand.
On 07/10/2014 06:42 AM, Always Learning wrote:
On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
5 hole or 7 hole ?
5 of course. Whatever do you need 7 for? What is the shift up and shift down for anyway?
BAUDOT beats ASCII and especially UNICODE any day. :)
Robert Moskowitz wrote:
On 07/10/2014 06:42 AM, Always Learning wrote:
On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:
On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:
'Ey! What'cho got 'gainst punch cards?
and let's not forget the punched tapes :)
5 hole or 7 hole ?
5 of course. Whatever do you need 7 for? What is the shift up and shift down for anyway?
BAUDOT beats ASCII and especially UNICODE any day. :)
But you're alleging that UNICODE is better than, say, EBCDIC?
mark, who was amused and annoyed by the Y2K ignorance
PS: Why, yes, I *did* start and work for years on mainframes.
On 07/08/2014 04:28 PM, Always Learning wrote:
On Tue, 2014-07-08 at 11:10 -0700, John R Pierce wrote:
On 7/8/2014 10:36 AM, Always Learning wrote:
75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).
Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.
actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)
110 baud definitely rings a bell. I saw my first Teletype in 1967/1968 at Scotland's National Engineering Laboratory (NEL). Chugging away, it seemed to be an exciting example of "real" computing - and it wasn't a bit like punched cards.
No. It was paper tape. And on a PDP8 I had access to in '67, it had a high speed paper tape reader to load the 'OS' and FORTRAN system. In 4K of memory.
The invention of the 8" diskette as the boot media for the 360 was a serious step forward. Also right around that time.
On 7/8/2014 2:07 PM, Robert Moskowitz wrote:
The invention of the 8" diskette as the boot media for the 360
370, not 360. the 360's had microcode in "ROM", one of the innovations of the System/370 was soft loaded microcode.
On 07/08/2014 07:11 PM, John R Pierce wrote:
On 7/8/2014 2:07 PM, Robert Moskowitz wrote:
The invention of the 8" diskette as the boot media for the 360
370, not 360. the 360's had microcode in "ROM", one of the innovations of the System/370 was soft loaded microcode.
Yeah. I thought about it a bit and did not feel right with the timeline. It would have to have been just before the 370. Makes more sense it was the 370. I ran with the BUNCH back then. IBM stuff was to be generally ignored...
On Tue, Jul 08, 2014 at 01:19:58PM -0400, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/08/2014 12:06 PM, Les Mikesell wrote:
<snip> > There are alot of possibilities here, if you're willing to think outside > the 1970's timesharing minicomputer box that gave rise to the historical > Unix philosophy. And this has nothing to do with Windows; I have been a > primarily-Linux user since 1997.
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
mark
Mainframes are housed in vaults with powerful airconditioners; operators walk around with 132-column fanfold printouts. Operators may have goatees.
Clouds are housed in vaults with powerful airconditioners; operators walk around with little gadgets. Operators may have goatees.
Dave
On Jul 8, 2014 1:48 PM, "Original Woodchuck" marmota@embarqmail.com wrote:
On Tue, Jul 08, 2014 at 01:19:58PM -0400, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/08/2014 12:06 PM, Les Mikesell wrote:
<snip> > There are alot of possibilities here, if you're willing to think
outside
the 1970's timesharing minicomputer box that gave rise to the
historical
Unix philosophy. And this has nothing to do with Windows; I have
been a
primarily-Linux user since 1997.
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
mark
Mainframes are housed in vaults with powerful airconditioners; operators walk around with 132-column fanfold printouts. Operators may have goatees.
Clouds are housed in vaults with powerful airconditioners; operators walk around with little gadgets. Operators may have goatees.
They prefer to be called chinbeards. ;)
Dave _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Mauricio Tavares wrote:
On Jul 8, 2014 1:48 PM, "Original Woodchuck" marmota@embarqmail.com wrote:
On Tue, Jul 08, 2014 at 01:19:58PM -0400, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/08/2014 12:06 PM, Les Mikesell wrote:
<snip> > There are alot of possibilities here, if you're willing to think outside the 1970's timesharing minicomputer box that gave rise to the historical Unix philosophy. And this has nothing to do with Windows; I have been a primarily-Linux user since 1997.
ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?
Mainframes are housed in vaults with powerful airconditioners; operators walk around with 132-column fanfold printouts. Operators may have goatees.
Clouds are housed in vaults with powerful airconditioners; operators walk around with little gadgets. Operators may have goatees.
They prefer to be called chinbeards. ;)
Right. Illiterate. And they're not cool enough to wear berets, like the gotee-wearers, back in the day....
mark
On 07/08/2014 01:19 PM, m.roth@5-cent.us wrote:
And can you explain the difference between "cloud" and "time-sharing on a mainframe"
Sure.
"Cloud" is much more dynamic, for better or for worse, than mainframes in ye olde days. Cloud takes advantage on smart clients, and, well, is a bit of a nebulous terms covering many things traditional servers do, but with more of an emphasis on dynamic load balancing. Ideally, if no one is using a server that server should not be running, as it is wasting power. The challenge is to get servers up with low latency. And when I say 'servers' that includes physical iron as well as fully virtualized hardware and more fluid virtual containers that just sortof act like a server.
It's all about getting the necessary services to the client processes, regardless of whether the client is smart or dumb.
And ideal application for cloud-based technology is renderfarms; transparent spinup and spindown of render machines, which often contain very power-hungry GPUs, saves lots of money.
As much as it is going to rub sysadmins the wrong way (because the very comfortable and flexible SA hat is one I wear often it definitely rubs me a bit wrong), ideally the admin should spend time on setup and implementation more than operation; the operation of this dynamic spinup and spindown of resources, once set up by a competent admin, should be entirely user-driven and automated.
Ye Olde Mainframes (not the more modern stuff, which *is* more cloud-oriented) never did this and required monstrous opex for personnel. Cloud is about reducing opex, pure and simple. Setup can be capex, and thus a separate budget (at least here, once again wearing the way too stiff CIO hat).
Robert mentions security, and that is a very very true statement, and is where it is incumbent upon the admin who sets it up to be competent.
On 7/8/2014 9:25 AM, Lamar Owen wrote:
Physical servers can be told to skip certain parts of their POST, especially the memory test. Memory tests are redundant with ECC.
but, you HAVE to zero ALL of memory with ECC to initialize it.
On 07/08/2014 01:22 PM, John R Pierce wrote:
On 7/8/2014 9:25 AM, Lamar Owen wrote:
Physical servers can be told to skip certain parts of their POST, especially the memory test. Memory tests are redundant with ECC.
but, you HAVE to zero ALL of memory with ECC to initialize it.
True enough; but this shouldn't take five minutes on a server with multiple GB/s memory bandwidth. My Dell 6950's take a full five minutes to POST, and that's ridiculous. There's eight cores; each core has enough bandwidth to its local RAM (NUMA, of course) where it should be able to sustain 2GB/s zeroing without a lot of trouble; that's a rate of 16GB/s aggregate, and my 32GB of RAM should be zeroed in 2 seconds or so. Not five minutes.
It's still not as bad as our Sun Enterprise 6500 with 18GB, though, which takes about a minute per GB, which is also ridiculous (it's also NUMA, and the Sun firmware does start up each CPU to test it's own local RAM blocks).
On 7/9/2014 8:34 AM, Lamar Owen wrote:
True enough; but this shouldn't take five minutes on a server with multiple GB/s memory bandwidth. My Dell 6950's take a full five minutes to POST, and that's ridiculous. There's eight cores; each core has enough bandwidth to its local RAM (NUMA, of course) where it should be able to sustain 2GB/s zeroing without a lot of trouble; that's a rate of 16GB/s aggregate, and my 32GB of RAM should be zeroed in 2 seconds or so. Not five minutes.
i find the biggest part of server POST is all the storage and network adapter bios's need to get in there, scan the storage busses, enumerate raids, initialize intel boot agents, and so forth.
On 07/09/2014 01:00 PM, John R Pierce wrote:
i find the biggest part of server POST is all the storage and network adapter bios's need to get in there, scan the storage busses, enumerate raids, initialize intel boot agents, and so forth.
I've found that disabling all but the boot device's BIOS works wonders and makes installs far happier, with the exception of real hardware RAID cards. The Linux kernel is quite happy doing any and all fibre-channel enumeration with the HBA's BIOS turned off. (All my large storage is FC and iSCSI SAN). And the 'Intel boot agent' only lives long enough to PXE boot if I need that. The 3Ware 9500's I have typically take a bit longer and require the BIOS, though, but with a small array that's a few tens of seconds, a minute tops. That's one advantage of the Linux mdraid......
But our 6950's spend five minutes only on the memory test; that's not counting the Dell PERC boot device enumeration and drive spinup.
The fastest booting servers I have are our two pfSense firewalls; I've trimmed the BIOS setup to the bone and those boxes reboot in a few tens of seconds. (Yeah, I count a firewall as a server, since it's running on server hardware (Intel 5000X-based quad core dual Xeons with 4GB of RAM each; does wire-speed with > one million pf table entries on a 1Gb/s WAN link) and providing an essential network service to the rest of the hosts on the network).
But, point taken, since there's more to a POST than just the memory test.
Lamar Owen wrote:
On 07/09/2014 01:00 PM, John R Pierce wrote:
i find the biggest part of server POST is all the storage and network adapter bios's need to get in there, scan the storage busses, enumerate raids, initialize intel boot agents, and so forth.
I've found that disabling all but the boot device's BIOS works wonders and makes installs far happier, with the exception of real hardware RAID cards. The Linux kernel is quite happy doing any and all fibre-channel
<snip> To me, what takes the most time on POST, far and away, is memory. We had a box - Dell, I *think*, but it might have been a Penguin (Supermicro) that took close to 20 min, before we turned off the memory check (well, yes, 256GB RAM)....
What I wish didn't take so long is the raid-45? driver, which seems to take forever, and always has.
mark
On Tue, Jul 8, 2014 at 11:25 AM, Lamar Owen lowen@pari.edu wrote:
Memory tests are redundant with ECC. (I know; I have an older SuperMicro server here that passes memory testing in POST but throws nearly continuous ECC errors in operation; it does operate, though). If it fails during spinup, flag the failure while spinning up another server.
I don't think that is generally true. I've seen several IBM systems disable memory during POST and come up running will a smaller amount.
Virtual servers have no need of POST (they also don't save as much power; although dynamic load balancing can do some predictive heuristics and spin up host hypervisors as needed and do live migration of server processes dynamically).
Our services that need scaling need all of the hardware capability and aren't virtualized. That might change someday...
To detect failures early, spin up every server in a rotating sequence with a testing instance, and skip POST entirely.
If you have to, spin up the server in a stateless mode and put it to sleep. Then wake it up with dynamic state.
Our servers tend to just run till they die. If we didn't need them we wouldn't have bought them in the first place. I suppose there are businesses with different processes that come and go, but I'm not sure that is desirable.
Long POSTs need to go away, with better fault tolerance after spinup being far more desirable, much like the promise of the old as dirt Tandem NonStop system. (I say the 'promise' rather than the 'implementation' for a reason.....).
If you need load balancing anyway you just run enough spares to cover the failures.
On 07/08/2014 01:27 PM, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 11:25 AM, Lamar Owen lowen@pari.edu wrote:
Memory tests are redundant with ECC. (I know; I have an older SuperMicro server here that passes memory testing in POST but throws nearly continuous ECC errors in operation; it does operate, though). If it fails during spinup, flag the failure while spinning up another server.
I don't think that is generally true. I've seen several IBM systems disable memory during POST and come up running will a smaller amount.
Yes, and I have a few Dells that do that as well. Unfortunately most OS's aren't 'hotplug/unplug' for RAM, which would alleviate the need to tag it out during POST. But perhaps some of today's and yesterday's hardware just isn't up to the task of reliable rapid power on. So perhaps I should have written 'Memory tests should be redundant with ECC.'
Our servers tend to just run till they die. If we didn't need them we wouldn't have bought them in the first place. I suppose there are businesses with different processes that come and go, but I'm not sure that is desirable.
Our load graphs here are very spurty, with the spurts going very high during certain image reduction processes.
It is to the point where I could probably save money by putting a few of the more power hungry systems that have spurty loads on a timed sleep basis, which WoL bringing them back up prior to the next day's batch. But that's an ad hoc solution, and I really don't like ad hoc solutions when infrastructure ones are available and better tested.
If you need load balancing anyway you just run enough spares to cover the failures.
And pay the power bill for them
Les Mikesell wrote:
On Tue, Jul 8, 2014 at 10:58 AM, Lamar Owen lowen@pari.edu wrote:
And dynamic spinup of servers to handle increased load is a use case for systemd's rapid bootup. They go hand-in-hand.
Don't know about your servers, but ours take much, much longer for their boot-time memory and hardware tests and initialization than anything the old style sysvinit scripts do.
Ours would, but we disabled the POST-time memory checks on most. When you've got upwards of 64GB, it starts to take a while... and for 256G... let's not go there, unless you've got 15 min.
mark
On 07/07/2014 08:46 PM, Robert Moskowitz wrote:
On 07/07/2014 07:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
So you are following the thread on the Fedora list? I have been ignoring it.
Best I can tell is learn it and use it. And if you have any services, fix them so that they work with systemd. I work with one that does not and it is very slow to complete its startup.
As far as I know there is no going back to SystemV at this point and I am fine with that.
systemd is just fine. It has been around on Fedora for a few releases now. It is quite compatible with old SystemV start scripts and systemd simply uses the SystemV start scripts as configuration files to start those services.
What you are probably seeing is the result of a side effect of the new systemd strategy. systemd only starts services when they are actually needed. systemd does this by simply creating a socket on which it listens for requests for that service. The service is only started when a request is made to that socket. Of course some services are up and running from the beginning, but those not needed are left to load and start when a request is made on the socket for that service. So the delay in starting your SystemV service means that your service is waiting for a reply from a service on which it depends and which has not yet been started. systemd receives the request from your service on the socket intended for the service yours is requesting. systemd then starts that service and returns the result - after a bit of a delay - to your SystemV service. After the first request to the systemd managed service, there should be no further delays. Unless the service is seldom used and systemd determines it can remove the service from memory with minimal impact.
I like systemd a lot. I still like SystemV a lot, too.
I have a page on one of my web sites that does not explain systemd, but rather provides a number of very good links that do explain it - in morbid detail. These links also discuss the philosophy behind the change. Good reading!
http://www.databook.bz/?page_id=2578
The latest Fedora documentation has good information about using systemd to manage services and managing and configuring systemd itself.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--
David P. Both, RHCE Millennium Technology Consulting LLC 919-389-8678
dboth@millennium-technology.com
www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both
This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately.
On Tue, Jul 08, 2014 at 12:47:38AM +0100, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd
To the tune of YMCA
Young man, you don't like systemd Oh young man, you get no sympathy Young man, you will find that your luck Is slowly running out with Linux
So young man, if you want to stick To something, that more resembles Unix And young man, if you want to sing Goodbye to Poettering,
(bah bah bah bah)
FreeeeeeeeeBSD (yeah yeah yeah) FreeeeeeeeeBSD
etc. I just made this up at work today, and that's as far as I got.
On Mon, 2014-07-07 at 20:59 -0400, Scott Robbins wrote:
On Tue, Jul 08, 2014 at 12:47:38AM +0100, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd
To the tune of YMCA
Young man, you don't like systemd Oh young man, you get no sympathy Young man, you will find that your luck Is slowly running out with Linux
So young man, if you want to stick To something, that more resembles Unix And young man, if you want to sing Goodbye to Poettering,
(bah bah bah bah)
FreeeeeeeeeBSD (yeah yeah yeah) FreeeeeeeeeBSD
etc. I just made this up at work today, and that's as far as I got.
Ah, a Broadway musical next ? :-)
I'm an old man who remembers multics, GECOS/GCOS and the 'B' programming language.
Is FeeBSD systemd-less ? Got a FreeBSD manual.
On Tue, Jul 08, 2014 at 02:26:59AM +0100, Always Learning wrote:
On Mon, 2014-07-07 at 20:59 -0400, Scott Robbins wrote:
To the tune of YMCA
So young man, if you want to stick To something, that more resembles Unix And young man, if you want to sing Goodbye to Poettering,
(bah bah bah bah)
FreeeeeeeeeBSD (yeah yeah yeah) FreeeeeeeeeBSD
etc. I just made this up at work today, and that's as far as I got.
Ah, a Broadway musical next ? :-)
I'm an old man who remembers multics, GECOS/GCOS and the 'B' programming language.
Is FeeBSD systemd-less ? Got a FreeBSD manual.
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
On Mon, 2014-07-07 at 21:34 -0400, Scott Robbins wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
Thanks. I've deployed C 5.10 and C 6.5. Thought I'll play with C 7.
I notice, from http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7, the apparent replacement of IPtables by firewalld
https://fedoraproject.org/wiki/FirewallD
On 07/08/2014 03:41 AM, Always Learning wrote:
On Mon, 2014-07-07 at 21:34 -0400, Scott Robbins wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
Thanks. I've deployed C 5.10 and C 6.5. Thought I'll play with C 7.
I notice, from http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7, the apparent replacement of IPtables by firewalld
Check "Static_Firewall" Chapter: https://fedoraproject.org/wiki/FirewallD#Static_Firewall_.28system-config-fi...
and one below it. You can have iptables rules and also rules from system-config-firewall
On 08.07.2014 09:12, Ljubomir Ljubojevic wrote:
On 07/08/2014 03:41 AM, Always Learning wrote:
On Mon, 2014-07-07 at 21:34 -0400, Scott Robbins wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
Thanks. I've deployed C 5.10 and C 6.5. Thought I'll play with C 7.
I notice, from http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7, the apparent replacement of IPtables by firewalld
Check "Static_Firewall" Chapter: https://fedoraproject.org/wiki/FirewallD#Static_Firewall_.28system-config-fi...
and one below it. You can have iptables rules and also rules from system-config-firewall
If you want to avoid firewalld for now you can uninstall it and instead install the iptables-services package. This replaces the old init scripts and provides an "iptables" systemd unit file that starts and stops iptables and if you require the old "service iptables save" command you can reach that using "/usr/libexec/iptables/iptables.init".
Also if you want to keep NetworkManager on a Server you can install the NetworkManager-config-server package. This only contains a config chunk with two settings: no-auto-default=* ignore-carrier=*
With this package installed you get a more traditional handling of the network. Interfaces don't get shutdown when the cable is pulled, no automatic configuration of unconfigured interfaces and no automatic reload of configuration files (the last one doesn't require the package and is now the NetworkManager default behaviour).
Regards, Dennis
I still prefer IPTables, so in Fedora I simply disabled firewalld and enabled IPTables. No need to uninstall. I have read that IPTables will continue to be available alongside firewalld for the unspecified future.
Note that IPTables rule syntax and structure have evolved so your ruleset may need to be updated. I did find that the current version of IPTables will actually convert old rulesets on the fly, at least as far as the syntax of the individual rules is concerned. From there you can simply use iptables-save to save the converted ruleset.
One of the items on my tudo list is to learn firewalld. The switch from ipchains took a bit of learning and I expect this switch will as well.
One of the stated reasons for firewalld is that dynamic rule changes do not clear the old rules before loading the new ones, to paraphrase, "where IPTables does." If true, that would leave a very small amount of time in which the host would be vulnerable. I have no desire to peruse the source code to determine the veracity of that statement, so if there is someone here who could verify that changing the rules in IPTables, whether using the iptables command or the iptables-restore command, I would be very appreciative. No need to go to any trouble to locate that answer as I am merely curious.
Thanks!
On 07/08/2014 08:00 AM, Dennis Jacobfeuerborn wrote:
On 08.07.2014 09:12, Ljubomir Ljubojevic wrote:
On 07/08/2014 03:41 AM, Always Learning wrote:
On Mon, 2014-07-07 at 21:34 -0400, Scott Robbins wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
Thanks. I've deployed C 5.10 and C 6.5. Thought I'll play with C 7.
I notice, from http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7, the apparent replacement of IPtables by firewalld
Check "Static_Firewall" Chapter: https://fedoraproject.org/wiki/FirewallD#Static_Firewall_.28system-config-fi...
and one below it. You can have iptables rules and also rules from system-config-firewall
If you want to avoid firewalld for now you can uninstall it and instead install the iptables-services package. This replaces the old init scripts and provides an "iptables" systemd unit file that starts and stops iptables and if you require the old "service iptables save" command you can reach that using "/usr/libexec/iptables/iptables.init".
Also if you want to keep NetworkManager on a Server you can install the NetworkManager-config-server package. This only contains a config chunk with two settings: no-auto-default=* ignore-carrier=*
With this package installed you get a more traditional handling of the network. Interfaces don't get shutdown when the cable is pulled, no automatic configuration of unconfigured interfaces and no automatic reload of configuration files (the last one doesn't require the package and is now the NetworkManager default behaviour).
Regards, Dennis
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--
David P. Both, RHCE Millennium Technology Consulting LLC 919-389-8678
dboth@millennium-technology.com
www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both
This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately.
On 08.07.2014 14:35, David Both wrote:
I still prefer IPTables, so in Fedora I simply disabled firewalld and enabled IPTables. No need to uninstall. I have read that IPTables will continue to be available alongside firewalld for the unspecified future.
Be careful with this though. A while ago I tried this on a system that also had libvirtd running and ran into the problem that libvirt detected the existence of firewalld and as a result tried to use it even though it was disables. It took a while to figure this out once I actually uninstalled firewalld and restarted libvirtd it started to use iptables. This might have been fixed by now but you should keep that in mind when you run into firewall trouble. Some software might mistakenly assume that just because firewalld is present is must also be in active use.
Note that IPTables rule syntax and structure have evolved so your ruleset may need to be updated. I did find that the current version of IPTables will actually convert old rulesets on the fly, at least as far as the syntax of the individual rules is concerned. From there you can simply use iptables-save to save the converted ruleset.
One of the items on my tudo list is to learn firewalld. The switch from ipchains took a bit of learning and I expect this switch will as well.
There was a discussion a while ago on fedora-devel that the current handling of firewalld and zones is not ideal and there might be changes in store for the future. This will probably not hit CentOS 7 but you might to want to keep an ear out in case some deeper structural changes happen. Always good to be ahead of the curve.
One of the stated reasons for firewalld is that dynamic rule changes do not clear the old rules before loading the new ones, to paraphrase, "where IPTables does." If true, that would leave a very small amount of time in which the host would be vulnerable. I have no desire to peruse the source code to determine the veracity of that statement, so if there is someone here who could verify that changing the rules in IPTables, whether using the iptables command or the iptables-restore command, I would be very appreciative. No need to go to any trouble to locate that answer as I am merely curious.
iptables-restore is atomic. It builds completely new tables and then just tells the kernel to switch the old version with the new version. Depending on the timing the packets are either handled by complete old rule set or the complete new rule set. There is never any moment where no rules are applied or only half of the new rules are inserted.
The problem firewalld tries to solve is that nowadays you often want to insert temporary rules that should only be active while a certain application is running. This collides a bit with the way iptables works. For example libvirt inserts specific rules when you define networks for virtualization dynamically. If you now do an iptables-save these rules get saved and on next boot when these rules are restored the exist again but now libvirt will add them dynamically a second time.
Firewalld is simply a framework built around iptables that allows for applications to "register" rules with additional information such as "this rule is a static one" or "this rule should only be used dynamically while application X is running". Then there is of course the handling of zones which is a concept iptables by itself does not know about.
Regards, Dennis
Dennis Jacobfeuerborn wrote:
On 08.07.2014 14:35, David Both wrote:
I still prefer IPTables, so in Fedora I simply disabled firewalld and enabled IPTables. No need to uninstall. I have read that IPTables will continue to be available alongside firewalld for the unspecified future.
<nsip>
One of the stated reasons for firewalld is that dynamic rule changes do not clear the old rules before loading the new ones, to paraphrase, "where IPTables does." If true, that would leave a very small amount of time
in which
the host would be vulnerable. I have no desire to peruse the source
code to
determine the veracity of that statement, so if there is someone here
who could verify that
changing the rules in IPTables, whether using the iptables command or the iptables-restore command, I would be very appreciative. No need to
go to
any trouble to locate that answer as I am merely curious.
<snip>
The problem firewalld tries to solve is that nowadays you often want to insert temporary rules that should only be active while a certain application is running. This collides a bit with the way iptables works. For example libvirt inserts specific rules when you define networks for virtualization dynamically. If you now do an iptables-save these rules get saved and on next boot when these rules are restored the exist again but now libvirt will add them dynamically a second time.
Firewalld is simply a framework built around iptables that allows for applications to "register" rules with additional information such as
<snip> And so nothing like, say, fail2ban....
mark
On 8.7.2014 17:25, m.roth@5-cent.us wrote:
Dennis Jacobfeuerborn wrote:
The problem firewalld tries to solve is that nowadays you often want to insert temporary rules that should only be active while a certain application is running. This collides a bit with the way iptables works. For example libvirt inserts specific rules when you define networks for virtualization dynamically. If you now do an iptables-save these rules get saved and on next boot when these rules are restored the exist again but now libvirt will add them dynamically a second time.
Firewalld is simply a framework built around iptables that allows for applications to "register" rules with additional information such as
And so nothing like, say, fail2ban....
I haven't looked closely on firewalld yet, but in practice it should probably allow making fail2ban functionality more robust and fail2ban like functionality simpler to implement. Especially as I distinctly remember of complaining of problems with fail2ban from Fedora list. (Granted have has very little time lately to read any mailing lists)
-vpk
On Jul 7, 2014, at 6:34 PM, Scott Robbins scottro@nyc.rr.com wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.
And I chose the word "abomination" carefully and deliberately. And I also chose the Biblical allegory very deliberately. Just as the "abomination of desolation" is that which will portend the end of the world, systemd is the "abomination of desolation" that will portend the beginnings of the destruction of the Linux most of us hold dear.
But that's not why I mentioned this... I'd never thought of BSDs before, but considering heartbleed and how OpenBSD forked LibreSSL and is taking security very seriously, it's actually something I am going to give a great deal of consideration to.
I've been a Linux admin for nearly 20 years now - I was around when it was 0.99 and everyone was cheering about it being POSIX finally. Maybe it's just time to move on.
--Russell
On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:
On Jul 7, 2014, at 6:34 PM, Scott Robbins scottro@nyc.rr.com wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.
Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)
Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
On 08.07.2014 13:57, Scott Robbins wrote:
On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:
On Jul 7, 2014, at 6:34 PM, Scott Robbins scottro@nyc.rr.com wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.
Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)
Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
Regards, Dennis
On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
That presumes that your conservative attitude is the majority opinion though.
Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.
Systemd is one of the features that I have been looking forward
to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken.
That's not what I said. I said I wondered if it would. I suspect it won't. Whether this is good or not depends upon one's point of view.
Scott Robbins wrote:
On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
Now that it's insinuated itself in the RHEL system, I do wonder if it
is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
That presumes that your conservative attitude is the majority opinion though.
Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.
<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented Here), and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?
mark
On Tue, Jul 08, 2014 at 10:27:41AM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.
<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented Here), and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person. He was formerly with Mandriva, I think, and came to Fedora where he has made enormous strides in seeing things from the user standpoint, getting bugs filed, making Fedora a much better distribution (and better documented), than it had been. My statement's implication, though of course, tongue in cheek, was that Even Adam thinks....
So, for any friends or fans of Adam on this list, I apologize if that came out as a putdown or anything more than a jesting complaint.
On Tue, Jul 08, 2014 at 12:21:43PM -0400, Scott Robbins wrote:
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person.
I should also add that Adam's comment was very tongue-in-cheek and aimed at people who took it that way. Again, I really apologize for taking that out of context and expecting everyone to somehow magically grasp the context especially as it seems it irked a few people. He was saying it to me and a few others, who he knows, and all fit the description, and it was certainly meant as a joke.
On Tue, 8 Jul 2014, Scott Robbins wrote:
I should also add that Adam's comment was very tongue-in-cheek and aimed at people who took it that way. Again, I really apologize for taking that out of context and expecting everyone to somehow magically grasp the context especially as it seems it irked a few people. He was saying it to me and a few others, who he knows, and all fit the description, and it was certainly meant as a joke.
Thanks for clairfying that, Scott. I retract my comments in my previous post suggesting that if he were serious, it was racist and ageist.
Gilbert
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Jul 8, 2014, at 9:27 AM, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Jul 08, 2014 at 12:21:43PM -0400, Scott Robbins wrote:
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person.
I should also add that Adam's comment was very tongue-in-cheek and aimed at people who took it that way. Again, I really apologize for taking that out of context and expecting everyone to somehow magically grasp the context especially as it seems it irked a few people. He was saying it to me and a few others, who he knows, and all fit the description, and it was certainly meant as a joke.
FWIW I accept your apology. I also would be remiss if I didn't point out that if this is the case, you've done him a huge, huge disservice by spreading a non-contextual insult towards a class of people that he probably actually did say.
Perhaps now he will be more careful with what he says - even amongst friends. Sometimes things said in confidence can come back to bite you.
What he said, even if amongst friends, btw, *is* wrong, and stupid, and should not have been said. But I'm guilty of the same thing, so beam, mote, and all that.
--Russell
On Tue, Jul 08, 2014 at 05:32:31PM -0700, Russell Miller wrote:
On Jul 8, 2014, at 9:27 AM, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Jul 08, 2014 at 12:21:43PM -0400, Scott Robbins wrote:
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person.
I should also add that Adam's comment was very tongue-in-cheek and aimed at people who took it that way. Again, I really apologize for taking that out of context and expecting everyone to somehow magically grasp the context especially as it seems it irked a few people. He was saying it to me and a few others, who he knows, and all fit the description, and it was certainly meant as a joke.
FWIW I accept your apology. I also would be remiss if I didn't point out that if this is the case, you've done him a huge, huge disservice by spreading a non-contextual insult towards a class of people that he probably actually did say.
I agree, and feel badly about it. In fairness to myself, it was made in a public place, but I should have thought about how it would affect people before posting it, and I do regret repeating it, especially since I have the highest esteem for Adam.
On 07/08/2014 12:21 PM, Scott Robbins wrote:
On Tue, Jul 08, 2014 at 10:27:41AM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.
<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented Here), and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person. He was formerly with Mandriva, I think, and came to Fedora where he has made enormous strides in seeing things from the user standpoint, getting bugs filed, making Fedora a much better distribution (and better documented), than it had been. My statement's implication, though of course, tongue in cheek, was that Even Adam thinks....
So, for any friends or fans of Adam on this list, I apologize if that came out as a putdown or anything more than a jesting complaint.
I have also had good interaction with Adam. I never found him getting down on my not being a real admin.
Scott Robbins wrote:
On Tue, Jul 08, 2014 at 10:27:41AM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.
<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented Here), and a faddist.... Did he actually have any *good*, persuasive
reasons
for such changes?
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person. He was formerly with Mandriva, I think, and came to Fedora where he has made enormous strides in seeing things from the user standpoint, getting bugs filed, making Fedora a much better distribution (and better documented), than it had been. My statement's implication, though of course, tongue in cheek, was that Even Adam thinks....
So, for any friends or fans of Adam on this list, I apologize if that came out as a putdown or anything more than a jesting complaint.
The only idea of him I have is from this thread, and I have formed an opinion headed *way* down in a nosedive from "not very high". And I know how other feminists feel when someone makes a sexist comment that they think is a throwaway line... but question where the line came from in their subconscious, and how it affects their attitude to what they're doing.
And to expand on my agreement with Les, sounds like he only talks to other fedora folks... and doesn't get out of his own little circle of admirers.
mark
On Tue, Jul 8, 2014 at 11:21 AM, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Jul 08, 2014 at 10:27:41AM -0400, m.roth@5-cent.us wrote:
Scott Robbins wrote:
On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.
<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented
Here),
and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?
Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person. He was formerly with Mandriva, I think, and came to Fedora where he has made enormous strides in seeing things from the user standpoint, getting bugs filed, making Fedora a much better distribution (and better documented), than it had been. My statement's implication, though of course, tongue in cheek, was that Even Adam thinks....
So, for any friends or fans of Adam on this list, I apologize if that came out as a putdown or anything more than a jesting complaint.
Yeah, tongue in cheek. Uh huh. Sure.
"Disadvantages: people who dislike change are going to hate this one. Note to people who dislike change: you could still remove NetworkManager post-install if you really hate it. Having it in core doesn't preclude that. You could also still exclude it with a kickstart. Makes the minimal install somewhat larger." - Adam Williamson ( https://bugzilla.redhat.com/show_bug.cgi?id=693602#c31)
On 07/08/2014 08:09 AM, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:
On Jul 7, 2014, at 6:34 PM, Scott Robbinsscottro@nyc.rr.com wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.
Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)
Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
Regards, Dennis
My concern it that it is a massive change with a large footprint. How secure is it really? It has arguably become the second kernel it touches and handles so many things.
Maybe on desktops it makes sense - but I fail to see any positives for servers that once started run for months at a time between reboots.
On 08.07.2014 15:22, Steve Clark wrote:
On 07/08/2014 08:09 AM, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:
On Jul 7, 2014, at 6:34 PM, Scott Robbinsscottro@nyc.rr.com wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.
Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)
Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
Regards, Dennis
My concern it that it is a massive change with a large footprint. How secure is it really? It has arguably become the second kernel it touches and handles so many things.
I agree but that is a change that you actively have to opt into though. CentOS 6 will receive updates for many years to come so you don't have to immediately migrate everything over in a rush. Also systemd is hardly new at this point. It has been available for years and had quite some time to mature. Red Hat would not have made it the core of its "Enterprise" OS if it didn't think it would be very reliable.
Maybe on desktops it makes sense - but I fail to see any positives for servers that once started run for months at a time between reboots.
The ability to jail services and restrict it's resources is one big plus for me. Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax. Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.
Its certainly a change one needs to get used to but as mentioned above I don't think its a bad change and you don't have to jump to it immediately if you don't want to.
Regards, Dennis
On 07/08/2014 08:42 AM, Dennis Jacobfeuerborn wrote:
On 08.07.2014 15:22, Steve Clark wrote:
On 07/08/2014 08:09 AM, Dennis Jacobfeuerborn wrote:
On 08.07.2014 13:57, Scott Robbins wrote:
On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:
On Jul 7, 2014, at 6:34 PM, Scott Robbinsscottro@nyc.rr.com wrote:
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.
Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)
Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
Regards, Dennis
My concern it that it is a massive change with a large footprint. How secure is it really? It has arguably become the second kernel it touches and handles so many things.
I agree but that is a change that you actively have to opt into though. CentOS 6 will receive updates for many years to come so you don't have to immediately migrate everything over in a rush. Also systemd is hardly new at this point. It has been available for years and had quite some time to mature. Red Hat would not have made it the core of its "Enterprise" OS if it didn't think it would be very reliable.
Maybe on desktops it makes sense - but I fail to see any positives for servers that once started run for months at a time between reboots.
The ability to jail services and restrict it's resources is one big plus for me. Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax. Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.
And this is indeed the crux of the matter ... systemd is NOT just about booting or boot up time (combing posts here .. but this is the answer to, why use this on a server where fast booting is not important).
Its certainly a change one needs to get used to but as mentioned above I don't think its a bad change and you don't have to jump to it immediately if you don't want to.
And this too .. try it, see if it meets your needs, if it doesn't you still have 6.5 years with CentOS-6.5 support until you have to move.
On Tue, 08 Jul 2014 09:04:59 -0500 Johnny Hughes johnny@centos.org wrote:
And this is indeed the crux of the matter ... systemd is NOT just about booting or boot up time (combing posts here .. but this is the answer to, why use this on a server where fast booting is not important).
Systemd is emacs for booting without extension capabilities - so at least with no clue.
The whole idea is to put stuff into a DSL which can't be formulated with a not turing complete language. To build something, which has nice shortcuts for many things: fine. But that has nothing to do with systemd.
What you could build is a event system with nice hooks to place your code. And you could use that for many things, when it's damn simple and fast.
But systemd is everything but not stupid simple. It's only stupid.
Best Regards Oli
Hi all,
I’ll just say something about all this, I think mostly as a reflection, on my 15 years of Linux and Unix experience, as a user, as a network admin and as an Linux/Unix evangelist and Windows/Microsoft hater on my early years:
Systemd is a totally unnecessary change, it goes totally agains Unix philosophy. But why not? Linux is already changing even POSIX standards by itself, regardless of any other Unix variant out there. Linux already has proprietary firmwares, NDAs, and many other “non free” code/characteristics. Linux is becoming a mess, today you can find software that runs just on specific distributions, Linux is becoming Windows in an awkward bad way, it’s is just not Microsoft, but when using on desktops, it crashes and get slow all the time, truly a Windows characteristic.
Maybe if you use a Hardcore distribution, you can probably get rid of these bugs, some for sure, but any mainstream distribution out there nowadays, it’s a failure on the desktop, never thought I would say that, but besides the know malware base, Windows today is way better on the desktop, it’s is stable, it’s is fast, it’s easy on the user.
On the server side it’s still the best for some applications, mainly because it has more proprietary drivers than any other OpenSource Unix variant, so if you need bleeding edge (or not so new) enterprise class functionality, Linux may be your only choice besides Windows, so, for some applications, not a hard choice to make.
Thankfully there will always be the BSD family, I’m not a big fan of FreeBSD, but for sure it’s very attractive, probably faster on many situations and rock solid. On the security side, for me OpenBSD is still unbeatable for Firewall, VPN and any other application where disk I/O is not an issue, it’s the state of the art of functionality and simplicity, it just works, secure by default, thats it.
So let Linux be Linux, Unix is another story, Linux may have been Unix for some time, Unix will continue to be Unix, and from now on, Linux will continue his evolution towards something new, hope for the better, if not there will always be alternatives ;)
Just to be clear: I mean no flames, just want to share my reflections on the subject, I’m still a faithfully Linux User/Admin.
Fabio Almeida
Em 08/07/2014, à(s) 12:28, Oliver Schad centos@automatic-server.com escreveu:
On Tue, 08 Jul 2014 09:04:59 -0500 Johnny Hughes johnny@centos.org wrote:
And this is indeed the crux of the matter ... systemd is NOT just about booting or boot up time (combing posts here .. but this is the answer to, why use this on a server where fast booting is not important).
Systemd is emacs for booting without extension capabilities - so at least with no clue.
The whole idea is to put stuff into a DSL which can't be formulated with a not turing complete language. To build something, which has nice shortcuts for many things: fine. But that has nothing to do with systemd.
What you could build is a event system with nice hooks to place your code. And you could use that for many things, when it's damn simple and fast.
But systemd is everything but not stupid simple. It's only stupid.
Best Regards Oli _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Jul 8, 2014 at 8:42 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax.
Sorry, but I'd recommend that anyone who thinks shell syntax is 'messy' just stay away from unix-like systems instead of destroying the best parts of them. There is a huge advantage of consistent behavior whether some command is executed interactively on the command line or started automatically by some other means.
Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.
What part of i/o redirection does the shell not handle well for you?
Its certainly a change one needs to get used to but as mentioned above I don't think its a bad change and you don't have to jump to it immediately if you don't want to.
'Immediately' has different meanings to different people. I'd rather see such things discussed in terms of cost of re-implementations. How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)? Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.
On 07/08/2014 11:58 AM, Les Mikesell wrote:
... How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)?
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
Even the Unix philosophy was new at one point. Just because it works doesn't mean it's the best that can be found.
Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.
Consistency is not the only goal. Efficiency should trump consistency, and I for one like being able to see where the direction lies well in advance of EL adopting a feature blind. Or don't you remember how Red Hat Linux development used to be before Fedora and the openness of that process?
(Leaving part of my .sig in for a change, as I'm wearing the CIO hat in this post.)
On Tue, 8 Jul 2014, Lamar Owen wrote:
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
Yes. Look at Microsoft and Windows 8 and a similar attitude of "get over it, and just buy it". I'm not surprised that the head developer was terminated days after its release. Lemmings think jumping off a cliff is a good idea, too. Several designers thinking its a good idea and implementing it across the board does NOT mean it's a good idea to the end user.
Even the Unix philosophy was new at one point. Just because it works doesn't mean it's the best that can be found.
The Unix philosophy is not new, but blossomed after Windows put a stranglehold on everything else.
Consistency is not the only goal. Efficiency should trump consistency,
I am darn sick and tired about hearing of "efficiency". Efficiency does not 100% translate to effective productivity. Furthermore, user satisfaction is not counted into efficiency. I have heard people complain about air conditioners with extremely high efficiencies. The problem is that they don't put out much cold air. If the product is ineffective, very hard to work with, but efficient...I'd far rather use something much less cumbersome and effective but being less efficient. That translates to higher productivity and satisfaction, which you really want. Effectiveness and satisfaction should go hand in hand with efficiency, every time.
(Leaving part of my .sig in for a change, as I'm wearing the CIO hat in this post.)
People will vote with their feet on this. And, that "old white men" are complaining about this is ageist, racist, and demeaning to EVERYONE. I am really disappointed in Red Hat saying this, far more than the whole systemd concerns. As others have stated, change for the sake of change isn't good. Slapping across the face your primary customer base with deep insults isn't good, even if the customers are horribly wrong, which is quite the opposite here. And trying to splash perfume on a steaming dogpile is absurd.
Don't worry, if this attitude continues with Red Hat, I won't let my rear hit the exit on the way out. And I'll do the best sort of advertising for this that I can: tell others the nonsense that is occurring, and to stay far away from it...
Gilbert
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Tue, Jul 8, 2014 at 12:36 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:
On Tue, 8 Jul 2014, Lamar Owen wrote:
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
Yes. Look at Microsoft and Windows 8 and a similar attitude of "get over it, and just buy it". I'm not surprised that the head developer
Apple is guilty of that too.
was terminated days after its release. Lemmings think jumping off a cliff is a good idea, too. Several designers thinking its a good idea and implementing it across the board does NOT mean it's a good idea to the end user.
Even the Unix philosophy was new at one point. Just because it works doesn't mean it's the best that can be found.
The Unix philosophy is not new, but blossomed after Windows put a stranglehold on everything else.
Consistency is not the only goal. Efficiency should trump consistency,
I am darn sick and tired about hearing of "efficiency". Efficiency does not 100% translate to effective productivity. Furthermore, user satisfaction is not counted into efficiency. I have heard people complain about air conditioners with extremely high efficiencies. The problem is that they don't put out much cold air. If the product is ineffective, very hard to work with, but efficient...I'd far rather use something much less cumbersome and effective but being less efficient. That translates to higher productivity and satisfaction, which you really want. Effectiveness and satisfaction should go hand in hand with efficiency, every time.
I think you are making the case for maintainability. Efficiency is in a certain way what brought the Y2K bug. I'll take maintainability over efficiency any day if I can (design constrains) even if I was writing a game.
(Leaving part of my .sig in for a change, as I'm wearing the CIO hat in this post.)
People will vote with their feet on this. And, that "old white men" are complaining about this is ageist, racist, and demeaning to EVERYONE. I am really disappointed in Red Hat saying this, far more than the whole systemd concerns. As others have stated, change for the sake of change isn't good. Slapping across the face your primary customer base with deep insults isn't good, even if the customers are horribly wrong, which is quite the opposite here. And trying to splash perfume on a steaming dogpile is absurd.
Don't worry, if this attitude continues with Red Hat, I won't let my rear hit the exit on the way out. And I'll do the best sort of advertising for this that I can: tell others the nonsense that is occurring, and to stay far away from it...
Gilbert
Gilbert Sebenste ******** (My opinions only!) ******
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/08/2014 12:51 PM, Mauricio Tavares wrote:
On Tue, Jul 8, 2014 at 12:36 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:
On Tue, 8 Jul 2014, Lamar Owen wrote:
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
Yes. Look at Microsoft and Windows 8 and a similar attitude of "get over it, and just buy it". I'm not surprised that the head developer
Apple is guilty of that too.
Consistency is not the only goal. Efficiency should trump consistency,
I am darn sick and tired about hearing of "efficiency". Efficiency does not 100% translate to effective productivity. Furthermore, user satisfaction is not counted into efficiency. I have heard people complain about air conditioners with extremely high efficiencies. The problem is that they don't put out much cold air. If the product is ineffective, very hard to work with, but efficient...I'd far rather use something much less cumbersome and effective but being less efficient. That translates to higher productivity and satisfaction, which you really want. Effectiveness and satisfaction should go hand in hand with efficiency, every time.
I think you are making the case for maintainability. Efficiency
is in a certain way what brought the Y2K bug. I'll take maintainability over efficiency any day if I can (design constrains) even if I was writing a game.
Nope I was there when we did the year 80 conversion going from single digit years to two digit years. We just did not have the capacity and we counted every byte in a record. We did Julian date format on tape and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less. We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.
Things change. Design goals change. Systems have to change.
On Tue, 8 Jul 2014, Robert Moskowitz wrote:
and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less. We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.
Things change. Design goals change. Systems have to change.
Of course they do. And those were changes in efficiency that were the result of needed productivity improvements. Change for the sake of major improvement(s). Wonderful, well-designed, efficient AND necessary. And it obviously made things more productive for everyone!
I argue that systemd neither improves efficiency, productivity or satisfaction...nor is it necessary.
Gilbert
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Tue, Jul 8, 2014 at 12:22 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:
On Tue, 8 Jul 2014, Robert Moskowitz wrote:
and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less. We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.
Things change. Design goals change. Systems have to change.
Of course they do. And those were changes in efficiency that were the result of needed productivity improvements. Change for the sake of major improvement(s). Wonderful, well-designed, efficient AND necessary. And it obviously made things more productive for everyone!
I argue that systemd neither improves efficiency, productivity or satisfaction...nor is it necessary.
More to the point, those 'old' efficiency hacks were from a time when programmer time was cheaper than the computer resources. Now, the computers should be doing the work for us instead of the other way around. Can anyone really make the argument that we can't afford the computer resources for transparent backwards compatibility now?
On 8.7.2014 20:45, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 12:22 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:
On Tue, 8 Jul 2014, Robert Moskowitz wrote:
and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less. We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.
Things change. Design goals change. Systems have to change.
Of course they do. And those were changes in efficiency that were the result of needed productivity improvements. Change for the sake of major improvement(s). Wonderful, well-designed, efficient AND necessary. And it obviously made things more productive for everyone!
I argue that systemd neither improves efficiency, productivity or satisfaction...nor is it necessary.
More to the point, those 'old' efficiency hacks were from a time when programmer time was cheaper than the computer resources. Now, the computers should be doing the work for us instead of the other way around. Can anyone really make the argument that we can't afford the computer resources for transparent backwards compatibility now?
Yes. Computers have probably resources, but programmers time is expensive (or when doing it in your own time it isn't fun to do) so thats why people aren't implementing them.
-vpk
On 07/08/2014 01:45 PM, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 12:22 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:
On Tue, 8 Jul 2014, Robert Moskowitz wrote:
and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less.
thinking back, I think it was 14 characters for cities and 25 for streets. But this IS going back 40 years. I still have some of the 9" tapes, but no tape drive...
We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.
Things change. Design goals change. Systems have to change.
Of course they do. And those were changes in efficiency that were the result of needed productivity improvements. Change for the sake of major improvement(s). Wonderful, well-designed, efficient AND necessary. And it obviously made things more productive for everyone!
I argue that systemd neither improves efficiency, productivity or satisfaction...nor is it necessary.
More to the point, those 'old' efficiency hacks were from a time when programmer time was cheaper than the computer resources. Now, the computers should be doing the work for us instead of the other way around. Can anyone really make the argument that we can't afford the computer resources for transparent backwards compatibility now?
On Tue, Jul 08, 2014 at 11:36:07AM -0500, Gilbert Sebenste wrote:
On Tue, 8 Jul 2014, Lamar Owen wrote:
People will vote with their feet on this. And, that "old white men" are complaining about this is ageist, racist, and demeaning to EVERYONE. I am really disappointed in Red Hat saying this, far more than the whole systemd concerns.
Again, let me clarify, it was a tongue-in-cheek comment made among friends, and certainly not a RedHat official quote.
On Tue, Jul 8, 2014 at 1:12 PM, Scott Robbins scottro@nyc.rr.com wrote:
On Tue, Jul 08, 2014 at 11:36:07AM -0500, Gilbert Sebenste wrote:
On Tue, 8 Jul 2014, Lamar Owen wrote:
People will vote with their feet on this. And, that "old white men" are complaining about this is ageist, racist, and demeaning to EVERYONE. I am really disappointed in Red Hat saying this, far more than the whole systemd concerns.
Again, let me clarify, it was a tongue-in-cheek comment made among friends, and certainly not a RedHat official quote.
But aside from insulting anyone, you should think of that reference realistically as meaning the people who have established systems working well enough to have built businesses worth maintaining. Do you really want to rock that boat in favor of youngsters that don't know how to make it work?
Lamar Owen wrote:
On 07/08/2014 11:58 AM, Les Mikesell wrote:
... How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)?
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long
No, it's *not* the wrong question. Are you going to figure ROI INCLUDING all the a) reworking, b) retraining (oh, that's right, almost *no* one pays for training, other than on-the-jop or take your own lunch brown bags) in the costs? And how 'bout how long it's going to recoup those up-front costs (or where you planning on hiring all new people anyway?), and will there be *another* change coming along in five years...?
ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
May I point to upstart, and that it lasted a few years, before folks decided it was a Bad Idea? How many years of systemd do we have to compare and contrast?
Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.
YES!!!!!!!!! Let fedora duke it out with ubuntu; give us a *work* o/s.
Consistency is not the only goal. Efficiency should trump consistency,
Wrong. I *STRONGLY* disagree. Efficiency should be a goal off consistency, and consistency should not be highly inefficient. However, as I've mentioned before, when I go home after a hard day administering a hundred-plus-many servers and workstations to my own workstation at home, I do *NOT* want to debug my o/s. (And I'm putting off trying to upgrade my router's DD-WRT, in the hope that I'll find something less buggy with USB printer support). <snip>
mark
On 07/08/2014 01:11 PM, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/08/2014 11:58 AM, Les Mikesell wrote:
... How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)?
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long
No, it's *not* the wrong question. Are you going to figure ROI INCLUDING all the a) reworking, b) retraining (oh, that's right, almost *no* one pays for training, other than on-the-jop or take your own lunch brown bags) in the costs? And how 'bout how long it's going to recoup those up-front costs (or where you planning on hiring all new people anyway?), and will there be *another* change coming along in five years...?
ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
May I point to upstart, and that it lasted a few years, before folks decided it was a Bad Idea? How many years of systemd do we have to compare and contrast?
Unfortunately the way systemd has intertwined itself into to so much more that just system startup, it could be around for a long time.
Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.
YES!!!!!!!!! Let fedora duke it out with ubuntu; give us a *work* o/s.
Consistency is not the only goal. Efficiency should trump consistency,
Wrong. I *STRONGLY* disagree. Efficiency should be a goal off consistency, and consistency should not be highly inefficient. However, as I've mentioned before, when I go home after a hard day administering a hundred-plus-many servers and workstations to my own workstation at home, I do *NOT* want to debug my o/s. (And I'm putting off trying to upgrade my router's DD-WRT, in the hope that I'll find something less buggy with USB printer support).
<snip>
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Jul 8, 2014 at 11:13 AM, Lamar Owen lowen@pari.edu wrote:
On 07/08/2014 11:58 AM, Les Mikesell wrote:
... How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)?
Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?'
But the answer is still the same. It's sort of the same as asking that about getting a shiny new car with a different door size that won't carry your old stuff without changes and then still won't do it any better. Our services take all the hardware can do and a lot of startup initialization on their own. Saving a fraction of a second of system time starting them is never going to be a good tradeoff for needing additional engineer training time on how to port them between two different versions of the same OS.
If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not.
So a deferred cost doesn't matter to you? You aren't young enough to still think that 6 years is a long time away, are you?
Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?
Yes, Linux distributions do a lot of things I consider stupid. Take the difficulty of maintaining real video drivers as an example.
Even the Unix philosophy was new at one point. Just because it works doesn't mean it's the best that can be found.
Re-using things that work may not be best, but if everyone is continually forced to re-implement them, they will never get a chance to do what is best. In terms of your ROI question, you should be asking if that is the best use of your time.
Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.
Consistency is not the only goal.
But that's why we are here using an 'enterprise' release, not rebuilding gentoo every day.
Efficiency should trump consistency,
Efficiency comes from following standards so components are reusable and can be layered on top of each other. Then you can focus on making the least efficient part better and spend your time where it will make a difference. Adding options to increase efficiency is great - as long as you don't break backwards compatibility.
and I for one like being able to see where the direction lies well in advance of EL adopting a feature blind. Or don't you remember how Red Hat Linux development used to be before Fedora and the openness of that process?
Yes, I remember it worked fantastically well up through at least RH7 - which was pretty much compatible with CentOS3. That was back when people actually using the systems contributed their fixes directly. I had a couple of 4+ year uptime runs on a system with RH7 + updates - and only shut it down to move it once.
On 07/08/2014 01:14 PM, Les Mikesell wrote:
On Tue, Jul 8, 2014 at 11:13 AM, Lamar Owen lowen@pari.edu wrote: But the answer is still the same. It's sort of the same as asking that about getting a shiny new car with a different door size that won't carry your old stuff without changes and then still won't do it any better. Our services take all the hardware can do and a lot of startup initialization on their own. Saving a fraction of a second of system time starting them is never going to be a good tradeoff for needing additional engineer training time on how to port them between two different versions of the same OS.
If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not.
So a deferred cost doesn't matter to you? You aren't young enough to still think that 6 years is a long time away, are you?
Amortized capex matters to me. I may not have the capex budget this year to do the development, but I do have opex monies to research potential development, and opex monies to do grant writing that can fund the development capex. I'm old enough to remember and to have read an original paper copy of the Misosys Quarterly with a column called 'Les Information.'
6 years is a short time, especially for grant funding cycles. But it is enough time for me to have researched, hopefully properly, the means by which to implement hopefully opex-reducing improvements. But these are business decisions, not technical ones.
Re-using things that work may not be best, but if everyone is continually forced to re-implement them, they will never get a chance to do what is best. In terms of your ROI question, you should be asking if that is the best use of your time.
My non-development time is opex; my development time is capex (for the purposes of many grants for which we apply). I always ask the question above when figuring ROI. And I got the nickname 'Mr. Make-Do' for the very reason that I do tend to heavily reuse 'ye olde stuffe.'
Consistency is not the only goal.
But that's why we are here using an 'enterprise' release, not rebuilding gentoo every day.
I guess you missed the adjective 'only' above. Consistency helps reduce opex; reduces opex produces better fiscal efficiency, at least in theory. Each business's situation will be different, YMMV, of course.
Efficiency should trump consistency,
Efficiency comes from following standards...
Everyone who commented thus far on my statement seems to have missed my wearing my CIO hat. I'm talking fiscal efficiency, as in getting the most bang for the buck, especially in terms of opex, which is nearly always a much larger number than capex for us (and, while I know this is not likely to make much technical sense, it is a true statement that $1 opex is not equal to $1 capex). This is not 'technical efficiency' here, but 'keep the lights on and the budget in the black' efficiency. If the budget goes red long enough it really doesn't matter what you do technically. If I need to get a grant to fund $100,000 capex that will save me $10,000 per year opex (and grants almost never fund opex) it is a no-brainer.
Yes, I remember it worked fantastically well up through at least RH7 - which was pretty much compatible with CentOS3.
Minor correction:
RHL 7.2 -> RHAS 2.1. RHL 9 -> RHEL 3.
I have a client that still has a RHL 5.2 machine running in production. It does its job, is not internet-connected and thus security updates are irrelevant, and it will run until it dies. Client has no budget to reengineer properly, and is migrating services one at a time in a pretty slow manner. There's only two semi-critical services left, and if they just went away the client would go back to a paper system while a newer system is being built. And they're fully prepared to do that rather than upgrade now.
That was back when people actually using the systems contributed their fixes directly. I had a couple of 4+ year uptime runs on a system with RH7 + updates - and only shut it down to move it once.
I am one of those people who contributed directly; my name can still be found in the changelogs for PostgreSQL 7.4 on CentOS 4 (and I would assume RHEL4, if PostgreSQL is part of the EUS set). I remember the mechanisms, and the gatekeepers, involved, very well. The Fedora way is way more open, with people outside of Red Hat directly managing packages instead of contributing fixes to the 'official' Red Hat packager for that package.
On Wed, Jul 9, 2014 at 12:11 PM, Lamar Owen lowen@pari.edu wrote:
That was back when people actually using the systems contributed their fixes directly. I had a couple of 4+ year uptime runs on a system with RH7 + updates - and only shut it down to move it once.
I remember the mechanisms, and the gatekeepers, involved, very well. The Fedora way is way more open, with people outside of Red Hat directly managing packages instead of contributing fixes to the 'official' Red Hat packager for that package.
I'm not convinced that being open and receptive to changes from people that aren't using and appear to not even like the existing, working system is better than having a single community, all running the same system because they already like it, and focusing on improving it while keeping things they like and are currently using. With the latter approach, there was a much better sense of the cost of breaking things that previously worked. With fedora, well, nobody cares - they aren't running large scale production systems on it anyway/
On 07/09/2014 01:31 PM, Les Mikesell wrote:
I'm not convinced that being open and receptive to changes from people that aren't using and appear to not even like the existing, working system is better than having a single community, all running the same system because they already like it, and focusing on improving it while keeping things they like and are currently using.
I think you and I remember a different set of lists. I remember lots of griping about changes being forced down throats. Heh, a quick perusal of one of the lists' archives just a minute ago confirmed my recollection.
With the latter approach, there was a much better sense of the cost of breaking things that previously worked.
Do you remember the brouhaha over libc5 that 'just worked' versus the 'changed for no reason' glibc2? And don't get me started on the recollections over the GNOME 1 to 2 upgrade (or fvwm to GNOME, for that matter!), or the various KDE upgrades (and the entire lack of KDE for RHL 5.x due to the odd license for Qt, remember? Mandrake got its start being essentially RHL with KDE.... and of course the 'stripping' of KDE to 'cripple it down the GNOME level' (otherwise known as the 'Red Hat Desktop')) or the various kernel uprevs (2.4 broke my whatzit2000 that nobody else has! You CAN'T upgrade!!!!!). And then there was gcc 2.96. (I can feel the tremor in the Source just mentioning that....) And then all the i18n changes for 8.0 (I dealt with that one directly, since the PostgreSQL ANSI C default had to be changed to whatever was now localized.... too bad the Redneck install language has gone away.) And then there was the weed called Kudzu. The bad rep for x.0 releases started somewhere, remember? (Smooge was there, too, and has an extensive page about the differences (this link is from my bookmarks and memory; AFAIK it still works): http://www.smoogespace.com/documents/behind_the_names.html ).
And I'm still waiting for my upgrade to Red Baron. ;-), in case you needed it....
Sorry Les, but I was there, and I have the e-mails. I guess people prefer being able to just gripe without the chance for real responsibility versus now having a bit of responsibility to help since the ability to actually do something about it is available.
Not that I necessarily disagree with your observations, by the way. I'm just looking at the brushstrokes of the really big picture and remembering how at the time it seemed like we sometimes were just moving from one kluge to another (if you insist on the alternate spelling 'kludge' feel free to use it.....). But it was a blast being there and watching this thing called Linux find its wings, no?
It is still a blast for me, even if I actually do serious work with several versions of Linux. And I'm looking forward to spending some quality time with systemd, of which I know very little, and seeing how I can make this new tool, which apparently a lot of really smart people think is a great idea, work for me (and I may find that I despise it; time will tell). I kind of feel like I've been given a new tool set with tools I've never seen, and finding out that a screwdriver and a chisel can actually be separate things! Or finding out what a 'fence wire' tool can *really* be used for..... ( see: http://www.garrettwade.com/images/330/66A0204.jpg )
And I have two previous versions of CentOS to fall back on while I learn the new tools; I have both C5 and C6 in production, and have plenty of time in which to do a proper analysis on the best way ('best way' of course being subjective; there is no such thing as an entirely objective 'best way') for me to leverage the new tools. The fact of the matter is that Red Hat would not bet the farm on systemd without substantial buy-in from a large number of people. The further fact the Debian and others have come to the same conclusion speaks volumes, whether any given person thinks it stupid or not. And I don't have enough data to know whether it's going to work for me or not; I'm definitely not going to knee-jerk about it, though.
But the rumors of something 'killing' Linux have and will always be exaggerated. Systemd certainly isn't going to, if gcc 2.96 didn't. I mean, think about it: the first rev out of gcc 2.96 wouldn't even compile the Linux kernel, IIRC!
On Wed, Jul 9, 2014 at 1:22 PM, Lamar Owen lowen@pari.edu wrote:
On 07/09/2014 01:31 PM, Les Mikesell wrote:
I'm not convinced that being open and receptive to changes from people that aren't using and appear to not even like the existing, working system is better than having a single community, all running the same system because they already like it, and focusing on improving it while keeping things they like and are currently using.
I think you and I remember a different set of lists. I remember lots of griping about changes being forced down throats. Heh, a quick perusal of one of the lists' archives just a minute ago confirmed my recollection.
No, that is exactly my point. Back then the griping by affected active users happened in more or less real time compared to the changes being done. Now fedora goes off on its own merry way for years before its breakage comes back to haunt the people that wanted stability.
With the latter approach, there was a much better sense of the cost of breaking things that previously worked.
Do you remember the brouhaha over libc5 that 'just worked' versus the 'changed for no reason' glibc2? And don't get me started on the recollections over the GNOME 1 to 2 upgrade (or fvwm to GNOME, for that matter!), or the various KDE upgrades (and the entire lack of KDE for RHL 5.x due to the odd license for Qt, remember?
Don't think people running a bunch of RH5 servers really cared about X or desktops at all...
And then all the i18n changes for 8.0 (I dealt with that one directly, since the PostgreSQL ANSI C default had to be changed to whatever was now localized....
That one was sort of inevitable. Likewise for grub2 and UEFI...
The bad rep for x.0 releases started somewhere, remember?
Well, that was the equivalent of fedora. You don't use that in production. The x.2 release mapped pretty well to 'enterprise'' - except maybe for 8.x and 9 which never really were very good.
Not that I necessarily disagree with your observations, by the way. I'm just looking at the brushstrokes of the really big picture and remembering how at the time it seemed like we sometimes were just moving from one kluge to another (if you insist on the alternate spelling 'kludge' feel free to use it.....). But it was a blast being there and watching this thing called Linux find its wings, no?
In these observations you have to take into account just how badly broken the base code was back then. Wade through some old changelogs if you disagree. There were real reasons that things had to change. But by, say, CentOS5 or so we had systems that would run indefinitely we a few security updates now and then. (Actually CentOS3 was pretty solid, but you have to follow the kernel).
And I have two previous versions of CentOS to fall back on while I learn the new tools; I have both C5 and C6 in production, and have plenty of time in which to do a proper analysis on the best way ('best way' of course being subjective; there is no such thing as an entirely objective 'best way') for me to leverage the new tools. The fact of the matter is that Red Hat would not bet the farm on systemd without substantial buy-in from a large number of people. The further fact the Debian and others have come to the same conclusion speaks volumes, whether any given person thinks it stupid or not. And I don't have enough data to know whether it's going to work for me or not; I'm definitely not going to knee-jerk about it, though.
I'm never against adding new options and features. But I am very aware of the cost of not making the new version backwards compatible with anything the old version would have handled. And I'm rarely convinced that someone who doesn't consider backwards compatibility as a first priority is going to do so later either, so you are likely wasting your time learning to work with today's version since tomorrows will break what you just did.
But the rumors of something 'killing' Linux have and will always be exaggerated. Systemd certainly isn't going to, if gcc 2.96 didn't. I mean, think about it: the first rev out of gcc 2.96 wouldn't even compile the Linux kernel, IIRC!
Yes, but on the other hand, people still pay large sums of money for other operating systems. And there are some reasons for that.
On 07/09/2014 03:20 PM, Les Mikesell wrote:
No, that is exactly my point. Back then the griping by affected active users happened in more or less real time compared to the changes being done. Now fedora goes off on its own merry way for years before its breakage comes back to haunt the people that wanted stability.
Real-time? Since when? The development direction was already pretty much done by the time the public betas were released and the griping began. Even by the time of the private betas the development direction on several of the releases was already pretty much set in stone. I only had a bit of input for PostgreSQL because I was maintaining the upstream RPM package at the time; but I had no pre-beta access to whatever was in the beehive queue at the time.
With fedora, on the other hand, you already know that what is going in the next version of EL is going to be previewed in Fedora and you are absolutely free to follow the Fedora lists and get involved in the actual process, rather than being fed an already mostly-baked beta every so often. If you don't follow the Fedora lists and get involved, well, you get what you pay for, I guess. I don't currently follow the Fedora lists, incidentally, but I do track the features that are being implemented. We already had Upstart, and the move from Upstart to systemd is not that big (at least in my opinion), so it's not something that got me up in arms. Plain text non-XML configs that can be on a non-executable filesystem and lots of really nice options in the unit configs really change the way you think of system startup. It is a change; I've not decided whether I think is a good change or not; most of the big Linux distributions have decided that it is a good change.
In a quick google, I found what I thought to be a pretty clearly written article (from 2012) on systemd's strong points from the point of view of a server admin: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight?showcomments
If it can really deliver this, particularly the feature of sysadmin-modified units all being in one place, yeah, looks like a good thing. And there will be plenty of eyes on it. Most of the articles looking at systemd's weak points (and there are several) aren't written in nearly as level a fashion as the above. Lots of vitriol to go around, unfortunately.
... Don't think people running a bunch of RH5 servers really cared about X or desktops at all...
You missed my Red Baron comment, didn't you? I ran Red Hat Linux 4.1 as a desktop, and once Mandrake 5.3 was out I went completely Linux as my primary work and personal desktop. I figured if I was going to run it as a server I needed to 'dogfood' things and really rely on it for daily work. And my employer agreed.
The days StarOffice became OpenOffice.org and then when OO.o 1.0 wound its way into RHL were very good days for this desktop Linux user.
...
Yes, but on the other hand, people still pay large sums of money for other operating systems. And there are some reasons for that.
Many of which are not technical.
On Wed, Jul 9, 2014 at 3:07 PM, Lamar Owen lowen@pari.edu wrote:
If you don't follow the Fedora lists and get involved, well, you get what you pay for, I guess.
Following the list just makes it more painfully clear that they don't care about compatibility or breakage of previously working code/assumptions or other people's work. It's all about change. I tried to use/follow fedora for a while, but gave up when an update between releases pushed a kernel that wouldn't boot on the fairly mainstream IBM server I was using for testing.
We already had Upstart, and the move from Upstart to systemd is not that big (at least in my opinion), so it's not something that got me up in arms.
Backwards compatibility isn't a big/little thing, it is binary choice yes/no. If you copy stuff over and it doesn't work, that's a no, and it is going to cost something to make it work again.
Don't think people running a bunch of RH5 servers really cared about X or desktops at all...
You missed my Red Baron comment, didn't you? I ran Red Hat Linux 4.1 as a desktop, and once Mandrake 5.3 was out I went completely Linux as my primary work and personal desktop. I figured if I was going to run it as a server I needed to 'dogfood' things and really rely on it for daily work. And my employer agreed.
Did you keep track of the time you spent keeping that working?
Yes, but on the other hand, people still pay large sums of money for other operating systems. And there are some reasons for that.
Many of which are not technical.
Many aren't. And many are just a large base of stuff that works and will break if anything underneath changes.
On 07/09/2014 04:27 PM, Les Mikesell wrote:
On Wed, Jul 9, 2014 at 3:07 PM, Lamar Owen lowen@pari.edu wrote:
If you don't follow the Fedora lists and get involved, well, you get what you pay for, I guess.
Following the list just makes it more painfully clear that they don't care about compatibility or breakage of previously working code/assumptions or other people's work. It's all about change. ...
c'est la vie.
The only constant is change. Some changes stick; some don't. Unix itself was a major change in the early 70's, and many of the same issues I see being mentioned here are rehashes of the Unix fragmentation grenade back in the 80's. People reinvent the wheel, and sometimes their wheel is better, and sometimes it isn't. And always a very vocal group will gripe against the wheel being reinvented at all, regardless of whether it might be better or not.
This wheel might be better and it might not; we'll never know if we don't try it out. Experience and tradition must be tempered with empirical results from actually experimenting with the new. (And do note that 'tempered' does not mean to do away with experience and tradition......).
Backwards compatibility isn't a big/little thing, it is binary choice yes/no. If you copy stuff over and it doesn't work, that's a no, and it is going to cost something to make it work again.
Have you checked how compatible or not systemd is for the init scripts of the packages about which you care (such as OpenNMS)?
Did you keep track of the time you spent keeping [desktop RHL 5.x] working?
My employer put a line item on my timesheet for it, so, yes, I kept track of it and got paid for it. Those paper files have long since been tossed, since that was fifteen-plus years ago. My employer was paying me to keep the server up, I had an employer who understood the value of training, and that employer definitely understood the value of dogfooding.
On Wed, Jul 9, 2014 at 3:43 PM, Lamar Owen lowen@pari.edu wrote:
The only constant is change.
Sure, but it is only progress if you stop changing things when they work.
Have you checked how compatible or not systemd is for the init scripts of the packages about which you care (such as OpenNMS)?
OpenNMS provides yum repositories. When they add the EL7 repo, I'll expect it to include something that already works. So that's not my problem but will likely waste someone else's time if the existing init script doesn't drop in. I'll just need to make things work for the internal programs, some of which are done by developers that would really rather stay on windows.
Did you keep track of the time you spent keeping [desktop RHL 5.x] working?
My employer put a line item on my timesheet for it, so, yes, I kept track of it and got paid for it. Those paper files have long since been tossed, since that was fifteen-plus years ago. My employer was paying me to keep the server up, I had an employer who understood the value of training, and that employer definitely understood the value of dogfooding.
Still you must have come up with some bottom line recommendations. Did your employer make all or some large number of staff follow your lead back then on desktop versions/updates after seeing what it costs? Personally, I gave up on the hardware aspect of a linux desktop as soon as I saw freenx working from windows/macs where vendor-optimized video drivers come with the distribution. And then having access to both Linux and native desktop programs I've tended to ignore the problems with linux desktop apps.
On 10/07/14 07:09, Les Mikesell wrote:
On Wed, Jul 9, 2014 at 3:43 PM, Lamar Owen lowen@pari.edu wrote: Did you keep track of the time you spent keeping [desktop RHL 5.x] working?
My employer put a line item on my timesheet for it, so, yes, I kept track of it and got paid for it. Those paper files have long since been tossed, since that was fifteen-plus years ago. My employer was paying me to keep the server up, I had an employer who understood the value of training, and that employer definitely understood the value of dogfooding.
Still you must have come up with some bottom line recommendations. Did your employer make all or some large number of staff follow your lead back then on desktop versions/updates after seeing what it costs? Personally, I gave up on the hardware aspect of a linux desktop as soon as I saw freenx working from windows/macs where vendor-optimized video drivers come with the distribution. And then having access to both Linux and native desktop programs I've tended to ignore the problems with linux desktop apps.
We use a large number of Linux desktops extensively and have since 5.2. For our applications and workflows, this was quicker and more feature rich. We use the same platform in a HPC scenario as well, so (Desktop) Linux is dependent on your needs.
I can sympathize with you that you are upset about systemd. CentOS, RH, Fedora or Linux is not stopping you from being involved or finding a solution to your problem with systemd. Here are some examples of the way you and others could give back to the community and help others that believe the same as you. 1. Engage with the community of the early Open Source version of RHEL ie Fedora. 2. Submit patches, rpms etc as alternatives to systemd for inclusion in Fedora. RH may include it in RHEL as an optional install. 3. Submit a bugzilla on sytsemd itemizing and describing the deficiencies. 4. Purchase Support and or services from RH and create a case with business justification. 5. Create a fork of CentOS7 that does not have systemd. 6. Create a fork of CentOS6 that has future features/bugs backported from Centos7 7. Financially support someone/people to do any of the above if you can't do it yourself.
As you can see there are lots of options with open source software. I am sure there are others I have missed. I hope that helps you find a solution to your problem.
Grant
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
On 07/08/2014 10:49 AM, Russell Miller wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
Couldn't have said it better.
On Tue, Jul 8, 2014 at 10:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
What's Windows-ish about it? It's all text files; easily available to look at. And Solaris with SMF went in this direction many years ago.
Tony Schreiner
On Tue, Jul 8, 2014 at 10:59 AM, Tony Schreiner anthony.schreiner@bc.edu wrote:
On Tue, Jul 8, 2014 at 10:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
What's Windows-ish about it? It's all text files; easily available to look at.
Windows used to have a single win.ini file with all configs in it. Then it replaced that with a binary equivalent you access and manipulate using programs or whatnot. I think the point is that is where systemd is going to, and there are many good arguments for that. But there are also compelling reasons against it.
Also, you as a developer/manager has to interact with this 2600lb Gorilla (he gained some weight throughout the years) that is the OS using libraries and programs that are poorly documented and rather buggy. Or hack your way in. All that while hoping that ape will not starting flinging poop your way for absolutely no reason (bugs, security flaws, etc).
And Solaris with SMF went in this direction many years ago.
And so did Apple in a certain way (their plists and launchd and so on). Was that an improvement? I honestly cannot answer that.
Tony Schreiner _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, Jul 8, 2014 at 9:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
This is an unfortunate problem in the community today, anyone who disagrees with status-quo is "just an antique", it's insulting to say the least. It doesn't matter our experience, we're just "causing trouble" because we "don't want change" which is an excuse that isn't even remotely true. Eventually when all these "old guys" leave, all that will be left are the inexperienced kids and that's when the real problems will begin to surface. There are a few good reasons to adopt systemd, but the bad outweigh the good in my opinion. Then there's the problem of giving children the keys to the kingdom ( http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html) as they do run off the old guard so they can have their toys.
Personally, we've started evaluating migrating from CentOS 6 to FreeBSD rather than CentOS 7.
On Tue, Jul 8, 2014 at 11:05 AM, Andrew Wyatt andrew@fuduntu.org wrote:
This is an unfortunate problem in the community today, anyone who disagrees with status-quo is "just an antique", it's insulting to say the least. It doesn't matter our experience, we're just "causing trouble" because we "don't want change" which is an excuse that isn't even remotely true. Eventually when all these "old guys" leave, all that will be left are the inexperienced kids and that's when the real problems will begin to surface.
The people promoting change most like do not have a large installed base of their own complex programming to maintain or any staff to retrain.
There are a few good reasons to adopt systemd, but the bad outweigh the good in my opinion.
My opinion is that if a new system is really better, then it should be capable of handling everything the previous standard did transparently. If it can't, then it's not really better. It is just different.
On Tue, Jul 8, 2014 at 11:12 AM, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jul 8, 2014 at 11:05 AM, Andrew Wyatt andrew@fuduntu.org wrote:
This is an unfortunate problem in the community today, anyone who
disagrees
with status-quo is "just an antique", it's insulting to say the least.
It
doesn't matter our experience, we're just "causing trouble" because we "don't want change" which is an excuse that isn't even remotely true. Eventually when all these "old guys" leave, all that will be left are
the
inexperienced kids and that's when the real problems will begin to
surface.
The people promoting change most like do not have a large installed base of their own complex programming to maintain or any staff to retrain.
They likely don't, if they did they would gain the experience to know better. Fortunately, we have CentOS 6 which still has a lot of life left in it.
There are a few good reasons to adopt systemd, but the bad outweigh the good in my opinion.
My opinion is that if a new system is really better, then it should be capable of handling everything the previous standard did transparently. If it can't, then it's not really better. It is just different.
I agree, completely. Who would replace the hood of a car with half a hood? It might have really awesome flames painted on it, but at the end of the day it's still half a hood.
On 07/08/2014 12:05 PM, Andrew Wyatt wrote:
On Tue, Jul 8, 2014 at 9:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
This is an unfortunate problem in the community today, anyone who disagrees with status-quo is "just an antique", it's insulting to say the least. It doesn't matter our experience, we're just "causing trouble" because we "don't want change" which is an excuse that isn't even remotely true. Eventually when all these "old guys" leave, all that will be left are the inexperienced kids and that's when the real problems will begin to surface. There are a few good reasons to adopt systemd, but the bad outweigh the good in my opinion. Then there's the problem of giving children the keys to the kingdom ( http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html) as they do run off the old guard so they can have their toys.
It is fun to attend a standards meeting (like IETF and IEEE 802) when some young guys and gals, along with their profs make a presentation on how things should REALLY be done. Then that grey headed guy or gal gentlely leads the Q&A into a critical edge case that completely breaks the proposal. At least in my area, we have the institutional memory of why we do things as we done. Sometimes things evolve where we CAN do it better now, or even have to do it better. But us old dogs still have the where-with-all to keep it all straight.
But also we are demanding more of our systems. HSMs make dealing with virtualization a must and this changes a lot of old assumptions. Remember what assume can spell.
<snip>Then that grey headed guy or gal gentlely leads the Q&A into a critical edge case that completely breaks the proposal. </snip>
When you do that to a certain developer you get banned from a certain G+ feed for make believe "personal attacks" because changing the conversation is much simpler than acknowledging a design flaw.
Kids these days!
On 7/8/2014 8:49 AM, Russell Miller wrote:
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
Well said. Why are the old proven ways somehow so deficient that we absolutely must replace them with something else, no matter how badly thought out. (yes I'm an old fart by some folks figuring, I actually prefer the command line and started with punch cards and paper tape).
Change isn't bad... but change for change's sake is stupid and that's what this looks like. New is not always better. Based on my observations over the years, new is rarely better! The more rapid the change, the more radical the change, the more likely the change won't stand the test of time, or rational thinking. Do the analysis, really do it without a bias toward a specific answer and sometimes, yes, sometimes the answer is leave things alone, they work fine the way they are. Just because something is old doesn't mean it needs to be replaced. Of course, sometimes the answer is to make changes, but keep them small, make them incrementally and give them time to prove themselves before rushing headlong towards the next thing.
Sadly, poorly thought out change seem to be the trend, and not a surprise given the number of folks with Windows backgrounds making their way into the Linux world. We are definitely loosing touch with the UNIX philosophy and that was what made it a great operating system for doing real work.
I started my work life as a maintainer and while I've done my fair share of development, I've always thought like a maintainer. Change almost always breaks things, so do it carefully and slowly and with thought not just about the local impact, but the global impact. Please! -- Steve
You aren't old.
(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)
On Jul 8, 2014, at 9:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/08/2014 12:44 PM, Hal Wigoda wrote:
You aren't old.
And I am a young 21. three times over. All that means is I have to learn new stuff now 3 times to get it right! As some people on this list will attest to :)
Soon I will be 26 (2^6). So that means that I have to then learn everything 6 times!
Age is what you make of it. Senior moments are to be cherished. ;)'
(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)
On Jul 8, 2014, at 9:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.
(and if that was yesterday, I don't want to hear about it. :))
--Russell
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/08/2014 12:55 PM, Robert Moskowitz wrote:
On 07/08/2014 12:44 PM, Hal Wigoda wrote:
You aren't old.
And I am a young 21. three times over. All that means is I have to learn new stuff now 3 times to get it right! As some people on this list will attest to :)
Soon I will be 26 (2^6). So that means that I have to then learn everything 6 times!
Hmm... well soon I will be 26 + 4.
Age is what you make of it. Senior moments are to be cherished. ;)'
(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)
On Jul 8, 2014, at 9:49 AM, Russell Miller duskglow@gmail.com wrote:
On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:
That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.
For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.
Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.
It's old but there is still some rumours that freebsd will get Launchd ported from OS X some day
On 07/07/2014 10:34 PM, Scott Robbins wrote:
On Tue, Jul 08, 2014 at 02:26:59AM +0100, Always Learning wrote:
On Mon, 2014-07-07 at 20:59 -0400, Scott Robbins wrote:
To the tune of YMCA
So young man, if you want to stick To something, that more resembles Unix And young man, if you want to sing Goodbye to Poettering,
(bah bah bah bah)
FreeeeeeeeeBSD (yeah yeah yeah) FreeeeeeeeeBSD
etc. I just made this up at work today, and that's as far as I got.
Ah, a Broadway musical next ? :-)
I'm an old man who remembers multics, GECOS/GCOS and the 'B' programming language.
Is FeeBSD systemd-less ? Got a FreeBSD manual.
No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.
It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)
On 07/07/2014 06:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
The answer to this is no, replacing systemd with something else is just way to invasive.
Since new versions of CentOS, Ubuntu, Debian, RHEL, Fedora, OpenSUSE, Arch, Mageia and other Linux distros are all switching to systemd as the default .. I would suggest that learning how to use it is going to be the way to go.
Of course, there are alternatives, including using CentOS-6 until 2020.
Johnny Hughes wrote:
On 07/07/2014 06:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
The answer to this is no, replacing systemd with something else is just way to invasive.
Since new versions of CentOS, Ubuntu, Debian, RHEL, Fedora, OpenSUSE, Arch, Mageia and other Linux distros are all switching to systemd as the default .. I would suggest that learning how to use it is going to be the way to go.
I just hope that the distribution of implementing systemd are not so shortsighted (or rather pushing force) as Fedora/RHEL and besides him also offer other alternative (OpenRC is IMO very good candidate, although with sysvinit and upstart I was also satisfied - both did _reliably_ their jobs).
Franta Hanzlik
On 07/07/2014 06:47 PM, Always Learning wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Is there a practical alternative to omnipresent, or invasive, systemd ?
I hate to say it ... but all the Blovaiting we might want to do or not do in support of or in opposition to systemd does not matter with respect to CentOS 7.
RHEL 7 has it, so CentOS 7 has it. Use CentOS 7 or don't ... your choice. If you want to replace systemd and you can figure out how .. do it.
If it works and you want to get into a SIG, great then start one.
If you want do discuss the mechanisms for removing systemd and collaborate about doing it via patches and changes to some package(s) in CentOS 7 .. great. Fork the packages from git.centos.org and go to github, start coding with your friends .. you can use the centos-devel mailing list to discuss the changes.
But failing that, lets try to close down the thread a bit unless there is really something constructive to add.
On 2014-07-07, Always Learning centos@u62.u22.net wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Has anyone here actually interacted with systemd, and if so could you perhaps provide a writeup of your experiences? I feel like I haven't seen any practical information on systemd in this thread, and I'd like to have that before forming an initial opinion (at which point I'd attempt to interact with it myself in order to form a better informed opinion).
--keith
On Mon, Jul 14, 2014 at 03:52:10PM -0700, Keith Keller wrote:
On 2014-07-07, Always Learning centos@u62.u22.net wrote:
Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).
Has anyone here actually interacted with systemd, and if so could you perhaps provide a writeup of your experiences? I feel like I haven't seen any practical information on systemd in this thread, and I'd like to have that before forming an initial opinion (at which point I'd attempt to interact with it myself in order to form a better informed opinion).
I've been using systemd ever since it was introduced in Fedora, and the RHEL7 beta and CentOS7 final since it came out. I could tell you about all the positive and negative experiences I've had. There's been a lot of misinformation posted on this list (such as the Windows Registry reference)[1]. I wouldn't want to make any decisions about systemd based on what I've seen on this list.
However, I think you should try it out yourself. I suggest giving it a try in a VM, or try one of the CentOS7 LiveCDs. I was quite hesitant about systemd when I started using it, but it was experience that led me to be able to make good judgements about it.
1. See the systemd myths web page http://0pointer.de/blog/projects/the-biggest-myths.html
On 2014-07-15, Jonathan Billings billings@negate.org wrote:
I've been using systemd ever since it was introduced in Fedora, and the RHEL7 beta and CentOS7 final since it came out. I could tell you about all the positive and negative experiences I've had.
I think this could be very useful, especially coming from someone who was initially reluctant (as I and clearly others are).
There's been a lot of misinformation posted on this list (such as the Windows Registry reference)[1]. I wouldn't want to make any decisions about systemd based on what I've seen on this list.
That's what I was concerned about. :) I certainly would try it for myself first, but if I were to read a lot of people writing "I tried to actually use systemd, and it was awful/fine/awesome" that would carry some weight.
However, I think you should try it out yourself. I suggest giving it a try in a VM, or try one of the CentOS7 LiveCDs. I was quite hesitant about systemd when I started using it, but it was experience that led me to be able to make good judgements about it.
- See the systemd myths web page
In the interest of full disclosure, that page is written by one of the primary authors of systemd, so we shouldn't expect an unbiased opinion. (Not saying it's wrong, only that it's important to understand the perspective an author might have.)
--keith
On Mon, Jul 14, 2014 at 09:50:18PM -0700, Keith Keller wrote:
On 2014-07-15, Jonathan Billings billings@negate.org wrote:
I've been using systemd ever since it was introduced in Fedora, and the RHEL7 beta and CentOS7 final since it came out. I could tell you about all the positive and negative experiences I've had.
I think this could be very useful, especially coming from someone who was initially reluctant (as I and clearly others are).
Ok, I'll give some examples of my experiences. Warning: long post.
As a systems integrator, I'm less concerned with hand-crafted, artisian init script hackery and more interested in consistency. I rarely start init scripts by running the init script manually, but rely on configuration management tools, which expect a uniform interface. I'm concerned with confining services to use the resource that are expected, and to make sure that they remain secure.
Prior to the systemd's release, I had created several custom services to manage the infrastructure and to serve up the apps I supported. They were all written using RHEL and CentOS-specific syntax. I had started looking at replacing them with Upstart-specific services around the time when systemd was announced. Both Upstart and systemd have simpler configuration syntax, their own commands and better support of dependency management.
When I started using and writing my own systemd units, I found them quite simple, the documentation sufficient, and the features quite useful. Finally getting proper ordering of services, being able to set mountpoints and network activation (for example) as dependencies of services, resource management, these all are huge wins for Linux systems.
For example, cgroups. I had already started using cgroups in el6, and you get automatic resource management with cgroups with systemd. This is a hugely positive feature that you don't even realize is possible until you start using it. This also extends to systemd-logind, so you can set up "slices" for resource management of users. Possible in el6 using pam_cgroup and cgred, but must better implemented with logind, since they're automatically created and added to a cgroup. Same for services.
From that perspective, now you can really think of a 'service' as a
unit, contained within what you define its resources to have. You can also have containers that make it possible to even give a service its own process namespace, with Docker or systemd-nspawn.
From a purely configuration management perspective, the ability to
just drop simple text files into directories to set up all of these features makes me happy. For example, instead of needing to modify /etc/fstab (which I hate doing, since I try to avoid making my CfgMgmt tool edit files), I can drop an NFS mointpoint definition into a .mount unit file, which I can then refer to in a .service unit file that requires the mountpoint.
Puppet, Chef and Bcfg2 (the CfgMgmt tools I've used) all support systemd, so the hard work has already been done to start using it. I was not particularly enamored with fancy SysVinit scripting, and usually prefer as simple and baseline functionality as possible, so I really see no loss switching to systemd. The fear of systemd being monolithic actually makes me chuckle, since systemd actually breaks out many of the functions of the SysVinit rc.sysinit into separate units, to be managed and modified as needed (such as TTY allocation, mounting filesystems, managing runlevels, etc.).
So, the things that have bothered me so far: 1.) The order of the 'service SERVICENAME start|stop|status' options is reversed for 'systemctl start|stop|status SERVICENAME.service'. It took me a while to get used to that. You can just keep using 'service' and get similar results, though. The output of the systemctl status is pretty complex too. Also, I keep forgetting to run 'systemctl status -l SERVICENAME.service' and the long lines are chopped off until I remember to use -l.
2.) Daemons under systemd don't really need to daemonize anymore. In the past, to start up a daemon process, you'd need to fork (or double-fork) and disconnect STDIN, STDOUT and STDERR file descriptors. This was just accepted knowledge. You don't need to do that anymore in systemd service units. Heck, write to stdout or stderr, it'll be recorded in the journal. Check out the openssh-server service unit, you'll see that sshd is run with -D there. Systemd supports daemonized services, it's just not necessary anymore.
3.) Old SysVinit services that did something other than start/stop/restart/status no longer work. While this was nice for consistency, it means that porting to systemd will require alternative methods. This really bugged me at first, but from the perspective of a systems management person, I can see why it was kind of a hack, and not consistently implemented.
4.) Debugging. Why is my unit not starting when I can start it from the command line? Once I figured out journalctl it was a bit easier, and typically it was SELinux, but no longer being able to just run 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables core dumps on services by default (at least it did on Fedora, the documentation now says it's on by default. Huh. I should test that...)
On 07/15/2014 09:38 AM, Jonathan Billings wrote:
On Mon, Jul 14, 2014 at 09:50:18PM -0700, Keith Keller wrote:
I think this could be very useful, especially coming from someone who was initially reluctant (as I and clearly others are).
Ok, I'll give some examples of my experiences. Warning: long post.
... When I started using and writing my own systemd units, I found them quite simple, ...
So, the things that have bothered me so far: ...
Jonathan, thanks for the balanced treatment and for posting actual experience and not just regurgitating tired tropes.
On 15 Jul 2014 14:38, "Jonathan Billings" billings@negate.org wrote:
4.) Debugging. Why is my unit not starting when I can start it from the command line? Once I figured out journalctl it was a bit easier, and typically it was SELinux, but no longer being able to just run 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables core dumps on services by default (at least it did on Fedora, the documentation now says it's on by default. Huh. I should test that...)
Jon as a heads up this isn't a systemd/el7 thing necessarily...
Look at the daemon function in /etc/init.d/functions that most standard EL init scripts will be using...
Core files have been disabled on things started with that by default (need to export a variable in the environment of the script usually via sysconfig) the whole of el6 ...
On Tue, Jul 15, 2014 at 9:46 AM, James Hogarth james.hogarth@gmail.com wrote:
4.) Debugging. Why is my unit not starting when I can start it from the command line? Once I figured out journalctl it was a bit easier, and typically it was SELinux, but no longer being able to just run 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables core dumps on services by default (at least it did on Fedora, the documentation now says it's on by default. Huh. I should test that...)
Jon as a heads up this isn't a systemd/el7 thing necessarily...
Look at the daemon function in /etc/init.d/functions that most standard EL init scripts will be using...
Core files have been disabled on things started with that by default (need to export a variable in the environment of the script usually via sysconfig) the whole of el6 ...
Is there a simple generic equivalent to: sh -x /etc/rc.d/init.d/program_name start to see how configurations options that are abstracted out of the main files are being picked up and expanded?
Jonathan Billings wrote:
On Mon, Jul 14, 2014 at 09:50:18PM -0700, Keith Keller wrote:
On 2014-07-15, Jonathan Billings billings@negate.org wrote:
I've been using systemd ever since it was introduced in Fedora, and the RHEL7 beta and CentOS7 final since it came out. I could tell you about all the positive and negative experiences I've had.
<SNIP>
3.) Old SysVinit services that did something other than start/stop/restart/status no longer work. While this was nice for consistency, it means that porting to systemd will require alternative methods. This really bugged me at first, but from the perspective of a systems management person, I can see why it was kind of a hack, and not consistently implemented.
<snip> This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.
mark
On 07/15/2014 11:33 AM, m.roth@5-cent.us wrote:
This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.
systemctl reload $unit
Documented in the systemctl(1) man page.
If the unit(s) you want to reload don't support that, and you want to reload more than one unit's configuration in one command, you use systemctl reload-or-restart $unit
(I've wanted that one for a while, and 'service' doesn't do that, along with globbing of the name; that is 'systemctl reload-or-restart httpd*' (with proper quoting) will restart or reload all running units that match the glob; yeah, now on my load-balanced multiple-frontends plone installation I could 'systemctl reload-or-restart plone-*' and it will do the right thing, no matter how many frontend instances I have selected for running.... That's actually pretty cool.
There are quite a few of the commands that systemctl supports that I have wanted for 'service' for a long time.
Lamar Owen wrote:
On 07/15/2014 11:33 AM, m.roth@5-cent.us wrote:
This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.
systemctl reload $unit
Documented in the systemctl(1) man page.
<snip> Which contradicts the long post from the guy I was responding to, who said it *only* did start, stop, restart....
mark
On Tue, Jul 15, 2014 at 11:57:10AM -0400, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/15/2014 11:33 AM, m.roth@5-cent.us wrote:
This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.
systemctl reload $unit
Documented in the systemctl(1) man page.
<snip> Which contradicts the long post from the guy I was responding to, who said it *only* did start, stop, restart....
What I meant is that it doesn't support extra action verbs, such as 'service httpd configtest'. I didn't mean to indicate that it ONLY supported start, stop, restart and status.
You can still run apache's configtest
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
httpd Service Control With the migration away from SysV init scripts, server administrators should switch to using the apachectl and systemctl commands to control the service, in place of the service command. The following examples are specific to the httpd service. The command: service httpd graceful is replaced by apachectl graceful The command: service httpd configtest is replaced by apachectl configtest The systemd unit file for httpd has different behavior from the init script as follows: A graceful restart is used by default when the service is reloaded. A graceful stop is used by default when the service is stopped.
Thanks, Richard
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jonathan Billings Sent: Tuesday, July 15, 2014 12:01 PM To: CentOS mailing list Subject: Re: [CentOS] Cemtos 7 : Systemd alternatives ?
On Tue, Jul 15, 2014 at 11:57:10AM -0400, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On 07/15/2014 11:33 AM, m.roth@5-cent.us wrote:
This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.
systemctl reload $unit
Documented in the systemctl(1) man page.
<snip> Which contradicts the long post from the guy I was responding to, who said it *only* did start, stop, restart....
What I meant is that it doesn't support extra action verbs, such as 'service httpd configtest'. I didn't mean to indicate that it ONLY supported start, stop, restart and status.
On Tue, 2014-07-15 at 12:00 -0400, Jonathan Billings wrote:
What I meant is that it doesn't support extra action verbs, such as 'service httpd configtest'. I didn't mean to indicate that it ONLY supported start, stop, restart and status.
So, in C7, how do I do a
system httpd configtest ?
Am I going to lose that facility in C7?
On 2014-07-15, Always Learning centos@u62.u22.net wrote:
So, in C7, how do I do a
system httpd configtest ?
Am I going to lose that facility in C7?
apachectl configtest
(which is all the init script does anyway)
--keith
On 07/15/2014 11:57 AM, m.roth@5-cent.us wrote:
Which contradicts the long post from the guy I was responding to, who said it *only* did start, stop, restart....
I figured it was a typo on his part, leaving out 'reload' like that, as condrestart is also missing, and it's part of the standard set. I took it more as, for instance, the PostgreSQL initscript's 'initdb' command, which is a unique one, is no longer directly supported as a command line option. I haven't looked at what PostgreSQL's unit under C7 does as yet if a database instance doesn't exist, but I'm sure it's already been thought through; I'll cross that bridge when I come to it.
Read the man page for yourself.
On Tue, 2014-07-15 at 11:33 -0400, m.roth@5-cent.us wrote:
This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.
That's easy. I just type: sv httpd reload
(sv is my system-wide abbreviation for system, 'cos I'm lazy)
On 2014-07-15, Jonathan Billings billings@negate.org wrote:
Ok, I'll give some examples of my experiences. Warning: long post.
Long, but really helpful. Thank you so much for putting your time in!
So, the things that have bothered me so far: 1.) The order of the 'service SERVICENAME start|stop|status' options is reversed for 'systemctl start|stop|status SERVICENAME.service'
Yes, I've seen this too with initctl. Grr! But that's mostly cosmetic, and just something to get used to (as you have).
2.) Daemons under systemd don't really need to daemonize anymore. In the past, to start up a daemon process, you'd need to fork (or double-fork) and disconnect STDIN, STDOUT and STDERR file descriptors. This was just accepted knowledge. You don't need to do that anymore in systemd service units. Heck, write to stdout or stderr, it'll be recorded in the journal. Check out the openssh-server service unit, you'll see that sshd is run with -D there. Systemd supports daemonized services, it's just not necessary anymore.
How is logging handled if services are printing to stdout? Does systemd separate logs (if told to) so that e.g. my sshd logs are separate from my postfix logs?
4.) Debugging. Why is my unit not starting when I can start it from the command line? Once I figured out journalctl it was a bit easier, and typically it was SELinux, but no longer being able to just run 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables core dumps on services by default (at least it did on Fedora, the documentation now says it's on by default. Huh. I should test that...)
Hmm, this seems most problematic of the issues you've described so far. Is journalctl the way to get to stdout/err of a systemd unit? If a service fails, where is that failure logged, and where is the output of the failed executable logged?
Thanks for your patience in this sometimes frustrating thread. ;-)
--keith
On Jul 15, 2014, at 4:16 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2014-07-15, Jonathan Billings billings@negate.org wrote:
2.) Daemons under systemd don't really need to daemonize anymore. In the past, to start up a daemon process, you'd need to fork (or double-fork) and disconnect STDIN, STDOUT and STDERR file descriptors. This was just accepted knowledge. You don't need to do that anymore in systemd service units. Heck, write to stdout or stderr, it'll be recorded in the journal. Check out the openssh-server service unit, you'll see that sshd is run with -D there. Systemd supports daemonized services, it's just not necessary anymore.
How is logging handled if services are printing to stdout? Does systemd separate logs (if told to) so that e.g. my sshd logs are separate from my postfix logs?
Service stdout logging goes to the journal and is copied to rsyslog, log entries are tagged with the control group they came from, in addition to the process name, so it is easy to see any logs, whether via syslog or stdout, generated by any process in the sshd.service control group, or postfix.service control group.
$ journalctl --follow _SYSTEMD_UNIT=sshd.service
man systemd.journal-fields for a list of all the fields you can search on
4.) Debugging. Why is my unit not starting when I can start it from the command line? Once I figured out journalctl it was a bit easier, and typically it was SELinux, but no longer being able to just run 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables core dumps on services by default (at least it did on Fedora, the documentation now says it's on by default. Huh. I should test that...)
Hmm, this seems most problematic of the issues you've described so far. Is journalctl the way to get to stdout/err of a systemd unit? If a service fails, where is that failure logged, and where is the output of the failed executable logged?
When you view the status of a service with systemctl it shows you the command line, when it last tried to start it, what processes are associated with the service if any are running, what the exit code was, and the last few lines from the journal of anything logged by that service, so is kind of a one-stop-shop. For example:
$ systemctl status sshd sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled) Active: active (running) since Thu 2014-07-10 20:55:47 CDT; 4 days ago Process: 1149 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS) Main PID: 1164 (sshd) CGroup: /system.slice/sshd.service └─1164 /usr/sbin/sshd -D
Jul 10 20:55:47 localhost systemd[1]: Starting OpenSSH server daemon... Jul 10 20:55:47 localhost systemd[1]: Started OpenSSH server daemon. Jul 10 20:55:48 localhost sshd[1164]: Server listening on 0.0.0.0 port 22. Jul 10 20:55:48 localhost sshd[1164]: Server listening on :: port 22.
$ sudo systemctl stop sshd $ systemctl status sshd sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled) Active: inactive (dead) since Tue 2014-07-15 17:29:09 CDT; 3s ago Process: 1164 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS) Process: 1149 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS) Main PID: 1164 (code=exited, status=0/SUCCESS)
Jul 10 20:55:47 localhost systemd[1]: Starting OpenSSH server daemon... Jul 10 20:55:47 localhost systemd[1]: Started OpenSSH server daemon. Jul 10 20:55:48 localhost sshd[1164]: Server listening on 0.0.0.0 port 22. Jul 10 20:55:48 localhost sshd[1164]: Server listening on :: port 22. Jul 15 17:29:09 localhost systemd[1]: Stopping OpenSSH server daemon... Jul 15 17:29:09 localhost sshd[1164]: Received signal 15; terminating. Jul 15 17:29:09 localhost systemd[1]: Stopped OpenSSH server daemon.
— Mark Tinberg, System Administrator Division of Information Technology - Network Services University of Wisconsin - Madison mtinberg@wisc.edu
On Mon, Jul 14, 2014 at 11:50 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
- See the systemd myths web page
In the interest of full disclosure, that page is written by one of the primary authors of systemd, so we shouldn't expect an unbiased opinion. (Not saying it's wrong, only that it's important to understand the perspective an author might have.)
One thing that bothers me very much when reading that is the several mentions of how you don't need to learn shell syntax as though that is an advantage or as if the author didn't already know and use it already. As if he didn't understand that _every command you type at the command line_ is shell syntax. Or as if he thinks learning a bunch of special-case language quirks is somehow better than one that you can use in many other situations. When you get something that fundamental wrong it is hard to take the rest seriously.
On Tue, Jul 15, 2014 at 10:01:34AM -0500, Les Mikesell wrote:
On Mon, Jul 14, 2014 at 11:50 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
- See the systemd myths web page
In the interest of full disclosure, that page is written by one of the primary authors of systemd, so we shouldn't expect an unbiased opinion. (Not saying it's wrong, only that it's important to understand the perspective an author might have.)
One thing that bothers me very much when reading that is the several mentions of how you don't need to learn shell syntax as though that is an advantage or as if the author didn't already know and use it already. As if he didn't understand that _every command you type at the command line_ is shell syntax. Or as if he thinks learning a bunch of special-case language quirks is somehow better than one that you can use in many other situations. When you get something that fundamental wrong it is hard to take the rest seriously.
You mean this paragraph?
"systemd certainly comes with a learning curve. Everything does. However, we like to believe that it is actually simpler to understand systemd than a Shell-based boot for most people. Surprised we say that? Well, as it turns out, Shell is not a pretty language to learn, it's syntax is arcane and complex. systemd unit files are substantially easier to understand, they do not expose a programming language, but are simple and declarative by nature. That all said, if you are experienced in shell, then yes, adopting systemd will take a bit of learning."
I think the point is that systemd unit file syntax is significantly simpler than shell syntax -- can we agree on that? It also is significantly less-featureful than a shell programming language. Yes, you're going to be using shell elsewhere, but in my experience, the structure of most SysVinit scripts is nearly identical, and where it deviates is where things often get confusing to people not as familiar with shell scripting. Many of the helper functions in /etc/rc.d/init.d/functions seem to exist to STOP people from writing unique shell code in their init scripts.
On Tue, Jul 15, 2014 at 10:18 AM, Jonathan Billings billings@negate.org wrote:
- See the systemd myths web page
In the interest of full disclosure, that page is written by one of the primary authors of systemd, so we shouldn't expect an unbiased opinion. (Not saying it's wrong, only that it's important to understand the perspective an author might have.)
One thing that bothers me very much when reading that is the several mentions of how you don't need to learn shell syntax as though that is an advantage or as if the author didn't already know and use it already. As if he didn't understand that _every command you type at the command line_ is shell syntax. Or as if he thinks learning a bunch of special-case language quirks is somehow better than one that you can use in many other situations. When you get something that fundamental wrong it is hard to take the rest seriously.
You mean this paragraph?
"systemd certainly comes with a learning curve. Everything does. However, we like to believe that it is actually simpler to understand systemd than a Shell-based boot for most people. Surprised we say that? Well, as it turns out, Shell is not a pretty language to learn, it's syntax is arcane and complex. systemd unit files are substantially easier to understand, they do not expose a programming language, but are simple and declarative by nature. That all said, if you are experienced in shell, then yes, adopting systemd will take a bit of learning."
I think the point is that systemd unit file syntax is significantly simpler than shell syntax -- can we agree on that?
No. Everything you type on a command line is shell syntax. If you don't think that is an appropriate way to start programs you probably shouldn't be using a unix-like system, much less redesigning it. If you don't think the shell is the best tool, how about fixing it so it will be the best in all situations.
It also is significantly less-featureful than a shell programming language. Yes, you're going to be using shell elsewhere, but in my experience, the structure of most SysVinit scripts is nearly identical, and where it deviates is where things often get confusing to people not as familiar with shell scripting. Many of the helper functions in /etc/rc.d/init.d/functions seem to exist to STOP people from writing unique shell code in their init scripts.
Yes, reusing common code and knowledge is a good thing. But spending a bit of time learning shell syntax will help you with pretty much everything else you'll ever do on a unix-like system, where spending that time learning a new way to make your program start at boot will just get you back to what you already could do on previous systems.
On Tue, Jul 15, 2014 at 10:32:16AM -0500, Les Mikesell wrote:
On Tue, Jul 15, 2014 at 10:18 AM, Jonathan Billings billings@negate.org wrote:
I think the point is that systemd unit file syntax is significantly simpler than shell syntax -- can we agree on that?
No. Everything you type on a command line is shell syntax. If you don't think that is an appropriate way to start programs you probably shouldn't be using a unix-like system, much less redesigning it. If you don't think the shell is the best tool, how about fixing it so it will be the best in all situations.
Yes, everything you type in a shell uses shell syntax. But systemd doesn't use a shell to start a program for a service. This has nothing to do with how programs are started from a shell, but rather how the init system is starting the program. Simplified, declaritive syntax, no need to write the entire logical sequence for handling the action verb parameter for each script ("Whoops! I forgot that ;; in the case statement!"). That's simpler.
It also is significantly less-featureful than a shell programming language. Yes, you're going to be using shell elsewhere, but in my experience, the structure of most SysVinit scripts is nearly identical, and where it deviates is where things often get confusing to people not as familiar with shell scripting. Many of the helper functions in /etc/rc.d/init.d/functions seem to exist to STOP people from writing unique shell code in their init scripts.
Yes, reusing common code and knowledge is a good thing. But spending a bit of time learning shell syntax will help you with pretty much everything else you'll ever do on a unix-like system, where spending that time learning a new way to make your program start at boot will just get you back to what you already could do on previous systems.
If the entirety of the Linux startup process was written in simple shell code, that might be a useful line of argument, but even in CentOS6 there was a non-shell init system (Upstart) which requires understanding of a domain-specific language, plus dozens of other various configurations, like xinetd, cron, anacron, gdm, etc which start processes on boot. Each has their quirks. Not all of them use shell syntax, and even those that did had caveats. systemd just replaces Upstart, and can potentially replace xinetd and cron as well, using the same syntax and bringing in the ability to refer to each other for startup sequence management.
I'm not arguing that you shouldn't learn shell programming (and I don't believe that Mr. Poettering is either), just that systemd units flattens the learning curve for creating new unit files.
On Tue, 15 Jul 2014 10:32:16 -0500 Les Mikesell lesmikesell@gmail.com wrote:
On Tue, Jul 15, 2014 at 10:18 AM, Jonathan Billings billings@negate.org wrote:
It also is significantly less-featureful than a shell programming language. Yes, you're going to be using shell elsewhere, but in my experience, the structure of most SysVinit scripts is nearly identical, and where it deviates is where things often get confusing to people not as familiar with shell scripting. Many of the helper functions in /etc/rc.d/init.d/functions seem to exist to STOP people from writing unique shell code in their init scripts.
Yes, reusing common code and knowledge is a good thing. But spending a bit of time learning shell syntax will help you with pretty much everything else you'll ever do on a unix-like system, where spending that time learning a new way to make your program start at boot will just get you back to what you already could do on previous systems.
Les, I could re-use your logic to argue that one should never even try to learn bash, and stick to C instead. Every *real* user of UNIX-like systems should be capable of writing C code, which is used in so many more circumstances than bash. C is so much more powerful, more expressive, immensely faster, covers a broader set of use-cases, is being used in so many more circumstances than bash, is far more generic, and in the long run it's a good investment in programming skills and knowledge.
Why would you ever want to start your system using some clunky shell-based interpreter like bash, (which cannot even share memory between processes in a native way), when you can simply write a short piece of C code, fork() all your services, compile it, and run?
All major pieces of any UNIX-like system were traditionally written in C, so what would be the point of ever introducing a less powerful language like bash, and doing the system startup in that?
And if you really insist on writing commands interactively into a command prompt, you are welcome to use tcsh, and reuse all the syntax and well-earned knowledge of C, rather than invest time to learn yet-another-obscure-scripting-language...
Right? Or not?
If not, you may want to reconsider your argument against systemd --- it's simple, clean, declarative, does one thing and does it well, and it doesn't pretend to be a panacea of system administration like bash does.
HTH, :-) Marko
On Tue, Jul 15, 2014 at 11:56 AM, Marko Vojinovic vvmarko@gmail.com wrote:
Yes, reusing common code and knowledge is a good thing. But spending a bit of time learning shell syntax will help you with pretty much everything else you'll ever do on a unix-like system, where spending that time learning a new way to make your program start at boot will just get you back to what you already could do on previous systems.
Les, I could re-use your logic to argue that one should never even try to learn bash, and stick to C instead.
You could, if every command typed by every user since unix v7 had been parsed with C syntax instead of shell so there would be something they could 'stick to'. But, that's not true.
Every *real* user of UNIX-like systems should be capable of writing C code, which is used in so many more circumstances than bash.
That might be true, but it is irrelevant.
Why would you ever want to start your system using some clunky shell-based interpreter like bash, (which cannot even share memory between processes in a native way), when you can simply write a short piece of C code, fork() all your services, compile it, and run?
If you think bash is 'clunky', then why even run an operating system where it is used as the native user interface? Or, if you need to change something, why not fix bash to have the close mapping to system calls that bourne shell had back in the days before sockets?
And if you really insist on writing commands interactively into a command prompt, you are welcome to use tcsh, and reuse all the syntax and well-earned knowledge of C, rather than invest time to learn yet-another-obscure-scripting-language...
Right? Or not?
Well, Bill Joy thought so. I wouldn't argue with him about it for his own use, but for everyone else it is just another incompatible waste of human time.
If not, you may want to reconsider your argument against systemd --- it's simple, clean, declarative, does one thing and does it well, and it doesn't pretend to be a panacea of system administration like bash does.
I'm sure it can work - and will. But I'm equally sure that in my lifetime the cheap computer time it might save for me in infrequent server reboots will never be a win over the expensive human time for the staff training and new documentation that will be needed to deal with it and the differences in the different systems that will be running concurrently for a long time.
The one place it 'seems' like it should be useful would be on a laptop if it handles sleep mode gracefully, but on the laptop where I've been testing RHEL7 beta it seems purely random whether it will wake from sleep and continue or if it will have logged me out. And I don't have a clue how to debug it.
On Tue, 2014-07-15 at 10:32 -0500, Les Mikesell wrote:
.... spending that time learning a new way to make your program start at boot will just get you back to what you already could do on previous systems.
So what is the advantage of systemd? I accept we have to use it in C7, but how is systemd going to improve the usability and reliability of Centos ?
On 7/15/2014 10:00 AM, Always Learning wrote:
So what is the advantage of systemd? I accept we have to use it in C7, but how is systemd going to improve the usability and reliability of Centos ?
the big thing with any of these new service managers (I'm more familiar with Solaris SMF than systemd, but I believe it does the same thing), is that it determines whether the service properly starts and tracks service dependencies. sysVinit style services could only be sequenced (start all lower numbered services before starting this one) and it had to wait for each service to start before going onto the next, while SMF and presumably systemd will start multiple services in parallel as long as they aren't dependent. also, SMF at least detects when a service fails/stops, and attempts to take corrective action per how that service is configured
On Tue, 2014-07-15 at 10:25 -0700, John R Pierce wrote:
the big thing with any of these new service managers (I'm more familiar with Solaris SMF than systemd, but I believe it does the same thing), is that it determines whether the service properly starts and tracks service dependencies. sysVinit style services could only be sequenced (start all lower numbered services before starting this one) and it had to wait for each service to start before going onto the next, while SMF and presumably systemd will start multiple services in parallel as long as they aren't dependent. also, SMF at least detects when a service fails/stops, and attempts to take corrective action per how that service is configured
Thank you for the enlightening information.