On 08/07/14 02:22, Always Learning wrote:

On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:

...

On 07/07/2014 07:47 PM, Always Learning wrote:

...

Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).

Is there a practical alternative to omnipresent, or invasive, systemd ?

...

So you are following the thread on the Fedora list? I have been ignoring it.

No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd

The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.

Seems a big revolution is being forced on Linux users when stability and the "same old familiar Linux" is desired by many, including me.

It's already started. Some configs have already moved from /etc to /usr under el7.

Whilst I'm as resistant to change as the next man, I've learned you can't fight it so best start getting used to it ;-)

...

Best I can tell is learn it and use it. And if you have any services, fix them so that they work with systemd. I work with one that does not and it is very slow to complete its startup.

I was keenly waiting to upgrade to C7. Perhaps I'll upgrade to C6 and retain familiar Linux.

On 08.07.2014 14:58, Adrian Sevcenco wrote:

On 07/08/2014 04:22 AM, Always Learning wrote:

...

On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:

...

On 07/07/2014 07:47 PM, Always Learning wrote:

...

Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).

Is there a practical alternative to omnipresent, or invasive, systemd ?

...

So you are following the thread on the Fedora list? I have been ignoring it.

No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd

The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.

err.. what? even on that wild fedora thread this did not come up!!!

i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..

There are no plans to "abolish" /etc and /var.

The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr. That way if you want to "factory reset" the system you can basically clear out /etc and you are back do the defaults. The same applies to /var. The idea is that /etc and /var become "site-local" directories that only contain the config you actually changed from the defaults for this system.

Since you already have experience with systemd you are already familiar with this system where it stores its unit files in /usr/lib/systemd and if you want to change some of them you copy them to /etc/systemd and change them there. Same principle.

/etc and /var will stay as valid as ever though and are not being "abolished".

Regards, Dennis

On 08.07.2014 15:53, Ned Slider wrote:

On 08/07/14 14:14, Dennis Jacobfeuerborn wrote:

...

On 08.07.2014 14:58, Adrian Sevcenco wrote:

...

On 07/08/2014 04:22 AM, Always Learning wrote:

...

On Mon, 2014-07-07 at 20:46 -0400, Robert Moskowitz wrote:

...

On 07/07/2014 07:47 PM, Always Learning wrote:

...

Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).

Is there a practical alternative to omnipresent, or invasive, systemd ?

...

So you are following the thread on the Fedora list? I have been ignoring it.

No. I read some of http://www.phoronix.com/scan.php?page=news_topic&q=systemd

The systemd proponent, advocate and chief developer? wants to abolish /etc and /var in favour of having the /etc and /var data in /usr.

err.. what? even on that wild fedora thread this did not come up!!!

i will presume that you understood well your information source and you are actually know what you are referring to ... so, could you elaborate more about this?(with some references) i use systemd for some time (and i keep myslef informed about it) and i would need to know in time about this kind of change..

There are no plans to "abolish" /etc and /var.

The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr. That way if you want to "factory reset" the system you can basically clear out /etc and you are back do the defaults. The same applies to /var. The idea is that /etc and /var become "site-local" directories that only contain the config you actually changed from the defaults for this system.

Since you already have experience with systemd you are already familiar with this system where it stores its unit files in /usr/lib/systemd and if you want to change some of them you copy them to /etc/systemd and change them there. Same principle.

/etc and /var will stay as valid as ever though and are not being "abolished".

That's not always true.

Some configs that were under /etc on el6 must now reside under /usr on el7.

Take modprobe blacklists for example.

On el5 and el6 they are in /etc/modprobe.d/

On el7 they need to be in /usr/lib/modprobe.d/

If you install modprobe blacklists to the old location under el7 they will not work.

I'm sure there are other examples, this is just one example I've happened to run into.

You might want to report this as a bug. The modprobe and modprobe.d man pages explicitly reference "/etc/modprobe.d/*.conf" for the configuration.

Regards, Dennis

I am sure now do not understand the bug end line. From Fedora 17 they modprobe.d moved from /etc to /var/lib ? if so why not just use a symlink from /etc to /var/lib if someone needs it there for any reason what so ever??

Eliezer

On 07/08/2014 09:12 PM, Ned Slider wrote:

Well, I stand corrected!

I was just running though the issue for a reply here, and what was broken in the rhel7rc is now fixed and indeed working as documented.

My issue looked like a regression of this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=873220

On Tue, Jul 8, 2014 at 1:08 PM, John R Pierce pierce@hogranch.com wrote:

On 7/8/2014 6:53 AM, Ned Slider wrote:

...

That's not always true.

Some configs that were under /etc on el6 must now reside under /usr on el7.

Take modprobe blacklists for example.

On el5 and el6 they are in/etc/modprobe.d/

On el7 they need to be in/usr/lib/modprobe.d/

If you install modprobe blacklists to the old location under el7 they will not work.

I'm sure there are other examples, this is just one example I've happened to run into.

this is insane. traditionally in Unix-like systems, /usr is supposed to be able to be read only and sharable between multiple systems, for instance in NFS boot scenarios. /var is specifically for host-specific complex configuration and status stuff like /var/logs /var/state /var/run and so forth.

And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?

Jonathan Billings wrote:

On Tue, Jul 08, 2014 at 01:22:54PM -0500, Les Mikesell wrote:

...

And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?

I think that a lot of these objections are addressed here:

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Great. And it's from freedesktop... as opposed to, say, a system user, and which implies to me that it's for runlevel 5 GUI-only users....

mark

On Tue, Jul 08, 2014 at 02:56:17PM -0400, m.roth@5-cent.us wrote:

...

I think that a lot of these objections are addressed here:

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Great. And it's from freedesktop... as opposed to, say, a system user, and which implies to me that it's for runlevel 5 GUI-only users....

This seems to be a common misconception.

To quote http://0pointer.de/blog/projects/the-biggest-myths.html:

9. Myth: systemd is a freedesktop.org project.

Well, systemd is certainly hosted at fdo, but freedesktop.org is little else but a repository for code and documentation. Pretty much any coder can request a repository there and dump his stuff there (as long as it's somewhat relevant for the infrastructure of free systems). There's no cabal involved, no "standardization" scheme, no project vetting, nothing. It's just a nice, free, reliable place to have your repository. In that regard it's a bit like SourceForge, github, kernel.org, just not commercial and without over-the-top requirements, and hence a good place to keep our stuff.

So yes, we host our stuff at fdo, but the implied assumption of this myth in that there was a group of people who meet and then agree on how the future free systems look like, is entirely bogus.

freedesktop.org hosts a variety of software projects, not all of which are desktop-oriented. Just look at the list here:

http://www.freedesktop.org/wiki/Software/

It's worth noting that much of the software projects hosted there are desktop-oriented, but that doesn't mean that systemd is only for desktops. It just happens to be the site where the systemd documentation resides, and is a great place to peruse if you are interested in learning more about systemd.

On Tue, Jul 08, 2014 at 02:34:49PM -0500, Les Mikesell wrote:

On Tue, Jul 8, 2014 at 1:47 PM, Jonathan Billings billings@negate.org wrote> > I think that a lot of these objections are addressed here:

...

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Ummm, 'addressed' by pointing out that a whole bunch of the changes fedora has made break things that are expected to work in unix-like systems. I fail to see how that helps with the problem.

I'm not sure if I'm reading the same page as you are. I could sum up the response to your objection with two points:

1. systemd works fine with /usr on a separate file system that is not pre-mounted at boot.

2. Modern linux distributions currently don't work well when /usr is not pre-mounted at boot, and this has been the case for a while.

Fedora went through a process to try to clean up the mess that Linux has fallen into, by identifying all the executables in /bin, /sbin, /etc, /var (etc.) that aren't needed to boot the system, and migrating them into /usr.

This migration was put into place for reasons unrelated to systemd. Perhaps you have a valid complaint about this change, but don't lump it together with your issue with systemd.

On Jul 8, 2014, at 1:22 PM, Les Mikesell lesmikesell@gmail.com wrote:

On Tue, Jul 8, 2014 at 1:08 PM, John R Pierce pierce@hogranch.com wrote:

...

On 7/8/2014 6:53 AM, Ned Slider wrote:

...

That's not always true.

Some configs that were under /etc on el6 must now reside under /usr on el7.

Take modprobe blacklists for example.

On el5 and el6 they are in/etc/modprobe.d/

On el7 they need to be in/usr/lib/modprobe.d/

If you install modprobe blacklists to the old location under el7 they will not work.

I'm sure there are other examples, this is just one example I've happened to run into.

this is insane. traditionally in Unix-like systems, /usr is supposed to be able to be read only and sharable between multiple systems, for instance in NFS boot scenarios. /var is specifically for host-specific complex configuration and status stuff like /var/logs /var/state /var/run and so forth.

And more to the point, /usr isn't supposed t be needed until you are past the point of mounting all filesystems so you can boot from something tiny. Doesn't modprobe need its files earlier than that?

This work is all about being able to boot a system with just a read-only /usr. Any foo you need to get to a complex filesystems, like NFS or encrypted software RAID needs to be in the initial ramdisk which the boot loader can access before the kernel loads and which tools like Dracut build based on what’s required for your particular setup. The seeds of that change basically existed from the time that initial ram disks were introduced as a feature a long time ago, now we’ve just widely acknowledged this reality.

— Mark Tinberg, System Administrator Division of Information Technology - Network Services University of Wisconsin - Madison mtinberg@wisc.edu

On Tue, 2014-07-08 at 15:14 +0200, Dennis Jacobfeuerborn wrote:

There are no plans to "abolish" /etc and /var.

The idea is that rather than say proftpd shipping a default config file /etc/proftpd.conf that you then have to edit for you needs instead it will ship the default config somewhere in /usr and let the config in /etc override the one in /usr.

Exactly the same as Logwatch does now in C5 and C6.

On 07/08/2014 11:37 AM, Always Learning wrote:

Please see the link above. I used it to find the 'stateless' item, and after selecting it clicked on

http://0pointer.de/blog/projects/stateless.html

There are many use cases involving servers where such a capability would be highly desirable. Most are cloud-oriented, where you want to spin up an instance rapidly (to deal with increased load, perhaps) and then spin it down, and having dynamically loaded /etc and /var content allows this in a smooth manner. Static servers have their uses, of course, but at least in my data center I find actual server load to be very dynamic, but power load to be rather static; why *shouldn't* the power used be proportional to the work load?

The real promise of 'cloud' technology is for us in in-house servers that can spin up only when needed, saving power and cooling costs in the process. Stateless is not the only way to go, of course, and nothing in the blog post to which you link is 'never again honor anything in /etc and /var' to be found, but rather, much like /etc serves as a fall-back for many programs who look first in a dot-file in ~, the content in /usr serves as an OS-default fallback to the per-system (or per-instance) configuration and state in /etc and /var.

It is a different way of looking at things, for sure, but I can definitely see a server use-case for this sort of thing, especially since there is significant budget pressure to reduce power costs.

And dynamic spinup of servers to handle increased load is a use case for systemd's rapid bootup. They go hand-in-hand.

The Unix philosophy unfortunately sometimes misses the forest for all of the trees. Sometimes tools need to actually be designed to work together, and sometimes a Swiss Army Knife is the right thing to have.

(And I'm an old Unix hack, too, having used Unix of several flavors since before Linux was even a gleam in Linus' eyes).

On 07/08/2014 12:06 PM, Les Mikesell wrote:

Don't know about your servers, but ours take much, much longer for their boot-time memory and hardware tests and initialization than anything the old style sysvinit scripts do.

Physical servers can be told to skip certain parts of their POST, especially the memory test. Memory tests are redundant with ECC. (I know; I have an older SuperMicro server here that passes memory testing in POST but throws nearly continuous ECC errors in operation; it does operate, though). If it fails during spinup, flag the failure while spinning up another server.

Virtual servers have no need of POST (they also don't save as much power; although dynamic load balancing can do some predictive heuristics and spin up host hypervisors as needed and do live migration of server processes dynamically).

To detect failures early, spin up every server in a rotating sequence with a testing instance, and skip POST entirely.

If you have to, spin up the server in a stateless mode and put it to sleep. Then wake it up with dynamic state.

There are alot of possibilities here, if you're willing to think outside the 1970's timesharing minicomputer box that gave rise to the historical Unix philosophy. And this has nothing to do with Windows; I have been a primarily-Linux user since 1997.

Long POSTs need to go away, with better fault tolerance after spinup being far more desirable, much like the promise of the old as dirt Tandem NonStop system. (I say the 'promise' rather than the 'implementation' for a reason.....).

On 07/08/2014 01:19 PM, m.roth@5-cent.us wrote:

Lamar Owen wrote:

...

On 07/08/2014 12:06 PM, Les Mikesell wrote:

<snip> > There are alot of possibilities here, if you're willing to think outside > the 1970's timesharing minicomputer box that gave rise to the historical > Unix philosophy. And this has nothing to do with Windows; I have been a > primarily-Linux user since 1997. ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?

Yes I can. I did/do both. There are many things I do not like about 'cloud' and the security ones are going to be tough nuts to work out. But it is the way computing is dividing up. I like the isolation of ownership and risks that 'cloud' enables.

I did time-sharing on a MARK-IV. I don't miss it.

On 07/08/2014 10:36 AM, Always Learning wrote:

On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:

...

ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?

75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).

Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.

Those were the days.

110 and 300 Bps. (model 35 and 33)

75 and 50 Baud was 5 level code (model 15, 19, 28 and 32)

There was never a 1200 Bps gearset

I'm an ex teletype mechanic.... Springs, levers, cams and electromagnets. That was my door to telecom and ultimately to computers.

On 7/8/2014 11:13 AM, Richard Pierce wrote:

I personally used a 'portable' 300-baud TI Silent 700 which printed on thermal paper and had an acoustic coupler on the side of it for those old phone handsets with the two circular cups. We dialed in and waited with great anticipation to see the next word coming from the remote machine. You also quickly learned what Ctrl-R was for due to the delete key didn't work very well‎ once the typed character was printed on thermal paper. Yes, 300 and 1200 baud were slow and taught us something about patience.

in college (early 1970s) my roommate had a GE Terminet 1200 which was a 120cps printer with plain paper and a ribbon, and an integral acoustic coupler. this was lightyears--er--12X faster than the defacto Teletype stuff most folks had. But, until circa 1980, most of my actual work was with punchcards and/or (later) direct connect VDTs at 9600 baud. I do still have a USR Courier 2400E somewhere in storage, which was a 2400 baud modem that had data compression and could send plain ascii at about 9600 bps, along with a couple Racal Vadic 9600-ish modems.

Always Learning wrote:

On Tue, 2014-07-08 at 13:19 -0400, m.roth@5-cent.us wrote:

...

ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?

75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).

Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.

Those were the days.

I was dialing in from work to upload homework at 300 baud, around '84. When I got my first modem for my first real PC (we'll skip the CoCo), *I* had 1200 baud. *nyah*

But between 1978, when I went back to college, and '81 or os, a year into my first programming job, I was on punch cards; then it was the shared three terminals in the hall. Originally, a 370-168 timeshare, then, after we won the lottery to get it nine months before most everyone, we had our 4300. And we had *real* line printers.....

But I say there *ain't* no differmenints. You'se is gots your share, we had VM regions.....

On 7/8/2014 10:36 AM, Always Learning wrote:

75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).

Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.

actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)

Always Learning wrote:

On Tue, 2014-07-08 at 11:10 -0700, John R Pierce wrote:

...

On 7/8/2014 10:36 AM, Always Learning wrote:

...

75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).

Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.

actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)

110 baud definitely rings a bell. I saw my first Teletype in 1967/1968 at Scotland's National Engineering Laboratory (NEL). Chugging away, it seemed to be an exciting example of "real" computing - and it wasn't a bit like punched cards.

'Ey! What'cho got 'gainst punch cards?

mark "except the card punch in the lab that punched *other* than what it printed, that once...."

Always Learning wrote:

On Tue, 2014-07-08 at 16:32 -0400, m.roth@5-cent.us wrote:

...

'Ey! What'cho got 'gainst punch cards?

Never used the Power Samas 36? column cards, just the plain boring 80's.

Nope, just the normal 80 column punchs. All IBM, y'know.

Was an excellent hand puncher. Could easily read cards by holding them up to the light and could fill-in the wrongly punched hole to avoid having to re-punch the entire card.

Never heard of a hand puncher. All I ever used or saw were desk-sized machines.

H-1250, H-120, H-L61, H-L66, H-L64, DPS 8 etc. + BBC Micro B & B+

To catch that error, it took the lab assistant, the *only* time in my school career I needed one, to read the actual holes.

Nasty.

mark

On Tue, 2014-07-08 at 17:10 -0400, Robert Moskowitz wrote:

The read up on Grace Hopper and how she 'discovered' an unknown opcode when a mispunch she glued in with nail polish. They used hand punchers a lot on her programming team.

Not entirely unknown because the opcode must have been known to the technicians or computer designers but not actually documented for the programmers.

40 used to be NOP (no op) on Honeywells H-200 series.

On 07/08/14 21:45, Hal Wigoda wrote:

...

On Jul 8, 2014, at 4:36 PM, Always Learning centos@u62.u22.net wrote:

...

On Tue, 2014-07-08 at 17:10 -0400, Robert Moskowitz wrote:

The read up on Grace Hopper and how she 'discovered' an unknown opcode when a mispunch she glued in with nail polish. They used hand punchers a lot on her programming team.

Not entirely unknown because the opcode must have been known to the technicians or computer designers but not actually documented for the programmers.

40 used to be NOP (no op) on Honeywells H-200 series.

And IBM assembler

(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)

Anyone want to borrow my IBM assembly text from college? I will say, though, that if I could have gotten the republication rights, I'd have put all manufacturers of sleeping pills out of business....

mark

On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:

'Ey! What'cho got 'gainst punch cards?

and let's not forget the punched tapes :)

-- Arun Khan

On 07/10/14 06:42, Always Learning wrote:

On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:

...

On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:

...

'Ey! What'cho got 'gainst punch cards?

and let's not forget the punched tapes :)

5 hole or 7 hole ?

Sorry, but when I hear that, I think of what my first wife used as the typesetter for an underground newspaper....

mark

Robert Moskowitz wrote:

On 07/10/2014 07:55 AM, mark wrote:

...

On 07/10/14 06:42, Always Learning wrote:

...

On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:

...

On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:

...

...

...

...

'Ey! What'cho got 'gainst punch cards?

and let's not forget the punched tapes :)

5 hole or 7 hole ?

Sorry, but when I hear that, I think of what my first wife used as the typesetter for an underground newspaper....

I assume it was not a linotypewriter that put out lead letters ready for the printing presses?

My uncle worked for the Cleveland Press as a typesetter.

They just had one office suite. She'd type the tape, and that would be sent off to the printers.

mark "we won't talk about the month I punch Addressograph plates...."

Always Learning wrote:

On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:

...

    mark "we won't talk about the month I punch Addressograph

plates...."

Addressograph plates? That is really ancient ! but they were incredible useful in those days.

Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM

mark

On 07/10/2014 12:47 PM, m.roth@5-cent.us wrote:

Always Learning wrote:

...

On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:

...

     mark "we won't talk about the month I punch Addressograph

plates...."

Addressograph plates? That is really ancient ! but they were incredible useful in those days.

Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM

But the Linotype melted the lead and you pressed which key you wanted the lead to flow into. Kind of. It was cool to see that bar of lead slowly get lowered into the melting pot and finally out the other side came the lead on steel printing plate. Though one I saw only made rows of text that then had to be lined up on the steel plate. I guess it was for allowing inclusion of pictures and such.

Ah how xerography changed things.

And that is again the point. We do things one way because with a big enough hammer we can get it to work. Then new ways and new goals come along and the old stuff heads off for the big melting pot in the backyard.

On Thu, Jul 10, 2014 at 12:47 PM, m.roth@5-cent.us wrote:

Always Learning wrote:

...

On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:

...

    mark "we won't talk about the month I punch Addressograph

plates...."

Addressograph plates? That is really ancient ! but they were incredible useful in those days.

Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM

Any picts or videos? I am just picturing a room with those thingies and a couple of Jacob's latters and a Van der Graff while on the background a table with a covered body is being slowly raised to the roof.

"No, not the third switch!"

  mark

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 07/10/2014 07:17 PM, Always Learning wrote:

On Thu, 2014-07-10 at 14:48 -0400, Mauricio Tavares wrote:

...

On Thu, Jul 10, 2014 at 12:47 PM, m.roth@5-cent.us wrote:

...

Always Learning wrote:

...

On Thu, 2014-07-10 at 10:39 -0400, m.roth@5-cent.us wrote:

...

     mark "we won't talk about the month I punch Addressograph

plates...."

Addressograph plates? That is really ancient ! but they were incredible useful in those days.

Yeah... but did you ever do it, or see it done? Forget the old manual Underwood, this required actual *force* hitting the keys (yes, the machine was electric). No speed, either - the actuator arms had to hit the metal. WHAM-WHAM-WHAM-WHAM

   Any picts or videos? I am just picturing a room with those

thingies and a couple of Jacob's latters and a Van der Graff while on the background a table with a covered body is being slowly raised to the roof.

"No, not the third switch!"

Sorry mate. The programmers were all busy sitting around the table in the engineers' room playing Bridge (a card game) :-)

Uker when we only had a short break. Pinochle when we had more time.

$1 a hand.

On 07/10/2014 06:42 AM, Always Learning wrote:

On Thu, 2014-07-10 at 10:33 +0530, Arun Khan wrote:

...

On Wed, Jul 9, 2014 at 2:02 AM, m.roth@5-cent.us wrote:

...

'Ey! What'cho got 'gainst punch cards?

and let's not forget the punched tapes :)

5 hole or 7 hole ?

5 of course. Whatever do you need 7 for? What is the shift up and shift down for anyway?

BAUDOT beats ASCII and especially UNICODE any day. :)

On 07/08/2014 04:28 PM, Always Learning wrote:

On Tue, 2014-07-08 at 11:10 -0700, John R Pierce wrote:

...

On 7/8/2014 10:36 AM, Always Learning wrote:

...

75 baud on a TTY (clank, clank, clank, ding, thud as the printer head returned to the beginning of the line) and an amazingly fast speed of 300 baud on the up-market Terminet (? spelling).

Perhaps the speeds were 300 and 1,200 baud? It was a long time ago.

actual Teletype KSR/ASR 33 kind of machines were 110 baud (10 cps, as they used 2 stop bits)

110 baud definitely rings a bell. I saw my first Teletype in 1967/1968 at Scotland's National Engineering Laboratory (NEL). Chugging away, it seemed to be an exciting example of "real" computing - and it wasn't a bit like punched cards.

No. It was paper tape. And on a PDP8 I had access to in '67, it had a high speed paper tape reader to load the 'OS' and FORTRAN system. In 4K of memory.

The invention of the 8" diskette as the boot media for the 360 was a serious step forward. Also right around that time.

On 07/08/2014 07:11 PM, John R Pierce wrote:

On 7/8/2014 2:07 PM, Robert Moskowitz wrote:

...

The invention of the 8" diskette as the boot media for the 360

370, not 360. the 360's had microcode in "ROM", one of the innovations of the System/370 was soft loaded microcode.

Yeah. I thought about it a bit and did not feel right with the timeline. It would have to have been just before the 370. Makes more sense it was the 370. I ran with the BUNCH back then. IBM stuff was to be generally ignored...

On Jul 8, 2014 1:48 PM, "Original Woodchuck" marmota@embarqmail.com wrote:

On Tue, Jul 08, 2014 at 01:19:58PM -0400, m.roth@5-cent.us wrote:

...

Lamar Owen wrote:

...

On 07/08/2014 12:06 PM, Les Mikesell wrote:

<snip> > There are alot of possibilities here, if you're willing to think

outside

...

...

the 1970's timesharing minicomputer box that gave rise to the

historical

...

...

Unix philosophy. And this has nothing to do with Windows; I have

been a

...

...

primarily-Linux user since 1997.

ROTFLMAO! And can you explain the difference between "cloud" and "time-sharing on a mainframe"?

    mark

Mainframes are housed in vaults with powerful airconditioners; operators walk around with 132-column fanfold printouts. Operators may have goatees.

Clouds are housed in vaults with powerful airconditioners; operators walk around with little gadgets. Operators may have goatees.

They prefer to be called chinbeards. ;)

Dave _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 07/08/2014 01:19 PM, m.roth@5-cent.us wrote:

And can you explain the difference between "cloud" and "time-sharing on a mainframe"

Sure.

"Cloud" is much more dynamic, for better or for worse, than mainframes in ye olde days. Cloud takes advantage on smart clients, and, well, is a bit of a nebulous terms covering many things traditional servers do, but with more of an emphasis on dynamic load balancing. Ideally, if no one is using a server that server should not be running, as it is wasting power. The challenge is to get servers up with low latency. And when I say 'servers' that includes physical iron as well as fully virtualized hardware and more fluid virtual containers that just sortof act like a server.

It's all about getting the necessary services to the client processes, regardless of whether the client is smart or dumb.

And ideal application for cloud-based technology is renderfarms; transparent spinup and spindown of render machines, which often contain very power-hungry GPUs, saves lots of money.

As much as it is going to rub sysadmins the wrong way (because the very comfortable and flexible SA hat is one I wear often it definitely rubs me a bit wrong), ideally the admin should spend time on setup and implementation more than operation; the operation of this dynamic spinup and spindown of resources, once set up by a competent admin, should be entirely user-driven and automated.

Ye Olde Mainframes (not the more modern stuff, which *is* more cloud-oriented) never did this and required monstrous opex for personnel. Cloud is about reducing opex, pure and simple. Setup can be capex, and thus a separate budget (at least here, once again wearing the way too stiff CIO hat).

Robert mentions security, and that is a very very true statement, and is where it is incumbent upon the admin who sets it up to be competent.

On 07/08/2014 01:22 PM, John R Pierce wrote:

On 7/8/2014 9:25 AM, Lamar Owen wrote:

...

Physical servers can be told to skip certain parts of their POST, especially the memory test. Memory tests are redundant with ECC.

but, you HAVE to zero ALL of memory with ECC to initialize it.

True enough; but this shouldn't take five minutes on a server with multiple GB/s memory bandwidth. My Dell 6950's take a full five minutes to POST, and that's ridiculous. There's eight cores; each core has enough bandwidth to its local RAM (NUMA, of course) where it should be able to sustain 2GB/s zeroing without a lot of trouble; that's a rate of 16GB/s aggregate, and my 32GB of RAM should be zeroed in 2 seconds or so. Not five minutes.

It's still not as bad as our Sun Enterprise 6500 with 18GB, though, which takes about a minute per GB, which is also ridiculous (it's also NUMA, and the Sun firmware does start up each CPU to test it's own local RAM blocks).

On 07/09/2014 01:00 PM, John R Pierce wrote:

i find the biggest part of server POST is all the storage and network adapter bios's need to get in there, scan the storage busses, enumerate raids, initialize intel boot agents, and so forth.

I've found that disabling all but the boot device's BIOS works wonders and makes installs far happier, with the exception of real hardware RAID cards. The Linux kernel is quite happy doing any and all fibre-channel enumeration with the HBA's BIOS turned off. (All my large storage is FC and iSCSI SAN). And the 'Intel boot agent' only lives long enough to PXE boot if I need that. The 3Ware 9500's I have typically take a bit longer and require the BIOS, though, but with a small array that's a few tens of seconds, a minute tops. That's one advantage of the Linux mdraid......

But our 6950's spend five minutes only on the memory test; that's not counting the Dell PERC boot device enumeration and drive spinup.

The fastest booting servers I have are our two pfSense firewalls; I've trimmed the BIOS setup to the bone and those boxes reboot in a few tens of seconds. (Yeah, I count a firewall as a server, since it's running on server hardware (Intel 5000X-based quad core dual Xeons with 4GB of RAM each; does wire-speed with > one million pf table entries on a 1Gb/s WAN link) and providing an essential network service to the rest of the hosts on the network).

But, point taken, since there's more to a POST than just the memory test.

On Tue, Jul 8, 2014 at 11:25 AM, Lamar Owen lowen@pari.edu wrote:

Memory tests are redundant with ECC. (I know; I have an older SuperMicro server here that passes memory testing in POST but throws nearly continuous ECC errors in operation; it does operate, though). If it fails during spinup, flag the failure while spinning up another server.

I don't think that is generally true. I've seen several IBM systems disable memory during POST and come up running will a smaller amount.

Virtual servers have no need of POST (they also don't save as much power; although dynamic load balancing can do some predictive heuristics and spin up host hypervisors as needed and do live migration of server processes dynamically).

Our services that need scaling need all of the hardware capability and aren't virtualized. That might change someday...

To detect failures early, spin up every server in a rotating sequence with a testing instance, and skip POST entirely.

If you have to, spin up the server in a stateless mode and put it to sleep. Then wake it up with dynamic state.

Our servers tend to just run till they die. If we didn't need them we wouldn't have bought them in the first place. I suppose there are businesses with different processes that come and go, but I'm not sure that is desirable.

Long POSTs need to go away, with better fault tolerance after spinup being far more desirable, much like the promise of the old as dirt Tandem NonStop system. (I say the 'promise' rather than the 'implementation' for a reason.....).

If you need load balancing anyway you just run enough spares to cover the failures.

Les Mikesell wrote:

On Tue, Jul 8, 2014 at 10:58 AM, Lamar Owen lowen@pari.edu wrote:

...

...

And dynamic spinup of servers to handle increased load is a use case for systemd's rapid bootup. They go hand-in-hand.

Don't know about your servers, but ours take much, much longer for their boot-time memory and hardware tests and initialization than anything the old style sysvinit scripts do.

Ours would, but we disabled the POST-time memory checks on most. When you've got upwards of 64GB, it starts to take a while... and for 256G... let's not go there, unless you've got 15 min.

mark

On Tue, Jul 08, 2014 at 02:26:59AM +0100, Always Learning wrote:

On Mon, 2014-07-07 at 20:59 -0400, Scott Robbins wrote:

...

To the tune of YMCA

So young man, if you want to stick To something, that more resembles Unix And young man, if you want to sing Goodbye to Poettering,

(bah bah bah bah)

FreeeeeeeeeBSD (yeah yeah yeah) FreeeeeeeeeBSD

etc. I just made this up at work today, and that's as far as I got.

Ah, a Broadway musical next ? :-)

I'm an old man who remembers multics, GECOS/GCOS and the 'B' programming language.

Is FeeBSD systemd-less ? Got a FreeBSD manual.

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

On 07/08/2014 03:41 AM, Always Learning wrote:

On Mon, 2014-07-07 at 21:34 -0400, Scott Robbins wrote:

...

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

Thanks. I've deployed C 5.10 and C 6.5. Thought I'll play with C 7.

I notice, from http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7, the apparent replacement of IPtables by firewalld

https://fedoraproject.org/wiki/FirewallD

Check "Static_Firewall" Chapter: https://fedoraproject.org/wiki/FirewallD#Static_Firewall_.28system-config-fi...

and one below it. You can have iptables rules and also rules from system-config-firewall

I still prefer IPTables, so in Fedora I simply disabled firewalld and enabled IPTables. No need to uninstall. I have read that IPTables will continue to be available alongside firewalld for the unspecified future.

Note that IPTables rule syntax and structure have evolved so your ruleset may need to be updated. I did find that the current version of IPTables will actually convert old rulesets on the fly, at least as far as the syntax of the individual rules is concerned. From there you can simply use iptables-save to save the converted ruleset.

One of the items on my tudo list is to learn firewalld. The switch from ipchains took a bit of learning and I expect this switch will as well.

One of the stated reasons for firewalld is that dynamic rule changes do not clear the old rules before loading the new ones, to paraphrase, "where IPTables does." If true, that would leave a very small amount of time in which the host would be vulnerable. I have no desire to peruse the source code to determine the veracity of that statement, so if there is someone here who could verify that changing the rules in IPTables, whether using the iptables command or the iptables-restore command, I would be very appreciative. No need to go to any trouble to locate that answer as I am merely curious.

Thanks!

On 07/08/2014 08:00 AM, Dennis Jacobfeuerborn wrote:

On 08.07.2014 09:12, Ljubomir Ljubojevic wrote:

...

On 07/08/2014 03:41 AM, Always Learning wrote:

...

On Mon, 2014-07-07 at 21:34 -0400, Scott Robbins wrote:

...

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

Thanks. I've deployed C 5.10 and C 6.5. Thought I'll play with C 7.

I notice, from http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7, the apparent replacement of IPtables by firewalld

https://fedoraproject.org/wiki/FirewallD

Check "Static_Firewall" Chapter: https://fedoraproject.org/wiki/FirewallD#Static_Firewall_.28system-config-fi...

and one below it. You can have iptables rules and also rules from system-config-firewall

If you want to avoid firewalld for now you can uninstall it and instead install the iptables-services package. This replaces the old init scripts and provides an "iptables" systemd unit file that starts and stops iptables and if you require the old "service iptables save" command you can reach that using "/usr/libexec/iptables/iptables.init".

Also if you want to keep NetworkManager on a Server you can install the NetworkManager-config-server package. This only contains a config chunk with two settings: no-auto-default=* ignore-carrier=*

With this package installed you get a more traditional handling of the network. Interfaces don't get shutdown when the cable is pulled, no automatic configuration of unconfigured interfaces and no automatic reload of configuration files (the last one doesn't require the package and is now the NetworkManager default behaviour).

Regards, Dennis

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

--

---

David P. Both, RHCE Millennium Technology Consulting LLC 919-389-8678

dboth@millennium-technology.com

www.millennium-technology.com www.databook.bz - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both

---

This communication may be unlawfully collected and stored by the National Security Agency (NSA) in secret. The parties to this email do not consent to the retrieving or storing of this communication and any related metadata, as well as printing, copying, re-transmitting, disseminating, or otherwise using it. If you believe you have received this communication in error, please delete it immediately.

Dennis Jacobfeuerborn wrote:

On 08.07.2014 14:35, David Both wrote:

...

I still prefer IPTables, so in Fedora I simply disabled firewalld and enabled IPTables. No need to uninstall. I have read that IPTables will continue to be available alongside firewalld for the unspecified future.

<nsip>

...

One of the stated reasons for firewalld is that dynamic rule changes do not clear the old rules before loading the new ones, to paraphrase, "where IPTables does." If true, that would leave a very small amount of time

in which

...

the host would be vulnerable. I have no desire to peruse the source

code to

...

determine the veracity of that statement, so if there is someone here

who could verify that

...

changing the rules in IPTables, whether using the iptables command or the iptables-restore command, I would be very appreciative. No need to

go to

...

any trouble to locate that answer as I am merely curious.

<snip>

The problem firewalld tries to solve is that nowadays you often want to insert temporary rules that should only be active while a certain application is running. This collides a bit with the way iptables works. For example libvirt inserts specific rules when you define networks for virtualization dynamically. If you now do an iptables-save these rules get saved and on next boot when these rules are restored the exist again but now libvirt will add them dynamically a second time.

Firewalld is simply a framework built around iptables that allows for applications to "register" rules with additional information such as

<snip> And so nothing like, say, fail2ban....

mark

On Jul 7, 2014, at 6:34 PM, Scott Robbins scottro@nyc.rr.com wrote:

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.

And I chose the word "abomination" carefully and deliberately. And I also chose the Biblical allegory very deliberately. Just as the "abomination of desolation" is that which will portend the end of the world, systemd is the "abomination of desolation" that will portend the beginnings of the destruction of the Linux most of us hold dear.

But that's not why I mentioned this... I'd never thought of BSDs before, but considering heartbleed and how OpenBSD forked LibreSSL and is taking security very seriously, it's actually something I am going to give a great deal of consideration to.

I've been a Linux admin for nearly 20 years now - I was around when it was 0.99 and everyone was cheering about it being POSIX finally. Maybe it's just time to move on.

--Russell

On 08.07.2014 13:57, Scott Robbins wrote:

On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:

...

On Jul 7, 2014, at 6:34 PM, Scott Robbins scottro@nyc.rr.com wrote:

...

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.

Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)

Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.

That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.

Regards, Dennis

Scott Robbins wrote:

On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:

...

On 08.07.2014 13:57, Scott Robbins wrote:

...

...

Now that it's insinuated itself in the RHEL system, I do wonder if it

is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.

That presumes that your conservative attitude is the majority opinion though.

Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.

<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented Here), and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?

mark

On Tue, Jul 08, 2014 at 12:21:43PM -0400, Scott Robbins wrote:

Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person.

I should also add that Adam's comment was very tongue-in-cheek and aimed at people who took it that way. Again, I really apologize for taking that out of context and expecting everyone to somehow magically grasp the context especially as it seems it irked a few people. He was saying it to me and a few others, who he knows, and all fit the description, and it was certainly meant as a joke.

On Jul 8, 2014, at 9:27 AM, Scott Robbins scottro@nyc.rr.com wrote:

On Tue, Jul 08, 2014 at 12:21:43PM -0400, Scott Robbins wrote:

...

Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person.

I should also add that Adam's comment was very tongue-in-cheek and aimed at people who took it that way. Again, I really apologize for taking that out of context and expecting everyone to somehow magically grasp the context especially as it seems it irked a few people. He was saying it to me and a few others, who he knows, and all fit the description, and it was certainly meant as a joke.

FWIW I accept your apology. I also would be remiss if I didn't point out that if this is the case, you've done him a huge, huge disservice by spreading a non-contextual insult towards a class of people that he probably actually did say.

Perhaps now he will be more careful with what he says - even amongst friends. Sometimes things said in confidence can come back to bite you.

What he said, even if amongst friends, btw, *is* wrong, and stupid, and should not have been said. But I'm guilty of the same thing, so beam, mote, and all that.

--Russell

On 07/08/2014 12:21 PM, Scott Robbins wrote:

On Tue, Jul 08, 2014 at 10:27:41AM -0400, m.roth@5-cent.us wrote:

...

Scott Robbins wrote:

...

On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:

...

On 08.07.2014 13:57, Scott Robbins wrote:

Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.

<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented Here), and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?

Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person. He was formerly with Mandriva, I think, and came to Fedora where he has made enormous strides in seeing things from the user standpoint, getting bugs filed, making Fedora a much better distribution (and better documented), than it had been. My statement's implication, though of course, tongue in cheek, was that Even Adam thinks....

So, for any friends or fans of Adam on this list, I apologize if that came out as a putdown or anything more than a jesting complaint.

I have also had good interaction with Adam. I never found him getting down on my not being a real admin.

On Tue, Jul 8, 2014 at 11:21 AM, Scott Robbins scottro@nyc.rr.com wrote:

On Tue, Jul 08, 2014 at 10:27:41AM -0400, m.roth@5-cent.us wrote:

...

Scott Robbins wrote:

...

On Tue, Jul 08, 2014 at 02:09:49PM +0200, Dennis Jacobfeuerborn wrote:

...

On 08.07.2014 13:57, Scott Robbins wrote:

...

Very true. I do remember Adam Williamson of Fedora commenting on their forums that he pictured many of the complainers about various changes, including systemd, to be old white guys, which fit me to a T.

<snip> So he's guilty of ageism, as well as aggressively NIH (Not Invented

Here),

...

and a faddist.... Did he actually have any *good*, persuasive reasons for such changes?

Wow. This was my bad in assuming everyone knows who Adam is--a very good natured and helpful person. He was formerly with Mandriva, I think, and came to Fedora where he has made enormous strides in seeing things from the user standpoint, getting bugs filed, making Fedora a much better distribution (and better documented), than it had been. My statement's implication, though of course, tongue in cheek, was that Even Adam thinks....

So, for any friends or fans of Adam on this list, I apologize if that came out as a putdown or anything more than a jesting complaint.

Yeah, tongue in cheek. Uh huh. Sure.

"Disadvantages: people who dislike change are going to hate this one. Note to people who dislike change: you could still remove NetworkManager post-install if you really hate it. Having it in core doesn't preclude that. You could also still exclude it with a kickstart. Makes the minimal install somewhat larger." - Adam Williamson ( https://bugzilla.redhat.com/show_bug.cgi?id=693602#c31)

On 08.07.2014 15:22, Steve Clark wrote:

On 07/08/2014 08:09 AM, Dennis Jacobfeuerborn wrote:

...

On 08.07.2014 13:57, Scott Robbins wrote:

...

On Mon, Jul 07, 2014 at 06:50:21PM -0700, Russell Miller wrote:

...

On Jul 7, 2014, at 6:34 PM, Scott Robbinsscottro@nyc.rr.com wrote:

...

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

That's a good point. Systemd may be the "abomination of desolation" that causes me to finally start moving to a BSD variant. Or at least start looking at one.

Y'know, I was considered a troll when I said on Fedora forums that systemd going into server systems might start driving people away from RH to the BSDs. (And to be honest, I was being trollish there, in a friendly way--in the same way at work I'll say something about Arch loudly enough for our Arch lover to hear.)

Now that it's insinuated itself in the RHEL system, I do wonder if it is going to start driving people away. In many ways, IMHO, RH has become the Windows of Linux, with no serious competitors, at least here in the US. Sure, some companies use something else, but when I had to job hunt last year, 90-95 percent of the Linux admin jobs were for RedHat/CentOS/OEL/SL admins.

That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.

Regards, Dennis

My concern it that it is a massive change with a large footprint. How secure is it really? It has arguably become the second kernel it touches and handles so many things.

I agree but that is a change that you actively have to opt into though. CentOS 6 will receive updates for many years to come so you don't have to immediately migrate everything over in a rush. Also systemd is hardly new at this point. It has been available for years and had quite some time to mature. Red Hat would not have made it the core of its "Enterprise" OS if it didn't think it would be very reliable.

Maybe on desktops it makes sense - but I fail to see any positives for servers that once started run for months at a time between reboots.

The ability to jail services and restrict it's resources is one big plus for me. Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax. Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.

Its certainly a change one needs to get used to but as mentioned above I don't think its a bad change and you don't have to jump to it immediately if you don't want to.

Regards, Dennis

On Tue, 08 Jul 2014 09:04:59 -0500 Johnny Hughes johnny@centos.org wrote:

And this is indeed the crux of the matter ... systemd is NOT just about booting or boot up time (combing posts here .. but this is the answer to, why use this on a server where fast booting is not important).

Systemd is emacs for booting without extension capabilities - so at least with no clue.

The whole idea is to put stuff into a DSL which can't be formulated with a not turing complete language. To build something, which has nice shortcuts for many things: fine. But that has nothing to do with systemd.

What you could build is a event system with nice hooks to place your code. And you could use that for many things, when it's damn simple and fast.

But systemd is everything but not stupid simple. It's only stupid.

Best Regards Oli

On Tue, Jul 8, 2014 at 8:42 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:

Also the switch from messy bash scripts to a declarative configuration makes things easier once you get used to the syntax.

Sorry, but I'd recommend that anyone who thinks shell syntax is 'messy' just stay away from unix-like systems instead of destroying the best parts of them. There is a huge advantage of consistent behavior whether some command is executed interactively on the command line or started automatically by some other means.

Then there is the fact that services are actually monitored and can be restarted automatically if they fail/crash and they run in a sane environment where stdout is redirected into the journal so that all output is caught which can be useful for debugging.

What part of i/o redirection does the shell not handle well for you?

Its certainly a change one needs to get used to but as mentioned above I don't think its a bad change and you don't have to jump to it immediately if you don't want to.

'Immediately' has different meanings to different people. I'd rather see such things discussed in terms of cost of re-implementations. How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)? Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.

On Tue, 8 Jul 2014, Lamar Owen wrote:

Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?

Yes. Look at Microsoft and Windows 8 and a similar attitude of "get over it, and just buy it". I'm not surprised that the head developer was terminated days after its release. Lemmings think jumping off a cliff is a good idea, too. Several designers thinking its a good idea and implementing it across the board does NOT mean it's a good idea to the end user.

Even the Unix philosophy was new at one point. Just because it works doesn't mean it's the best that can be found.

The Unix philosophy is not new, but blossomed after Windows put a stranglehold on everything else.

Consistency is not the only goal. Efficiency should trump consistency,

I am darn sick and tired about hearing of "efficiency". Efficiency does not 100% translate to effective productivity. Furthermore, user satisfaction is not counted into efficiency. I have heard people complain about air conditioners with extremely high efficiencies. The problem is that they don't put out much cold air. If the product is ineffective, very hard to work with, but efficient...I'd far rather use something much less cumbersome and effective but being less efficient. That translates to higher productivity and satisfaction, which you really want. Effectiveness and satisfaction should go hand in hand with efficiency, every time.

(Leaving part of my .sig in for a change, as I'm wearing the CIO hat in this post.)

People will vote with their feet on this. And, that "old white men" are complaining about this is ageist, racist, and demeaning to EVERYONE. I am really disappointed in Red Hat saying this, far more than the whole systemd concerns. As others have stated, change for the sake of change isn't good. Slapping across the face your primary customer base with deep insults isn't good, even if the customers are horribly wrong, which is quite the opposite here. And trying to splash perfume on a steaming dogpile is absurd.

Don't worry, if this attitude continues with Red Hat, I won't let my rear hit the exit on the way out. And I'll do the best sort of advertising for this that I can: tell others the nonsense that is occurring, and to stay far away from it...

Gilbert

******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************

On 07/08/2014 12:51 PM, Mauricio Tavares wrote:

On Tue, Jul 8, 2014 at 12:36 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:

...

On Tue, 8 Jul 2014, Lamar Owen wrote:

...

Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?

Yes. Look at Microsoft and Windows 8 and a similar attitude of "get over it, and just buy it". I'm not surprised that the head developer

   Apple is guilty of that too.

Consistency is not the only goal. Efficiency should trump consistency,

...

I am darn sick and tired about hearing of "efficiency". Efficiency does not 100% translate to effective productivity. Furthermore, user satisfaction is not counted into efficiency. I have heard people complain about air conditioners with extremely high efficiencies. The problem is that they don't put out much cold air. If the product is ineffective, very hard to work with, but efficient...I'd far rather use something much less cumbersome and effective but being less efficient. That translates to higher productivity and satisfaction, which you really want. Effectiveness and satisfaction should go hand in hand with efficiency, every time.

   I think you are making the case for maintainability.  Efficiency

is in a certain way what brought the Y2K bug. I'll take maintainability over efficiency any day if I can (design constrains) even if I was writing a game.

Nope I was there when we did the year 80 conversion going from single digit years to two digit years. We just did not have the capacity and we counted every byte in a record. We did Julian date format on tape and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less. We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.

Things change. Design goals change. Systems have to change.

On Tue, Jul 8, 2014 at 12:22 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:

On Tue, 8 Jul 2014, Robert Moskowitz wrote:

...

and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less. We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.

Things change. Design goals change. Systems have to change.

Of course they do. And those were changes in efficiency that were the result of needed productivity improvements. Change for the sake of major improvement(s). Wonderful, well-designed, efficient AND necessary. And it obviously made things more productive for everyone!

I argue that systemd neither improves efficiency, productivity or satisfaction...nor is it necessary.

More to the point, those 'old' efficiency hacks were from a time when programmer time was cheaper than the computer resources. Now, the computers should be doing the work for us instead of the other way around. Can anyone really make the argument that we can't afford the computer resources for transparent backwards compatibility now?

On 07/08/2014 01:45 PM, Les Mikesell wrote:

On Tue, Jul 8, 2014 at 12:22 PM, Gilbert Sebenste sebenste@weather.admin.niu.edu wrote:

...

On Tue, 8 Jul 2014, Robert Moskowitz wrote:

...

and did the conversion for display to save another byte. Efficiency? We were desperate for every byte we could squeeze out. the US Post Office created a standard so that all US cities (and supposedly streets) could be entered in 14 characters or less.

thinking back, I think it was 14 characters for cities and 25 for streets. But this IS going back 40 years. I still have some of the 9" tapes, but no tape drive...

...

...

We changed the abbreviation of Nebraska from NB to NE (I remember writing that conversion program) so we could more easily mix US and Canada addresses (those they would not change their 6 character code to our 5 digit one). We burned CPU to save storage. then rewrote key routines in assembler and hacked the COBOL calls to make it all work.

Things change. Design goals change. Systems have to change.

Of course they do. And those were changes in efficiency that were the result of needed productivity improvements. Change for the sake of major improvement(s). Wonderful, well-designed, efficient AND necessary. And it obviously made things more productive for everyone!

I argue that systemd neither improves efficiency, productivity or satisfaction...nor is it necessary.

More to the point, those 'old' efficiency hacks were from a time when programmer time was cheaper than the computer resources. Now, the computers should be doing the work for us instead of the other way around. Can anyone really make the argument that we can't afford the computer resources for transparent backwards compatibility now?

On Tue, Jul 8, 2014 at 1:12 PM, Scott Robbins scottro@nyc.rr.com wrote:

On Tue, Jul 08, 2014 at 11:36:07AM -0500, Gilbert Sebenste wrote:

...

On Tue, 8 Jul 2014, Lamar Owen wrote:

People will vote with their feet on this. And, that "old white men" are complaining about this is ageist, racist, and demeaning to EVERYONE. I am really disappointed in Red Hat saying this, far more than the whole systemd concerns.

Again, let me clarify, it was a tongue-in-cheek comment made among friends, and certainly not a RedHat official quote.

But aside from insulting anyone, you should think of that reference realistically as meaning the people who have established systems working well enough to have built businesses worth maintaining. Do you really want to rock that boat in favor of youngsters that don't know how to make it work?

On 07/08/2014 01:11 PM, m.roth@5-cent.us wrote:

Lamar Owen wrote:

...

On 07/08/2014 11:58 AM, Les Mikesell wrote:

...

... How much is this going to cost a typical company _just_ to keep their existing programs working the same way over the next decade (which is a relatively short time in terms of business-process changes)?

Les, this is the wrong question to ask. The question I ask is 'What will be my return on investment be, in potentially lower costs, to run my programs in a different way?' If there is no ROI, or a really long

No, it's *not* the wrong question. Are you going to figure ROI INCLUDING all the a) reworking, b) retraining (oh, that's right, almost *no* one pays for training, other than on-the-jop or take your own lunch brown bags) in the costs? And how 'bout how long it's going to recoup those up-front costs (or where you planning on hiring all new people anyway?), and will there be *another* change coming along in five years...?

...

ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not. Fact is that all of the major Linux distributions are going this way; do you really think all of them would change if this change were stupid?

May I point to upstart, and that it lasted a few years, before folks decided it was a Bad Idea? How many years of systemd do we have to compare and contrast?

Unfortunately the way systemd has intertwined itself into to so much more that just system startup, it could be around for a long time.

...

...

Even if the changes themselves are minor, you have to cover the cost of paying some number of people for that 'get used to the syntax' step. Personally I think Red Hat did everyone a disservice by splitting the development side off to fedora and divorcing it from the enterprise users that like the consistency.

YES!!!!!!!!! Let fedora duke it out with ubuntu; give us a *work* o/s.

...

Consistency is not the only goal. Efficiency should trump consistency,

Wrong. I *STRONGLY* disagree. Efficiency should be a goal off consistency, and consistency should not be highly inefficient. However, as I've mentioned before, when I go home after a hard day administering a hundred-plus-many servers and workstations to my own workstation at home, I do *NOT* want to debug my o/s. (And I'm putting off trying to upgrade my router's DD-WRT, in the hope that I'll find something less buggy with USB printer support).

<snip>

    mark

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 07/08/2014 01:14 PM, Les Mikesell wrote:

On Tue, Jul 8, 2014 at 11:13 AM, Lamar Owen lowen@pari.edu wrote: But the answer is still the same. It's sort of the same as asking that about getting a shiny new car with a different door size that won't carry your old stuff without changes and then still won't do it any better. Our services take all the hardware can do and a lot of startup initialization on their own. Saving a fraction of a second of system time starting them is never going to be a good tradeoff for needing additional engineer training time on how to port them between two different versions of the same OS.

...

If there is no ROI, or a really long ROI, well, I still have C6 to run until 2020 while I invest the time in determining if a new way is better or not.

So a deferred cost doesn't matter to you? You aren't young enough to still think that 6 years is a long time away, are you?

Amortized capex matters to me. I may not have the capex budget this year to do the development, but I do have opex monies to research potential development, and opex monies to do grant writing that can fund the development capex. I'm old enough to remember and to have read an original paper copy of the Misosys Quarterly with a column called 'Les Information.'

6 years is a short time, especially for grant funding cycles. But it is enough time for me to have researched, hopefully properly, the means by which to implement hopefully opex-reducing improvements. But these are business decisions, not technical ones.

Re-using things that work may not be best, but if everyone is continually forced to re-implement them, they will never get a chance to do what is best. In terms of your ROI question, you should be asking if that is the best use of your time.

My non-development time is opex; my development time is capex (for the purposes of many grants for which we apply). I always ask the question above when figuring ROI. And I got the nickname 'Mr. Make-Do' for the very reason that I do tend to heavily reuse 'ye olde stuffe.'

...

Consistency is not the only goal.

But that's why we are here using an 'enterprise' release, not rebuilding gentoo every day.

I guess you missed the adjective 'only' above. Consistency helps reduce opex; reduces opex produces better fiscal efficiency, at least in theory. Each business's situation will be different, YMMV, of course.

...

Efficiency should trump consistency,

Efficiency comes from following standards...

Everyone who commented thus far on my statement seems to have missed my wearing my CIO hat. I'm talking fiscal efficiency, as in getting the most bang for the buck, especially in terms of opex, which is nearly always a much larger number than capex for us (and, while I know this is not likely to make much technical sense, it is a true statement that $1 opex is not equal to $1 capex). This is not 'technical efficiency' here, but 'keep the lights on and the budget in the black' efficiency. If the budget goes red long enough it really doesn't matter what you do technically. If I need to get a grant to fund $100,000 capex that will save me $10,000 per year opex (and grants almost never fund opex) it is a no-brainer.

Yes, I remember it worked fantastically well up through at least RH7 - which was pretty much compatible with CentOS3.

Minor correction:

RHL 7.2 -> RHAS 2.1. RHL 9 -> RHEL 3.

I have a client that still has a RHL 5.2 machine running in production. It does its job, is not internet-connected and thus security updates are irrelevant, and it will run until it dies. Client has no budget to reengineer properly, and is migrating services one at a time in a pretty slow manner. There's only two semi-critical services left, and if they just went away the client would go back to a paper system while a newer system is being built. And they're fully prepared to do that rather than upgrade now.

That was back when people actually using the systems contributed their fixes directly. I had a couple of 4+ year uptime runs on a system with RH7 + updates - and only shut it down to move it once.

I am one of those people who contributed directly; my name can still be found in the changelogs for PostgreSQL 7.4 on CentOS 4 (and I would assume RHEL4, if PostgreSQL is part of the EUS set). I remember the mechanisms, and the gatekeepers, involved, very well. The Fedora way is way more open, with people outside of Red Hat directly managing packages instead of contributing fixes to the 'official' Red Hat packager for that package.

On 07/09/2014 01:31 PM, Les Mikesell wrote:

I'm not convinced that being open and receptive to changes from people that aren't using and appear to not even like the existing, working system is better than having a single community, all running the same system because they already like it, and focusing on improving it while keeping things they like and are currently using.

I think you and I remember a different set of lists. I remember lots of griping about changes being forced down throats. Heh, a quick perusal of one of the lists' archives just a minute ago confirmed my recollection.

With the latter approach, there was a much better sense of the cost of breaking things that previously worked.

Do you remember the brouhaha over libc5 that 'just worked' versus the 'changed for no reason' glibc2? And don't get me started on the recollections over the GNOME 1 to 2 upgrade (or fvwm to GNOME, for that matter!), or the various KDE upgrades (and the entire lack of KDE for RHL 5.x due to the odd license for Qt, remember? Mandrake got its start being essentially RHL with KDE.... and of course the 'stripping' of KDE to 'cripple it down the GNOME level' (otherwise known as the 'Red Hat Desktop')) or the various kernel uprevs (2.4 broke my whatzit2000 that nobody else has! You CAN'T upgrade!!!!!). And then there was gcc 2.96. (I can feel the tremor in the Source just mentioning that....) And then all the i18n changes for 8.0 (I dealt with that one directly, since the PostgreSQL ANSI C default had to be changed to whatever was now localized.... too bad the Redneck install language has gone away.) And then there was the weed called Kudzu. The bad rep for x.0 releases started somewhere, remember? (Smooge was there, too, and has an extensive page about the differences (this link is from my bookmarks and memory; AFAIK it still works): http://www.smoogespace.com/documents/behind_the_names.html ).

And I'm still waiting for my upgrade to Red Baron. ;-), in case you needed it....

Sorry Les, but I was there, and I have the e-mails. I guess people prefer being able to just gripe without the chance for real responsibility versus now having a bit of responsibility to help since the ability to actually do something about it is available.

Not that I necessarily disagree with your observations, by the way. I'm just looking at the brushstrokes of the really big picture and remembering how at the time it seemed like we sometimes were just moving from one kluge to another (if you insist on the alternate spelling 'kludge' feel free to use it.....). But it was a blast being there and watching this thing called Linux find its wings, no?

It is still a blast for me, even if I actually do serious work with several versions of Linux. And I'm looking forward to spending some quality time with systemd, of which I know very little, and seeing how I can make this new tool, which apparently a lot of really smart people think is a great idea, work for me (and I may find that I despise it; time will tell). I kind of feel like I've been given a new tool set with tools I've never seen, and finding out that a screwdriver and a chisel can actually be separate things! Or finding out what a 'fence wire' tool can *really* be used for..... ( see: http://www.garrettwade.com/images/330/66A0204.jpg )

And I have two previous versions of CentOS to fall back on while I learn the new tools; I have both C5 and C6 in production, and have plenty of time in which to do a proper analysis on the best way ('best way' of course being subjective; there is no such thing as an entirely objective 'best way') for me to leverage the new tools. The fact of the matter is that Red Hat would not bet the farm on systemd without substantial buy-in from a large number of people. The further fact the Debian and others have come to the same conclusion speaks volumes, whether any given person thinks it stupid or not. And I don't have enough data to know whether it's going to work for me or not; I'm definitely not going to knee-jerk about it, though.

But the rumors of something 'killing' Linux have and will always be exaggerated. Systemd certainly isn't going to, if gcc 2.96 didn't. I mean, think about it: the first rev out of gcc 2.96 wouldn't even compile the Linux kernel, IIRC!

On 07/09/2014 03:20 PM, Les Mikesell wrote:

No, that is exactly my point. Back then the griping by affected active users happened in more or less real time compared to the changes being done. Now fedora goes off on its own merry way for years before its breakage comes back to haunt the people that wanted stability.

Real-time? Since when? The development direction was already pretty much done by the time the public betas were released and the griping began. Even by the time of the private betas the development direction on several of the releases was already pretty much set in stone. I only had a bit of input for PostgreSQL because I was maintaining the upstream RPM package at the time; but I had no pre-beta access to whatever was in the beehive queue at the time.

With fedora, on the other hand, you already know that what is going in the next version of EL is going to be previewed in Fedora and you are absolutely free to follow the Fedora lists and get involved in the actual process, rather than being fed an already mostly-baked beta every so often. If you don't follow the Fedora lists and get involved, well, you get what you pay for, I guess. I don't currently follow the Fedora lists, incidentally, but I do track the features that are being implemented. We already had Upstart, and the move from Upstart to systemd is not that big (at least in my opinion), so it's not something that got me up in arms. Plain text non-XML configs that can be on a non-executable filesystem and lots of really nice options in the unit configs really change the way you think of system startup. It is a change; I've not decided whether I think is a good change or not; most of the big Linux distributions have decided that it is a good change.

In a quick google, I found what I thought to be a pretty clearly written article (from 2012) on systemd's strong points from the point of view of a server admin: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight?showcomments

If it can really deliver this, particularly the feature of sysadmin-modified units all being in one place, yeah, looks like a good thing. And there will be plenty of eyes on it. Most of the articles looking at systemd's weak points (and there are several) aren't written in nearly as level a fashion as the above. Lots of vitriol to go around, unfortunately.

... Don't think people running a bunch of RH5 servers really cared about X or desktops at all...

You missed my Red Baron comment, didn't you? I ran Red Hat Linux 4.1 as a desktop, and once Mandrake 5.3 was out I went completely Linux as my primary work and personal desktop. I figured if I was going to run it as a server I needed to 'dogfood' things and really rely on it for daily work. And my employer agreed.

The days StarOffice became OpenOffice.org and then when OO.o 1.0 wound its way into RHL were very good days for this desktop Linux user.

...

Yes, but on the other hand, people still pay large sums of money for other operating systems. And there are some reasons for that.

Many of which are not technical.

On 07/09/2014 04:27 PM, Les Mikesell wrote:

On Wed, Jul 9, 2014 at 3:07 PM, Lamar Owen lowen@pari.edu wrote:

...

If you don't follow the Fedora lists and get involved, well, you get what you pay for, I guess.

Following the list just makes it more painfully clear that they don't care about compatibility or breakage of previously working code/assumptions or other people's work. It's all about change. ...

c'est la vie.

The only constant is change. Some changes stick; some don't. Unix itself was a major change in the early 70's, and many of the same issues I see being mentioned here are rehashes of the Unix fragmentation grenade back in the 80's. People reinvent the wheel, and sometimes their wheel is better, and sometimes it isn't. And always a very vocal group will gripe against the wheel being reinvented at all, regardless of whether it might be better or not.

This wheel might be better and it might not; we'll never know if we don't try it out. Experience and tradition must be tempered with empirical results from actually experimenting with the new. (And do note that 'tempered' does not mean to do away with experience and tradition......).

Backwards compatibility isn't a big/little thing, it is binary choice yes/no. If you copy stuff over and it doesn't work, that's a no, and it is going to cost something to make it work again.

Have you checked how compatible or not systemd is for the init scripts of the packages about which you care (such as OpenNMS)?

Did you keep track of the time you spent keeping [desktop RHL 5.x] working?

My employer put a line item on my timesheet for it, so, yes, I kept track of it and got paid for it. Those paper files have long since been tossed, since that was fifteen-plus years ago. My employer was paying me to keep the server up, I had an employer who understood the value of training, and that employer definitely understood the value of dogfooding.

On 10/07/14 07:09, Les Mikesell wrote:

On Wed, Jul 9, 2014 at 3:43 PM, Lamar Owen lowen@pari.edu wrote: Did you keep track of the time you spent keeping [desktop RHL 5.x] working?

...

My employer put a line item on my timesheet for it, so, yes, I kept track of it and got paid for it. Those paper files have long since been tossed, since that was fifteen-plus years ago. My employer was paying me to keep the server up, I had an employer who understood the value of training, and that employer definitely understood the value of dogfooding.

Still you must have come up with some bottom line recommendations. Did your employer make all or some large number of staff follow your lead back then on desktop versions/updates after seeing what it costs? Personally, I gave up on the hardware aspect of a linux desktop as soon as I saw freenx working from windows/macs where vendor-optimized video drivers come with the distribution. And then having access to both Linux and native desktop programs I've tended to ignore the problems with linux desktop apps.

We use a large number of Linux desktops extensively and have since 5.2. For our applications and workflows, this was quicker and more feature rich. We use the same platform in a HPC scenario as well, so (Desktop) Linux is dependent on your needs.

I can sympathize with you that you are upset about systemd. CentOS, RH, Fedora or Linux is not stopping you from being involved or finding a solution to your problem with systemd. Here are some examples of the way you and others could give back to the community and help others that believe the same as you. 1. Engage with the community of the early Open Source version of RHEL ie Fedora. 2. Submit patches, rpms etc as alternatives to systemd for inclusion in Fedora. RH may include it in RHEL as an optional install. 3. Submit a bugzilla on sytsemd itemizing and describing the deficiencies. 4. Purchase Support and or services from RH and create a case with business justification. 5. Create a fork of CentOS7 that does not have systemd. 6. Create a fork of CentOS6 that has future features/bugs backported from Centos7 7. Financially support someone/people to do any of the above if you can't do it yourself.

As you can see there are lots of options with open source software. I am sure there are others I have missed. I hope that helps you find a solution to your problem.

Grant

On 07/08/2014 10:49 AM, Russell Miller wrote:

On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:

...

That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.

For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.

Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.

And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.

(and if that was yesterday, I don't want to hear about it. :))

--Russell

Couldn't have said it better.

On Tue, Jul 8, 2014 at 10:59 AM, Tony Schreiner anthony.schreiner@bc.edu wrote:

On Tue, Jul 8, 2014 at 10:49 AM, Russell Miller duskglow@gmail.com wrote:

...

On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:

...

That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.

For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.

Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.

And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.

(and if that was yesterday, I don't want to hear about it. :))

--Russell

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

What's Windows-ish about it? It's all text files; easily available to look at.

Windows used to have a single win.ini file with all configs in it. Then it replaced that with a binary equivalent you access and manipulate using programs or whatnot. I think the point is that is where systemd is going to, and there are many good arguments for that. But there are also compelling reasons against it.

Also, you as a developer/manager has to interact with this 2600lb Gorilla (he gained some weight throughout the years) that is the OS using libraries and programs that are poorly documented and rather buggy. Or hack your way in. All that while hoping that ape will not starting flinging poop your way for absolutely no reason (bugs, security flaws, etc).

And Solaris with SMF went in this direction many years ago.

And so did Apple in a certain way (their plists and launchd and so on). Was that an improvement? I honestly cannot answer that.

Tony Schreiner _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Tue, Jul 8, 2014 at 11:05 AM, Andrew Wyatt andrew@fuduntu.org wrote:

...

...

This is an unfortunate problem in the community today, anyone who disagrees with status-quo is "just an antique", it's insulting to say the least. It doesn't matter our experience, we're just "causing trouble" because we "don't want change" which is an excuse that isn't even remotely true. Eventually when all these "old guys" leave, all that will be left are the inexperienced kids and that's when the real problems will begin to surface.

The people promoting change most like do not have a large installed base of their own complex programming to maintain or any staff to retrain.

There are a few good reasons to adopt systemd, but the bad outweigh the good in my opinion.

My opinion is that if a new system is really better, then it should be capable of handling everything the previous standard did transparently. If it can't, then it's not really better. It is just different.

On 07/08/2014 12:05 PM, Andrew Wyatt wrote:

On Tue, Jul 8, 2014 at 9:49 AM, Russell Miller duskglow@gmail.com wrote:

...

On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:

...

That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.

For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.

Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.

And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.

(and if that was yesterday, I don't want to hear about it. :))

This is an unfortunate problem in the community today, anyone who disagrees with status-quo is "just an antique", it's insulting to say the least. It doesn't matter our experience, we're just "causing trouble" because we "don't want change" which is an excuse that isn't even remotely true. Eventually when all these "old guys" leave, all that will be left are the inexperienced kids and that's when the real problems will begin to surface. There are a few good reasons to adopt systemd, but the bad outweigh the good in my opinion. Then there's the problem of giving children the keys to the kingdom ( http://lists.freedesktop.org/archives/systemd-devel/2014-May/019664.html) as they do run off the old guard so they can have their toys.

It is fun to attend a standards meeting (like IETF and IEEE 802) when some young guys and gals, along with their profs make a presentation on how things should REALLY be done. Then that grey headed guy or gal gentlely leads the Q&A into a critical edge case that completely breaks the proposal. At least in my area, we have the institutional memory of why we do things as we done. Sometimes things evolve where we CAN do it better now, or even have to do it better. But us old dogs still have the where-with-all to keep it all straight.

But also we are demanding more of our systems. HSMs make dealing with virtualization a must and this changes a lot of old assumptions. Remember what assume can spell.

On 7/8/2014 8:49 AM, Russell Miller wrote:

For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.

Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.

And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.

(and if that was yesterday, I don't want to hear about it. :))

--Russell

Well said. Why are the old proven ways somehow so deficient that we absolutely must replace them with something else, no matter how badly thought out. (yes I'm an old fart by some folks figuring, I actually prefer the command line and started with punch cards and paper tape).

Change isn't bad... but change for change's sake is stupid and that's what this looks like. New is not always better. Based on my observations over the years, new is rarely better! The more rapid the change, the more radical the change, the more likely the change won't stand the test of time, or rational thinking. Do the analysis, really do it without a bias toward a specific answer and sometimes, yes, sometimes the answer is leave things alone, they work fine the way they are. Just because something is old doesn't mean it needs to be replaced. Of course, sometimes the answer is to make changes, but keep them small, make them incrementally and give them time to prove themselves before rushing headlong towards the next thing.

Sadly, poorly thought out change seem to be the trend, and not a surprise given the number of folks with Windows backgrounds making their way into the Linux world. We are definitely loosing touch with the UNIX philosophy and that was what made it a great operating system for doing real work.

I started my work life as a maintainer and while I've done my fair share of development, I've always thought like a maintainer. Change almost always breaks things, so do it carefully and slowly and with thought not just about the local impact, but the global impact. Please! -- Steve

On 07/08/2014 12:44 PM, Hal Wigoda wrote:

You aren't old.

And I am a young 21. three times over. All that means is I have to learn new stuff now 3 times to get it right! As some people on this list will attest to :)

Soon I will be 26 (2^6). So that means that I have to then learn everything 6 times!

Age is what you make of it. Senior moments are to be cherished. ;)'

(Sent from iPhone, so please accept my apologies in advance for any spelling or grammatical errors.)

...

On Jul 8, 2014, at 9:49 AM, Russell Miller duskglow@gmail.com wrote:

...

On Jul 8, 2014, at 5:09 AM, Dennis Jacobfeuerborn dennisml@conversis.de wrote:

That presumes that your conservative attitude is the majority opinion though. Systemd is one of the features that I have been looking forward to in CentOS 7 because of the new capabilities it provides so while this will surely drive some people away it will actually attract others and if you think that this will lead to some sort of great exodus then I think you are mistaken. Not everybody is this uncomfortable with change.

For the record, I'm not uncomfortable with change. I'm uncomfortable with stupid, poorly thought out, monolithic change that ignores half a century of the UNIX philosophy. And creating a daemon that tries to handle everything but the kitchen sink and implementing it in such a way as to make it nearly incomprehensible to me certainly qualifies as that type of change.

Sysvinit may not be perfect, but it's UNIX. Systemd is... a lot of things, but more of a windows-like solution than I"m comfortable with. It's just dumb. Surely there could have been a better way of accomplishing their goals without creating the equivalent of Cartman's Trapper Keeper.

And yea, I'm kind of an old white guy (is 38 old?) The guy who called that out as a negative is not helping his cause with me. This old white guy has been doing Linux administration when some people on this list were pulling the hair of girls they liked and eating bugs.

(and if that was yesterday, I don't want to hear about it. :))

--Russell

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

It's old but there is still some rumours that freebsd will get Launchd ported from OS X some day

On 07/07/2014 10:34 PM, Scott Robbins wrote:

On Tue, Jul 08, 2014 at 02:26:59AM +0100, Always Learning wrote:

...

On Mon, 2014-07-07 at 20:59 -0400, Scott Robbins wrote:

...

To the tune of YMCA

So young man, if you want to stick To something, that more resembles Unix And young man, if you want to sing Goodbye to Poettering,

(bah bah bah bah)

FreeeeeeeeeBSD (yeah yeah yeah) FreeeeeeeeeBSD

etc. I just made this up at work today, and that's as far as I got.

Ah, a Broadway musical next ? :-)

I'm an old man who remembers multics, GECOS/GCOS and the 'B' programming language.

Is FeeBSD systemd-less ? Got a FreeBSD manual.

No systemd in FreeBSD. It isn't Linux, and like any O/S, has its own oddities.

It would take more adjustment, IMHO, to go from CentOS 6.x to FreeBSD than to go to 7.x. (I'm saying this as someone who uses both FreeBSD and Fedora which has given a hint of what we'll see in CentOS 7.)

Johnny Hughes wrote:

On 07/07/2014 06:47 PM, Always Learning wrote:

...

Reading about systemd, it seems it is not well liked and reminiscent of Microsoft's "put everything into the Windows Registry" (Win 95 onwards).

Is there a practical alternative to omnipresent, or invasive, systemd ?

The answer to this is no, replacing systemd with something else is just way to invasive.

Since new versions of CentOS, Ubuntu, Debian, RHEL, Fedora, OpenSUSE, Arch, Mageia and other Linux distros are all switching to systemd as the default .. I would suggest that learning how to use it is going to be the way to go.

I just hope that the distribution of implementing systemd are not so shortsighted (or rather pushing force) as Fedora/RHEL and besides him also offer other alternative (OpenRC is IMO very good candidate, although with sysvinit and upstart I was also satisfied - both did _reliably_ their jobs).

Franta Hanzlik

On 2014-07-15, Jonathan Billings billings@negate.org wrote:

I've been using systemd ever since it was introduced in Fedora, and the RHEL7 beta and CentOS7 final since it came out. I could tell you about all the positive and negative experiences I've had.

I think this could be very useful, especially coming from someone who was initially reluctant (as I and clearly others are).

There's been a lot of misinformation posted on this list (such as the Windows Registry reference)[1]. I wouldn't want to make any decisions about systemd based on what I've seen on this list.

That's what I was concerned about. :) I certainly would try it for myself first, but if I were to read a lot of people writing "I tried to actually use systemd, and it was awful/fine/awesome" that would carry some weight.

However, I think you should try it out yourself. I suggest giving it a try in a VM, or try one of the CentOS7 LiveCDs. I was quite hesitant about systemd when I started using it, but it was experience that led me to be able to make good judgements about it.

1. See the systemd myths web page

http://0pointer.de/blog/projects/the-biggest-myths.html

In the interest of full disclosure, that page is written by one of the primary authors of systemd, so we shouldn't expect an unbiased opinion. (Not saying it's wrong, only that it's important to understand the perspective an author might have.)

--keith

On 07/15/2014 09:38 AM, Jonathan Billings wrote:

On Mon, Jul 14, 2014 at 09:50:18PM -0700, Keith Keller wrote:

...

I think this could be very useful, especially coming from someone who was initially reluctant (as I and clearly others are).

Ok, I'll give some examples of my experiences. Warning: long post.

... When I started using and writing my own systemd units, I found them quite simple, ...

So, the things that have bothered me so far: ...

Jonathan, thanks for the balanced treatment and for posting actual experience and not just regurgitating tired tropes.

On Tue, Jul 15, 2014 at 9:46 AM, James Hogarth james.hogarth@gmail.com wrote:

...

4.) Debugging. Why is my unit not starting when I can start it from the command line? Once I figured out journalctl it was a bit easier, and typically it was SELinux, but no longer being able to just run 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables core dumps on services by default (at least it did on Fedora, the documentation now says it's on by default. Huh. I should test that...)

Jon as a heads up this isn't a systemd/el7 thing necessarily...

Look at the daemon function in /etc/init.d/functions that most standard EL init scripts will be using...

Core files have been disabled on things started with that by default (need to export a variable in the environment of the script usually via sysconfig) the whole of el6 ...

Is there a simple generic equivalent to: sh -x /etc/rc.d/init.d/program_name start to see how configurations options that are abstracted out of the main files are being picked up and expanded?

On 07/15/2014 11:33 AM, m.roth@5-cent.us wrote:

This one does bother me. I may not want to restart a production instance of apache, when all I want it to do is reload the configuration files, so that one site changes while the others are all running happily as clams.

systemctl reload $unit

Documented in the systemctl(1) man page.

If the unit(s) you want to reload don't support that, and you want to reload more than one unit's configuration in one command, you use systemctl reload-or-restart $unit

(I've wanted that one for a while, and 'service' doesn't do that, along with globbing of the name; that is 'systemctl reload-or-restart httpd*' (with proper quoting) will restart or reload all running units that match the glob; yeah, now on my load-balanced multiple-frontends plone installation I could 'systemctl reload-or-restart plone-*' and it will do the right thing, no matter how many frontend instances I have selected for running.... That's actually pretty cool.

There are quite a few of the commands that systemctl supports that I have wanted for 'service' for a long time.