On Wed, Apr 14, 2021 at 10:48:29PM +, Holger Levsen wrote:
> On Thu, Mar 25, 2021 at 04:17:01PM +, Jonathan Dowland wrote:
> > I once considered packaging sed from v7 UNIX, which has all the
> > coreutils bundled in one source repo, and so literally considered
> > src:unix, although in
On Thu, Mar 25, 2021 at 04:17:01PM +, Jonathan Dowland wrote:
> I once considered packaging sed from v7 UNIX, which has all the
> coreutils bundled in one source repo, and so literally considered
> src:unix, although in both cases it was largely a joke and I didn't
> pursue it.
*g*, nice!
On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote:
> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
> is, maybe it's time for a src:proper-unix-system package for those who care?
I once considered packaging sed from v7 UNIX, which has all the
coreutils
On Mon, Feb 22, 2021 at 09:50:25AM +, Holger Levsen wrote:
> I'll still oppose installing a locate package on every system by default
> which burns energy every day on millions of computers for almost noone's
> benefit.
>
> Those who want locate, can apt install it. The rest shouldn't default
On Sun, Feb 21, 2021 at 08:52:44PM +0100, Michael Biebl wrote:
> plocate already ships a native .timer unit, so all it would take is to add
> RandomizedDelaySec= to plocate-updatedb.timer with a reasonably chosen
> value.
nice.
I'll still oppose installing a locate package on every system by
Am 19.02.21 um 15:50 schrieb Marc Haber:
On Fri, 19 Feb 2021 10:34:45 +0100, Florian Lohoff wrote:
All locate variants are a PITA on servers, especially when virtualized.
Imagine a 100+ VM hypervisor at 6:30 starting an updatedb job on all VMs
in parallel. I debugged stuff like that for
On Fri, 19 Feb 2021 10:34:45 +0100, Florian Lohoff wrote:
>All locate variants are a PITA on servers, especially when virtualized.
>Imagine a 100+ VM hypervisor at 6:30 starting an updatedb job on all VMs
>in parallel. I debugged stuff like that for customers so yes - This
>problem is real.
We
On Sat, Feb 13, 2021 at 02:15:17PM -0800, Noah Meyerhans wrote:
> On Mon, Feb 08, 2021 at 07:28:56PM +0100, Richard Hartmann wrote:
> > I very dimly remember updatedb being a concern when cloud images were
> > first discussed. Back then and today, agreed, it does not make sense
> > there.
>
>
On Mon, Feb 08, 2021 at 07:28:56PM +0100, Richard Hartmann wrote:
> I very dimly remember updatedb being a concern when cloud images were
> first discussed. Back then and today, agreed, it does not make sense
> there.
Agreed, but we don't install all Priority: standard packages on the
cloud
Jonathan Carter dijo [Wed, Feb 10, 2021 at 07:29:14PM +0200]:
> >> Define "proper Unix"...
> >
> > The definition depends on whether you are a longhair or shorthair.
>
> If you're a proper blue-haired person, then the only proper Unix is Debian.
Please do note that your definition might be of
Adrian Bunk writes:
> On Tue, Feb 09, 2021 at 12:02:33PM -0800, Russ Allbery wrote:
>> Adrian Bunk writes:
>>> On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
users on shared systems can expect it to be available without asking
an administrator first. To me,
On Tue, Feb 09, 2021 at 12:02:33PM -0800, Russ Allbery wrote:
> Adrian Bunk writes:
> > On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
> >>...
> >> users on
> >> shared systems can expect it to be available without asking an
> >> administrator
> >> first. To me, locate has
On 2021/02/10 15:16, Bjørn Mork wrote:
> Adam Borowski writes:
>>> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
>>> is, maybe it's time for a src:proper-unix-system package for those who care?
>>
>> Define "proper Unix"...
>
> The definition depends on whether you
On 2021-02-09 22:12:31 +0100, Ansgar wrote:
> "Steinar H. Gunderson" writes:
> > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> >> Furthermore, any mechanism they use to configure one of them
> >> (e.g. for privacy or performance reasons) will not control the other,
> >> and
On Wed, Feb 10, 2021 at 01:38:56PM +0100, Adam Borowski wrote:
> > As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
> > is, maybe it's time for a src:proper-unix-system package for those who care?
> Define "proper Unix"...
well, I'd leave this to the people who care.
On Wed, 2021-02-10 at 13:38 +0100, Adam Borowski wrote:
> Define "proper Unix"...
A system including Emacs. So we would need emacs at Priority: standard
or even important or required :]
Ansgar
Adam Borowski writes:
> On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote:
>> On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
>> > I happen to disagree. To me this is yet another step away from being a
>> > proper Unix system - to something else. Which would be fine if
On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote:
> On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
> > I happen to disagree. To me this is yet another step away from being a
> > proper Unix system - to something else. Which would be fine if it moved
> > us forward.
>
>
On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
> I happen to disagree. To me this is yet another step away from being a
> proper Unix system - to something else. Which would be fine if it moved
> us forward.
As it's 2021 and 99% of the Linux user base has no idea what UNIX (or
Marvin Renich writes:
> * Steinar H. Gunderson [210209 14:27]:
>> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
>> > And there are now also many non-technical Linux users who have never
>> > used a shell.
>>
>> Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
>>
On Lu, 08 feb 21, 23:13:10, Steinar H. Gunderson wrote:
>
> The downside is, of course, the nightly updatedb job, which it is rare that
> anyone will notice, and the space used.
That's assuming the system is left running over night. It might be
noticeable if run on next system start.
Kind
On Mi, 10 feb 21, 12:24:20, Andrey Rahmatullin wrote:
> On Tue, Feb 09, 2021 at 03:58:39PM -0500, Marvin Renich wrote:
> > These have come to be expected to be on a typical Linux system by almost
> > every technically-knowledgeable Linux user. Locate does not satisfy
> > that criterion
> (I'm
On Tue, Feb 09, 2021 at 03:58:39PM -0500, Marvin Renich wrote:
> These have come to be expected to be on a typical Linux system by almost
> every technically-knowledgeable Linux user. Locate does not satisfy
> that criterion
(I'm surprised by this, if this is true)
--
WBR, wRAR
signature.asc
On Tue, Feb 9, 2021 at 9:12 PM Ansgar wrote:
> Admittedly Debian's other defaults like making every file in $HOME
> world-readable by default are very unfriendly too on both multi-user
> systems (obviously) and single-user systems where suddenly even the
> "nobody" user has access to lots of
"Steinar H. Gunderson" writes:
> On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
>> Furthermore, any mechanism they use to configure one of them
>> (e.g. for privacy or performance reasons) will not control the other,
>> and again they may well be unaware of the existence of the
* Steinar H. Gunderson [210209 14:27]:
> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
> > And there are now also many non-technical Linux users who have never
> > used a shell.
>
> Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
> traceroute? host? All of these
Adrian Bunk writes:
> On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
>>...
>> users on
>> shared systems can expect it to be available without asking an administrator
>> first. To me, locate has always been a standard tool on a UNIX system, so it
>> makes sense to install
On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
> And there are now also many non-technical Linux users who have never
> used a shell.
Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
traceroute? host? All of these are irrelevant for a non-technical
non-shell user,
On Mon, Feb 08, 2021 at 11:13:10PM +0100, Steinar H. Gunderson wrote:
>...
> users on
> shared systems can expect it to be available without asking an administrator
> first. To me, locate has always been a standard tool on a UNIX system, so it
> makes sense to install it by default.
>...
"Shared
On Mon, Feb 08, 2021 at 01:57:42PM -0800, Josh Triplett wrote:
> That doesn't make it usable for portable scripting. A script can't
> assume the presence of locate without declaring a dependency on it, and
> there's currently no virtual package for locate. And even if locate is
> present, a script
Steinar H. Gunderson wrote:
> On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> > locate is a purely user-facing tool,
> > not really usable for portable scripting, since neither its presence nor
> > its functioning can be assumed.
>
> Really? Basic functionality is the same
On Sat, Feb 6, 2021 at 6:29 PM Steinar H. Gunderson wrote:
> Now, there is plocate (written and maintained by myself). It is orders of
> magnitude faster than mlocate
I use plocate on most days. Directly installed on laptops and
desktops, and via backports on all my file servers.
> I believe
On Sun, Feb 07, 2021 at 03:12:25PM +, Paul Wise wrote:
> On my desktop a no-change update takes 40s and the I/O usage is around
> 1800 K/s according to iotop-c, probably would be more painful on
> HDD-only systems.
That's interesting; how many files do you have on your machine, roughly?
(e.g.
On Sun, Feb 7, 2021 at 9:58 AM Steinar H. Gunderson wrote:
> On my server, with ~12M files on rotating media, updatedb.plocate finishes in
> ~40 seconds, IIRC. (I'd re-check to be sure, but today is RAID Sunday... :-) )
> On my laptop with 875k files and a regular SSD, it's less than three. It
On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> locate is a purely user-facing tool,
> not really usable for portable scripting, since neither its presence nor
> its functioning can be assumed.
Really? Basic functionality is the same between locate.findutils, mlocate and
plocate.
On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> I absolutely think that plocate makes sense as the "default" locate; it
> seems like an improvement on mlocate in every way.
>
> However, I don't think *any* locate should be in the base install, as
> long as that entails having any
On Feb 06, "Steinar H. Gunderson" wrote:
> mlocate used to be Priority: standard; for some reason that I haven't been
> able to unearth (despite the efforts of several people), there is now an
Probably because long ago it replaced locate from findutils which used
to be standard too.
> release
On Sun, Feb 07, 2021 at 12:40:55AM +, Paul Wise wrote:
> I support having locate in the base install, but I don't think that
> the cost of daily walking the entire filesystem is low; especially
> with HDDs and older storage or computers that can be a lot of I/O. I
> guess it also alters the
Steinar H. Gunderson wrote:
> Now, there is plocate (written and maintained by myself). It is orders of
> magnitude faster than mlocate (both on SSDs and HDDs alike), has the same
> security model, a smaller database (typically half the size), and fixes
> a few long-standing mlocate bugs. It is
On Sat, Feb 6, 2021 at 5:29 PM Steinar H. Gunderson wrote:
> I believe a good, fast locate is something that we should have in our base
> install; it is fine to keep it out of the cloud image (as today), but it is
> genuinely useful for both desktops and servers, and with a low cost.
I support
On Sun, Feb 7, 2021 at 12:05 AM Steinar H. Gunderson wrote:
> It's a pretty thin use-case, but someone could have scripts that call mlocate
> explicitly (not through the locate symlink). Or have something that is
> capable of reading mlocate's database. Or wish to have both to benchmark
> against
On Sat, Feb 06, 2021 at 10:18:45PM +0100, Bernd Zeimetz wrote:
>> Thoughts?
> I think plocate should have a Conflicts: mlocate. There is no need to
> install two locate implementations in parallel, it will just create
> useless IO.
It's a pretty thin use-case, but someone could have scripts that
On 2/6/21 6:10 PM, Steinar H. Gunderson wrote:
> I believe a good, fast locate is something that we should have in our base
> install; it is fine to keep it out of the cloud image (as today), but it is
> genuinely useful for both desktops and servers, and with a low cost.
seconded, thanks for
43 matches
Mail list logo
