On Wed, 2008-05-21 at 09:34 -0400, Bart Silverstrim wrote:
> less error prone from
> whoopsy-fingers on the keyboard.

I have to disagree very much. A single command is much easier to get
error-free than a manual repetition of the same thing for 300 times


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Wed, 2008-05-21 at 11:30 -0300, Derek Broughton wrote:
> Nobody, at any point in this thread, has argued against "text file based
> configs". I've argued against editing them with a text editor

What the heck is the advantage of text file-based configs supposed to be
if nobody is allowed to touch them with an editor? Might just as well be
binary blobs then.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Chris G wrote:
>
>>>> And the best user interface is always no user interface whenever
>>>>> it is possible for the machine to do it correctly by itself.
>>>> I can't argue with that :-)
>>> I can! The problem with the machine doing it correctly by itself is
>>> that it almost inevitably has to make some default assumptions.
>>> That's all very well if they're correct and it's all very lovely and
>>> nice but the odd case when they're wrong can be infinitely frustrating.
>> Yes, but this is the precise circumstance where you don't want a GUI
>> with the same wrong assumptions trying to force them on you.
>>
> I see no basic difference between a GUI assuming something and a
> CLI/editor configuration assuming something. Either can make a
> (wrong) assumption, assume nothing at all and leave you to make the
> setting yourself, or show you what it has assumed and allow you to
> change it (this last is my preference).

Text editors usually don't assume anything about the meaning of the
content they edit. So they aren't specifically helpful other than
letting you paste in large chunks of stuff from a known-working copy or
do bulk search/replace transformations that are much harder in
field-oriented config tools, but they are predictable and never harmful,
plus you always have the full compliment of external tools that know how
to manipulate text, most of which work as filters within sensible editors.

--
Les Mikesell
lesmikesell@gmail.com





--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Wed, May 21, 2008 10:14 am, Mario Vukelic wrote:
> What the heck is the advantage of text file-based configs supposed to be
> if nobody is allowed to touch them with an editor? Might just as well be
> binary blobs then.

We can edit them through Perl, Python or shell scripts. Those are fine.
But an actual text editor is verboten. And no, I'm being serious since
at one point he did say if we didn't like the configuration tool this is
OSS and we can always alter it to suit our needs. In short he has an
irrational objection to system administrators while having irrational
faith in programmers. He forgets, of course, that many system
administrators are also programmers.

--
Steve Lamb


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Wed, 2008-05-21 at 11:18 -0300, Derek Broughton wrote:
> If the designer didn't add
> a "duplicate this" button, you could always just use the underlying
> copy/paste of the GUI environment.

I fail to see how this is different to editing the config file.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

On Wed, May 21, 2008 at 8:37 AM, James B. Byrne <byrnejb@harte-lyne.ca> wrote:
>
> This indeed turned out to be an SELinux policy problem which I have since
> resolved.

Whoa, whoa, whoa, nice shooting, Tex! (Ghostbusters)

Not so fast - please post the solution, too, for posterity (and those
of us who don't use SELinux but might, someday, in the not too distant
far future...).

Thanks.

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

On Wed, 2008-05-21 at 10:20 -0700, Steve Lamb wrote:
> He forgets, of course, that many system
> administrators are also programmers.

And that some editors are really just specific incantations of a much
more complete system. I mean where does the "text editor" part begin and
end in Emacs?


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Derek Broughton <news@pointerstop.ca> wrote:

> Florian Diesch wrote:
>
>> I just don't know *any* GUI config tools that supports this things.
>> And that's just the basics, with text file based configs you easily
>> get versioning, template or rule based generation, automatic
>> distribution, ...
>
> Nobody, at any point in this thread, has argued against "text file based
> configs". I've argued against editing them with a text editor

So it's fine to edit them as long as I don't use an editor?


> - and you don't get _any_ of those benefits using vi.

The nice thing about text files is that there are so many tools to
work with them. Shouldn't be much of a problem to integrate them in a
modern vi clone like vim.


Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Florian Diesch wrote:
> The nice thing about text files is that there are so many tools to
> work with them. Shouldn't be much of a problem to integrate them in a
> modern vi clone like vim.

Esp. if one uses one of the many vims with an embedded scripting engine.
vim-python with built in mercurial, anyone?

--
Steve C. Lamb | But who decides what they dream?
PGP Key: 1FC01004 | And dream I do...
-------------------------------+---------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

Will Woods wrote:
> Preupgrade is currently designed to be exactly as secure as an anaconda
> http install. No less, no more.

But it's not being marketed as an alternative to an Anaconda HTTP install with
less downtime as the only improvement. It's being marketed as a safer
alternative to a live upgrade with Yum, and as a faster, more convenient and
less bandwidth-wasting alternative to downloading and burning DVD images. See
this article for example:

http://www.redhatmagazine.com/2008/04/15/interview-fedora-developers-seth-vidal-and-will-woods/

The article talks a lot about how Preupgrade is better than both a Yum upgrade
and a DVD-based upgrade, but says very little about network-based Anaconda
upgrades, and it's completely silent about the security aspect. Here's a
quote from the article:

"So you can upgrade with the convenience and bandwidth savings of a live
upgrade, but without the risky craziness inherent therein."

Yeah, it avoids the risky craziness inherent in a Yum upgrade but adds instead
the crazy riskiness inherent in an HTTP-based Anaconda upgrade. That's no
improvement in my book. No matter what the risks with a Yum upgrade are,
getting intruders in my computer is worse.

> Nothing's *missing*. There just aren't any signatures to check for the
> boot images, and there never have been.

For several years now, all my boot images have been included in ISO images.
Those ISO images have been accompanied by checksum files, and those checksum
files have been cryptographically signed. I always verify the signature and
the checksums, and when they're verified correctly I know that all the files
in the ISO image are clean, including the boot images.

Generating detached signatures for the boot images and putting them in the
directory where the images are published would take at most five minutes of
manual work for each release.

> Furthermore anaconda doesn't check the gpg signatures of packages it
> downloads and installs during http installs. Never has. That's bug #998.
> (Yes, #998. Not a typo. See https://bugzilla.redhat.com/998)

Would you like to guess why I never do network-based installs except from my
own server directly attached with a crossover cable?

Björn Persson

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list