Perhaps on your projects: on mine, I'm afraid they represent direct expense and lost income

These are new designs, effectively release candidates. It is _extremely_ difficult, and hideously expensive, to pre-test everything in final configuration, and these are very complex systems that are subjected to enormous stresses on launch and recovery. Complex modeling and mechanical specifications cannot hope to catch the surprises that may be found in final reviews and checklists, on the ground, before launching the craft.

  I'm afraid "improve build quality" could be a managerial directive, like "safety first" that doesn't actually describe any real, individual process that's not already in place.

> this being said, I can't really see filing the charges as being more cumbersome than doing the paperwork for letting them go.

I'm afraid it's not uncommon, especially at first. Handwritten documents have room for describing circumstances, many automated systems do not, or lack the necessary categories and wind up with the documents miscategorized or misdirected when first used. It's certainly common with trouble ticket and budget systems: I'm facing several such cases right now.

> Those old and crusty daemon and log management integration tools are simply crap compared to systemd's integrated approach. You obviously don't have any real experience with systemd if you think otherwise. Everything is at least 100 times better than compared to SysVinit/Upstart (and Syslog etc).

Can I safely assume that you never used Dan Bernsteiin's "daemontools", which stayed of the complexities of logging and worked very well for daemon management.? If SysV init was due for replacement, then there are much lighter tools that could have done just _that_ task.

I do not "want to configure systemd". I want to not replace several decades of daemon and log management integration in dozens if not hundreds of distinct environments with an entirely distinct, complex, and poorly integrated system.

The idea that "in a few years, all Linux distros will use it" is completely irrelevant to the upfront cost of switching now.

The existing compilation settings are, of course, in the SRPM's published by Red Hat. Manipulating them and replacing core utilities means maintaining an internal fork: it would no longer be part of, nor supported by, Red Hat's distribution. I'm afraid that it would also be like removing a car's battery. One can jumpstart the car, but it will cause a host of other problems because the rest of the operating system is now integrated with such a core component.

> You are off course also wrong about systemd requiring the whole package or nothing. Just look at the compile switch options.

"Compile switch options" are entirely irrelevant to published binary system components, such as systemd in RHEL 7. It's certainly possible to compile many system tools without specific features: this does not make them "separate" from the systemd monolith.

> This just wrong; systemd dramatically increases security by eg. making use of "Kernel Capabilities"

Just like SELinux, which I'm afraid most developers and many admins turn off as their first step in setting up new systems. Using internal security structures requires extra development time: it may be well invested, but it's extra work that is already discouraging people form upgrading or activating such security features. Please do not assume that simply because a security structure is available that it will be welcomed, or used, by most developers.

Yes, there are certainly advantages to a more intelligent daemon for starting, and managing, critical services. But weaving it into system logging is a support nightmare, at variance with the older UNIX and Linux approach of using simple tools to do very specific tasks, and chaining them together as needed, rather than making a monstrous "does everything" tool.

The approach of using simple 'daemon' files has been repeatedly engineered, and done well, by such experts as Dan J. Bernstein with his old "daemontools" package. That tool worked very well, it just never became part of standard Linux distributions due to his previously very strange licensing. He's since discarded that licensing and made it public domain: I'd have frankly preferred to see something much lighter weight and independent such as daemontools, perhsps with patches to provide a more sensible layout of components. Dan apparently considers the Linux File System Hierarchy to be irrelevant to his work and tended to put his components in some odd places, but that was easily patched.

RHEL 7 actually has a number of my corporate colleagues and partners looking more deeply at Ubuntu. If they're going to have to rewrite that much of their software and toolkits to switch to RHEL 7, it effectively lowers the threshold to switch entirely to a different distribution. And I'm afraid RHEL 7 is already behind the leading edge on many of its components.

And of course, XKCD has an excellent cartoon about just this sort of problem:

              http://xkcd.com/327/

It looks like little Bobby "Tables" has grown up, discovered herself, and changed her name and gender to Roberta "PHP".:

> As such, would someone please explain to me why the IRS allows anyone (let alone the IRS' top administrator) to download their emails to their desktops and delete them from their servers?

Many companies not only allow this, they demand it. As people send around Word attachments and use long email strings as their personal institutional memory, many core email systems simply do not have the space to hold that data. They favor smaller, leaner email environments that they have some hope of maintaining, and are not willing or funded to take on responsibility for the Terabytes of data an individual bureaucrat may generate in a few years use. By making the individual responsible for it, they make expunging or preserving it the individual's problem, not theirs.

The Congressman did not ask for the email. He asked for the "metadata", who sent it and when, and to whom. NSA monitoring and collection of metadata was shown as pervasive by Edward Snowden's revelations and by their own testimony to Congress, so it's difficult for them to now say "we only collect metadata". The IRS office that handles tax exemptions also corresponds with many international organizations, some of which are accused of being criminally based or fronts for illegal political activity. (Sinn Fein from Ireland, and numerous Muslim charities have been accused of this for years.)

It's a fascinating "damned if you do, damned if you don't" for the NSA. If they can't produce the metadata on request, then the amount of effort and money invested in their monitoring is clearly wasted. If they do produce the data, it verifies that they do, as a matter of course, monitor the ordinary business communications of peaceful, law abiding personnel going about charitable enterprise.

This is confusing: From my diabetic colleague: glucagon is dispensed in response to low blood sugar by the alpha cells of the pancreas, which apparently remain intact, not by the destroyed beta cells that are missing form the pancreas. If the diabetes is being treated well with insulin, why wouldn't the patient's normal glucagon response work well?

From my colleague reading over my shoulder: many diabetics lose their glucagon sensitivity, but apparently due to overall blood sugar control. They still have the relevant alpha cells, and my colleague would expect the glucagon sensitivity to recover with otherwise good diabetes control from manipulating the insulin alone..

Wikipedia has a useful list of pre-assigned IP addresses, at http://en.wikipedia.org/wiki/L.... I can certainly understand military groups wanting Class A records, because their equipment can last for decades and be very difficult to upgrade safely and robustly, and because they helped fund the early Intenet.

I do note that MIT has its own /8, or over 16,000,000 addresses. I do wonder if they could be convinced to switch to IPv6 and free up the space for legacy environments around the world.