Re: "locate" easier to use than "find"
On Mon, 21 Aug 2023 15:56:11 +0200
wrote:
>On Mon, Aug 21, 2023 at 03:19:19PM +0200, Roger Price wrote:
>> On Mon, 21 Aug 2023, Hans wrote:
>>
>> > find .mozilla -name favicons.sqlite -ls
>> > 1512492 2144 -rw-r--r-- 1 myusername myusernama 2195456 Aug
>> > 21 13:29 .mozilla/firefox/gs0gkgv2.default/favicons.sqlite 1515049
>> > 260 -rw-r--r-- 1 myusername myusername 262144 Aug 18 22:36
>> > .mozilla/firefox/th3dv2jy.default-1461749950404/favicons.sqlite
>>
>> For me command "locate" is easier to use than "find":
>
>They do different things. Locate is much faster, but it only looks
>into file names. Find can do nearly everything, like looking into
>file metadata ("show me all files younger than 12 days" or "owned
>by www-data"), running external programs (e.g. grep), yadda, yadda.
>
>To each job its tool.
>
>Cheers
Have basically stopped using traditional 'find' outside of scripts, as
always thought I was about the last one. Replaced with 'fd-find' which
really is simpler/more intuitive, sometimes actually faster. Quite
typical case where ~20% of the functionality will be doing the trick
90% of the time, in less time, and to me that already looks more like
99%. Especially on single user systems. I'm feeling rather more sorry
to say it's the same with 'ag', better known as the silversearcher,
another one of those long-serving workhorses that by the way is slated
for being dropped from Debian in just a couple of days: no longer
maintained, long dead upstream. I've used it for heavy grepping about
everywhere and for so many years. Most obvious replacement in this case
apparently 'ripgrep', also Rust of course. Has a few more edges I find
a little weird but got comfortable in a matter of a days anyhow. It's
all similar enough, about the hardest part is getting the actual
commands right: never a big fan of aliases I still regularly type
'find' instead of 'fd', it's muscle memory. ;)
Meanwhile traditional (m)locate got itself replaced with plocate, it
wasn't always that fast! Old things go, new arrive, I'm still using
bash though. Sorry for going off on another tangent. If anyone is still
using 'ag', just consider the options. And yes, GNU 'find' is
overcomplicated, I've long made do with a couple of shell functions
just to fight the repetition.
Oliver
Re: Firefox resource utilization (was Re: A case for supporting antiquated hardware, was Re: A hypervisor for a headless server?)
On Tue, 6 Jun 2023 06:05:18 +0200 wrote: >On Mon, Jun 05, 2023 at 05:59:11PM -0400, Celejar wrote: > >[...] > >> The only case I can see in which such offloading would >> be unethical is where the website operator is somehow engaging in >> deceptive behavior, but assuming it is not [...] > >A pretty strong assumption given that the crushing maturity of >the internet is fuelled by the ad industry, which, barred some >exceptions, can be characterised as "deception for hire". > >Cheers So somehow there still is no such thing as free lunch. You could just as well "blame" a cable TV network for running all those ads, your TV set after all won't eat less power. No profit means no fancy shows, sports, nor fancy websites. On the web things get quickly fuzzy of course, but in general neither is exactly deceptive. We know what we're doing and what we're doing is voluntary and the catches, if not obvious, are obviously well known. Know a workaround or work without it. I'm still a (somewhat) regular terminal links user, a text browser that is, no javascript not to mention anything more demanding, find it quite comfortable for text-dominated sites, like docs or Wikepedia, doesn't go well with physics/math content though. Also ok for a quick brush-up on news sites, where there's still a need, most don't work anymore but some do, not the ads. After all those years uBlock Origin probably saved me tangible money too, especially with German electricity costs (who's to blame?), but then what's cheating? Greetings, Oliver
Re: relevance of packages in repositories
On Sun, 07 May 2023 21:36:32 +0200 Michel Verdier wrote: >And beside the fact we are on a debian forum, and that debian is much >better than fedora and arch linux, all this don't answer the main >problem : there is no package called neodim. If this is this neodim : > >https://github.com/zbirenbaum/neodim It was already concluded we're supposed to be talking about Neovim, the versions match and let's not nail someone down on typos in a grumpy one-off shot. Using niche forks of niche 1970s-based editors (don't! I'm a die-hard vim user and I love the 70s) one should better be prepared for all sorts of frustration and maybe learn to handle it more gracefully. For once it doesn't even look so great across the board: https://repology.org/project/neovim/versions Debian isn't alone anyway. Yes, it gets more love in Arch, Fedora, and the (still) remarkably focused Void. At least for now! Does *everything* else you expect? The Gentoo-way you could walk right away, also with Debian. Building yourself is always an option, sometimes the only one, just don't drop it system-wide. Speaking of relevance and neovim and with due qualifications Popcon remains instructive: vim #1061 vs. neovim #6607, still clocking in higher than I would've guessed, but that is after all those years (forked in 2015). Out of curiosity is anyone at all on this list using Neovim? Main editor? Nah. I'm far from a Debian bigot but there's better reason to dump a whole distribution, and important as a specific editor can be other things you might try before. Like getting in touch with the team, maybe you can help somehow. The user list isn't made for this and most packages are relevant. Oliver
Re: Is perl still the No.1 language for sysadmin?
On Sun, 02 Apr 2023 22:42:14 +0200
Michel Verdier wrote:
>IMO style is perhaps important for development. But libs et regex are
>more important for sysadmin. I use python if a library is there or if I
>need to interface another python program. In example mutagen for
>covering mp3 files. And I use perl everywhere when I need a regex:
>parsing logs and the like. Specially with backref and substitution
>which are painful with python (IMO).
>
That's the whole point IMO, and the question was specifically about
system administration purposes, no clue why Lisp popped up. Or why
Python yet again, not say Ruby, arguably more of an (once) intended
Perl heir. So Perl's basically still around where there's a lot of
ageing "just works" layer and where you don't havy many dependencies or
special needs regarding funky libraries, frameworks, etc. And it can be
mostly for the same reason we're literally keeping hundreds if not
thousands of shell scripts around, full with arcane sed and awk
incantations and whatnot. It's doing the job, so what? Personally I
never really bothered to learn awk, so I'm still using Perl, on a daily
basis in fact, but for exactly the stuff some others would pull out
sed/awk/... Scripting, programming in the very small or what I've seen
Perl being touted to be *meant* for already 30 years ago. The fact at
some point some folks tried, more or less successfully, to make
something else entirely out of it, won't change history. Seems to me
people easily forget this but Perl was intended, created to be a tool.
A text processing tool. Not a language, or environment like Python.
So is it still the first choice for sysadmin work on Linux? Well I
doubt it, I also doubt it ever was. That would be shell. ;)
Still recall some interview from a couple of years ago where Larry Wall
apparently struggled with the Perl 6 thing ("Raku"), and at some point
he said, kind of like it's his last straw, well maybe it's (6) gonna be
the language of the singularity. He didn't really smile, guess he even
shrugged his shoulders, it was quite dry. Was he serious? Who knows,
it's Wall. Turns out though ChatGPT is--as virtually all ML
code--written in Python, that's at least according to Wikipedia and not
too surprising. There you go. Depending on what you make of it, there
may not come much after Python:
https://cacm.acm.org/magazines/2023/1/267976-the-end-of-programming/fulltext
Be that as it may I don't see much of a reason for learning Perl today
unless you're a die-hard hobbyist with near infinite amount of time
and an undying penchant for obsolete technology.
Oliver
Re: Flatpak memory usage
On Mon, 13 Feb 2023 09:35:34 -0500 wrote: >Am I correct in assuming that package formats like Flatpak, Snap and >Appimage, because they package up everything with the executable, would >consume more system memory? One of the reasons to use these formats is >to avoid library version mismatches, and peg the libraries which >accompany an executable at a certain version. But if this is true, then >it stands to reason that the executable would use, for example, GNOME >libraries which aren't the same as what's on your system being shared >by other software. Thus, when you launch X flatpak, it must load its >own version of the GNOME libraries. Which would take up more system >memory. > Flatpak is the odd one out and doesn't exactly work like this. Rather than completely self-contained images, the packages aren't that much different from what we have in Debian. The difference being that as for dependencies it's more of an all or nothing affair. Or what's called a "runtime", basically a small userland mostly tied to specific desktop environments. Clearly not as economical, especially if all you need is a single app, which to be fair isn't Flatpak's intented use case, or everything you're using needs a different runtime. It's also simpler though. With nothing but, say, GTK software you might always get away with a single runtime. I do, although with very few apps installed. Yes, if you're then also running something installed via Debian, or yet another package manager, with the same dependencies, there's redundancy, this is true even where versions match. I wouldn't rack my brains on that however, modern loaders are quite intelligent and dynamic linking is selective in a sense. I guess it's quite attractive for people like me who are not even using one of the full-blown DEs like GNOME, so there's little that must be resident all the time and I'm more flexibel in "load balancing" if need be, which should be almost never considering today's memory supplies. And I don't think any of these solutions is specifically catering to resource-constrained systems. With that you're probably always better off with installing from a single source. Oliver
Re: Choosing neovim over vim as default
Hello! On Fri, 04 Nov 2022 20:30:51 +0530 Bharatvaj P H wrote: >vimscript9 > feels like a bad decision, it is incompatible with vimscript2 and > does not match performance with lua. Probably not many scripting languages do. But then I'm not sure performance is the be-all and end-all when it comes to editor plugins. Certainly not for the Vim folks and even though speed was one the grounds for the change, as far as I'm aware it's not the most important. >Until vim9 I thought vim as a slimmer version of neovim but >it's the opposite. I've never heard this before. The whole point of Neovim was getting rid of what those folks identify or consider as "legacy" baggage. It is slimmer, hence maybe faster. That's good for Neovim, but not crucial for all of us. >Currently there is confusion among developers when >writing a plugin whether to choose vimscript9 or lua. And the only >point vimscript9 has is tha it is available in all distros. Is it time >to switch over to neovim? Choosing lua over vimscript9 reduces the >cognitive load of many people. I'm not to answer, just a user, though I would strongly oppose it. We also ship I believe quite a few emacs forks, clones or variations, I guess no one is ever seriously about to consider changing the default. Vim is Vim. Neovim is Neovim. Anyone is free to use whatever they prefer, and that's surely more people than those who write their own plugins, or need to adapt one, they may still care about what editor they use. Once they have to, chances are they're going to learn a new language anyway, because Lua isn't exactly popular. Oliver
Re: Why are some Debian bugs ignored for a long time?
On Sat, 20 Aug 2022 13:26:14 +0100 Brian wrote: >Reasons for the perceived "ignored" status might be: > > * The maintainer judges that the bug affects very few users. > * The maintainer does not have the resources to deal with the bug. > * A solution is already in hand and awaiting upload to unstable. > * The maintainer puts the report on the back burner and forgets about > it. > * The bug is low down on the priority list. > * The maintainer sees the bug as a user issue and not an issue with > package quality. > * The maintainer has little or nothing to contribute that would lead > to the report progressing. > * Fixing this issue is not worth the effort, if possible at all. > No, these are (more or less reasonable) grounds for not getting *to work* on some potential issue, and that is what you state yourself! With one exception--a fix warranting no further comment is imminent--none of these points however justifies providing no *feedback* to begin with, and if it's a won't-fix/don't care plus signature. In fact, most if not all would seem to explicitly ask for it. I'd even think there might well be less reason for interaction other than the auto confirmation once some change is pending, especially if it's obvious. As I understand it though Chuck is not primarily complaining about ignored issues. But about ignored reporters. We are a peoples project? And while I perfectly understand there can be countless causes *even* preventing maintainers from providing feedback, whether timely or long-time, this is simply an entirely different matter and would have to be explained in another way. At least this is getting us somewhere: > >Neither should a user have any expectation of a timely interaction, >nice though it may be to be get further involvement from a maintainer. So be it. If also a rule I'm afraid it's probably about as old as Debian and a rather antiquated conception of software development or the expectations of its wider ecosystem. Nor does volunteering in itself relieve you from certain minimal considerations that naturally arise when contributing to what is ultimately a social enterprise. Not to mention that, hopefully, all testing and bug reporting here is just as voluntary. ;) It's the whole point, isn't it? And if consideration means to, perhaps temporarily, *visibly* suspend some role when there's not enough time or more pressing issues, or at least to leave some clue to that effect somewhere, like on a personal website, as some have done. Pushing issues into some black hole however isn't exactly enticing, I can easily imagine technically advanced users instead rather sorting some things out themselves immediately, locally, and from experience just forgo the BTS altogether. Oliver
Re: Status of Virtualbox in debian
On Tue, 21 Jun 2022 13:31:11 +0100 Joe wrote: > >Yes, I was using it a few years ago, and a new Debian kernel made the >guest additions unusable. I forget what I needed them for, but gave up >on VB then. I dare say a later version of the VB additions fixed the >problem, but there was no knowing how long this would take, or whether >this would happen after every kernel upgrade. > Nearly. To be fair though that's usually not Debian specific, the latest patch for our own packages for instance was liberally taken from Arch Linux. The VB folks too are constantly trying to keep up with a moving target as is the kernel and basically every changelog sports a line or two announcing as much. And then these guys are (or have been anyway) cranking out releases like hardly anything that's (mostly) free software after all, maybe apart from Linux itself. In fact I dimly remember FreeBSD at some point giving up on it more or less completely, they were pretty much on their own and hopeless. We're already lucky Linux is just big enough to be supported and somehow worth it, how long, who knows. One probably shouldn't be surprised though if something like this perhaps doesn't always, immediately work OOB on the shiniest, newest kernel releases. If at all possible and stability is the main thing, it's a typical use case for an LTS kernel by the way. Regards, Oliver
Re: Alternatives to ISC dhcp-client ?
On Sun, 8 May 2022 09:20:25 -0400 Dan Ritter wrote: > Stefan Monnier wrote: > > Rick Thomas [2022-05-07 19:47:57] wrote: > > > According to the ISC webpage: > > >> ISC has ended development on the ISC DHCP client as of early > > >> 2022. This client implementation is no longer maintained and > > >> should not be used in production any longer. > > > Can anybody recommend a good replacement? > > > > Depends on your needs, but `busybox` provides a dhcp client that's > > good enough for the most common situations. > > > The package name is udhcpc. > > -dsr- > Right, it's not (yet?) tagged for provides/dhcp-client but at home would probably do the trick for me, too. Alternatively there's dhcpcd5, which is tagged and also specifically mentioned on the ISC's eom-page, though apparently a much broader solution. I'll be using the legacy one until it's actually removed from Debian and then switch to whatever is recommended, if anything and provided it's not networkd. Oliver https://roy.marples.name/projects/dhcpcd
Re: APT testing and unstabe Firefox: can't find newest version from unstable
On Fri, 03 Sep 2021 20:50:06 +0200 Sven Joachim wrote: > >Version 91 is only in experimental. > Probably blocked by some Rust stuff again. Anyone who's waiting and if possible please get a flatpak and get on with your life. Debian is providing that for a reason, too. We've been at the same point about a year ago when on some mailing list it was suggested Debian should just provide a flatpak. A joke of course, well I think it was. Still I decided to actually give it a try and have been happily using two of these since then, Firefox, and Chromium, which itself is too often vulnerable in Sid. Perhaps in the future distributions should really consider making do with, say, Firefox ESR and direct users who need "more" to something anyone can sort of agree on and flock together, that might well be avenues like Flatpak or AppImage. Container solutions are certainly not the be-all and end-all but I don't see much of a drawback for a case like this. You'll spend about a GiB extra, it's basically pulling its own small userland, once. Command line use needs some getting used to, kind of like systemd, hardly surprising if you know where it's from. But easy enough, same with desktop integration. There's no sane reason for using an outdated web browser today. If you want or need to stay purist, there is always ESR. Oliver
Re: Replacement Email Client
On Sat, 24 Oct 2020 16:04:00 -0700
Patrick Bartek wrote:
>
>Looking for recommendations for a lightweight email client that will
>handle HTML as well as plain text to replace Claws-Mail. Have been
>using Claws-Mail for years and before it Sylpheed. Claws used to have
>a basic HTML plugin renderer which was sufficient, but latest version
>does not.
I didn't even know it was gone, but apparently 3.17.7 just
(re)introduced a light viewer duly taking care of people who need it.
LiteHTML. It's packaged as claws-mail-litehtml-viewer, can't say if
it's any good, there are other options though. Even something
based on Dillo! ;) Not bad for a project with a different set of
priorities. Don't like a plugin? Feeling more like using behemoth
Firefox ('hate accessing mail through a browser'):
Config -> Preferences -> Message View -> External Programs
Not really a new feature either nor scratching CM's surface, but you
surely knew that too. I'm a CLI/TUI/oldskool devotee myself yet Mutt is
one of those things I never got around learning. Takes some time. Only
to fire up FF whenever you want to see a picture. Well I guess people
are different and some always have a browser flinging around anyway. See
what works for you.
Oliver
Re: Question on dpkg -l output.
On Sat, 22 Dec 2018 01:10:34 +0200 aprekates wrote: > In my case both: > > $ dpkg -l w* > > and > > $ dpkg -l 'w*' > > will report the same list > Hi! I'm getting the same sort of output and it seems to me these are packages, dpkg knows about providing some virtual packages, that something else on your system depends upon, but which is already satisfied in other ways. This would for instance explain why I see w3m and chromium, although having had neither installed at any time: both provide www-browser, and something I have depends on it. Cheers
