On Thu, October 22, 2015 17:25, Valeri Galtsev wrote:
. . . Still, disregarding the part some of us dislike personally (plus often reboots necessary to install some vital updates
- which all Linuxes are prone to beginning somewhere around
2.6 kernel) . . .
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
James B. Byrne wrote:
On Thu, October 22, 2015 17:25, Valeri Galtsev wrote:
. . . Still, disregarding the part some of us dislike personally (plus often reboots necessary to install some vital updates
- which all Linuxes are prone to beginning somewhere around
2.6 kernel) . . .
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
So systemd moves Linux to more resemble Windows?
mark
On Fri, October 23, 2015 8:46 am, m.roth@5-cent.us wrote:
James B. Byrne wrote:
On Thu, October 22, 2015 17:25, Valeri Galtsev wrote:
. . . Still, disregarding the part some of us dislike personally (plus often reboots necessary to install some vital updates
- which all Linuxes are prone to beginning somewhere around
2.6 kernel) . . .
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
So systemd moves Linux to more resemble Windows?
I regret James cut out positive part I said - about great job both RH and CentOS teams are doing!
But coming back to negative part (which is about almost any Linux distribution). These often reboots started in my recollection around 2.6 kernel which is long ago. Already then one of my friends started calling Linux "Lindoze" apparently stressing you need to reboot it often, like MS Windows. I would suggest to take his label with a grain of salt, as he is the one who also used funny name for another well known system, after Oracle bough out Sun Microsystems he called Sun-Oracle "snorkel" (as if you pronounce it awfully fast).
This was what made first step to "similarity" at least in one respect of Linux to MS Windows. Is systemd yet another step? No comment from me, as at some point I decided to not be on any side of apparently awfully polarized on this issue community. ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, 23 Oct 2015, Valeri Galtsev wrote:
But coming back to negative part (which is about almost any Linux distribution). These often reboots started in my recollection around 2.6 kernel which is long ago.
There's no way that needing a reboot is related to 2.6. Indeed newer features like ksplice can /reduce/ the number of reboots required.
jh
On Fri, October 23, 2015 9:40 am, John Hodrien wrote:
On Fri, 23 Oct 2015, Valeri Galtsev wrote:
But coming back to negative part (which is about almost any Linux distribution). These often reboots started in my recollection around 2.6 kernel which is long ago.
I always admire the "creative trimming". You can really quite shift what one tried to say. The above is _not_ the point I tried to make! ;-)
Valeri
There's no way that needing a reboot is related to 2.6. Indeed newer features like ksplice can /reduce/ the number of reboots required.
jh _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Oct 23, 2015, at 9:46 AM, m.roth@5-cent.us wrote:
James B. Byrne wrote:
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
So systemd moves Linux to more resemble Windows?
No. If anything, systemd handles upgrades better than SysV init, since it handles re-execing better. Please stop spreading FUD.
Most likely the glibc and openssl updates are what people are talking about. Doesn’t require a reboot, just restarting all the services that might have those libraries loaded.
-- Jonathan Billings billings@negate.org
On 10/23/2015 12:51 PM, Jonathan Billings wrote:
No. If anything, systemd handles upgrades better than SysV init, since it handles re-execing better. Please stop spreading FUD.
Most likely the glibc and openssl updates are what people are talking about. Doesn’t require a reboot, just restarting all the services that might have those libraries loaded.
and of course, new kernels generally require a reboot, unless you've got that live kernel update thing running (which scares the heck out of me).
Jonathan Billings wrote:
On Oct 23, 2015, at 9:46 AM, m.roth@5-cent.us wrote:
James B. Byrne wrote:
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
So systemd moves Linux to more resemble Windows?
No. If anything, systemd handles upgrades better than SysV init, since it handles re-execing better. Please stop spreading FUD.
<snip> What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what's going on, just worked or didn't, so I don't know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It's much less informative in most ways in helping me solve problems.
mark
On Fri, 23 Oct 2015 22:44, m.roth@5-cent.us <m.roth@...> wrote:
Jonathan Billings wrote:
On Oct 23, 2015, at 9:46 AM, m.roth@5-cent.us wrote:
James B. Byrne wrote:
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
So systemd moves Linux to more resemble Windows?
No. If anything, systemd handles upgrades better than SysV init, since it handles re-execing better. Please stop spreading FUD.
<snip> What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what's going on, just worked or didn't, so I don't know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It's much less informative in most ways in helping me solve problems.
Well, looking back, during kernel 2.6 there was no systemd at all. But! That was the time where udev and dbus came into the boot cycle.
IMHO, the intrinsics between glibc (always a cause for refresh of initrd and full reboot) and udev where the start of the "reboot often".
Later on came dbus from the pure app-message-bus to the monster (kdbus?) that it is now, adding in its own dreg of dependencies and making the boot cycle unclean in itself.
The mess we have now, is not the work of just one change.
What was the rationale to get udev into boot? -- Handling the ever changing mess of plugable, switchable hardware. Not born and bred for servers, but for mobiles (phones, tablets, laptops).
Who was the one that decided that "one-size-fits-all" and put that into server environment?
What was the rationale to let dbus near the system start at all? -- Again mobile development.
Same as before who was the one that thought, "nice, lets fuck up the servers even more with that".
Systemd was just the latest development, and not the worst. Yes, it could have gone better, and some of the devs have had more head-in-the-clouds than feet-on-the-ground.
Looking back, systemd is the only "big" change since 2.6 that makes sense for servers. It's surrounding scene, however, does not make much sense for servers. Journald is a mess, but solveable -- install a "real" syslogd and get on with life.
The mess that is networking, well, that could have / should have gone better. Lets not cast out the babe with the wash-water, through.
That the difference between Linux servers and MS-Windows server got smaller is a matter of both sides.
The difference between a MS-Win 2k server and a MS-Win 2016 server is much more than just 16 years.
MS-Win 2016 kann be headless. A break-trough, 2012 was partly there.
What was the jump forward for linux servers in this 16 years?
We have lost some of the original Unix way: every tool should do one thing, and should do it right, be as small and as fast as possible.
MicroSoft seems to have learned from its errors.
Linux, well, atm we make them, and en mass.
- Yamaban.
PS: PHP devs should keep an eye on PHP 7. That will be ugly for every one that ignores the warning signs. Operators and Declarations esp.
On 10/23/2015 05:45 PM, Yamaban wrote:
Well, looking back, during kernel 2.6 there was no systemd at all. But! That was the time where udev and dbus came into the boot cycle. ... What was the rationale to get udev into boot? -- Handling the ever changing mess of plugable, switchable hardware. Not born and bred for servers, but for mobiles (phones, tablets, laptops). ... What was the rationale to let dbus near the system start at all? -- Again mobile development.
Was it? Many servers are deployed as standard images, both physical and virtual, and having a single, standard, cloned image boot easily on multiple types of hardware makes lots of sense in this environment. Dbus is about hardware enumeration, both cold and hot plug. And there are servers with hotplug PCIe, even hotplug CPU's. Dbus makes hotplug HDD support smoother, for instance, and hotplug isn't limited to USB or firewire (eSATA and external SAS, even fibre channel, can be hotplugged in most cases).
I still remember having to rebuild initrds when moving a clone from a server with one type of disk controller to another. It should work a lot better with dynamic hardware detection in the initrd. (I wont's say it's prefect, because I haven't personally tried every possible combination of hardware, but it has worked lately when I needed it to work.)
A SAN storage processor, for instance, must be able to hotplug drives, enclosures, front end and back end interfaces, power supplies, and sometimes even processors while staying up.
Systemd was just the latest development, and not the worst. Yes, it could have gone better, and some of the devs have had more head-in-the-clouds than feet-on-the-ground.
Looking back, systemd is the only "big" change since 2.6 that makes sense for servers. ...
I would agree.
What was the jump forward for linux servers in this 16 years?
Better hardware support, ease of virtualization (as a guest and as a host), and dynamic hardware detection for rapid redeployment/hardware upgrade, just to mention three.
On 10/24/2015 10:08 AM, Lamar Owen wrote:
Was it? Many servers are deployed as standard images, both physical and virtual, and having a single, standard, cloned image boot easily on multiple types of hardware makes lots of sense in this environment. Dbus is about hardware enumeration, both cold and hot plug. And there are servers with hotplug PCIe, even hotplug CPU's. Dbus makes hotplug HDD support smoother, for instance, and hotplug isn't limited to USB or firewire (eSATA and external SAS, even fibre channel, can be hotplugged in most cases).
s/Dbus/Udev/g
Argh. Long morning already.
On 10/23/2015 03:44 PM, m.roth@5-cent.us wrote:
Jonathan Billings wrote:
On Oct 23, 2015, at 9:46 AM, m.roth@5-cent.us wrote:
James B. Byrne wrote:
I am glad to discover that I am not losing my mind. I too have been rather dismayed at the perceived increase in frequency with which I must reboot my servers. I wondered whether this was simply a misconception on my part or an actual change in the environment.
Apparently it is the later.
So systemd moves Linux to more resemble Windows?
No. If anything, systemd handles upgrades better than SysV init, since it handles re-execing better. Please stop spreading FUD.
<snip> What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what's going on, just worked or didn't, so I don't know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It's much less informative in most ways in helping me solve problems.
Jesus Christ .. do we really have to start ANOTHER systemd thread.
For the sake of everyone's sanity .. if you (any user, not mark specifically) don't want to use systemd, then please don't use CentOS-7. CentOS-7 contains systemd and where ever Red Hat puts it, CentOS will rebuild the source code.
If people don't like the distro, then use something else.
These lists are for providing USEFUL information to CentOS users .. flame threads will result in list users who are moderated.
On 2015-10-24, Johnny Hughes johnny@centos.org wrote:
For the sake of everyone's sanity .. if you (any user, not mark specifically) don't want to use systemd, then please don't use CentOS-7.
For example, you could help out with Devuan, which aims to remove systemd from Debian, or you can switch to Slackware, one of the few major distros not to even include systemd (so far).
Johnny, thank you for your efforts in trying to keep the mailing list on-topic. :)
--keith
On Sat, October 24, 2015 12:23 pm, Keith Keller wrote:
On 2015-10-24, Johnny Hughes johnny@centos.org wrote:
For the sake of everyone's sanity .. if you (any user, not mark specifically) don't want to use systemd, then please don't use CentOS-7.
For example, you could help out with Devuan, which aims to remove systemd from Debian, or you can switch to Slackware, one of the few major distros not to even include systemd (so far).
Or switch away from Linux, say, to (Free|Opnen|Net|PC-|...)BSD just to expand options. But to take advantage of the greatness of RHEL and CentOS life cycle you have to live with systemd and friends no matter what you thinks about them (you see, I already have convinced myself ;-).
And yes, thanks for everybody's effort to keep discussion off the insanely polarizing us topic(s).
Valeri
Johnny, thank you for your efforts in trying to keep the mailing list on-topic. :)
--keith
-- kkeller@wombat.san-francisco.ca.us
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 10/24/2015 01:59 PM, Valeri Galtsev wrote:
On Sat, October 24, 2015 12:23 pm, Keith Keller wrote:
On 2015-10-24, Johnny Hughes johnny@centos.org wrote:
For the sake of everyone's sanity .. if you (any user, not mark specifically) don't want to use systemd, then please don't use CentOS-7.
For example, you could help out with Devuan, which aims to remove systemd from Debian, or you can switch to Slackware, one of the few major distros not to even include systemd (so far).
Or switch away from Linux, say, to (Free|Opnen|Net|PC-|...)BSD just to expand options. But to take advantage of the greatness of RHEL and CentOS life cycle you have to live with systemd and friends no matter what you thinks about them (you see, I already have convinced myself ;-).
And yes, thanks for everybody's effort to keep discussion off the insanely polarizing us topic(s).
I am quite happy even for there to be a SIG to modify CentOS-7 to not require systemd and creating a variant of that branch. Those discussions (if enough volunteers were found to staff the SIG) would take place on the CentOS-Devel mailing list.
But what is of no use to anyone is another 500 mail flame thread about systemd being the devil.
Johnny, thank you for your efforts in trying to keep the mailing list on-topic. :)
On Mon, October 26, 2015 11:11 am, Johnny Hughes wrote:
On 10/24/2015 01:59 PM, Valeri Galtsev wrote:
On Sat, October 24, 2015 12:23 pm, Keith Keller wrote:
On 2015-10-24, Johnny Hughes johnny@centos.org wrote:
For the sake of everyone's sanity .. if you (any user, not mark
specifically) don't want to use systemd, then please don't use CentOS-7.
For example, you could help out with Devuan, which aims to remove
systemd from Debian, or you can switch to Slackware, one of the few major distros not to even include systemd (so far).
Or switch away from Linux, say, to (Free|Opnen|Net|PC-|...)BSD just to
expand options. But to take advantage of the greatness of RHEL and CentOS
life cycle you have to live with systemd and friends no matter what you
thinks about them (you see, I already have convinced myself ;-). And yes, thanks for everybody's effort to keep discussion off the insanely
polarizing us topic(s).
I am quite happy even for there to be a SIG to modify CentOS-7 to not
require systemd and creating a variant of that branch. Those
discussions (if enough volunteers were found to staff the SIG) would
take place on the CentOS-Devel mailing list.
I would be very interested in that. Not as a developer which I am not, but as an end user (or almost end user as I am sysadmin ;-) If that happens, will there be announcement on centos@centos.org list or I should subscribe to CentOS-Devel mailing list?
Valeri
But what is of no use to anyone is another 500 mail flame thread about
systemd being the devil.
Johnny, thank you for your efforts in trying to keep the mailing list
on-topic. :)
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Sat, 24 Oct 2015, Johnny Hughes wrote:
On 10/23/2015 03:44 PM, m.roth@5-cent.us wrote:
What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what's going on, just worked or didn't, so I don't know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It's much less informative in most ways in helping me solve problems.
Jesus Christ .. do we really have to start ANOTHER systemd thread.
Yes.
These lists are for providing USEFUL information to CentOS users ..
Let's get some information that might be useful:
Are binary logfiles an inherent part of systemd? If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.
Is the aforementioned dearth of information an inherent part of systemd? If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.
The evil of binary journals for people is fairly cut and dry. If data is only for another program, making it binary when it could easily be text is against unix philosophy and a bad design choice, but not proof of evil. When the data is text specifically to be read by people, choosing to make it binary is evil and rude.
flame threads will result in list users who are moderated.
E.g. Johhny Hughes?
What do threat posts result in?
On 10/26/2015 12:19 PM, Michael Hennebry wrote:
On Sat, 24 Oct 2015, Johnny Hughes wrote:
On 10/23/2015 03:44 PM, m.roth@5-cent.us wrote:
What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what's going on, just worked or didn't, so I don't know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It's much less informative in most ways in helping me solve problems.
Jesus Christ .. do we really have to start ANOTHER systemd thread.
Yes.
These lists are for providing USEFUL information to CentOS users ..
Let's get some information that might be useful:
Are binary logfiles an inherent part of systemd? If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.
Is the aforementioned dearth of information an inherent part of systemd? If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.
The evil of binary journals for people is fairly cut and dry. If data is only for another program, making it binary when it could easily be text is against unix philosophy and a bad design choice, but not proof of evil. When the data is text specifically to be read by people, choosing to make it binary is evil and rude.
All of that might be true, however this is not the place to discuss that.
The goal if CentOS is to exactly build RHEL's source code. We do that. If that is not what you want in a Linux distribution, then CentOS is not for you .. that is just the facts.
We are not going to change something that is designed a certain way in RHEL source code.
So, that means that the place to have those discussions is not on a CentOS list, but on a list where something can be done about it. On the list where the code is actually developed, on a Fedora List or a RHEL list.
flame threads will result in list users who are moderated.
E.g. Johhny Hughes?
What do threat posts result in?
That is not a threat, it is a promise. I set the moderation bits on the list. I get dozens of emails off list asking for people to moderated on the flame fest emails.
We should all be adult and professional enough to understand that designing of software happens somewhere else and endlessly complaining about it here does nothing to get it fixed. It just annoys users who want to use centos and get help using it.
On Mon, Oct 26, 2015 at 04:42:49PM -0500, Johnny Hughes wrote:
That is not a threat, it is a promise. I set the moderation bits on the list. I get dozens of emails off list asking for people to moderated on the flame fest emails.
Johnny,
Thank you for providing this service to the community! I can understand why people are upset about systemd, but this isn't the place to rage about it.
-- greg
From https://lists.centos.org/mailman/listinfo/centos : CentOS -- CentOS mailing list
About CentOS English (USA)
This is a General discussion list for all issues CentOS. Security updates are currently announced on this list once daily. This list is read and reply for anyone that is a member of the mailing list.
To see the collection of prior postings to the list, visit the CentOS Archives.
On Mon, 26 Oct 2015, Johnny Hughes wrote:
On 10/26/2015 12:19 PM, Michael Hennebry wrote:
On Sat, 24 Oct 2015, Johnny Hughes wrote:
On 10/23/2015 03:44 PM, m.roth@5-cent.us wrote:
What FUD? It adds *binary* logfiles, readable only with a separate program; when I restart a service, it does not *tell* me what's going on, just worked or didn't, so I don't know, if it fails, where, the messages from journalctl are extremely unhelpful, and when it boots, if I want to watch, it tends to hide much info. It's much less informative in most ways in helping me solve problems.
Jesus Christ .. do we really have to start ANOTHER systemd thread.
Yes.
These lists are for providing USEFUL information to CentOS users ..
Let's get some information that might be useful:
Are binary logfiles an inherent part of systemd? If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.
Is the aforementioned dearth of information an inherent part of systemd? If so, equating systemd with the devil would seem appropriate. My expectation is that it is not.
The evil of binary journals for people is fairly cut and dry. If data is only for another program, making it binary when it could easily be text is against unix philosophy and a bad design choice, but not proof of evil. When the data is text specifically to be read by people, choosing to make it binary is evil and rude.
All of that might be true, however this is not the place to discuss that.
Of course this is the place to whine about systemd threads when journalctl is under discussion.
The goal if CentOS is to exactly build RHEL's source code. We do that. If that is not what you want in a Linux distribution, then CentOS is not for you .. that is just the facts.
We are not going to change something that is designed a certain way in RHEL source code.
The contents of /etc/ssh/ssh_config ?
Other post-install modifications are certainly possible. A demon that continuously makes text copies of the journalctl logs? A replacement for journalctl?
So, that means that the place to have those discussions is not on a CentOS list, but on a list where something can be done about it. On the list where the code is actually developed, on a Fedora List or a RHEL list.
flame threads will result in list users who are moderated.
E.g. Johhny Hughes?
What do threat posts result in?
That is not a threat, it is a promise. I set the moderation bits on the list. I get dozens of emails off list asking for people to moderated on the flame fest emails.
Call it a promise if you want. Denying that it is a threat is a bit much.
We should all be adult and professional enough to understand that designing of software happens somewhere else and endlessly complaining about it here does nothing to get it fixed. It just annoys users who want to use centos and get help using it.
-
Greg Lindahl -
James B. Byrne -
John Hodrien -
John R Pierce -
Johnny Hughes -
Jonathan Billings -
Keith Keller -
Lamar Owen -
m.roth＠5-cent.us -
Michael Hennebry -
Valeri Galtsev -
Yamaban