From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c4ee062d for ; Mon, 29 Apr 2019 20:45:46 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 85C1B948F2; Tue, 30 Apr 2019 06:45:45 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5B97A948F1; Tue, 30 Apr 2019 06:45:16 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XJ7knHbp"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 785CE948F1; Tue, 30 Apr 2019 06:45:14 +1000 (AEST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by minnie.tuhs.org (Postfix) with ESMTPS id 2CCA7948F0 for ; Tue, 30 Apr 2019 06:45:13 +1000 (AEST) Received: by mail-lj1-f177.google.com with SMTP id f23so10722831ljc.0 for ; Mon, 29 Apr 2019 13:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HCH4pS8z8i0RHtPCbEcidv+YGcHBWNQlfr8OPLjk1gQ=; b=XJ7knHbpvn76PknY4vUdKDKuUUCz3Y0KaC3PG9MZ4qTEYn2jqFCjcIcBDrg3eYgJCe dz2q5B6nM88cRjznEZmUl/6XvEGbMEvzVYjHip15UPEKwaWhjsKbxBJzIu3SHkx8NzRe JcM8mNc2tp4YuP62+sgMchWDA5v1y7glEFOX+65VjLUDLQBvFh5PuvpZsPvUA/MqSHke SryoYZ6gWN+yilYs9YYRnhTjksDK9OPgmbfQnE141IGk2nMBuNcvCbZ+B7ZSukgsw3kk Pw3bb+EBYxzWunBnamb0NzjDwKJopm7LhE2e3ywj/hAEv3TwsqsPvuO0SOhlJrVreanF CWYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HCH4pS8z8i0RHtPCbEcidv+YGcHBWNQlfr8OPLjk1gQ=; b=IPi/vu2t4ecwJk80iykUZzNasFCkWnl/6XZtJ0MUvGxYZ5+3C5gvh/DD+be0ggEIRP xjE1f5bPhdyLOjgOPydvIvXuLU4FvrKsiy6aC8NYFqunoYaWIbnWUDi5SHZlnfZiuUfd teLd1Y98YnFEJFAJ/wqIzx2Ko4FI18wE/vonwM73BShgWsvT4LBmBM1Y+UE+Wz2SrpXr BKuSLZjZJU42IivaOEfIAl/J7NtKdTQlXDSoHYptOIo98jZn29Z9rQiFcuDLO8o6HrRP VdEy995fIFLeveeCZM1ukGb07uEGg6wUq7a+IbinE8TOiSNRDYgE8aTy3O+hbfx9InY5 Dg+w== X-Gm-Message-State: APjAAAXWahRN9/LIY3MqWS/mOwg0T9fMq04bvLZRqHXXaJS7gLCa2Z8T 9meneYVaNNkyARweCnhLKjSCm4MrSU1b1vyuydBKwYch X-Google-Smtp-Source: APXvYqzwTPEPYCJOwSTXnOEc47gQi411F1RVprbr9FRYnoUEs6lpSDYmBQ1GYaJzkWOnuPWp3BJPxdtoSwZKT5hQYUo= X-Received: by 2002:a2e:9ed3:: with SMTP id h19mr34081491ljk.129.1556570711202; Mon, 29 Apr 2019 13:45:11 -0700 (PDT) MIME-Version: 1.0 References: <20190428165452.9BB414422F@lignose.oclsc.org> <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com> <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> In-Reply-To: <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> From: Christopher Browne Date: Mon, 29 Apr 2019 16:44:59 -0400 Message-ID: To: =?UTF-8?Q?Michael_Kj=C3=B6rling?= Content-Type: multipart/alternative; boundary="0000000000004f20ca0587b15c25" Subject: Re: [TUHS] A question about ls(1) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000004f20ca0587b15c25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 29 Apr 2019 at 14:15, Michael Kj=C3=B6rling w= rote: > On 28 Apr 2019 13:00 -0700, from bakul@bitblocks.com (Bakul Shah): > > IMHO separate files are fine but it would've been nice to > > a) have a place other than $HOME to store these files and > > XDG already does that. At least Norman already mentioned ~/.config in > this thread. > > https://www.freedesktop.org/wiki/Software/xdg-user-dirs/ > > Not sure how common that is on non-Linux systems, but it seems pretty > common on modern Linux distributions. > That's application-specific, not distribution or OS specific. I have 58 subdirectories of ~/.config on my workstation at work; that's not deviating much from your case; 58 directories (indicating about 58 apps), 2047 subdirectories, 7422 files, 481MB of data, the largest bits being cache data for Google Chrome web browser. > My workstation Debian system has a staggering 3467 files in that > directory, spread around 444 directories (75 directories directly > under ~/.config). Plus another 142 dot-directories and 66 dotfiles in > ~/. Now, ~/.config typically uses multiple files per application, and > at a glance there's some stuff there that could definitely go, but I > still shudder to think of having all of those directly under ~/, so > it's clearly doing _some_ good in that regard. > I have had little reason to worry about this; I tend to concur. > > b) a standardized plain text format > > I'm not sure about that; different applications have very different > needs, and trying to shoehorn one into another would be ugly; quite > possibly even more ugly than just having different formats. Yeah, the time they tried doing that, we got "XML everywhere," and that wasn't a notable improvement. What you see on mobile devices these days is that the ".config/" file is a SQLite database, which is where both configuration and application data are captured. As someone that spends a great deal of his time writing SQL code, I find that not too heinous; others might disagree. I think having a SQLite file is better than getting some heinous XML file. (Especially if the XML file is some thinly disguised serialization of a hierarchy of COM objects, where modifying element order would be liable to make your Windows application blow up.) The "mobile platforms" have gotten quite a lot of milage out of using SQLite databases (true both on Android and on iOS); there could be worse things. The SQLite web site does have a page somewhat proselytizing this: https://sqlite.org/appfileformat.html I heard D Richard Hipp (author of SQLite, now head of the dev team) explain this at PGCon 5 years ago < https://www.pgcon.org/2014/schedule/events/736.en.html> He also contended that the world might be a better place if LibreOffice documents were captured as SQLite databases rather than being bundles of XML stored in a .zip archive. That's a nice lively argument to have. Actually poke at the slides at PGCon 2014; he makes similar arguments about git repos (what if metadata were in a database?) and ePub book files. If we were going to forcibly shoehorn everything into one thing, I think I'= d rather that than a lot of the alternatives. But I'm admittedly excessively comfortable with SQL ;-) I can live with us having a number of data formats, particularly if they remain simple. --=20 When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" --0000000000004f20ca0587b15c25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon,= 29 Apr 2019 at 14:15, Michael Kj=C3=B6rling <michael@kjorling.se> wrote:
On 28 Apr 2019 1= 3:00 -0700, from b= akul@bitblocks.com (Bakul Shah):
> IMHO separate files are fine but it would've been nice to
> a) have a place other than $HOME to store these files and

XDG already does that. At least Norman already mentioned ~/.config in
this thread.

https://www.freedesktop.org/wiki/Software/xd= g-user-dirs/

Not sure how common that is on non-Linux systems, but it seems pretty
common on modern Linux distributions.

T= hat's application-specific, not distribution or OS specific.
=
I have 58 subdirectories of ~/.config on my workstation at w= ork; that's not
deviating much from your case; 58 directories= (indicating about 58 apps),
2047 subdirectories, 7422 files, 481= MB of data, the largest bits being
cache data for Google Chrome w= eb browser.=C2=A0
=C2=A0
My workstation Debian system has a staggering 3467 files in that
directory, spread around 444 directories (75 directories directly
under ~/.config). Plus another 142 dot-directories and 66 dotfiles in
~/. Now, ~/.config typically uses multiple files per application, and
at a glance there's some stuff there that could definitely go, but I still shudder to think of having all of those directly under ~/, so
it's clearly doing _some_ good in that regard.
=C2= =A0
I have had little reason to worry about this; I tend to = concur.
=C2=A0
> b) a standardized plain text format

I'm not sure about that; different applications have very different
needs, and trying to shoehorn one into another would be ugly; quite
possibly even more ugly than just having different formats.

Yeah, the time they tried doing that, we got "XML ev= erywhere," and
that wasn't a notable improvement.
<= div>
What you see on mobile devices these days is that the &q= uot;.config/" file
is a SQLite database, which is where both= configuration and application
data are captured.

<= /div>
As someone that spends a great deal of his time writing SQL code,=
I find that not too heinous; others might disagree.=C2=A0 I thin= k having a
SQLite file is better than getting some heinous XML fi= le.
(Especially if the XML file is some thinly disguised serializ= ation of
a hierarchy of COM objects, where modifying element orde= r would be
liable to make your Windows application blow up.)
<= /div>
=C2=A0
The "mobile platforms" have gotten qui= te a lot of milage out of using
SQLite databases (true both on An= droid and on iOS); there could
be worse things.

The SQLite web site does have a page somewhat proselytizing

I heard D Ric= hard Hipp (author of SQLite, now head of the dev team)



--
When confronted by a di= fficult problem, solve it by reducing it to the
question, "How woul= d the Lone Ranger handle this?"
--0000000000004f20ca0587b15c25--