Hey folks, just thought I'd share with you that I've released the latest
versions of pf-badhost and unbound-adblock which add support for NetBSD :)
pf-badhost webpage: https://www.geoghegan.ca/pfbadhost.html
unbound-adblock webage: https://www.geoghegan.ca/unbound-adblock.html
Key
So, does anyone have a working mozilla firefox-74.0 on 9.0 amd64?
I've been rebuilding another amd64 system starting with a stock 9.0
install, and I decided I should try firefox, since I haven't tried it in
a very long time, so I just used "pkgin install firefox" to try
However it just dumps
At Tue, 30 Jun 2020 14:28:38 -0700, "Greg A. Woods" wrote:
Subject: Re: So it seems "umount -f /nfs/mount" still doesn't work.
>
> At Tue, 30 Jun 2020 12:52:37 -0700, "Greg A. Woods" wrote:
> Subject: So it seems "umount -f /nfs/mount" still doesn't work.
> >
>
So, I should have
On Wed, Jul 01, 2020 at 09:07:54PM +0300, Staffan Thomén wrote:
> [ 184722.7286780] panic: lock error: Mutex: mutex_vector_enter,564: locking
> against myself: lock 0xc380065c6a40 cpu 0 lwp 0xc38007290aa0
> [ 184722.7286780] cpu0: Begin traceback...
> [ 184722.7286780] vpanic() at
On Wed, 1 Jul 2020 at 17:25, Michael Cheponis
wrote:
>
> Yes, it's possible to move to ~/.Trash or something -- but now you need to
> write ever-increasingly-complicated scripts to e.g. unrm a directory tree.
>
> I agree that backups are necessary, but who hasn't had a corrupted backup?
> And
> There are scripts which will create and remove a set of snapshots on
> zfs, which would be pretty much what you have in mind.
> [...]
> Traditional Unix filesystems don't support this well, I am afraid.
Well, "traditional" is a vague term, but we in {Net,Free}BSD land
have the McKusick's FFS
Michael van Elst wrote:
On Mon, Jun 29, 2020 at 07:08:40PM +0300, Staffan Thomén wrote:
Chavdar Ivanov wrote:
# ccdconfig -c ccd0 0 /dev/zvol/dsk/internal1/photos@backup
You are mapping a snapshot, it will be r/o.
You have to promote it first.
While it's true that the snapshot is r/o,
Malcom H sent this msg directly to me, but I do think it's useful on this
tread:
filesystems which support creation of checkpoints and/or snapshots are
probably the appropriate way to solve that issue - zfs is one that comes to
mind, although istr there is a "fssnap" feature in ffs in NetBSD but
On Wed, 1 Jul 2020 09:25:12 -0700
Michael Cheponis wrote:
> Yes, it's possible to move to ~/.Trash or something -- but now you need to
> write ever-increasingly-complicated scripts to e.g. unrm a directory tree.
>
So let's replace this shell script with ever-increasingly-complicated
code that
On 2020-07-01 18:25, Michael Cheponis wrote:
I agree that backups are necessary, but who hasn't had a corrupted backup?
And it's much less convenient. With disks so big these days, a 'shadow
filesystem' seems most logical to me.
There are scripts which will create and remove a set of
Yes, it's possible to move to ~/.Trash or something -- but now you need to
write ever-increasingly-complicated scripts to e.g. unrm a directory tree.
I agree that backups are necessary, but who hasn't had a corrupted backup?
And it's much less convenient. With disks so big these days, a 'shadow
On Wed, 1 Jul 2020 at 01:18, Michael Cheponis
wrote:
>
> Have you ever done this:
>
> $ rm good-stuff
> $ echo oh noo\!
>
> because good-stuff is in the bitbucket of no return.
>
> unrm exists as a shell script: http://freshmeat.sourceforge.net/projects/unrm
>
> But, as the commenter says, it
On Tue, 30 Jun 2020 17:18:14 -0700
Michael Cheponis wrote:
> So I'm proposing that "rm" move files to the shadow FS, and some other
> command or switch to rm to really remove them(e.g. temp files).
Of cause you can setup your environment whichever way you like it. Most
other people may
13 matches
Mail list logo
