[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5540F6E3.8000706@gmail.com>
Date: Wed, 29 Apr 2015 11:21:07 -0400
From: Austin S Hemmelgarn <ahferroin7@...il.com>
To: Theodore Ts'o <tytso@....edu>, Harald Hoyer <harald@...hat.com>,
Richard Weinberger <richard@....at>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On 2015-04-29 11:03, Theodore Ts'o wrote:
> On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
>> Sure, I can write one binary to rule them all, pull out all the code from all
>> tools I need, but for me an IPC mechanism sounds a lot better. And it should be
>> _one_ common IPC mechanism and not a plethora of them. It should feel like an
>> operating system and not like a bunch of thrown together software, which is
>> glued together with some magic shell scripts.
>
> And so requiring wireshark (and X?) in initramfs to debug problems
> once dbus is introduced is better?
>
> I would think shell scripts are *easier* to debug when things go
> wrong, especially in a minimal environment such as an initial ram
> disk. Having had to debug problems in a distro initramfs when trying
> to help a customer bring up a FC boot disk long ago in another life,
> I'm certain I would rather debug problems while on site at a
> classified machine room[1] using shell scripts, and trying to debug
> dbus is something that would be infinitely worse.
>
> - Ted
>
> [1] So no laptop, no google, no access to sources to figure out random
> dbus messages, etc.
Likewise.
I keep hearing from people that shell scripting is hard, it really isn't
compared to a number of other scripting languages, you just need to
actually learn to do it right (which is getting more and more difficult
these days cause fewer and fewer CS schools are teaching Unix).
Download attachment "smime.p7s" of type "application/pkcs7-signature" (2967 bytes)
Powered by blists - more mailing lists