On 10/25/2014 04:55 PM, Matthew Petach wrote:
Completely agree on this point--but I fail to see why it has to be one
or the other? Why can't systemd have a --text flag to tell it to
output in ascii text mode for those of us who prefer it that way?
It still logs to syslog, and syslog can still l
On Sat, 25 Oct 2014 17:56:52 -0500, Jimmy Hess said:
> The next thing you know, SystemD will add package management, ISO
> building, and eliminate the need for Debian, Ubuntu, SuSE, Redhat,
> Etc to even exist.
That's already on Lennart's to-do list, you know.
pgpsrz4mwPqsz.pgp
Description:
On Sat, Oct 25, 2014 at 12:22 PM, Stephen Satchell wrote:
> The whole rc script thing strikes me as an interim solution that
> required a minimum of code changes (graduate student project?) that went
> viral. Bad as it was, it worked. Duct tape and bailing wire
[snip]
> Systemd is not a re-f
On Sat, Oct 25, 2014 at 02:41:55PM -0700, Peter Baldridge wrote:
> On Sat, Oct 25, 2014 at 1:55 PM, Matthew Petach wrote:
> > Why can't systemd have a --text flag to
> > tell it to output in ascii text mode for those
> > of us who prefer it that way?
^
This | is not what that | does
On Sat, Oct 25, 2014 at 01:55:43PM -0700, Matthew Petach wrote:
> On Sat, Oct 25, 2014 at 10:22 AM, Stephen Satchell
> wrote:
> > Oh, and I hate binary logs. Period. If you can't stand plain text,
> > then try XML. At least humans have a *chance* to read it without having
> > to make fancy read
On Sat, Oct 25, 2014 at 1:55 PM, Matthew Petach wrote:
> Why can't systemd have a --text flag to
> tell it to output in ascii text mode for those
> of us who prefer it that way?
It does.
--no-pager
--
Pete
On Sat, Oct 25, 2014 at 10:22 AM, Stephen Satchell
wrote:
> ...
> Oh, and I hate binary logs. Period. If you can't stand plain text,
> then try XML. At least humans have a *chance* to read it without having
> to make fancy reader tools.
>
>
Completely agree on this point--but I fail
to see why
On 10/25/2014 08:12 AM, Jeffrey Ollie wrote:
> If all of the scripts are cut'n'paste copes of each other, wouldn't it
> be better to figure out a way to stop cutting and pasting? I can't
> count the number of times I've run into problems with my code because
> of that, never mind how many times it
On Fri, Oct 24, 2014 at 10:10 AM, Jim Mercer wrote:
> On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote:
>> All those init.d scripts do about 95% the same thing, all hacked
>> together in shell. Most of them are probably just slightly edited
>> versions of some few paleo-scripts.
>
> in
- Original Message -
> From: "Lamar Owen"
> Speaking from my own experience, the actually relevant and
> package-specific guts of the typical initscript could be easily
> replaced by a simple text configuration that simply gives:
>
> 1.) What to start
> 2.) When to start it (traditional
> All those init.d scripts do about 95% the same thing, all hacked
> together in shell. Most of them are probably just slightly edited
> versions of some few paleo-scripts.
>
> Set the location of the pid file, set the path of the executable, set
> the command line flags/options, maybe change some
On Fri, Oct 24, 2014 at 12:41:39AM -0400, Barry Shein wrote:
> All those init.d scripts do about 95% the same thing, all hacked
> together in shell. Most of them are probably just slightly edited
> versions of some few paleo-scripts.
in FreeBSD, the bulk of the rc.d scripts are basically the same
On 10/24/2014 03:35 AM, Tei wrote:
I pled the Linux people to stay inside the unix philosophy to use text files.
You do realize that the systemd config files are still text, right? As
to the binary journal, well, by default RHEL 7 (and rebuilds) do at
least mirror the journal output to syslog
I pled the Linux people to stay inside the unix philosophy to use text files.
Low newbies like me learn from reading config files, and fix thing by
reading log files, tryiing to make some sense of the error messages
there, and using the most suspicious line as the handle to google for
a solution (
All those init.d scripts do about 95% the same thing, all hacked
together in shell. Most of them are probably just slightly edited
versions of some few paleo-scripts.
Set the location of the pid file, set the path of the executable, set
the command line flags/options, maybe change some flags/opti
On 10/23/2014 10:43 AM, Lamar Owen wrote:
> Wouldn't it be more 'do one thing well' if you had a 'super' inetd
> setup that can start services in a better way than with individually
> packaged (by different packagers in most cases) shell scripts that are
> going to run as root?
inetd versus xine
On 10/23/2014 02:22 PM, valdis.kletni...@vt.edu wrote:
On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said:
Now, I've read the arguments, and I am squarely in the 'do one thing and
do it well' camp. But, let's turn that on its head, shall we? Why oh
why do we want every single package to imple
On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said:
> Now, I've read the arguments, and I am squarely in the 'do one thing and
> do it well' camp. But, let's turn that on its head, shall we? Why oh
> why do we want every single package to implement its own initscript and
> possibly do it poorly?
This is a good point, but it is perfectly possible to have a sysvinit
system not written in shell scripts. I had rewritten most of the init
system in python at one point for example. And its only been made easier
to do over time now that #! Interpertation was moved kernelside. A system
like this
On 10/22/2014 03:51 PM, Barry Shein wrote:
I wish I had a nickel for every time I started to implement something
in bash/sh, used it a while, and quickly realized I needed something
like perl and had to rewrite the whole thing.
Barry, you've been around a long time, and these words are pearls o
20 matches
Mail list logo
