Hey -- the end of the year is coming up fast. Wouldn't you feel
better about yourself if you added a github sponsorship to balance out
your incredible year? :)
Do you live in one of these places?
Australia
Austria
Belgium
Canada
Cyprus
Czech Republic
Denmark
Estonia
Finland
France
Germany
Updating src tree:
P src/distrib/sets/lists/tests/mi
P src/distrib/syspkg/sets/comp/Makefile
cvs update: `src/distrib/syspkg/sets/comp/comp-c-catman/COMMENT' is no longer
in the repository
cvs update: `src/distrib/syspkg/sets/comp/comp-c-catman/DESCR' is no longer in
the repository
cvs update:
Am 09.11.2020 um 16:55 schrieb g...@duzan.org:
>
>
>>
>> Hello all you XEN experts!
>>
>> I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and
>> hosted on a commercial provider (www.prgmr.com). Since I'm running
>> 8.1 I think that implies that I'm running in HVM mode?
>> Lack of good randomness does not quite equal insecure install. Warn
>> about it, sure, but I think *requiring* randomness is a bad idea.
>> For example, I've been working with recent NetBSD at work, for
>> something for which the presence or absence of good random-seed data
>> makes absolutely
On Mon, Nov 09, 2020 at 11:15:52PM +0100, Vincent DEFERT wrote:
> On 09/11/2020 21:49, m...@netbsd.org wrote:
> > Unfortunately it leads to surprise failures if programs ever use
> > /dev/random. If not seeded, reads from it will block forever.
> If it has such consequences, the installer - or
On 09/11/2020 21:49, m...@netbsd.org wrote:
Unfortunately it leads to surprise failures if programs ever use
/dev/random. If not seeded, reads from it will block forever.
If it has such consequences, the installer - or maybe a 'first-run'
startup script? - should of course take care of it.
That
On Mon, Nov 09, 2020 at 09:53:50AM -0500, Mouse wrote:
> > So: happy to make it more userfriendly, simpler, rephrase messages,
> > whatever needed - but we should not end up with insecure installs.
>
> Lack of good randomness does not quite equal insecure install. Warn
> about it, sure, but I
On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> i run into it on real hardware, thinkpad t60.
>
> my preference is:
>
> - when booting in a VM, if there is no RNG device attached,
> the system should print a warning with instructions on how
> to attach the device.
In practice this
Hi Paul,
> I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and
> hosted on a commercial provider (www.prgmr.com). Since I'm running
> 8.1 I think that implies that I'm running in HVM mode?
most NetBSD's on prgmr running in PV mode currently as far as I
understood (at least,
> Hello all you XEN experts!
>
> I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and
> hosted on a commercial provider (www.prgmr.com). Since I'm running
> 8.1 I think that implies that I'm running in HVM mode?
I'm running 8.1_STABLE on PRGMR, and I'm running PV. They have
Hello all you XEN experts!
I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and
hosted on a commercial provider (www.prgmr.com). Since I'm running
8.1 I think that implies that I'm running in HVM mode?
Anyway, the provider will soon be upgrading their host to a PVHVM-only
> So: happy to make it more userfriendly, simpler, rephrase messages,
> whatever needed - but we should not end up with insecure installs.
Lack of good randomness does not quite equal insecure install. Warn
about it, sure, but I think *requiring* randomness is a bad idea. For
example, I've been
Hi,
I observed some weird behavior when I ran tar on a filesystem
with a /dev directory. I ran the equivalent of:
(cd / && tar -cf - . ) | (cd /somewhere && tar -xpf - )
and got the following error messages:
tar: Couldn't list extended attributes: Invalid argument
tar: Couldn't list extended
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2020.11.09.10.19.18 martin src/share/mk/bsd.prog.mk,v 1.334
2020.11.09.10.19.41 martin src/usr.sbin/makemandb/Makefile,v 1.11
Logs can be found at:
On Mon, Nov 09, 2020 at 11:03:31AM +, nia wrote:
> On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> > On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > > fwiw, i think the default options should be as close to Just Work as
> > > possible.
> > >
> > > i have installed
On Mon, Nov 09, 2020 at 11:03:31AM +, nia wrote:
> On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> > On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > > fwiw, i think the default options should be as close to Just Work as
> > > possible.
> > >
> > > i have installed
On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > fwiw, i think the default options should be as close to Just Work as
> > possible.
> >
> > i have installed NetBSD irl with people who have only a little bit of unix
> >
Hi folks,
On Mon, May 18, 2020 at 09:41:17PM +, Andrew Doran wrote:
> Finally got around to trying this. Having beaten on it for a while with
> real hardware I don't see any problem with swapping over NFS on 9.99.63.
>
> On Sat, May 02, 2020 at 12:06:48PM +1000, Paul Ripke wrote:
>
> > I
On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> fwiw, i think the default options should be as close to Just Work as possible.
>
> i have installed NetBSD irl with people who have only a little bit of unix
> knowledge, and watched them wince every time something doesn't go as planned.
>
fwiw, i think the default options should be as close to Just Work as possible.
i have installed NetBSD irl with people who have only a little bit of unix
knowledge, and watched them wince every time something doesn't go as planned.
often this is on older, spare hardware, that's just to play with
On Sat, Nov 07, 2020 at 06:12:34PM +1100, matthew green wrote:
> this is an update on my previous testing. i've excluded
> amd64 release builds from this set, takes too long ;)
Indeed remarkable! I assume you build the same source tree on the various
versions? Did you use the benchmarking stuff
The NetBSD Test Fixture wrote:
> nbmake[7]: nbmake[7]: don't know how to make -ltermlib. Stop
The build is still failing. The problems started with this commit:
2020.11.08.21.56.47 nia src/external/bsd/kyua-cli/Makefile.inc,v 1.8
2020.11.08.21.56.47 nia
22 matches
Mail list logo
