According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
On 09/04/17 05:39, Anthony K wrote:
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
All ideas, true or false, follow those stages, but one hopes that the false ones are eventually derided and toppled.
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
Accepting it as a fait accompli. It makes life much harder for no obvious gain, but short of creating one's own distro we seem to be stuck with it. To answer your question, a combination of proposition 1 and the first part of proposition 3.
For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly. Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.
On 04/09/2017 04:30 AM, J Martin Rushton wrote:
On 09/04/17 05:39, Anthony K wrote:
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
All ideas, true or false, follow those stages, but one hopes that the false ones are eventually derided and toppled.
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
Accepting it as a fait accompli. It makes life much harder for no obvious gain, but short of creating one's own distro we seem to be stuck with it. To answer your question, a combination of proposition 1 and the first part of proposition 3.
For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly. Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.
I agree. I never had a problem with init scripts. Anyone who understood bash/sh could fairly easily come to grips with init scripts. I have no idea where to look for whatever starts up services with systemd. What language is systemd written in...? no idea. Yes, I tried reading docs, but they're so vague and inscrutable that I gave up. E.g., what is a "unit"? Could they have picked a word more vague? What does "unit" tell us which "thing" doesn't? Basically, a service is either running or stopped... so what is "static"? "Static" means the opposite of "moving" or "dynamic". How does "static" describe a service?
In short, although computer geeks generally aren't known for being good at documentation, in the commercial world at any rate. But this is GNU/Linux. We rely on online documentation and the open source community to figure out problems and make improvements. Lacking sensible documentation, it's hard to figure out problems. If problems can't be figured out, we're faced with problematic systems. And who's going to tolerate that for long? How is that an improvement over Redmondware?
On Sun, Apr 09, 2017 at 09:30:20AM +0100, J Martin Rushton wrote:
For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly.
As someone who has both debugged and written many init scripts, I'm a big fan of the way systemd does things. Every distro provided their own shell functions, so you ended up with a debian init script, a redhat init script, and usually some weird "kinda works everywhere" init script that used neither and reinvented the wheel.
Quite often, what was going wrong was *NOT* apparent by glancing at the init script. How do you enforce limits on the service? Run ulimits in the script? The service starts fine if you run '/etc/rc.d/init.d/myservice start', but then if you run 'service myservice start', it fails. On top of that, there's no journal so you can't even *SEE* why it is failing during boot unless it is kind enough to write an error to the console. Hope you have a crash cart!
Also, how configurable is the init script? You had to hope that upstream was smart enough to use environment variables that were sourced from /etc/sysconfig/servicename. Sometimes I had to do evil things like put executable code into /etc/sysconfig/servicename which fixed problems with the init script.
Also, that reminds me, there's no simple way to override some or all of a packaged init script, except to provide your own alternative init script that had a different name. And don't get me started on the terrible startup sequence rules. I've seen several people who have edited the init script itself and then had it replaced by a yum update, breaking their service. The RPMs don't mark the init script as a config file.
Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.
I don't know... I find the unit syntax pretty simple to read. It says what processes are going to be run, what user it'll run under, you can see what order it wants to be run, etc. There are dozens of man pages for systemd, each with examples.
Don't get me wrong, I have a lot of anger about some of the stuff that systemd does. But lets not reminisce about SysVinit as if it was anything but a horrible mess. systemd's best feature is that it finally makes managing services better.
I'm ok with it as a init system, not much enthused by its ancillary components.
-- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro
----- Original Message -----
From: "Anthony K" akcentos@anroet.com To: "CentOS mailing list" centos@centos.org Sent: Sunday, 9 April, 2017 05:39:59 Subject: [CentOS] OT: systemd Poll
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 4/8/2017 9:39 PM, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I wish the documentation was a bit better. systemd and networkmanager definitely change the rules... I had a minimal C7 VM where I had a heck of a time getting it to use the right DNS servers, only way I got it set up was to use nmtui, my attempts at using nmcli were an exercise in frustration. maybe this is more of a networkmanager problem more than systemd, but they are both tied together in my mind.
On Sun, Apr 9, 2017 at 2:20 AM, John R Pierce pierce@hogranch.com wrote:
On 4/8/2017 9:39 PM, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I wish the documentation was a bit better. systemd and networkmanager definitely change the rules... I had a minimal C7 VM where I had a heck of a time getting it to use the right DNS servers, only way I got it set up was to use nmtui, my attempts at using nmcli were an exercise in frustration. maybe this is more of a networkmanager problem more than systemd, but they are both tied together in my mind.
Yes, lack of documentation is a big bug-a-boo in my mind also. However, I do think working with systemd is a bit like working with udev
hooks. My first experience with systemd was probably back in late 2011. In any case, the RH documentation on it may be beneficial at this point:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
or maybe take a look at the Fedora projects info:
https://www.freedesktop.org/wiki/Software/systemd/
-- john r pierce, recycling bits in santa cruz
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 04/09/2017 04:30 AM, J Martin Rushton wrote:
On 09/04/17 05:39, Anthony K wrote:
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
All ideas, true or false, follow those stages, but one hopes that the false ones are eventually derided and toppled.
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
Accepting it as a fait accompli. It makes life much harder for no obvious gain, but short of creating one's own distro we seem to be stuck with it. To answer your question, a combination of proposition 1 and the first part of proposition 3.
For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly. Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.
+1
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, April 10, 2017 7:29 am, Steve Clark wrote:
On 04/09/2017 04:30 AM, J Martin Rushton wrote:
On 09/04/17 05:39, Anthony K wrote:
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
All ideas, true or false, follow those stages, but one hopes that the false ones are eventually derided and toppled.
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
Accepting it as a fait accompli. It makes life much harder for no obvious gain, but short of creating one's own distro we seem to be stuck with it. To answer your question, a combination of proposition 1 and the first part of proposition 3.
For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly. Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.
The same here. Could repeat that word for word. I fled what I could to FreeBSD, but in that process systemd was just the last drop that confirmed that my earlier decision to abandon Linux to the extent I can was right. Whatever has to stay Linux sucks ... more time for any problem than it used to.
Valeri
+1
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com _______________________________________________ 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 ++++++++++++++++++++++++++++++++++++++++
Like you, I have been looking for alternatives to Linux due to systemd, SELinux, desktop environments gone way off course, etc. What can and can't be replaced with FreeBSD or other alternatives (and why)?
----- Original Message ----- From: "Valeri Galtsev" galtsev@kicp.uchicago.edu To: "centos" centos@centos.org Sent: Monday, April 10, 2017 8:38:03 AM Subject: Re: [CentOS] OT: systemd Poll
On Mon, April 10, 2017 7:29 am, Steve Clark wrote:
On 04/09/2017 04:30 AM, J Martin Rushton wrote:
On 09/04/17 05:39, Anthony K wrote:
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
All ideas, true or false, follow those stages, but one hopes that the false ones are eventually derided and toppled.
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
Accepting it as a fait accompli. It makes life much harder for no obvious gain, but short of creating one's own distro we seem to be stuck with it. To answer your question, a combination of proposition 1 and the first part of proposition 3.
For those of us with (in my case) over 30 years in the industry, reading init scripts is trivial and at least we can see what is going on and fix problems quickly. Some vague, poorly documented, data file which is interpreted by a black box is the sort of joy one expects from the murkier regions of Redmond not the sunnier climes of Carolina.
The same here. Could repeat that word for word. I fled what I could to FreeBSD, but in that process systemd was just the last drop that confirmed that my earlier decision to abandon Linux to the extent I can was right. Whatever has to stay Linux sucks ... more time for any problem than it used to.
Valeri
+1
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
-- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com _______________________________________________ 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 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 2017-04-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
The same here. Could repeat that word for word. I fled what I could to FreeBSD, but in that process systemd was just the last drop that confirmed that my earlier decision to abandon Linux to the extent I can was right. Whatever has to stay Linux sucks ... more time for any problem than it used to.
FWIW this is a distro issue, not a Linux issue. Slackware still has not switched to systemd IIRC. I would imagine there are other distros that haven't switched (yet).
--keith
On 04/08/2017 09:39 PM, Anthony K wrote:
According to "Arthur Schopenhauer":
"All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I am using systemd, don't really have a problem with it.
It was different at first but so far I manage to have adjusted.
It's different. For better or worse I can't say, but I can do what I need to do with it.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I've never had to write my own init scripts before so I'm not feeling the pain of others, but having professionally managed machines running SystemD for a while now honestly I don't mind it. While the language used (units, targets) is confusing and documentation could be better, there are some things I like about it more than SysVInit.
Once upon a time, Pete Orrall pete@cs1x.com said:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I've never had to write my own init scripts before so I'm not feeling the pain of others, but having professionally managed machines running SystemD for a while now honestly I don't mind it. While the language used (units, targets) is confusing and documentation could be better, there are some things I like about it more than SysVInit.
Yeah, the old init script setup was sorely lacking in some areas (especially dependencies). While there were well-written init scripts that were easy to understand, had plenty of configuration options, etc., there were many that were largely unreadable.
I like to distinguish systemd-the-pid-1 from systemd-the-project; I generally like systemd-the-pid-1 (it isn't perfect by any means, but I think it is an improvement). On the other hand, I dislike the scope creep and "replace all the wheels" approach of systemd-the-project.
Pete Orrall wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I've never had to write my own init scripts before so I'm not feeling the pain of others, but having professionally managed machines running SystemD for a while now honestly I don't mind it. While the language used (units, targets) is confusing and documentation could be better, there are some things I like about it more than SysVInit.
Don't look at me - I still *loathe* systemd. Change for no other reason than to put it on your resume, and write papers about.
Examples: is it service, or target, and where of many places do I have to look to find a given service name? Why change names, such as rpc-idmapd to nfs-idmapd? And I've just been fighting today, because I have to munge the MAC address for a workstation, because they have old software that is very usefull, and there's no budget to pay the company that bought the software $15k (no kidding) so that they can shift the license to the new workstation, and that's tied to eth0 and the MAC.
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
And the binary message log.... At home, I'm staying on CentOS 6 until it EoLs.
mark
I know this is systemd-punching day, but at least get your information straight.
On Mon, Apr 10, 2017 at 03:38:03PM -0400, m.roth@5-cent.us wrote:
Why change names, such as rpc-idmapd to nfs-idmapd?
Unrelated to systemd, as far as I can tell. Fedora adopted new names that made more sense, and it was incorporated into RHEL7.
And I've just been fighting today, because I have to munge the MAC address for a workstation, because they have old software that is very usefull, and there's no budget to pay the company that bought the software $15k (no kidding) so that they can shift the license to the new workstation, and that's tied to eth0 and the MAC.
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
Unrelated to systemd. This actually started happening in RHEL6 with the biosdevname feature. systemd can handle the NIC naming stuff, but it started happening well before systemd appeared in RHEL.
Having consistent device names is helpful when you've got more than one NIC and you don't want to rely on the order in which the network driver is loaded to define the interface name.
Le 10/04/2017 à 21:57, Jonathan Billings a écrit :
Having consistent device names is helpful when you've got more than one NIC and you don't want to rely on the order in which the network driver is loaded to define the interface name.
On my Slackware servers (no systemd, no funny network interface names), I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0 and eth1 (and eth2 etc.) if needed.
Keep It Simple.
On Mon, 2017-04-10 at 22:45 +0200, Nicolas Kovacs a écrit:
On my Slackware servers (no systemd, no funny network interface names), I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0 and eth1 (and eth2 etc.) if needed.
Keep It Simple.
Un bon idea ! Ich auch Ikki ook :-)
On 04/12/17 22:02, Always Learning wrote:
On Mon, 2017-04-10 at 22:45 +0200, Nicolas Kovacs a écrit:
On my Slackware servers (no systemd, no funny network interface names), I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0 and eth1 (and eth2 etc.) if needed.
Keep It Simple.
Un bon idea ! Ich auch Ikki ook :-)
That's even scientific: "entities shall not be multiplied without need" - Occam's razor.
mark
Jonathan Billings wrote: <snip>
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
Unrelated to systemd. This actually started happening in RHEL6 with the biosdevname feature. systemd can handle the NIC naming stuff, but it started happening well before systemd appeared in RHEL.
Having consistent device names is helpful when you've got more than one NIC and you don't want to rely on the order in which the network driver is loaded to define the interface name.
In what universe are those "consistant" device names, as opposed to eth[0...]? And how could it help automated scripts that you can run on *any* system you're administering?
mark
On 4/10/2017 1:57 PM, m.roth@5-cent.us wrote:
In what universe are those "consistant" device names, as opposed to eth[0...]? And how could it help automated scripts that you can run on *any* system you're administering?
if I have a Intel gigE interface and a Marvell 10g interfaces, which one is eth0 and why?
Say its Intel on eth0 and Marvell on eth1, if I then add another intel, is the Marvell now eth2 ?
On Mon, April 10, 2017 4:17 pm, John R Pierce wrote:
On 4/10/2017 1:57 PM, m.roth@5-cent.us wrote:
In what universe are those "consistant" device names, as opposed to eth[0...]? And how could it help automated scripts that you can run on *any* system you're administering?
if I have a Intel gigE interface and a Marvell 10g interfaces, which one is eth0 and why?
Say its Intel on eth0 and Marvell on eth1, if I then add another intel, is the Marvell now eth2 ?
Without intent to contradict... I really would prefer them numbered according to their bus address. Not in the order (or reverse order - as it was once) of them been discovered. And if you add hardware with bus address between those of eth0 and eth1, you will have newly added one become eth1, and former eth1 becomes eth2. I know, it stems from old idiotic habit to always look inside the boxes... call me an old UNIX outcast. (No, don't, that would be a complement I unlikely deserve ;-)
Valeri
-- john r pierce, recycling bits in santa cruz
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 4/10/2017 2:27 PM, Valeri Galtsev wrote:
Without intent to contradict... I really would prefer them numbered according to their bus address. Not in the order (or reverse order - as it was once) of them been discovered. And if you add hardware with bus address between those of eth0 and eth1, you will have newly added one become eth1, and former eth1 becomes eth2. I know, it stems from old idiotic habit to always look inside the boxes... call me an old UNIX outcast. (No, don't, that would be a complement I unlikely deserve
bus address is a somewhat nebulous concept on PCI, afaik, its not neccessarily slot specific. its even messier on things like USB
And to add to the issues concerning consistency, what if you have a fail over unit and you're replicating configuration (i.e. NIC), you really prefer that NIC names remain the same. Given the hardware morass underneath all of this, the only safe choice (regardless of whether you use systemd, init scripts, whatever) is to take control and force the association of the name to the MAC address in the appropriate file. It doesn't allow total configuration replication but it does allow enough (with judicious use of segregation) to be useful.
This does concern me, another post referred to the heavy-handed way in which systemd has been implemented and I totally agree. "You will conform" - no exceptions. What I fear is that we will lose the ability to control the name, MAC address association at some future point because "no one needs to do that" (speaking from their ivory tower).
----- Original Message ----- From: "John R Pierce" pierce@hogranch.com To: "centos" centos@centos.org Sent: Monday, April 10, 2017 4:36:48 PM Subject: Re: [CentOS] OT: systemd Poll
On 4/10/2017 2:27 PM, Valeri Galtsev wrote:
Without intent to contradict... I really would prefer them numbered according to their bus address. Not in the order (or reverse order - as it was once) of them been discovered. And if you add hardware with bus address between those of eth0 and eth1, you will have newly added one become eth1, and former eth1 becomes eth2. I know, it stems from old idiotic habit to always look inside the boxes... call me an old UNIX outcast. (No, don't, that would be a complement I unlikely deserve
bus address is a somewhat nebulous concept on PCI, afaik, its not neccessarily slot specific. its even messier on things like USB
On Tue, Apr 11, 2017 at 08:02:56AM -0500, Leroy Tennison wrote:
This does concern me, another post referred to the heavy-handed way in which systemd has been implemented and I totally agree. "You will conform" - no exceptions. What I fear is that we will lose the ability to control the name, MAC address association at some future point because "no one needs to do that" (speaking from their ivory tower).
To be honest, if you use systemd-networkd (instead of NM or the network init script), you can arbitrarily name your interfaces whatever you want, in a much more configuration-management-friendly way.
It's just that systemd-networkd isn't that well-known yet. I'm on the fence about whether I like it or not. It is nice that its really simple files and consistent across distros, but it doesn't yet do stuff like wifi well. Also, most GNOME desktops have a NM applet that gets confused if you're using systemd-networkd. I still feel like systemd-networkd is a lot less convoluted than NetworkManager.
https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.ht...
Jonathan Billings wrote:
On Tue, Apr 11, 2017 at 08:02:56AM -0500, Leroy Tennison wrote:
This does concern me, another post referred to the heavy-handed way in which systemd has been implemented and I totally agree. "You will conform" - no exceptions. What I fear is that we will lose the ability to control the name, MAC address association at some future point because "no one needs to do that" (speaking from their ivory tower).
To be honest, if you use systemd-networkd (instead of NM or the network init script), you can arbitrarily name your interfaces whatever you
want, in a
much more configuration-management-friendly way.
It's just that systemd-networkd isn't that well-known yet. I'm on the fence about whether I like it or not. It is nice that its really simple
files
and consistent across distros, but it doesn't yet do stuff like wifi well. Also, most GNOME desktops have a NM applet that gets confused if you're
using
systemd-networkd. I still feel like systemd-networkd is a lot less convoluted than NetworkManager.
https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.ht...
I may need to look into that. I mean, I've disliked NM since I first saw it in 6. I mean, why would I want it to even try wpa-supplicant on a wired network? And perhaps for home users or laptops, but for a server install, I NEVER want avahi running.
mark "Do what I tell you to do, and stop trying to think you know better"
Interesting, I'm going to have to look into this.
----- Original Message ----- From: "Jonathan Billings" billings@negate.org To: "centos" centos@centos.org Sent: Tuesday, April 11, 2017 8:32:49 AM Subject: Re: [CentOS] OT: systemd Poll
On Tue, Apr 11, 2017 at 08:02:56AM -0500, Leroy Tennison wrote:
This does concern me, another post referred to the heavy-handed way in which systemd has been implemented and I totally agree. "You will conform" - no exceptions. What I fear is that we will lose the ability to control the name, MAC address association at some future point because "no one needs to do that" (speaking from their ivory tower).
To be honest, if you use systemd-networkd (instead of NM or the network init script), you can arbitrarily name your interfaces whatever you want, in a much more configuration-management-friendly way.
It's just that systemd-networkd isn't that well-known yet. I'm on the fence about whether I like it or not. It is nice that its really simple files and consistent across distros, but it doesn't yet do stuff like wifi well. Also, most GNOME desktops have a NM applet that gets confused if you're using systemd-networkd. I still feel like systemd-networkd is a lot less convoluted than NetworkManager.
https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.ht...
John R Pierce wrote:
On 4/10/2017 1:57 PM, m.roth@5-cent.us wrote:
In what universe are those "consistant" device names, as opposed to eth[0...]? And how could it help automated scripts that you can run on *any* system you're administering?
if I have a Intel gigE interface and a Marvell 10g interfaces, which one is eth0 and why?
Say its Intel on eth0 and Marvell on eth1, if I then add another intel, is the Marvell now eth2 ?
And if I have a 5-yr-old Penguin (OEM-branded Supermicro), and a Dell PowerEdge R530 and an HP ProLiant dl580 and a hot-off-the-presses Penguin/Intel, what will their primary device be named?
As opposed to you installing a new NIC in addition to one that's there... which, since you've just installed it, I suppose you could add the UUID to whatever you want to name it.
mark
On 04/10/2017 05:17 PM, John R Pierce wrote:
On 4/10/2017 1:57 PM, m.roth@5-cent.us wrote:
In what universe are those "consistant" device names, as opposed to eth[0...]? And how could it help automated scripts that you can run on *any* system you're administering?
if I have a Intel gigE interface and a Marvell 10g interfaces, which one is eth0 and why?
Say its Intel on eth0 and Marvell on eth1, if I then add another intel, is the Marvell now eth2 ?
In my experience the new interface would be eth2, because the startup scripts create a mac binding to ethx name in the /etc/udev/rules.d/70-persistent-net.rules file, so even if the intel is probed before the marvel the scripts rename them to keep them in the original order.
Steve
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it's a change but it also makes sense. IIRC this is how FreeBSD handles NIC names.
On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it's a change but it also makes sense. IIRC this is how FreeBSD handles NIC names.
FreeBSD uses the driver in the name, such as bge0, em0, and so on, as opposed to bge0 or em0, depending upon the make of the card.
On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it's a change but it also makes sense. IIRC this is how FreeBSD handles NIC names.
It's true that FreeBSD names their network interfaces after the driver.
But the consistent device naming in Linux comes from slot index numbers, physical location and even the MAC (if so configured), and not what driver it uses.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
But the consistent device naming in Linux comes from slot index numbers, physical location and even the MAC (if so configured), and not what driver it uses.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Thanks for the clarification, John. I will check this out.
On 04/11/2017 05:30 AM, Jonathan Billings wrote:
On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it's a change but it also makes sense. IIRC this is how FreeBSD handles NIC names.
It's true that FreeBSD names their network interfaces after the driver.
But the consistent device naming in Linux comes from slot index numbers, physical location and even the MAC (if so configured), and not what driver it uses.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Okay that makes sense.
eno1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 0c:c4:7a:c8:a5:4c txqueuelen 1000 (Ethernet) eno2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 0c:c4:7a:c8:a5:4d txqueuelen 1000 (Ethernet)
Those two are my onboard nic, Intel - Scheme 1
enp10s0f0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:1b:21:94:72:37 txqueuelen 1000 (Ethernet) enp10s0f1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:1b:21:94:72:36 txqueuelen 1000 (Ethernet) enp9s0f0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:1b:21:94:72:35 txqueuelen 1000 (Ethernet) enp9s0f1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
Those four are on a PCI-E card, Intel - Scheme 3
05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 09:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
Anyway thanks for that link.
On 04/11/2017 05:39 AM, Alice Wonder wrote:
On 04/11/2017 05:30 AM, Jonathan Billings wrote:
On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:
And *why* random NIC names? Quick, you've got servers from 5 manufacturers, of different ages... what's the NIC going to be called? Do names like enp5s0 offer any convenience to *anyone* not a hardware engineer?
As someone else had stated, it's not related to SystemD but Fedora/RHEL has changed the way they handle some things. NICs, for instance, are no longer named after the device number (eth0, eth1, eth2, etc.) but after the *driver* name. Yes, it's a change but it also makes sense. IIRC this is how FreeBSD handles NIC names.
It's true that FreeBSD names their network interfaces after the driver.
But the consistent device naming in Linux comes from slot index numbers, physical location and even the MAC (if so configured), and not what driver it uses.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Okay that makes sense.
eno1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 0c:c4:7a:c8:a5:4c txqueuelen 1000 (Ethernet) eno2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 0c:c4:7a:c8:a5:4d txqueuelen 1000 (Ethernet)
Those two are my onboard nic, Intel - Scheme 1
enp10s0f0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:1b:21:94:72:37 txqueuelen 1000 (Ethernet) enp10s0f1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:1b:21:94:72:36 txqueuelen 1000 (Ethernet) enp9s0f0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:1b:21:94:72:35 txqueuelen 1000 (Ethernet) enp9s0f1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
Those four are on a PCI-E card, Intel - Scheme 3
05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 09:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
Anyway thanks for that link.
er, I meant to add that the 09: seems to correspond with the enp9s* and the 0a: seems to correspond with the enp10s*
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
It is what it is.
I can see that systemd may not look as straightforward as init scripts, but it has been clear for a while that SysVinit is generally not really fit-for-purpose. Things like the mystic incantations embedded in comments at the top to try and make chkconfig work properly, or the lack of a consistent approach to configuring parameters (are they embedded in the script? In /etc/sysconfig? The package's own config files?).
The fact that there was at one point multiple solutions to the problem (with systemd eventually becoming the accepted one) and that no dev is really going to voluntarily go through the pain and abuse of implementing something new like this shows that it really was thought to be necessary.
I think what is/was the issue is the abrasive way that some of it was done. It seems to have put people's backs up no end and makes them predisposed to find fault with it.
It's just different, that's all. It does the job it was designed to do. It even copes with legacy init scripts, so you can still use them if you want.
And I remember when these new fangled init scripts first appeared - boy did everyone find them confusing and hated them.
P.
On 4/10/2017 3:20 PM, Pete Biggs wrote:
And I remember when these new fangled init scripts first appeared - boy did everyone find them confusing and hated them.
indeed. BSD just used /etc/rc.conf and /etc/rc.d/{servicename}.... then AT&T SystemV came along with the whole levels and init.d and everything.
On 04/10/2017 03:20 PM, Pete Biggs wrote:
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
It is what it is.
I can see that systemd may not look as straightforward as init scripts, but it has been clear for a while that SysVinit is generally not really fit-for-purpose. Things like the mystic incantations embedded in comments at the top to try and make chkconfig work properly, or the lack of a consistent approach to configuring parameters (are they embedded in the script? In /etc/sysconfig? The package's own config files?).
The fact that there was at one point multiple solutions to the problem (with systemd eventually becoming the accepted one) and that no dev is really going to voluntarily go through the pain and abuse of implementing something new like this shows that it really was thought to be necessary.
I think what is/was the issue is the abrasive way that some of it was done. It seems to have put people's backs up no end and makes them predisposed to find fault with it.
It's just different, that's all. It does the job it was designed to do. It even copes with legacy init scripts, so you can still use them if you want.
And I remember when these new fangled init scripts first appeared - boy did everyone find them confusing and hated them.
P.
My first *IX system had only /etc/inittab and I had to manually add and configure inetd. Next generation used the bsd init system... Monolithic. No process start/stop, but I understood it. Then SystemV came along; Individual processes could be started, stopped, and queried. The came the function file and THAT was a complete mess... Every distro developer had his own idea of what functions were needed.
In all three of those cases, there was a single, simple start up entity. That was the literal binary program init. It read /etc/inittab and used that to handle process management and those management processes were completely transparent. Standardized, well known locations were used. It was considered to be a not just good practice, but excellent practice to do so. It wasn't commonly done, but it was relatively simple to swap between them too.
The current crop of system initialization systems, do everything possible to obscure the details of operation... Boot status on the console? Nope, obscured. Processes logged to standard places? Nope, someone might hijack the logs (we had a technique for that... remote logging, but that isn't important enough to make work... Too much trouble).
The bottom line seems to be, "I've looked at this, and I know better than 20, 30 years of experience, so throw it all out and do it my way"... And if things get broken in the process... Oh well, that's progress.
I've had my init system lose communication with the desktop gui and decide to reboot my system. Yes, systemd did that. dbus got an upgrade and was restarting so systemd rebooted my system.
While not directly a systemd problem, I've haddistro builds of apache that didn't work because of some patch "needed" so systemd could manage apache (We need systemd hooked so deeply into every process now?!). Yes, each of these was corrected... But they didn't need to happen and NEVER happened with earlier init systems.
The concepts in upstart, launchd, and systemd are mildly interesting to me and probably more so to others. The implementations of the ideas have been poorly thought out and tested. They cause so much trouble for me as to make them worthless to me. When complaints are registered, the response has often been "if we don't force it, it will never be tested". Completely unacceptable.
This is MY issue with the new shiny toy. Heedless and needless system breakage by an escaped lab rat.
On 04/10/2017 08:13 PM, Bruce Ferrell wrote:
On 04/10/2017 03:20 PM, Pete Biggs wrote:
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
It is what it is.
I can see that systemd may not look as straightforward as init scripts, but it has been clear for a while that SysVinit is generally not really fit-for-purpose. Things like the mystic incantations embedded in comments at the top to try and make chkconfig work properly, or the lack of a consistent approach to configuring parameters (are they embedded in the script? In /etc/sysconfig? The package's own config files?).
The fact that there was at one point multiple solutions to the problem (with systemd eventually becoming the accepted one) and that no dev is really going to voluntarily go through the pain and abuse of implementing something new like this shows that it really was thought to be necessary.
I think what is/was the issue is the abrasive way that some of it was done. It seems to have put people's backs up no end and makes them predisposed to find fault with it.
It's just different, that's all. It does the job it was designed to do. It even copes with legacy init scripts, so you can still use them if you want.
And I remember when these new fangled init scripts first appeared - boy did everyone find them confusing and hated them.
P.
My first *IX system had only /etc/inittab and I had to manually add and configure inetd. Next generation used the bsd init system... Monolithic. No process start/stop, but I understood it. Then SystemV came along; Individual processes could be started, stopped, and queried. The came the function file and THAT was a complete mess... Every distro developer had his own idea of what functions were needed.
In all three of those cases, there was a single, simple start up entity. That was the literal binary program init. It read /etc/inittab and used that to handle process management and those management processes were completely transparent. Standardized, well known locations were used. It was considered to be a not just good practice, but excellent practice to do so. It wasn't commonly done, but it was relatively simple to swap between them too.
The current crop of system initialization systems, do everything possible to obscure the details of operation... Boot status on the console? Nope, obscured. Processes logged to standard places? Nope, someone might hijack the logs (we had a technique for that... remote logging, but that isn't important enough to make work... Too much trouble).
The bottom line seems to be, "I've looked at this, and I know better than 20, 30 years of experience, so throw it all out and do it my way"... And if things get broken in the process... Oh well, that's progress.
I've had my init system lose communication with the desktop gui and decide to reboot my system. Yes, systemd did that. dbus got an upgrade and was restarting so systemd rebooted my system.
While not directly a systemd problem, I've haddistro builds of apache that didn't work because of some patch "needed" so systemd could manage apache (We need systemd hooked so deeply into every process now?!). Yes, each of these was corrected... But they didn't need to happen and NEVER happened with earlier init systems.
The concepts in upstart, launchd, and systemd are mildly interesting to me and probably more so to others. The implementations of the ideas have been poorly thought out and tested. They cause so much trouble for me as to make them worthless to me. When complaints are registered, the response has often been "if we don't force it, it will never be tested". Completely unacceptable.
This is MY issue with the new shiny toy. Heedless and needless system breakage by an escaped lab rat.
And I have to wonder, why in /usr/lib/systemd/system/ is there a file named -.slice ?? Didn't anyone see a problem with this...? or countless possible problems? Doesn't instill confidence.
On Tue, 11 Apr 2017, ken wrote:
And I have to wonder, why in /usr/lib/systemd/system/ is there a file named -.slice ?? Didn't anyone see a problem with this...? or countless possible problems? Doesn't instill confidence.
Well wonder no more!! Simply look it up in the man pages. It is documented after all!!
Hummm, lets see: (vcliff pts2) # grep Documentation= /usr/lib/systemd/system/-.slice Documentation=man:systemd.special(7) (vcliff pts2) #
I will let you do the rest of the research yourself. :-)
Regards,
On 04/11/2017 07:42 AM, me@tdiehl.org wrote:
On Tue, 11 Apr 2017, ken wrote:
And I have to wonder, why in /usr/lib/systemd/system/ is there a file named -.slice ?? Didn't anyone see a problem with this...? or countless possible problems? Doesn't instill confidence.
Well wonder no more!! Simply look it up in the man pages. It is documented after all!!
Hummm, lets see: (vcliff pts2) # grep Documentation= /usr/lib/systemd/system/-.slice Documentation=man:systemd.special(7) (vcliff pts2) #
I will let you do the rest of the research yourself. :-)
Tom, you're missing the point.
Another huge concern: It breaks, someone else has to fix it because it's in the C source - after it reaches a high enough priority. At least with scripts you could conceivably hack it. From what I've read there is some ability to get systemd to defer to a script, I'm going to have to become an expert at that.
----- Original Message ----- From: "Bruce Ferrell" bferrell@baywinds.org To: "centos" centos@centos.org Sent: Monday, April 10, 2017 7:13:55 PM Subject: Re: [CentOS] OT: systemd Poll
On 04/10/2017 03:20 PM, Pete Biggs wrote:
I must admit that I skipped through the first and second stages - I never found creating init scripts a joy and instead opted to write my own scripts that I launched via inittab. As such, I welcomed the simplicity systemd's service files without fuss.
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
It is what it is.
I can see that systemd may not look as straightforward as init scripts, but it has been clear for a while that SysVinit is generally not really fit-for-purpose. Things like the mystic incantations embedded in comments at the top to try and make chkconfig work properly, or the lack of a consistent approach to configuring parameters (are they embedded in the script? In /etc/sysconfig? The package's own config files?).
The fact that there was at one point multiple solutions to the problem (with systemd eventually becoming the accepted one) and that no dev is really going to voluntarily go through the pain and abuse of implementing something new like this shows that it really was thought to be necessary.
I think what is/was the issue is the abrasive way that some of it was done. It seems to have put people's backs up no end and makes them predisposed to find fault with it.
It's just different, that's all. It does the job it was designed to do. It even copes with legacy init scripts, so you can still use them if you want.
And I remember when these new fangled init scripts first appeared - boy did everyone find them confusing and hated them.
P.
My first *IX system had only /etc/inittab and I had to manually add and configure inetd. Next generation used the bsd init system... Monolithic. No process start/stop, but I understood it. Then SystemV came along; Individual processes could be started, stopped, and queried. The came the function file and THAT was a complete mess... Every distro developer had his own idea of what functions were needed.
In all three of those cases, there was a single, simple start up entity. That was the literal binary program init. It read /etc/inittab and used that to handle process management and those management processes were completely transparent. Standardized, well known locations were used. It was considered to be a not just good practice, but excellent practice to do so. It wasn't commonly done, but it was relatively simple to swap between them too.
The current crop of system initialization systems, do everything possible to obscure the details of operation... Boot status on the console? Nope, obscured. Processes logged to standard places? Nope, someone might hijack the logs (we had a technique for that... remote logging, but that isn't important enough to make work... Too much trouble).
The bottom line seems to be, "I've looked at this, and I know better than 20, 30 years of experience, so throw it all out and do it my way"... And if things get broken in the process... Oh well, that's progress.
I've had my init system lose communication with the desktop gui and decide to reboot my system. Yes, systemd did that. dbus got an upgrade and was restarting so systemd rebooted my system.
While not directly a systemd problem, I've haddistro builds of apache that didn't work because of some patch "needed" so systemd could manage apache (We need systemd hooked so deeply into every process now?!). Yes, each of these was corrected... But they didn't need to happen and NEVER happened with earlier init systems.
The concepts in upstart, launchd, and systemd are mildly interesting to me and probably more so to others. The implementations of the ideas have been poorly thought out and tested. They cause so much trouble for me as to make them worthless to me. When complaints are registered, the response has often been "if we don't force it, it will never be tested". Completely unacceptable.
This is MY issue with the new shiny toy. Heedless and needless system breakage by an escaped lab rat.
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Leroy Tennison writes:
Another huge concern: It breaks, someone else has to fix it because it's in the C source - after it reaches a high enough priority. At least with scripts you could conceivably hack it. From what I've read there is some ability to get systemd to defer to a script, I'm going to have to become an expert at that.
Best of both worlds - power-grabbing systemd plus convoluted init scripts.
On 04/11/2017 09:10 AM, Leroy Tennison wrote:
Another huge concern: It breaks, someone else has to fix it because it's in the C source - after it reaches a high enough priority. At least with scripts you could conceivably hack it. From what I've read there is some ability to get systemd to defer to a script, I'm going to have to become an expert at that.
Even as a former C programmer, that disturbs me too. I'd much rather have a bash script to look at-- and manually step through.
I'd much rather have a bash script to look at-- and manually step through.
Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing *nix for nearly 10 years and *still* am unable to read anything vaguely complicated in bash whereas I can write fairly decent python after 6 months. From my point of view SystemD is amazing I can write a 6 line service file for my apps and it *just works* and I don't have to think about it anymore.
What is it about SystemD that brings out the Richard Stallman in everyone?
Andrew Holway wrote:
I'd much rather have a bash script to look at-- and manually step through.
Same here.
Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing *nix for nearly 10 years and *still* am unable to read anything
vaguely
complicated in bash whereas I can write fairly decent python after 6 months. From my point of view SystemD is amazing I can write a 6 line service file for my apps and it *just works* and I don't have to think about it anymore.
What is it about SystemD that brings out the Richard Stallman in everyone?
Sorry, other than my manager's extreme use of regular expressions, most scripts are perfectly clear. I'm not sure what you're seeing as an "impenetrable nightmare"
mark "likes bash, because I can use my c-shell-isms"
most scripts are perfectly clear.
This is the Richard Stallman assumption:
He assumes that the average normal person is able to program Fortran 77 and Lisp and are able to spend inordinate amounts of time debugging and getting obscure OSS software packages working because using Skype and other proprietary software is somehow evil. Bash is a significant barrier for entry unless you spend a significant amount of your time writing bash whereas a service file is 6 lines for a proper service management solution.
From a usability point of view init is a disaster.
On 04/11/2017 07:50 AM, Andrew Holway wrote:
I'd much rather have a bash script to look at-- and manually step through.
Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing *nix for nearly 10 years and *still* am unable to read anything vaguely complicated in bash whereas I can write fairly decent python after 6 months. From my point of view SystemD is amazing I can write a 6 line service file for my apps and it *just works* and I don't have to think about it anymore.
What is it about SystemD that brings out the Richard Stallman in everyone? _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
*10 WHOLE years*... And bash is *STILL* impenetrable for you?
How about over 30 and it took me a week? No, I don't carry a CS degree or cert of any kind either, just some high school.
For me, systemd has been an absolute nightmare of unexpected reboots and non-transparently broken processes with just plain bad implementations crammed onto my system. Faster boot they said, except it ISN'T faster now, it's slower and MUCH more difficult to sort through to find out why with it's monolithic architecture and poor documentation.
It wasn't broken before. What was being fixed?
On Tue, Apr 11, 2017 at 09:02:45AM -0700, Bruce Ferrell wrote:
How about over 30 and it took me a week? No, I don't carry a CS degree or cert of any kind either, just some high school.
For me, systemd has been an absolute nightmare of unexpected reboots and non-transparently broken processes with just plain bad implementations crammed onto my system. Faster boot they said, except it ISN'T faster now, it's slower and MUCH more difficult to sort through to find out why with it's monolithic architecture and poor documentation.
It wasn't broken before. What was being fixed?
I feel like this conversation has reached the "lets just keep repeating FUD about systemd" stage and probably won't progress in a useful direction.
Maybe we should just jump right to the end that we always have each time this comes up. systemd is the death of linux and you're leaving for FreeBSD/devuan/whatever. Lets just move along now.
On 04/11/2017 09:11 AM, Jonathan Billings wrote:
On Tue, Apr 11, 2017 at 09:02:45AM -0700, Bruce Ferrell wrote:
How about over 30 and it took me a week? No, I don't carry a CS degree or cert of any kind either, just some high school.
For me, systemd has been an absolute nightmare of unexpected reboots and non-transparently broken processes with just plain bad implementations crammed onto my system. Faster boot they said, except it ISN'T faster now, it's slower and MUCH more difficult to sort through to find out why with it's monolithic architecture and poor documentation.
It wasn't broken before. What was being fixed?
I feel like this conversation has reached the "lets just keep repeating FUD about systemd" stage and probably won't progress in a useful direction.
Maybe we should just jump right to the end that we always have each time this comes up. systemd is the death of linux and you're leaving for FreeBSD/devuan/whatever. Lets just move along now.
Well, sorta yes and sorta no Jonathan. Yes, in that I've moved my personal systems to Linux distros that don't use systemd.
No in the it's not "FUD"... The complaints about the code and development are facts. Not alternative facts, real, verifiable incidents and outages.
Professionally, I end up having to deal with these incidents that suck my time and effort and irritate my customers.
Just move on, ISN'T a solution.
I deal in solutions. Partially, where possible, I move my customers to system that don't have this viral infection just as I moved them off of windows, where possible.
systemd isn't "the death of linux". It is a serious quagmire that needs to be resolved. That can only happen by confronting the issue head on. step one is admitting a problem exists.
On Tue, Apr 11, 2017 at 09:24:11AM -0700, Bruce Ferrell wrote:
Well, sorta yes and sorta no Jonathan. Yes, in that I've moved my personal systems to Linux distros that don't use systemd.
No in the it's not "FUD"... The complaints about the code and development are facts. Not alternative facts, real, verifiable incidents and outages.
Professionally, I end up having to deal with these incidents that suck my time and effort and irritate my customers.
Just move on, ISN'T a solution.
I deal in solutions. Partially, where possible, I move my customers to system that don't have this viral infection just as I moved them off of windows, where possible.
systemd isn't "the death of linux". It is a serious quagmire that needs to be resolved. That can only happen by confronting the issue head on. step one is admitting a problem exists.
While some of these might be valid concerns, the CentOS mailing list isn't really the place where you'll be able to achieve those goals. CentOS is a rebuild of RHEL, with very little change. Maybe as a Red Hat customer, you might get more traction complaining about how their OS runs.
I suggest getting involved with the systemd project if you'd like to make positive change there. You can also participate in the Fedora Project if you'd like to influence how systemd manages the OS. You'll also have plenty of heads-up about things coming down the pipe before they hit CentOS.
If you want a real head-scratcher, take a look at how systemd --user runs on Fedora 25. It is my current painful interaction with systemd.
Le 11/04/2017 à 18:11, Jonathan Billings a écrit :
Maybe we should just jump right to the end that we always have each time this comes up. systemd is the death of linux and you're leaving for FreeBSD/devuan/whatever. Lets just move along now.
I've been using CentOS 5.x almost exclusively for a few years on both servers and desktops, and then I went back to Slackware Linux because I liked its simplicity. Slackware is still running on most of my servers and desktops, and I even maintain a small spinoff distribution for desktops (https://www.microlinux.eu).
I'm currently faced with the perspective of teaching Linux for some bigger companies (think broadcasting business). Since here in France, many big companies are running RHEL on their servers, I thought it might be a good idea to check out CentOS again. So some time ago I started fiddling with more recent versions again, and I even have a new section on my blog about CentOS: http://blog.microlinux.fr/centos/
I just read through this thread, and I must say I'm a bit worried, to the point that I'm asking myself: is CentOS still as reliable as it was? This is not a rhetorical question, but a real one. On my Slackware servers, I'm hosting a few dozen websites, various platforms for schools and public libraries, some streaming stuff, webmail, etc. and these machines *never ever* give me any headache. Can I expect the same stability from CentOS 7?
Cheers,
Niki
On 04/11/2017 10:16 AM, Nicolas Kovacs wrote:
I just read through this thread, and I must say I'm a bit worried, to the point that I'm asking myself: is CentOS still as reliable as it was?
Yes. I've been very happy with release 7 across hundreds of servers and dozens of configurations.
On 04/11/2017 10:36 AM, Gordon Messmer wrote:
On 04/11/2017 10:16 AM, Nicolas Kovacs wrote:
I just read through this thread, and I must say I'm a bit worried, to the point that I'm asking myself: is CentOS still as reliable as it was?
Yes. I've been very happy with release 7 across hundreds of servers and dozens of configurations.
Ditto that. CentOS 7 has been an amazing release for me.
I just read through this thread, and I must say I'm a bit worried, to the point that I'm asking myself: is CentOS still as reliable as it was?
Yes.
This is not a rhetorical question, but a real one. On my Slackware servers, I'm hosting a few dozen websites, various platforms for schools and public libraries, some streaming stuff, webmail, etc. and these machines *never ever* give me any headache. Can I expect the same stability from CentOS 7?
I have a hundred or so CentOS desktops, ~10 webservers hosting many virtual sites, an LDAP infrastructure, a couple of VM servers, a number of large computational clusters, mail servers, mail relays, a Nextcloud host and so on all running on CentOS of various flavours (but mostly 7 now) and ALL of them rock solid. I don't see any of these random reboots because of systemd, it is just not something I recognise - the uptimes are usually in the months to years region.
Look, CentOS is a RHEL clone, RH make money out of this and they aren't going to produce an OS that is flaky. If they did, no one would use it.
P.
Le 11/04/2017 à 19:43, Pete Biggs a écrit :
Look, CentOS is a RHEL clone, RH make money out of this and they aren't going to produce an OS that is flaky. If they did, no one would use it.
That was my initial thought. Thanks for confirming it.
Cheers,
Niki
On Tue, April 11, 2017 12:43 pm, Pete Biggs wrote:
I just read through this thread, and I must say I'm a bit worried, to the point that I'm asking myself: is CentOS still as reliable as it was?
Yes.
This is not a rhetorical question, but a real one. On my Slackware servers, I'm hosting a few dozen websites, various platforms for schools and public libraries, some streaming stuff, webmail, etc. and these machines *never ever* give me any headache. Can I expect the same stability from CentOS 7?
I have a hundred or so CentOS desktops, ~10 webservers hosting many virtual sites, an LDAP infrastructure, a couple of VM servers, a number of large computational clusters, mail servers, mail relays, a Nextcloud host and so on all running on CentOS of various flavours (but mostly 7 now) and ALL of them rock solid. I don't see any of these random reboots because of systemd, it is just not something I recognise - the uptimes are usually in the months to years region.
Years uptime, wow! What do you do when security update for kernel or glibc is released? These come as often as once every 45 days in my observation.
Valeri
Look, CentOS is a RHEL clone, RH make money out of this and they aren't going to produce an OS that is flaky. If they did, no one would use it.
P. _______________________________________________ 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 Tue, April 11, 2017 1:23 pm, Pete Biggs wrote:
Years uptime, wow! What do you do when security update for kernel or glibc is released? These come as often as once every 45 days in my observation.
They're non-exposed hosts doing very specific things - think internal network with an air-gap to the internet.
Ah, that explains. Doesn't suite me though: I do run machines in an assumption that bad guy is already inside. Saved me twice: I watched attempts of elevation of privileges (unsuccessful) before I locked regular user account that was compromised. So this doesn't suit me, alas, even for backend servers. I guess I had too "strict" teachers ;-)
Thanks for clarifying!
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Similar. When user jobs can run for a couple of months you can't just do a reboot every few days. Yum makes doing updates easy, but that can bring another problem: I've seen people do "yum update" multiple times and not realise that they need to reboot.
On 11/04/17 19:23, Pete Biggs wrote:
Years uptime, wow! What do you do when security update for kernel or glibc is released? These come as often as once every 45 days in my observation.
They're non-exposed hosts doing very specific things - think internal network with an air-gap to the internet.
P. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, Apr 11, 2017 at 12:11:19PM -0400, Jonathan Billings wrote:
I feel like this conversation has reached the "lets just keep repeating FUD about systemd" stage and probably won't progress in a useful direction.
Maybe we should just jump right to the end that we always have each time this comes up. systemd is the death of linux and you're leaving for FreeBSD/devuan/whatever. Lets just move along now.
Young man, You feel down on your luck Young man You're tired of Linux Young Man You want to free Of trying to figure out systemd
Why don't you try.... Freeeeee BSD FreeeBSD It still has an init that you can see (though they're talking of trying OpenRC)
And so on. Sorry, that's all I was allowed to sing at work before people got annoyed. (We're a FreeBSD shop though).
On Apr 11, 2017, at 11:28 AM, Scott Robbins scottro11@gmail.com wrote:
(though they're talking of trying OpenRC)
Not just talking. TrueOS, neé PC-BSD, now runs on OpenRC.
So let me tell you about how my recent TrueOS server upgrade broke virtually all of my services on the TrueOS server, roached the X configuration, and now has the system in an un-upgradeable state, to the point that it’s looking like I’ll have to reinstall if I ever want to install software from pkg again.
Oh, and let’s also talk about how FreeBSD has been training people to run services via direct /etc/rc.d/$service script calls, but now you must use rc-service calls, with no graceful fallback. Got scripts calling the old style scripts? Too bad.
The grass isn’t always greener on the other side of the fence.
On Tue, April 11, 2017 4:41 pm, Warren Young wrote:
On Apr 11, 2017, at 11:28 AM, Scott Robbins scottro11@gmail.com wrote:
(though they're talking of trying OpenRC)
Not just talking. TrueOS, neé PC-BSD, now runs on OpenRC.
So let me tell you about how my recent TrueOS server upgrade broke virtually all of my services on the TrueOS server, roached the X configuration, and now has the system in an un-upgradeable state, to the point that itâs looking like Iâll have to reinstall if I ever want to install software from pkg again.
Oh, and letâs also talk about how FreeBSD has been training people to run services via direct /etc/rc.d/$service script calls, but now you must use rc-service calls, with no graceful fallback. Got scripts calling the old style scripts? Too bad.
All systems suck. And thanks to that I got my job.
Valeri
The grass isnât always greener on the other side of the fence.
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Tue, Apr 11, 2017 at 05:11:25PM -0500, Valeri Galtsev wrote:
On Tue, April 11, 2017 4:41 pm, Warren Young wrote:
On Apr 11, 2017, at 11:28 AM, Scott Robbins scottro11@gmail.com wrote:
(though they're talking of trying OpenRC)
Not just talking. TrueOS, neé PC-BSD, now runs on OpenRC.
So let me tell you about how my recent TrueOS server upgrade broke virtually all of my services on the TrueOS server, roached the X configuration, and now has the system in an un-upgradeable state, to the point that itâs looking like Iâll have to reinstall if I ever want to install software from pkg again.
All systems suck. And thanks to that I got my job.
And as for me, I was just trying to make people laugh. :)
On 11/04/17 17:02, Bruce Ferrell wrote:
On 04/11/2017 07:50 AM, Andrew Holway wrote:
I'd much rather have a bash script to look at-- and manually step through.
Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing *nix for nearly 10 years and *still* am unable to read anything vaguely complicated in bash whereas I can write fairly decent python after 6 months. From my point of view SystemD is amazing I can write a 6 line service file for my apps and it *just works* and I don't have to think about it anymore.
What is it about SystemD that brings out the Richard Stallman in everyone? _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
*10 WHOLE years*... And bash is *STILL* impenetrable for you?
How about over 30 and it took me a week? No, I don't carry a CS degree or cert of any kind either, just some high school.
For me, systemd has been an absolute nightmare of unexpected reboots and non-transparently broken processes with just plain bad implementations crammed onto my system. Faster boot they said, except it ISN'T faster now, it's slower and MUCH more difficult to sort through to find out why with it's monolithic architecture and poor documentation.
It wasn't broken before. What was being fixed?
Boot speed isn't everything. My servers take far longer to initialise than boot, so having to repeat the boot to sort out the black magic takes __much__ longer than having a steppable script.
Interesting that you should cite Stallman because freedom is an issue here, we've been reduced to Microsoft when it comes to init. We've lost most of our flexibility with no option to choose piecemeal what we want and don't want.
----- Original Message ----- From: "Andrew Holway" andrew.holway@gmail.com To: "centos" centos@centos.org Sent: Tuesday, April 11, 2017 9:50:02 AM Subject: Re: [CentOS] OT: systemd Poll
I'd much rather have a bash script to look at-- and manually step through.
Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing *nix for nearly 10 years and *still* am unable to read anything vaguely complicated in bash whereas I can write fairly decent python after 6 months. From my point of view SystemD is amazing I can write a 6 line service file for my apps and it *just works* and I don't have to think about it anymore.
What is it about SystemD that brings out the Richard Stallman in everyone? _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 04/11/2017 09:48 AM, Leroy Tennison wrote:
Interesting that you should cite Stallman because freedom is an issue here, we've been reduced to Microsoft when it comes to init. We've lost most of our flexibility with no option to choose piecemeal what we want and don't want.
You also don't have the flexibility to replace the kernel. Or glibc.
Does anyone here remember Red Hat 5, when libc5 was replaced with glibc? The noise about systemd seems *awfully* familiar.
On 2017-04-11, Gordon Messmer gordon.messmer@gmail.com wrote:
You also don't have the flexibility to replace the kernel. Or glibc.
But you do, don't you? It'll take you months to replace them, or years to rewrite, but you *can* do it. That is the freedom that open source software provides that proprietary OSes do not; it does not come with the additional promise to provide exactly the software you specify.
--keith
On Tue, April 11, 2017 9:09 pm, Keith Keller wrote:
On 2017-04-11, Gordon Messmer gordon.messmer@gmail.com wrote:
You also don't have the flexibility to replace the kernel. Or glibc.
But you do, don't you? It'll take you months to replace them, or years to rewrite, but you *can* do it.
I agree. We had once new machine with 32 bit CPUs and 8GB of RAM - that time RAM was cheap, but amd664 architecture didn't exist yet,- and standard kernel only supported 1 GB user space. Not changeable in kernel config. It took me between one and two weeks to find hardcoded boundaries, and change them; 3.5 GB for userspace was max I could squeeze leaving the rest to kernel + stack + ... and still having stable solid system. That was decent solution.
I wholeheartedly agree with Keith.
Valeri
That is the freedom that open source software provides that proprietary OSes do not; it does not come with the additional promise to provide exactly the software you specify.
--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 04/11/2017 07:09 PM, Keith Keller wrote:
On 2017-04-11, Gordon Messmergordon.messmer@gmail.com wrote:
You also don't have the flexibility to replace the kernel. Or glibc.
But you do, don't you? It'll take you months to replace them, or years to rewrite, but you*can* do it.
The same is true of systemd, which is what I'm trying to illustrate.
On 09/04/17 05:39, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I think the points been made, can we all move along and let this thread be.
<humor for the day>Why don't we discuss something ***less*** controversial, like politics or religion?</humor for the day>
----- Original Message ----- From: "Karanbir Singh" mail-lists@karan.org To: "centos" centos@centos.org Sent: Wednesday, April 12, 2017 6:19:43 AM Subject: Re: [CentOS] OT: systemd Poll
On 09/04/17 05:39, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
I think the points been made, can we all move along and let this thread be.
On 04/12/2017 05:59 AM, Leroy Tennison wrote:
<humor for the day>Why don't we discuss something ***less*** controversial, like politics or religion?</humor for the day>
Even when I'm the one complaining (and I don't about systemd), I'm always reminded of some TV clip I saw when I was young and can't place of a bunch of old people complaining :
"Well we've never done it that way before"
On Wed, April 12, 2017 8:07 am, Alice Wonder wrote:
On 04/12/2017 05:59 AM, Leroy Tennison wrote:
<humor for the day>Why don't we discuss something ***less*** controversial, like politics or religion?</humor for the day>
Even when I'm the one complaining (and I don't about systemd), I'm always reminded of some TV clip I saw when I was young and can't place of a bunch of old people complaining :
"Well we've never done it that way before"
To their credit one can say: some older people do realize that they didn't fit into "iPad generation". ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev wrote:
On Wed, April 12, 2017 8:07 am, Alice Wonder wrote:
On 04/12/2017 05:59 AM, Leroy Tennison wrote:
<humor for the day>Why don't we discuss something ***less*** controversial, like politics or religion?</humor for the day>
Even when I'm the one complaining (and I don't about systemd), I'm always reminded of some TV clip I saw when I was young and can't place of a bunch of old people complaining :
"Well we've never done it that way before"
Of course, to be fair, there may have been a *reason* for not doing it that way before....
To their credit one can say: some older people do realize that they didn't fit into "iPad generation". ;-)
I a) actively dislike Apple, and b) I want a *real* keyboard.
mark "tease me about my age, and I'll beat you with my cane!"
Of course, to be fair, there may have been a *reason* for not doing it that way before....
Between the early 1990's and early 2000's the price of a GB of memory went from ~$100,000 to ~$1000*. I guess a lot of the design decisions made for things like init were focussed on this. In 1995 is was common for server platforms to have 32Mb ram whereas the kernel alone in my PC here at home is consuming just over 500MB. It seems reasonable that software components built in 1997 will not be fit for purpose in 2017.
* According to perfunctory google search: http://www.statisticbrain.com/average-historic-price-of-ram/
Andrew Holway wrote:
Of course, to be fair, there may have been a *reason* for not doing it that way before....
Between the early 1990's and early 2000's the price of a GB of memory went from ~$100,000 to ~$1000*. I guess a lot of the design decisions made for things like init were focussed on this. In 1995 is was common for server platforms to have 32Mb ram whereas the kernel alone in my PC here at home is consuming just over 500MB. It seems reasonable that software components built in 1997 will not be fit for purpose in 2017.
- According to perfunctory google search:
http://www.statisticbrain.com/average-historic-price-of-ram/
a) I was speaking in much more general terms than just software. b) Stuff built then will run unbelievable fast on modern systems - and no, in the nineties, we were not manually swapping. c) If it fulfils its intended purpose, why would you redefine it as not fit for that purpose? d) And then there stuff that I'm not sure of the purpose... like eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"
Speaking of vi, I'm amazed at just how powerful it is. (And I'm not being sarcastic, there's not much I've searched for in regard to its capabilities that I haven't found). No thread drift here...
----- Original Message ----- From: "m roth" m.roth@5-cent.us To: "centos" centos@centos.org Sent: Wednesday, April 12, 2017 1:08:25 PM Subject: Re: [CentOS] humor (was Re: OT: systemd Poll)
Andrew Holway wrote:
Of course, to be fair, there may have been a *reason* for not doing it that way before....
Between the early 1990's and early 2000's the price of a GB of memory went from ~$100,000 to ~$1000*. I guess a lot of the design decisions made for things like init were focussed on this. In 1995 is was common for server platforms to have 32Mb ram whereas the kernel alone in my PC here at home is consuming just over 500MB. It seems reasonable that software components built in 1997 will not be fit for purpose in 2017.
- According to perfunctory google search:
http://www.statisticbrain.com/average-historic-price-of-ram/
a) I was speaking in much more general terms than just software. b) Stuff built then will run unbelievable fast on modern systems - and no, in the nineties, we were not manually swapping. c) If it fulfils its intended purpose, why would you redefine it as not fit for that purpose? d) And then there stuff that I'm not sure of the purpose... like eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"
And mine on medon.htt-consult.com done with Geany.
Using a editor that understands html tags so you can collapse ones not being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany.
Using a editor that understands html tags so you can collapse ones not being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Yeah, well, I've tried word processors, and, years back, I tried Quanta, which was specifically for working on web pages, and the HTML generated by all word processors sucks dead Mar-a-Lago roaches. And *all* of them want to left-justify, even if there's an option not to, and you set that, rather than leaving it properly indented.
mark
On Thu, Apr 13, 2017 at 2:06 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany.
Using a editor that understands html tags so you can collapse ones not being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Yeah, well, I've tried word processors, and, years back, I tried Quanta, which was specifically for working on web pages, and the HTML generated by all word processors sucks dead Mar-a-Lago roaches. And *all* of them want to left-justify, even if there's an option not to, and you set that, rather than leaving it properly indented.
The forced left justify part reminds me of a conversation I had with a vendor last year. It was something on the lines of "I know this might come as a shock to you but there are people out there who has phone numbers that are not exactly 9 digits long and postal codes with letters and numbers."
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Mauricio Tavares wrote:
On Thu, Apr 13, 2017 at 2:06 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany.
Using a editor that understands html tags so you can collapse ones not being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Yeah, well, I've tried word processors, and, years back, I tried Quanta, which was specifically for working on web pages, and the HTML generated by all word processors sucks dead Mar-a-Lago roaches. And *all* of them want to left-justify, even if there's an option not to, and you set that, rather than leaving it properly indented.
The forced left justify part reminds me of a conversation I hadwith a vendor last year. It was something on the lines of "I know this might come as a shock to you but there are people out there who has phone numbers that are not exactly 9 digits long and postal codes with letters and numbers."
Gosh! Wow! Who'd a thought that?! (Now let's see, can I remember my friend in Canada's postal code without looking?)
mark
On Thu, April 13, 2017 1:38 pm, Mauricio Tavares wrote:
On Thu, Apr 13, 2017 at 2:06 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like
eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany. Using a editor that understands html tags so you can collapse ones not
being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Yeah, well, I've tried word processors, and, years back, I tried
Quanta,
which was specifically for working on web pages, and the HTML generated by all word processors sucks dead Mar-a-Lago roaches. And *all* of them want to left-justify, even if there's an option not to, and you set that,
rather than leaving it properly indented.
Just to add a bit to discussion. There are tools (editors) to edit html code for web pages. Looking at some html documents I see a lot of junk added by these tools. Who will blame stupid program that is designed to handle everything for doing that? Not me. But I do not what any junk inside anything I wrote. Do you want "mozilla generator" in the hidden field of your html document? But I must confess: I do not write html or php webpages (except for most trivial ones, or editing ones written by someone else). And as Mark I use vi for that (and almost for everything, fancy formatted printouts may be exemption). Will you be surprised by the fact that some web servers are configured to not serve files ending with tilde symbol "~"? As these will be served as text verbatim, and therefore will disclose whateve you have inside file with the same name without tilde. I know more than one web developer who use emacs, edits files in situ (not elsewhere) and never even think of cleaning xxxx~ files.
Valeri
The forced left justify part reminds me of a conversation I hadwith a vendor last year. It was something on the lines of "I know this
might come as a shock to you but there are people out there who has phone numbers that are not exactly 9 digits long and postal codes with letters and numbers."
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Thu, Apr 13, 2017 at 12:01 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Thu, April 13, 2017 1:38 pm, Mauricio Tavares wrote:
On Thu, Apr 13, 2017 at 2:06 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like
eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany. Using a editor that understands html tags so you can collapse ones not
being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Yeah, well, I've tried word processors, and, years back, I tried
Quanta,
which was specifically for working on web pages, and the HTML generated
by
all word processors sucks dead Mar-a-Lago roaches. And *all* of them
want
to left-justify, even if there's an option not to, and you set that,
rather than leaving it properly indented.
Just to add a bit to discussion. There are tools (editors) to edit html code for web pages. Looking at some html documents I see a lot of junk added by these tools. Who will blame stupid program that is designed to handle everything for doing that? Not me. But I do not what any junk inside anything I wrote. Do you want "mozilla generator" in the hidden field of your html document? But I must confess: I do not write html or php webpages (except for most trivial ones, or editing ones written by someone else). And as Mark I use vi for that (and almost for everything, fancy formatted printouts may be exemption). Will you be surprised by the fact that some web servers are configured to not serve files ending with tilde symbol "~"? As these will be served as text verbatim, and therefore will disclose whateve you have inside file with the same name without tilde. I know more than one web developer who use emacs, edits files in situ (not elsewhere) and never even think of cleaning xxxx~ files.
Valeri
The forced left justify part reminds me of a conversation I hadwith a vendor last year. It was something on the lines of "I know this
might come as a shock to you but there are people out there who has phone numbers that are not exactly 9 digits long and postal codes with letters and numbers."
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
I have been known to code complete html sites with pretty deep css in vi :)
I use Atom lately for any code work and like it. https://atom.io/
Cameron
On 04/13/2017 03:01 PM, Valeri Galtsev wrote:
On Thu, April 13, 2017 1:38 pm, Mauricio Tavares wrote:
On Thu, Apr 13, 2017 at 2:06 PM, m.roth@5-cent.us wrote:
Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
d) And then there stuff that I'm not sure of the purpose... like
eclipse, that needs 2GB to run... for an editor.
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany. Using a editor that understands html tags so you can collapse ones not
being edited does make life simpler. Also lets you know, indirectly, when your copy and pasting messed up the tag pairing.
Yeah, well, I've tried word processors, and, years back, I tried
Quanta,
which was specifically for working on web pages, and the HTML generated by all word processors sucks dead Mar-a-Lago roaches. And *all* of them want to left-justify, even if there's an option not to, and you set that,
rather than leaving it properly indented.
Just to add a bit to discussion. There are tools (editors) to edit html code for web pages. Looking at some html documents I see a lot of junk added by these tools. Who will blame stupid program that is designed to handle everything for doing that? Not me. But I do not what any junk inside anything I wrote. Do you want "mozilla generator" in the hidden field of your html document?
That is why I use Geany. It gives you a very basic html template and you go from there.
I have been 'learning on the job' to make decent boxes for my commands, with bars when needed.
Still working on it and would love to have a copy to clipboard button, but all the various examples I have found are not working.
But I must confess: I do not write html or php webpages (except for most trivial ones, or editing ones written by someone else). And as Mark I use vi for that (and almost for everything, fancy formatted printouts may be exemption). Will you be surprised by the fact that some web servers are configured to not serve files ending with tilde symbol "~"? As these will be served as text verbatim, and therefore will disclose whateve you have inside file with the same name without tilde. I know more than one web developer who use emacs, edits files in situ (not elsewhere) and never even think of cleaning xxxx~ files.
Valeri
The forced left justify part reminds me of a conversation I hadwith a vendor last year. It was something on the lines of "I know this
might come as a shock to you but there are people out there who has phone numbers that are not exactly 9 digits long and postal codes with letters and numbers."
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, 2017-04-13 at 10:39 -0400, Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
mark "my web pages proudly built in vi!"
And mine on medon.htt-consult.com done with Geany.
Gedit works for me - webpages, PHP, init (with Vi) et cetera.
On 04/16/2017 04:37 PM, Always Learning wrote:
On Thu, 2017-04-13 at 10:39 -0400, Robert Moskowitz wrote:
On 04/12/2017 02:08 PM, m.roth@5-cent.us wrote:
mark "my web pages proudly built in vi!"And mine on medon.htt-consult.com done with Geany.
Gedit works for me - webpages, PHP, init (with Vi) et cetera.
That means loading gnome. I use Xfce. Much better battery life with Xfce.
Le 16/04/2017 à 22:46, Robert Moskowitz a écrit :
That means loading gnome. I use Xfce. Much better battery life with Xfce.
On a side note (from a Vim user), Geany works perfectly under Xfce and has no weird GNOME dependencies. I know because I maintain an Xfce-centered distribution. (https://www.microlinux.eu)
Cheers,
Niki
Le 12/04/2017 à 19:41, Andrew Holway a écrit :
Between the early 1990's and early 2000's the price of a GB of memory went from ~$100,000 to ~$1000*. I guess a lot of the design decisions made for things like init were focussed on this. In 1995 is was common for server platforms to have 32Mb ram whereas the kernel alone in my PC here at home is consuming just over 500MB. It seems reasonable that software components built in 1997 will not be fit for purpose in 2017.
Back in 2013 I did some Linux training for a company in Montpellier. The first week the server racks hadn't been delivered yet, so we were stuck. In a cupboard, I found an antique Dell Poweredge 1300 server that was out of service, made around 1997 or so. I dusted it off, found a power cable, a monitor, a network cable and a keyboard and connected the thing. It had a P-III 500 MHz processor, 3 x 9 GB SCSI disks and a whooping 128 MB of RAM, and not a single USB port (only parallel).
I happened to have the three CD-Rom set of Slackware 14.0 32-bit, so I gave that a spin. The installation took quite some time, but after the initial reboot, I managed to login, and the base system took no more than 15 MB RAM.
So the first week we began working the course on this machine (which we aptly named "grossebertha", because it was a noisy monster). After a week or so, our new hardware arrived, and since the Windows trainer complained about "8 GB RAM not being enough for a Windows server installation", we decided just to nag him a bit to see how far we could take the course on our old machine. In the end, we had NTP, Dnsmasq, Samba, NIS+NFS, a LAMP stack, Squid, SquidGuard and SquidAnalyzer, and a few other things running on this old monster.
Cheers,
Niki
On Wed, April 12, 2017 1:31 pm, Nicolas Kovacs wrote:
Le 12/04/2017 à 19:41, Andrew Holway a écrit :
Between the early 1990's and early 2000's the price of a GB of memory
went
from ~$100,000 to ~$1000*. I guess a lot of the design decisions made
for
things like init were focussed on this. In 1995 is was common for
server
platforms to have 32Mb ram whereas the kernel alone in my PC here at
home
is consuming just over 500MB. It seems reasonable that software
components
built in 1997 will not be fit for purpose in 2017.
Back in 2013 I did some Linux training for a company in Montpellier. The
first week the server racks hadn't been delivered yet, so we were stuck. In a cupboard, I found an antique Dell Poweredge 1300 server that was out of service, made around 1997 or so. I dusted it off, found a power cable, a monitor, a network cable and a keyboard and connected the thing. It had a P-III 500 MHz processor, 3 x 9 GB SCSI disks and a whooping 128 MB of RAM, and not a single USB port (only parallel).
I happened to have the three CD-Rom set of Slackware 14.0 32-bit, so I
gave that a spin. The installation took quite some time, but after the initial reboot, I managed to login, and the base system took no more than 15 MB RAM.
So the first week we began working the course on this machine (which we
aptly named "grossebertha", because it was a noisy monster). After a week or so, our new hardware arrived, and since the Windows trainer complained about "8 GB RAM not being enough for a Windows server installation", we decided just to nag him a bit to see how far we could take the course on our old machine. In the end, we had NTP, Dnsmasq, Samba, NIS+NFS, a LAMP stack, Squid, SquidGuard and SquidAnalyzer, and a few other things running on this old monster.
When Windows 2000 came out some called it "bloated pig". Some 6 years down the road Linux started catching up ;-) Then we stopped laughing about Windows.
Valeri
Cheers,
Niki
-- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 _______________________________________________ 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 Wed, Apr 12, 2017 at 2:56 PM, Andrew Holway andrew.holway@gmail.com wrote:
When Windows 2000 came out some called it "bloated pig". Some 6 years down the road Linux started catching up ;-) Then we stopped laughing about Windows.
All in the name of progress..
I have been told that Windows developers were taught not to optimize their code for memory/cpu/etc since those could be solved by throwing more hardware at it. Instead they should make clean readable code. Not claiming that is exclusive to Windows or the clean readable part is followed...
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, April 12, 2017 2:39 pm, Mauricio Tavares wrote:
On Wed, Apr 12, 2017 at 2:56 PM, Andrew Holway andrew.holway@gmail.com wrote:
When Windows 2000 came out some called it "bloated pig". Some 6 years down the road Linux started catching up ;-) Then we stopped laughing about Windows.
All in the name of progress..
I have been told that Windows developers were taught not tooptimize their code for memory/cpu/etc since those could be solved by throwing more hardware at it. Instead they should make clean readable code. Not claiming that is exclusive to Windows or the clean readable part is followed...
Continuing in the same spirit. Way back SELinux (before it made it into main stream kernel) had a competitor. LIDS. De-ciphers as Linux Intrusion Detection System (but name is confusing). Creature of Purdue University Computer science department. Basically LISD was a kernel patch that upon end of boot sequence demotes root account to privileges of user nobody. This makes system impregnable on the fly (but real pain to administer - any change can only be done as: shut down, change, boot). I was so impressed, I still remember about it. Never came to using it though. If it did, it might give big pain to NSA and friends. But SELinux won, and LIDS never made it into main stream kernel - to my regret. As far as SELinux is concerned, several people still think that several (how many?) thousands of extra code in the kernel may bring more harm than do good. Anyway, the last IMHO is where "tastes differ".
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Wed, 12 Apr 2017 15:59:41 -0500 (CDT) "Valeri Galtsev" galtsev@kicp.uchicago.edu wrote:
On Wed, April 12, 2017 2:39 pm, Mauricio Tavares wrote:
On Wed, Apr 12, 2017 at 2:56 PM, Andrew Holway andrew.holway@gmail.com wrote:
When Windows 2000 came out some called it "bloated pig". Some 6 years down the road Linux started catching up ;-) Then we stopped laughing about Windows.
All in the name of progress..
I have been told that Windows developers were taught not tooptimize their code for memory/cpu/etc since those could be solved by throwing more hardware at it. Instead they should make clean readable code. Not claiming that is exclusive to Windows or the clean readable part is followed...
Continuing in the same spirit. Way back SELinux (before it made it into main stream kernel) had a competitor. LIDS. De-ciphers as Linux Intrusion Detection System (but name is confusing). Creature of Purdue University Computer science department. Basically LISD was a kernel patch that upon end of boot sequence demotes root account to privileges of user nobody. This makes system impregnable on the fly (but real pain to administer - any change can only be done as: shut down, change, boot). I was so impressed, I still remember about it. Never came to using it though. If it did, it might give big pain to NSA and friends. But SELinux won, and LIDS never made it into main stream kernel - to my regret. As far as SELinux is concerned, several people still think that several (how many?) thousands of extra code in the kernel may bring more harm than do good. Anyway, the last IMHO is where "tastes differ".
Valeri
the wikipedia confirms my memory that SELinux is a child of the NSA. Is anyone astonished that this allowed them to hack into Linux?
d
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Mauricio Tavares wrote:
On Wed, Apr 12, 2017 at 2:56 PM, Andrew Holway andrew.holway@gmail.com wrote:
When Windows 2000 came out some called it "bloated pig". Some 6 years down the road Linux started catching up ;-) Then we stopped laughing
about
Windows.
All in the name of progress..
I have been told that Windows developers were taught not tooptimize their code for memory/cpu/etc since those could be solved by throwing more hardware at it. Instead they should make clean readable code. Not claiming that is exclusive to Windows or the clean readable part is followed...
I read an interview 10? 15? years ago with Gates, and it was clear he was a hardware junky.
mark
On 4/12/2017 12:39 PM, Mauricio Tavares wrote:
I have been told that Windows developers were taught not tooptimize their code for memory/cpu/etc since those could be solved by throwing more hardware at it. Instead they should make clean readable code. Not claiming that is exclusive to Windows or the clean readable part is followed...
There is a good case to be made for avoiding 'premature optimization' in software design and development.
On Wed, Apr 12, 2017 at 02:25:52PM -0700, John R Pierce wrote:
On 4/12/2017 12:39 PM, Mauricio Tavares wrote:
I have been told that Windows developers were taught not tooptimize their code for memory/cpu/etc since those could be solved by throwing more hardware at it. Instead they should make clean readable code. Not claiming that is exclusive to Windows or the clean readable part is followed...
There is a good case to be made for avoiding 'premature optimization' in software design and development.
Yeah. Especially because (good) modern compilers can do an amazing job of optimizing for you, enough so that you often don't need to put any effort at all into it. then there are those corner cases, wherein you DO.
On Wed, Apr 12, 2017 at 08:31:29PM +0200, Nicolas Kovacs wrote:
Le 12/04/2017 à 19:41, Andrew Holway a écrit :
Between the early 1990's and early 2000's the price of a GB of memory went from ~$100,000 to ~$1000*. I guess a lot of the design decisions made for things like init were focussed on this. In 1995 is was common for server platforms to have 32Mb ram whereas the kernel alone in my PC here at home is consuming just over 500MB. It seems reasonable that software components built in 1997 will not be fit for purpose in 2017.
Back in 2013 I did some Linux training for a company in Montpellier. The first week the server racks hadn't been delivered yet, so we were stuck. In a cupboard, I found an antique Dell Poweredge 1300 server that was out of service, made around 1997 or so. I dusted it off, found a power cable, a monitor, a network cable and a keyboard and connected the thing. It had a P-III 500 MHz processor, 3 x 9 GB SCSI disks and a whooping 128 MB of RAM, and not a single USB port (only parallel).
Similar, much earlier tale of my own. Doing Intro Unix training at a client site. The classroom had PCs with Hummingbird's XDMCP software to remotely connect to a monster HP unix system. On Monday arrival I learned their HP license expired over the weekend and remote access was not possible.
I had my laptop, either a Pentium or P II, running Solaris x86. I put it on the network and had the students point their XDMCP to it. Ran the first two days of class with 12 students plux the console all running X graphical logins. On Wednesday they had us switch to the HP. Some students asked if they could switch back because the laptop seemed more responsive.
Jon
On Wed, Apr 12, 2017 at 07:41:33PM +0200, Andrew Holway wrote:
Of course, to be fair, there may have been a *reason* for not doing it that way before....
Between the early 1990's and early 2000's the price of a GB of memory went from ~$100,000 to ~$1000*. I guess a lot of the design decisions made for things like init were focussed on this. In 1995 is was common for server platforms to have 32Mb ram whereas the kernel alone in my PC here at home is consuming just over 500MB. It seems reasonable that software components built in 1997 will not be fit for purpose in 2017.
Just another historic note. Until System V, Release 4, circa 1989 or 90, AT&T's Unix ran on computers with a 64KB memory space. That was just the code though, the data, static, dynamic, and stack were in a second 64KB space. That was all the pdp-11 allowed.
The merger of BSD code with AT&T code in SVR4 pushed it off of the pdp-11s. But it still ran on things like the AT&T 3B-20 which had a 1MB virtual memory addressing scheme.
Jon
Hello CentOS community members,
A hardware vendor provided us with a .qcow2 file to run on our KVM hypervisor file that will monitor/control said hardware (firewall). I'd like to import this .qcow2 to run as a logical volume (named 'server3') in an existing logical group named 'centos' on our CentOS Linux release 7.1.1503 server.
Right now the .qcow2 file is sitting /root partition with limited disk space. The logical group 'centos' is already setup with lots of free space. There are a few logical volumes already configured.
lvm> vgs VG #PV #LV #SN Attr VSize VFree centos 1 5 1 wz--n- 1.82t 1.52t
lvm> lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert server1 centos owi-aos--- 100.00g server2 centos -wi-a----- 100.00g root centos -wi-ao---- 50.00g swap centos -wi-ao---- 4.00g
lvm> lvdisplay --- Logical volume --- LV Path /dev/centos/swap LV Name swap VG Name centos LV UUID oB3cTX-zujK-dkOa-IxU2-SsIf-HEM7-816nu1 LV Write Access read/write LV Creation host, time localhost, 2015-11-11 21:54:49 -0500 LV Status available # open 2 LV Size 4.00 GiB Current LE 1024 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0
--- Logical volume --- LV Path /dev/centos/root LV Name root VG Name centos LV UUID iWHXnK-o6JN-Duzb-VyFc-yAjD-B65R-02t2aV LV Write Access read/write LV Creation host, time localhost, 2015-11-11 21:54:52 -0500 LV Status available # open 1 LV Size 50.00 GiB Current LE 12800 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:1
--- Logical volume --- LV Path /dev/centos/server1 LV Name server1 VG Name centos LV UUID zx23A5-oNJW-prbw-vdTo-mIBA-Olfr-EjaRja LV Write Access read/write LV Creation host, time xxxx.xxx.xxx, 2016-06-01 15:17:32 -0400 LV snapshot status source of server1 [active] LV Status available # open 1 LV Size 100.00 GiB Current LE 25600 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:6
--- Logical volume --- LV Path /dev/centos/server2 LV Name server2 VG Name centos LV UUID lzaBBu-hSMp-ZXSa-aVlS-hZJf-Ccfe-vdHatI LV Write Access read/write LV Creation host, time xxxxx.xxx.xxx, 2017-03-21 11:35:24 -0400 LV snapshot status active destination for server2 LV Status available # open 0 LV Size 100.00 GiB Current LE 25600 COW-table size 50.00 GiB COW-table LE 12800 Allocated to snapshot 35.76% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:8
How would can you import/migrate this .qcow2 into a logical volume? Any advice would be greatly appreciated.
Thank you, Scott
Le 12/04/2017 à 15:31, Scott Gennari a écrit :
How would can you import/migrate this .qcow2 into a logical volume? Any advice would be greatly appreciated.
- get size of qcow2 image:
qemu-img info yourFile.qcow2
- create a logical volume of same size:
ssm create -s xxxxxxxb -n yourLvName -p centos
- copy image:
qemu-img convert yourFile.qcow2 -O raw /dev/centos/yourLvName
On 04/12/2017 10:19 AM, Philippe BOURDEU d'AGUERRE wrote:
Le 12/04/2017 à 15:31, Scott Gennari a écrit :
How would can you import/migrate this .qcow2 into a logical volume? Any advice would be greatly appreciated.
- get size of qcow2 image:
qemu-img info yourFile.qcow2
- create a logical volume of same size:
ssm create -s xxxxxxxb -n yourLvName -p centos
- copy image:
qemu-img convert yourFile.qcow2 -O raw /dev/centos/yourLvName
That worked perfectly. Thank you, Philippe!
Cheers, Scott
On 04/09/2017 12:39 AM, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
So, the hornets are swarming.....
But to answer your question: None of the above. If I want to run CentOS 7, I need to learn systemd. It doesn't matter what my opinion is of the systemd developers, or of systemd itself; CentOS is an RHEL rebuild, and RHEL 7 ships systemd. If I do not want to deal with systemd, then I need to use something other than CentOS 7. My 'feelings' on the subject are irrelevant.
On 09/04/17 14:39, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd? Are you still ridiculing it, violently opposed to it, or have you mellowed to it?
Thanks for all those that responded. systemd still appears to be a sore topic.
systemd is still coping a whole lot of ridicule but not so violent opposition. Can't say I understand why, but you can't please all of the people all of the time!
Quick comments to some issues identified in the conversation: =============================================================
There are several responses siting poor documentation but I can't fault the documentation; there's plenty of it and the man pages are quite well structured - man -k --names-only systemd
Also, there's a lot of people moving to FreeBSD - but it appears that the grass isn't greener there either as they are now trialling OpenRC.
One issue I resolved quickly after installing CentOS 7 was to revert to ethx for interface names and to install iptables and remove firewalld. The other occassional issue I have is where restarting services takes a seriously long time and I've discovered that restarting `systemd-logind.service, dbus.service, and polkit.service resolves this, albeit for a short period before it crops up again *[0]*.
In closing: ########### There are conspiracy theories out there that the NSA is involved with bringing systemd to Linux so they can have easy access to *"unknown"* bugs - aka backdoors - to all Linux installations using systemd *[1]*. I guess anything goes now that Edward Snowden has educated us all - for better or worse.
Thanks again to all respondents - I quite enjoyed the read - I did read all responses.
Regards, ak.
*[0]* - https://github.com/systemd/systemd/issues/2925 *[1]* - https://www.google.com.au/search?complete=0&hl=en&site=webhp&sou...
Not wishing to extend this thread further, but ...
There are conspiracy theories out there that the NSA is involved with bringing systemd to Linux so they can have easy access to *"unknown"* bugs - aka backdoors - to all Linux installations using systemd *[1]*.
They're conspiracy theories, and that's it. The bottom line is that in general people don't like not understanding things and when they come across something they don't understand they create a mythology around those things to rationalise their non-understanding. Factor in to that the general mindset of Linux hackers/admins that they must know and understand every part of their system and you create the perfect environment for such theories to grow and blossom.
Systemd is complex; it's implementation was badly handled on a social level. Nevertheless it is open source. It is highly unlikely that the NSA, or any other agency, would risk putting in backdoors to code that could be audited by Joe "random hacker" Blogs, let alone that might be discovered by hostile agencies.
There is no doubt that most security agencies have a long list of zero- day exploits in their toolbox - I would hazard to suggest that they wouldn't be doing their job if they didn't! But I seriously doubt they would commission exploitable code in something that is openly auditable.
P.
On 04/15/2017 04:46 AM, Pete Biggs wrote:
Not wishing to extend this thread further, but ...
There are conspiracy theories out there that the NSA is involved with bringing systemd to Linux so they can have easy access to *"unknown"* bugs - aka backdoors - to all Linux installations using systemd *[1]*.
They're conspiracy theories, and that's it.
Hmm. That's not quite it. Wikileaks recently posted a trove of docs on CIA exploits. It was big news. I'm surprised you missed that. And, yes, the exploits also include more than a few against linux. Go to their site and look under vault7. Or search for "linux" or "redhat"... you'll get hundreds of hits. Here's just one: https://wikileaks.org/spyfiles4/documents/FinSpy-3.10-User-Manual.docx (If you have only a few seconds to look at it, see page 34.)
The bottom line is that in general people don't like not understanding things and when they come across something they don't understand they create a mythology around those things to rationalise their non-understanding.
True, but that "mansplanation" can point in a lot of ways, including at Pollyanna.
.... Systemd is complex; it's implementation was badly handled on a social level. Nevertheless it is open source. It is highly unlikely that the NSA, or any other agency, would risk putting in backdoors to code that could be audited by Joe "random hacker" Blogs, let alone that might be discovered by hostile agencies.
Years ago it was revealed that one of the linux developers inserted an exploit into the gcc code which, when the login code was compiled, would give him access to any system running it, effectively every linux system. This exploit was in the linux code for a long time and was never discovered. It was revealed only by the developer himself, and only because he was retiring. Point is: Code is often complex, especially that written in C (or C++ and others), so much so that an exploit can be written into it and not discovered for a long time, or ever. This is yet another argument against systemd: it would be much easier to hide an exploit in it than in a handful of bash scripts.
There is no doubt that most security agencies have a long list of zero- day exploits in their toolbox - I would hazard to suggest that they wouldn't be doing their job if they didn't! But I seriously doubt they would commission exploitable code in something that is openly auditable.
P.
P., I used to think that too... indeed, I was thoroughly convinced of it. But reality changed my mind.
On Apr 16, 2017, at 6:53 AM, ken gebser@mousecar.com wrote:
Years ago it was revealed that one of the linux developers inserted an exploit into the gcc code which, when the login code was compiled, would give him access to any system running it, effectively every linux system. This exploit was in the linux code for a long time and was never discovered. It was revealed only by the developer himself, and only because he was retiring. Point is: Code is often complex, especially that written in C (or C++ and others), so much so that an exploit can be written into it and not discovered for a long time, or ever. This is yet another argument against systemd: it would be much easier to hide an exploit in it than in a handful of bash scripts.
When you say “one of the linux developers”, you mean Ken Thompson?
http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack
This story predates Linux, and describes a problem with any potential software.
You realize ‘bash’ could be just as malicious as systemd in this scenario? Are you meticulously going through *it’s* source code in your version of the world? Note: bash is not written in bash.
-- Jonathan Billings billings@negate.org
There is no doubt that most security agencies have a long list of zero-
day exploits in their toolbox - I would hazard to suggest that they wouldn't be doing their job if they didn't! But I seriously doubt they would commission exploitable code in something that is openly auditable.
P.
P., I used to think that too... indeed, I was thoroughly convinced of it. But reality changed my mind.
Indeed. I think the assertion "OSS is somehow safer because of community audit" is a logical fallacy. How would one go about "auditing" in the first place? Even if the various Intelligence agencies are not injecting vulnerabilities then they would certainly be in a strong position to discover some of the holes already existing some time before they become public.
Unless you're operating an air gap network you can be damn sure that 'they' can get into your systems if they really want to.
On 04/16/2017 06:51 AM, Andrew Holway wrote:
There is no doubt that most security agencies have a long list of zero-
day exploits in their toolbox - I would hazard to suggest that they wouldn't be doing their job if they didn't! But I seriously doubt they would commission exploitable code in something that is openly auditable.
P.
P., I used to think that too... indeed, I was thoroughly convinced of it. But reality changed my mind.
Indeed. I think the assertion "OSS is somehow safer because of community audit" is a logical fallacy. How would one go about "auditing" in the first place? Even if the various Intelligence agencies are not injecting vulnerabilities then they would certainly be in a strong position to discover some of the holes already existing some time before they become public.
I'm more worried about cloud services and the large number of root certificates that software trusts by default.
That's where a lot of the hacks are going to happen, and AFAIK the only defense against it is DNSSEC + DANE which very few zones actually utilize.
Indeed. I think the assertion "OSS is somehow safer because of community audit" is a logical fallacy. How would one go about "auditing" in the first place?
There are tools to audit source code for problems - OSS is safer *because* the source is available and can be audited.
Even if the various Intelligence agencies are not injecting vulnerabilities then they would certainly be in a strong position to discover some of the holes already existing some time before they become public.
Yes. And despite what people think, those agencies don't have super powers. They have tools to help them, and lots of resources, but nothing out of the ordinary. There is nothing that the NSA can do that can't be done by other agencies or even individuals (or enough individuals working together).
There is no doubt that every single security agency in the world has a team working on discovering exploitable code in all operating systems. It's what they do. Any exploit they find that has been reported is probably because some other agency has found it as well so they want to stop them using it.
Unless you're operating an air gap network you can be damn sure that 'they' can get into your systems if they really want to.
The only truly secure machine is one that is at the bottom of a mine shaft, turned off and dismantled. :-)
P.
On Sun, 2017-04-16 at 18:25 +0100, Pete Biggs wrote:
Yes. And despite what people think, those agencies don't have super powers. They have tools to help them, and lots of resources, but nothing out of the ordinary.
Untrue. They are in advance of mainstream developments. Spying has existed for thousands, of years *and* it is their job to discover and then discretely monitor what is going-on.
It is never one team doing everything but many highly specialist teams dedicated to particular aspects of intelligence gathering which they do expertly, and impressively, well.
All countries monitor, by all available means, what is happening in their own territory and around the world. Just because, for example, the USA and Russia are not officially loving buddies it never ever prevents their intelligence agencies covertly sharing intelligence of mutual interest. It is a incestuous world with an international web of contacts doing favours and often disregarding their own government's official political pronouncements.
There is nothing that the NSA can do that can't be done by other agencies or even individuals (or enough individuals working together).
Mmmm, you forgot physical access to targets :-) That is one of their advantages together with links into national infrastructures and seemingly endless money. They are much more audacious than "normal" people.
There is no doubt that every single security agency in the world has a team working on discovering exploitable code in all operating systems. It's what they do. Any exploit they find that has been reported is probably because some other agency has found it as well so they want to stop them using it.
Not only software but hardware too. Most hardware has backdoors which may not be routinely disclosed to purchasers. The question then arises if the "official" backdoor is the only one. Difficult to detect if the logic is coded on a chip.
The only truly secure machine is one that is at the bottom of a mine shaft, turned off and dismantled. :-)
Nope, just protected from public networks like the Internet and from radio transmissions of all types. Faraday-cage types and 'high-security rooms' don't have to be buried at the bottom of mines; they exist everywhere.
On Sun, 2017-04-16 at 06:53 -0400, ken wrote:
On 04/15/2017 04:46 AM, Pete Biggs wrote:
Not wishing to extend this thread further, but ...
There are conspiracy theories out there that the NSA is involved with bringing systemd to Linux so they can have easy access to *"unknown"* bugs - aka backdoors - to all Linux installations using systemd *[1]*.
They're conspiracy theories, and that's it.
Hmm. That's not quite it. Wikileaks recently posted a trove of docs on CIA exploits. It was big news. I'm surprised you missed that. And, yes, the exploits also include more than a few against linux.
That's not what I said - I said that the security agencies writing backdoors into systemd was a conspiracy theory. I said later that they have exploits as part of their toolkit. I'm surprised you missed that part when you replied to it ...
Years ago it was revealed that one of the linux developers inserted an exploit into the gcc code which, when the login code was compiled, would give him access to any system running it, effectively every linux system. This exploit was in the linux code for a long time and was never discovered. It was revealed only by the developer himself, and only because he was retiring. Point is: Code is often complex, especially that written in C (or C++ and others), so much so that an exploit can be written into it and not discovered for a long time, or ever. This is yet another argument against systemd: it would be much easier to hide an exploit in it than in a handful of bash scripts.
Perhaps bash is exploitable - designed to hide the malicious code put into the init.d scripts by the NSA.
P.
On 04/16/2017 03:53 AM, ken wrote:
And, yes, the exploits also include more than a few against linux. Go to their site and look under vault7. Or search for "linux" or "redhat"... you'll get hundreds of hits. Here's just one: https://wikileaks.org/spyfiles4/documents/FinSpy-3.10-User-Manual.docx (If you have only a few seconds to look at it, see page 34.)
That document appears to describe a remote control application, not an exploit. It's only useful once you have administrative access to the system in question.
I won't say that I don't think exploits against Linux systems exist, that would be naive. But, I haven't yet seen any CVEs for GNU/Linux systems resulting from the Vault7 leaks.
On Apr 15, 2017, at 12:19 AM, Anthony K akcentos@anroet.com wrote:
Also, there's a lot of people moving to FreeBSD - but it appears that the grass isn't greener there either as they are now trialling OpenRC.
You appear to have misunderstood my post.
First, TrueOS is not FreeBSD. TrueOS is to FreeBSD as Ubuntu is to Debian, kinda-sorta. Some of the things the TrueOS people do make their way back into FreeBSD, but TrueOS largely exists for those who want an easier desktop experience than stock FreeBSD or want a semi-supported bleeding-edge distribution of FreeBSD.
Now that TrueOS is based on the CURRENT (i.e. bleeding-edge) branch of FreeBSD development, TrueOS also serves a pioneer role for FreeBSD: those being the guys with all the arrows in their backs.
Because of that, TrueOS’s adoption of OpenRC doesn’t mean FreeBSD will follow suit. Maybe they will, maybe they won’t.
Second, it’s not a “trial”. It was announced, and then suddenly between two versions BSD rc was switched to OpenRC. No “are you sure,” no “here are the consequences,” no “sorry, what you’re doing here is incompatible.” Just boom, best-effort automatic conversion; if it breaks, you get to keep both pieces.
(Kinda makes you smile when you remember all the threads from those who found out that RHEL family OSes can’t self-upgrade between major versions. Suddenly it’s looking like a feature. Imagine if the EL6 to EL7 transition happened the same way.)
FreeBSD proper splits the difference between these two upgrade methods. You have to explicitly opt into minor version upgrades, and automatic major version upgrades are possible but always offered with plenty of warnings and migration advice.
If you want a FreeBSD-specific lesson from this, it would be “don't run 12.0-CURRENT on critical servers.”
Also, I’ll remind the list that one of the *prior* times the systemd topic came up, I was the one reminding people that most of our jobs summarize as “Cope with change.”
-
Alice Wonder -
Always Learning -
Andrew Holway -
Anthony K -
Bruce Ferrell -
Cameron Smith -
Chris Adams -
Christian, Mark -
Dave Stevens -
Fred Smith -
Gordon Messmer -
isdtor -
J Martin Rushton -
John R Pierce -
Jon LaBadie -
Jonathan Billings -
Karanbir Singh -
Kay Schenk -
Keith Keller -
ken -
Lamar Owen -
Leroy Tennison -
m.roth＠5-cent.us -
mark
-
Mauricio Tavares -
me＠tdiehl.org -
Nicolas Kovacs -
Nux! -
Pete Biggs -
Pete Orrall -
Philippe BOURDEU d'AGUERRE -
Robert Moskowitz -
Scott Gennari -
Scott Robbins -
Steve Clark -
Valeri Galtsev -
Warren Young