Re: [Code Bounty] NVMM hypervisor landed in DragonFly

[Michael Neumann]

On Sun, Aug 08, 2021 at 11:36:27AM +, Antonio Huete Jiménez wrote:
> Sorry, I was not clear enough in the previous email. I mean an alternative
> paying method that might be easier, more convenient for us all.

Thanks for mentioning that. I already wrote to Aaron before I read your
email. Now also contacted Matt :).

As more people were involved, Matt most likely knows better who gets
which amount ;).


> 
> Quoting Antonio Huete Jiménez :
> 
> > For the bounty itself, please contact Matt as we have an alternative
> > that might be more convenient.
> > 
> > Quoting Michael Neumann :
> > 
> > > On Sun, Aug 08, 2021 at 12:25:02PM +0800, Aaron LI wrote:
> > > > Hi DFlyers,
> > > > 
> > > > As you might already know, the NVMM hypervisor has landed in
> > > > DragonFly for a while and it's working quite well.  So I think
> > > > the hypervisor code bounty has been now accomplished.
> > > 
> > > Hi Aaron,
> > > 
> > > Great news! I am recompiling world now to test things out. Is there a
> > > list of systems that are known to work with our NVMM/qemu?
> > > 
> > > Will send you a private mail concerning the code bounty.
> > > 
> > > Regards,
> > > 
> > >  Michael
> 
> 
> 

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: [Code Bounty] NVMM hypervisor landed in DragonFly

[Michael Neumann]

On Sun, Aug 08, 2021 at 12:25:02PM +0800, Aaron LI wrote:
> Hi DFlyers,
> 
> As you might already know, the NVMM hypervisor has landed in DragonFly for a 
> while and it's working quite well.  So I think the hypervisor code bounty has 
> been now accomplished.

Hi Aaron,

Great news! I am recompiling world now to test things out. Is there a
list of systems that are known to work with our NVMM/qemu?

Will send you a private mail concerning the code bounty.

Regards,

  Michael

Re: slow GUI on Dragonfly 6.0.0

[Michael Neumann]

On Thu, Jun 24, 2021 at 08:37:16PM +0200, Fritjof Bornebusch wrote:
> Hi,
> 
> I just installed Dragonfly 6.0.0 with Lumina on a T460.
> One CPU core is always at 100%, even if top shows 0.0% for all processes. The 
> remaining cores (3) are at 0%.
> 
> Using a browser is increadible slow. Opening more than 1 tab is nearly 
> impossible. The usage of the cores does not change significantly.
> 
> Terminal apps work with normal speed.
> 
> Any hints what to do?

Hi Fritjof,

Can you try a different window manager? xfce4 for instance or cwm. This
is to rule out lumina as the source of the problem. Are there any
warnings / error messages printed on the console?

I was using Lumina on DragonFly in the past... and your problem sounds
familiar to me. But it's too long ago and I might get things mixed up.
Did you start "dbus" (dbus_enable=YES in /etc/rc.conf)?

Regards,

  Michael

Re: DragonFly 6.0 release!

[Michael Neumann]

On Mon, May 10, 2021 at 01:54:02PM -0400, Justin Sherrill wrote:
> DragonFly 6.0 is released - here's the release page:
> https://www.dragonflybsd.org/release60/

Thanks for all the great work!

Regards,

  Michael

Re: Installing Dragonflybsd on old board.

[Michael Neumann]

On Sun, Apr 25, 2021 at 11:01:46AM -0300, andre almeida pfeiffer wrote:
> Hello,

Ola Andre,

> I'm new to this list so I would like to introduce myself. My name is
> Pfeiffer, I'm from Brazil and for some time now I have wanted to try
> Dragonflybsd out.

Welcome to DragonFly! Seems like you have german ancestors, at least
your name suggests that :)

> My computer is an old GA 78LMT USB 3 with Amd FX and 32GB ram.
> 
> I would like to setup Dragonflybsd with some hypervisor (Best if its XEN or
> KVM, although, from what I read, XEN is not currently supported).
> 
> After burning the Dragonflybsd system either to a usb stick or CD/DVD I
> have been unable to get it to load the system installer. Not much
> information or control is show to help me, I'm also not very knowledgeable
> about operating systems inner details. Is there someone who could help me
> debug and install the system in that mentioned setup? Maybe I'm missing
> some setup on my board?

Where exactly does it stop working? Can you provide a screenshot?

Note that DragonFly might not be the most user-friendly operating system
out there. It's likely that you will encounter some issues here and
there.  Some hardware might not be supported or some software will not
work. Keep that in mind. Other than that, it's a great operating system
with very helpful community.

Running DragonFly under KVM should work flawlessly. My DragonFly server
was running under KVM for years without any issues. Dunno about XEN. For
sure there is no dom0 support.

Regards,

  Michael

Re: New binary packages available (Sync Jan 17 2021)

[Michael Neumann]

On Thu, Feb 18, 2021 at 12:54:50AM +, Antonio Huete Jiménez wrote:
> Dear users,
> 
> There is a new binary package set available for master and RELEASE.

Thanks for the hard work to keep the packages up to date!

Regards,

  Michael

Re: dports

[Michael Neumann]

On Thu, Feb 04, 2021 at 07:53:22PM -0800, Jonathan Engwall wrote:
> For the third time - do you know the first time I was successful - I am
> attempting to add a GPU.
> I am trying now to use the dport and I see this: 
> try 'make deinstall' then 'make reinstall' to 'upgrade' perl5 properly.
> Installing perl5 took HOURS. I installed it two weeks ago. Perl5 has 2400+
> tests and I passed all but one!
> What is this crap? What is 'make deinstall?'
> A friend of mine died last night because his piece-of-shit sister "made the
> call" and took away the ventilator. She posted about it on facebook. It
> makes me think. He was 50 in a few weeks. You have time you have, that is
> what you get. Why am I still wasting time on this OS. It's been a solid
> year now. Things only seem to get BROKEN!

You already had perl5 installed, right? I think, you need "make
reinstall" here. Or maybe just use the prebuild packages "pkg ins
perl5".

Regards,


  Michael

Re: Binary packages available for "staged" branch of DPorts?

[Michael Neumann]

On Wed, Dec 30, 2020 at 08:48:36AM -0500, Justin Sherrill wrote:
> On Tue, Dec 29, 2020 at 5:34 AM Michael Neumann  wrote:
> 
> >
> 
> 10 syncs a year sounds really good to me and I am more than satisfied
> > with that!!! I wish there were just more information about all these
> > cool things *outside* of IRC so that they also find their way into the
> > DragonFly Digest (which I am more likely to read than IRC ;-).
> >
> 
> I would love to have a single constant place to show what's built and
> what's not, for dports.  There's no immediate way to tell if you can
> install an application on DragonFly.  You can look in the dports directory
> and see if there's a package, but that doesn't show if it's just not
> building right now, if it would build, etc.

Are you thinking of something like www.freshports.org or
http://www.ravenports.com/catalog/?

If the report generated by synth/dsynth would emit JSON then we could
hack something similar to ravenports without much effort.

Regards,

  Michael

Re: Binary packages available for "staged" branch of DPorts?

[Michael Neumann]

On Mon, Dec 28, 2020 at 10:57:47PM +, Antonio Huete Jiménez wrote:
> 
> Quoting Michael Neumann :
> 
> > On Sun, Dec 27, 2020 at 11:51:15PM -0800, Matthew Dillon wrote:
> >> Antonio (tuxillo) and I build 'staged' regularly, but the staged repos are
> >> always in a state of flux and I don't recommend depending on it.  That
> >> said, I often have an external URL available for binary repo access to test
> >> bulks, and at the moment it is operational and on staged:
> >>
> >> http://apollo.backplane.com/Ripper/live_packages/
> >>
> >> Your download bw from this site is going to be pretty horrible though as it
> >> is in my home.  Maybe Antonio can set up a semi-official staged HTML link
> >> from the colo.
> >
> > IMHO something like biweekly or monthly builds would be great to  
> > have as> a DragonFly user.
> 
> Sure, but for that we need more than 2 people, which is basically what  
> we have now :P

You and me? :P

> We've done 10 syncs (once the current one is completed) in 2020, which  
> isn't too bad.

10 syncs a year sounds really good to me and I am more than satisfied
with that!!! I wish there were just more information about all these
cool things *outside* of IRC so that they also find their way into the
DragonFly Digest (which I am more likely to read than IRC ;-).

Regards,

  Michael

Re: Binary packages available for "staged" branch of DPorts?

[Michael Neumann]

On Sun, Dec 27, 2020 at 11:51:15PM -0800, Matthew Dillon wrote:
> Antonio (tuxillo) and I build 'staged' regularly, but the staged repos are
> always in a state of flux and I don't recommend depending on it.  That
> said, I often have an external URL available for binary repo access to test
> bulks, and at the moment it is operational and on staged:
> 
> http://apollo.backplane.com/Ripper/live_packages/
> 
> Your download bw from this site is going to be pretty horrible though as it
> is in my home.  Maybe Antonio can set up a semi-official staged HTML link
> from the colo.

IMHO something like biweekly or monthly builds would be great to have as
a DragonFly user.

>
> Again, these links are always in flux, so don't depend on it :-)
> 
> Antonio believes he can get the next sync to master done by the end of the
> year.  It will have the chromium fix.

That'd be great, thanks! Happy new year then :)

Regards,

  Michael

Binary packages available for "staged" branch of DPorts?

[Michael Neumann]

Hi,

I just noticed that the last commit to DPorts master branch is from Oct
4th. The "staged" branch is up-to-date but I cannot find any binary
packages built for it. Are there any?

Regards,

  Michael

Re: docker on dragonfly

[Michael Neumann]

On Wed, Nov 04, 2020 at 04:40:20PM +0200, Tiran Efrat wrote:
> thanks for the replies.
> Still, it's not clear to me whether there's a container solution (although
> i assume you'd mention if there was.). What about VM solution?
> thanks,
> Tiran.

We have jail(8).

Regards,

  Michael

> On Wed, Nov 4, 2020 at 3:53 PM Siju George  wrote:
> 
> > *Docker* is developed in the Go language and utilizes *LXC*, cgroups, and
> > the Linux kernel itself.
> >
> > --Siju
> >
> > On Wed, Nov 4, 2020, 6:38 PM Patrick McDonough <~patrick/d...@awk.is>
> > wrote:
> >
> >> I could be awfully wrong, so a more authoritative answer would be
> >> welcome. But Docker's daemon (the service that runs containers) is to my
> >> knowledge quite specific to Linux, and more recently Windows.
> >>
> >> The common route to docker 'support' outside of those two platforms was
> >> (is?) to run a virtualised Linux host that then ran the docker service,
> >> with containers executed inside that virtual machine. This is how Docker
> >> for MacOS works right now.
> >>
> >> It seems like the docker-machine package will do this for you, but I
> >> haven't tested it myself.
> >>
> >> Perhaps more interesting than useful; there was an effort in FreeBSD to
> >> provide a more native docker solution using a mix of jails, ZFS and their
> >> Linux compatibility layer. But I can't say how well it worked, or if it is
> >> still supported. But you may want to ask them.
> >>
> >> Patrick
> >>
> >> On Wed, 4 Nov 2020 13:23:19 +0200
> >> Tiran Efrat  wrote:
> >>
> >> > Hi,
> >> > Does dragonfly support docker engine installation? I couldn't find an
> >> > installer.
> >> > thanks,
> >> > Tiran.
> >>
> >

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: Touchpad problems

[Michael Neumann]

On Tue, Oct 27, 2020 at 10:38:31PM +0300, Jean Louis wrote:
> Is there any way to configure touchpad that it works?
> 
> I have enabled in /boot/loader.conf:
> 
> hw.psm.synaptics_support="1"
> 
> and in X like this:
> 
> Section "InputDevice"
> Identifier  "Touchpad0"
> Driver  "synaptics"
> Option  "Protocol" "psm"
> Option  "Device" "/dev/psm0"
> EndSection
> 
> and still touchpad is not working. First it worked and I had to move
> touchpad during X startup, then worked. If I did not touch it during X
> it did not wark when X was loaded.

Try to enable moused (moused_enable=YES in rc.conf) and use device
/dev/sysmouse instead for X.

Regards,

  Michael

Re: DragonFly bad performance with RIAK benchmark

[Michael Neumann]

On Sun, Aug 16, 2020 at 01:01:12PM +0200, Michael Neumann wrote:
> On Fri, Aug 14, 2020 at 04:29:24PM +0200, Jávorszky Balázs wrote:
> > Hi Michael,
> > 
> > Thx for the tips, gonna check them. I myself doubt too that it's 
> > DragonFly or HAMMER2 :) My feeling is that erlang should be at least 
> > marginally faster on DragonFly/HAMMER2.
> > 
> > A guestion regarding the latest erlang/elixir: have you seen these error 
> > messages? They are annoying but don't affect overall operation.
> > 
> > ```
> > 
> > 16:26:59.500 [error] Bad output fd in erts_poll()! fd=22, 
> > port=#Port<0.5>, driver=spawn, name=/usr/local/bin/git
> > 
> > ```
> 
> No I did not recognize those on my system, but that does not mean that
> they did not appear.
> 
> This is coming from erts/emulator/sys/common/erl_check_io.c line 1893,
> function bad_fd_in_pollset(). Why is it spawning "git"??
> 
> If you have any "simple" benchmark that we can run on DragonFly which
> exhibits the same performance degradation please let me know and I will
> try to run it on my system.
> 
> Regards,
> 
>   Michael


Sorry, I did not read your message carefully enough (read on phone while
in holidays :). So it seems you are building the basho Erlang/OTP
version from git. Make sure to apply the patches from dports
/usr/dports/lang/erlang/{files,dragonfly}.  Especially the DragonFly
specific one:

/usr/dports/lang/erlang/dragonfly/patch-erts_configure.in.

In case they apply.

You should also try to run Riak with the "official" Erlang/OPT from our
ports (pkg ins erlang)! Basho states that it should be fully
interoperable and the version you are building is OTP/16 while we have
OTP/21 in the ports.

Regards,

  Michael

Re: DragonFly bad performance with RIAK benchmark

[Michael Neumann]

On Fri, Aug 14, 2020 at 04:29:24PM +0200, Jávorszky Balázs wrote:
> Hi Michael,
> 
> Thx for the tips, gonna check them. I myself doubt too that it's 
> DragonFly or HAMMER2 :) My feeling is that erlang should be at least 
> marginally faster on DragonFly/HAMMER2.
> 
> A guestion regarding the latest erlang/elixir: have you seen these error 
> messages? They are annoying but don't affect overall operation.
> 
> ```
> 
> 16:26:59.500 [error] Bad output fd in erts_poll()! fd=22, 
> port=#Port<0.5>, driver=spawn, name=/usr/local/bin/git
> 
> ```

No I did not recognize those on my system, but that does not mean that
they did not appear.

This is coming from erts/emulator/sys/common/erl_check_io.c line 1893,
function bad_fd_in_pollset(). Why is it spawning "git"??

If you have any "simple" benchmark that we can run on DragonFly which
exhibits the same performance degradation please let me know and I will
try to run it on my system.

Regards,

  Michael

Re: DragonFly bad performance with RIAK benchmark

[Michael Neumann]

On Fri, Aug 14, 2020 at 10:24:00AM +0200, Jávorszky Balázs wrote:
> Hi,
> 
> We are using RIAK as our database, and for various reasons (well, TrueOS 
> has been abandoned...), we need to pick a new OS.

Can you try some gerneral Erlang/Elixir benchmarks first? I doubt it's
really DragonFly or HAMMER2 that slows down that much but rather the
Erlang port that might miss some optimizations on DragonFly. It could be
a missing #ifdef in the Erlang scheduler for instance. I had been
running Elixir and Erlang myself on DragonFly but never did any serious
performance comparisons. One further thing you could try is to run Riak
on DragonFly with different numbers of Erlang scheduler threads (+S)
or turn off SMP just to see if it makes a difference. If you are more
experienced, you could look for #ifdef __FreeBSD__ in the Erlang code 
and see if there is an appropriate #ifdef __DragonFly__ as well, or if
the #else branch falls back to some generic, slow code.

Regards,

  Michael

Re: Having /var/run separately mounted?

[Michael Neumann]

On Tue, Apr 28, 2020 at 07:14:43AM +, Dr. Martin Ivanov wrote:
> I would like to have /var/run mounted separately as it is not a 
> directory to be backed up.
> 
> 
> I tried mounting it as a tmpfs or as a null mount under /build. In both 
> cases it did not work, because some processes write to /var/run before it is 
> mounted and some after that. In particular, problems arise due to the shared 
> memory, which has to be mounted

Have you tried adding an entry to fstab like this:

/build/var.run  /var/runnullrw  0   0

This should then be mounted automatically by /etc/rc.d/mountcritlocal.
Once mountcritlocal has mounted the local file systems it will create a
/var/run/shm entry. So your /build/var.run should have a `shm`
subdirectory.

If you want to mount /var/run as tmpfs then you have to edit
/etc/rc.d/mountcritlocal slightly. Right at the end you will find:

mount_tmpfs -m 01777 dummy /var/run/shm
mkdir -p -m 01777 /var/run/shm/tmp

If /var/run should be a tmpfs, the `shm` directory and other directories
will not exist and you have to create them. Take a look at
/etc/mtree/BSD.var.dist and search for `var`. You will find the
subdirectories and their modes that you have to create. Create those
directories right before the `mount_tmpfs` call above.

Haven't tried that myself, but I think that should work.

Regards,

  Michael

Problems with WLAN - iwm0

[Michael Neumann]

Hi,

I can't get my WLAN working here with iwm0 on DragonFly 5.8.0. It always shows
"status: no carrier". I double checked with a recent FreeBSD (12.1), and there,
the same commands on the command line work. This is an open WLAN, I haven't
tested it with wpa supplicant.  Note that on FreeBSD I have to explicitly
specify the channel, otherwise I can't get it to work either.

Any ideas?

# dmesg | grep iwm0

iwm0: hw rev 0x230, fw ver 22.361476.0, address 74:70:fd:fa:5a:3c

# kldstat

Id Refs AddressSize Name
 1   12 0x8020 1eb5520  kernel
 21 0x820b6000 c8f8 ehci.ko
 31 0x820c3000 cec0 xhci.ko
 41 0x820d 11c50dm.ko
 51 0x820e2000 1d6b8if_iwm.ko
 61 0x8210 1bb250   iwm8265fw.ko

# ifconfig wlan create wlandev iwm0 up

wlan0: driver didn't set altq_maxlen
wlan0: MAC address: 74:70:fd:fa:5a:3c
wlan0

# ifconfig wlan0 scan

SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
my-ssid xx:xx:xx:xx:xx:xx9   54M   0:0100 EHTCAP WME

# ifconfig wlan create wlandev iwm0 channel 9 ssid my-ssid up

re0: flags=8802 mtu 1500
options=1b
ether 80:fa:5b:62:db:72
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049 mtu 16384
options=43
inet 127.0.0.1 netmask 0xff00 
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
groups: lo 
wlan0: flags=8843 mtu 1500
inet6 fe80::7670:fdff:fefa:5a3c%wlan0 prefixlen 64 scopeid 0x3 
ether 74:70:fd:fa:5a:3c
groups: wlan 
ssid my-ssid channel 9 (2452 MHz 11g)
country US authmode OPEN privacy OFF txpower 0 bmiss 10 scanvalid 60
protmode CTS wme bintval 0
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier

Regards,

  Michael

Re: Has anyone installed TensorFlow?

[Michael Neumann]

On Thu, Apr 16, 2020 at 11:00:14AM -0700, Jonathan Engwall wrote:
> Michael,
> No, bazel won't build. No protoc, I tried the BUILD from third party, I
> cloned from github and downloaded from the project main page with the same
> results.

With some effort, we might get protoc to build on DragonFly... but not so sure
about TensorFlow.

> I am not running linux.ko for compatibility, and would rather not. What are
> the steps to use PyTorch?

I haven't tried myself on DragonFly, so you might also run into problems with
PyTorch. You need to install from source:

https://github.com/pytorch/pytorch#from-source

There are some alternatives to PyTorch or TensorFlow:

  * MLPack (pkg ins mlpack) 
  * Keras (pkg ins py37-keras)
  * Theano (pkg ins py37-theano)

Regards,

  Michael


> Thank you,
> Jonathan Engwall
> 
> On Thu, Apr 16, 2020, 12:59 AM Michael Neumann  wrote:
> 
> > On Wed, Apr 15, 2020 at 05:20:42PM -0700, Jonathan Engwall wrote:
> > > It seems DragonFly is practically locked out of TensorFlow. Bazel is just
> > > too finicky.
> > > Is there a work around?
> >
> > Can you describe more precisely, why TensorFlow is not working on
> > DragonFly?
> >
> > Can't you get bazel to build?
> >
> > Have you tried PyTorch instead?
> >
> > Regards,
> >
> >   Michael
> >
> >

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: Has anyone installed TensorFlow?

[Michael Neumann]

On Wed, Apr 15, 2020 at 05:20:42PM -0700, Jonathan Engwall wrote:
> It seems DragonFly is practically locked out of TensorFlow. Bazel is just
> too finicky.
> Is there a work around?

Can you describe more precisely, why TensorFlow is not working on DragonFly?

Can't you get bazel to build?

Have you tried PyTorch instead?

Regards,

  Michael

Re: No sound from front headphones jack

[Michael Neumann]

On Mon, Mar 02, 2020 at 02:41:44PM +0530, Siju George wrote:
> On Mon, Feb 17, 2020 at 10:14 PM Michael Neumann  wrote:
> 
> >
> > Try setting:
> >
> > sysctl hw.snd.default_unit=n
> >
> > for some number of "n".
> >
> > Maybe
> >
> > sysctl hw.snd.default_unit=25
> >
> > or
> >
> > sysctl hw.snd.default_unit=27
> >
> > could work. If I am not mistaken, "n" is the "nid" that you see in the
> > dmesg
> > output.
> >
> >
> Thank you so much Michael :-)
> 
> I tried but it did not work. Please see the output
> 
> # sysctl hw.snd.default_unit=25
> hw.snd.default_unit: 1
> sysctl: hw.snd.default_unit=25: Invalid argument
> # sysctl hw.snd.default_unit=2
> hw.snd.default_unit: 1 -> 2
> # sysctl hw.snd.default_unit=3
> hw.snd.default_unit: 2 -> 3
> # sysctl hw.snd.default_unit=4
> hw.snd.default_unit: 3
> sysctl: hw.snd.default_unit=4: Invalid argument
> # sysctl hw.snd.default_unit=5
> hw.snd.default_unit: 3
> sysctl: hw.snd.default_unit=5: Invalid argument
> # sysctl hw.snd.default_unit=6
> hw.snd.default_unit: 3
> sysctl: hw.snd.default_unit=6: Invalid argument
> # sysctl hw.snd.default_unit=7
> hw.snd.default_unit: 3
> sysctl: hw.snd.default_unit=7: Invalid argument

Yeah, that's my fault :)

Setting hw.snd_default_unit will "symlink" /dev/dsp to
/dev/dsp${hw.snd.default_unit}. 

Please try:

cat /dev/sndstat

This will show something like this:

Installed devices:
pcm0:  (play)
pcm1:  (play)
pcm2:  (play/rec) default

To use pcm2, you have to `sysctl hw.snd_default_unit=2`. Please try the
available devices.

Hope this helps! Otherwise, "man sound" gives a quite good introduction or you
can also find helpful information in the FreeBSD manual (we might have a copy
of this as "DragonFly manual" too).

Regards,

  Michael

Re: No sound from front headphones jack

[Michael Neumann]

eeded in 1 usecs
> [drm] ring test on 3 succeeded in 8 usecs
> [drm] ring test on 5 succeeded in 2 usecs
> [drm] UVD initialized successfully.
> [drm] ib test on ring 0 succeeded in 0 usecs
> [drm] ib test on ring 3 succeeded in 0 usecs
> [drm] ib test on ring 5 succeeded
> [drm] radeon_device_init: Taking over the fictitious range 
> 0xe000-0xf000
> [drm] hw_i2c forced on, you may experience display detection problems!
> tunable drm.video.HDMI-A-1 is not set
> tunable drm.video.DVI-D-1 is not set
> tunable drm.video.VGA-1 is not set
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   HDMI-A-1
> [drm]   HPD2
> [drm]   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
> [drm]   Encoders:
> [drm] DFP1: INTERNAL_UNIPHY1
> [drm] Connector 1:
> [drm]   DVI-D-1
> [drm]   HPD4
> [drm]   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
> [drm]   Encoders:
> [drm] DFP2: INTERNAL_UNIPHY
> [drm] Connector 2:
> [drm]   VGA-1
> [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
> [drm]   Encoders:
> [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [drm] fb mappable at 0xE0363000
> [drm] vram apper at 0xE000
> [drm] size 5324800
> [drm] fb depth is 24
> [drm]pitch is 5888
> kms console: xpixels 1440 ypixels 900
> [drm] Initialized radeon 2.48.0 20080528 for (null) on minor 0
> drm0 on vgapci0

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: download verification with md5?

[Michael Neumann]

On Thu, Jan 02, 2020 at 11:02:05PM -0500, Justin Sherrill wrote:
> Agreed, you should generally have https everywhere, but I don't have
> time to work on that machine tonight.  If it helps:
> 
> SHA512 (dfly-x86_64-5.6.2_REL.img.bz2) =
> 9efd1c1d85408ced59f4ab9509178358971e49627094c75a45b9533ac4a20753380237635a2c0c3c3d09e150a195770b5917866e93bf6e0d8cbbe5c90637b41f
> SHA512 (dfly-x86_64-5.6.2_REL.img) =
> f2860ff51d3cb162933cca1d38fabdf1920a8aa91c1fe0cefe351cbc14c7abaa638958e6d0042b02efde6375e916222bbafd18d03d9cde94369ef1e293e25092
> SHA512 (dfly-x86_64-5.6.2_REL.iso) =
> 3af1f8a8cf5ead7d9e9afbd3392821ed74398aca94239c77114c8c75a74af7f1e78b760dffebef6d452b0d9502724fbc3eeded718c845378f3847e6ca2eca57b
> SHA512 (dfly-x86_64-5.6.2_REL.iso.bz2) =
> 97407ab9c0c2bf9d459cd8f9d2d2796dd4466a8cfe67692eaaa2cf833eea16670ba7ab075dd76678ef979492cb9336ee332b49a5664b62f297660fa930c1e86d

Thanks Justin!

Would be great if you could in addition provide .asc signatures for the
files using security/gnupg.

1. Create key: gpg --gen-key

2. Export public key (put on website): gpg --export --armor youremailaddress > 
mykey.asc

3. Sign file: gpg --armor --detach-sign snapshot.tar.gz

4. Upload snapshot.tar.gz.asc

Then, everyone who trusts your public key can verify that these binaries
were actually signed by you using:

gpg --verify snapshot.tar.gz.asc snapshot.tar.gz

Given that your private key stays secured this adds another layer of
security. Right now, even using SHA256 checksums would be no more secure
in case you download the checksum file (md5.txt or sha256.txt) from the
same mirror server as the file itself.

If you need help setting this up, please let me know.

Regards,

  Michael

> 
> On Thu, Jan 2, 2020 at 2:59 PM inter.service.intelligence
>  wrote:
> >
> > hey,
> > I was thinking about installing dragonflybsd but the download page doesn't 
> > show any hashes except md5, which is a joke at this point. Quote 
> > "cryptographically broken and unsuitable for further use"
> >
> > Is that the approach to security at dragonflybsd? a md5 approach?
> >
> > furthermore: there is no https on the http://lists.dragonflybsd.org/ and it 
> > handles sensitive information like an email.
> >
> >
> > Really not encouraging for security minded users like me.
> >
> > Greets
> >
> >

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: rust 1.39 and errno

[Michael Neumann]

l request was 
> > https://github.com/rust-lang/libc/pull/1432/.
> > 
> > More recently, there was a commit to DragonFly itself that did add 
> > __errno_location, so presumably the Rust libc could now really use it. That 
> > commit was 
> > https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/60d311380ff2bf02a87700a0f3e6eb53e6034920
> > 
> > I'd like to gain a better understanding of how all this stuff works. For 
> > starters:
> > 
> > - The compile failure says that libc::__error does not exist, but the libc 
> > included in the source does seem to have it defined. Is it unavailable 
> > because thread local storage is disabled?
> > 
 > 
> > - Many prior version of rustc have been successfuly built for DragonFly. 
> > Did those have something that avoided the use of errno, or is getrandom a 
> > new addition to the build and that's why it's failing?
> > 
> > Thanks for any insight on this stuff,
> > 
> > Chuck

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: DragonFlyBSD Project Update - colo upgrade, future trends

[Michael Neumann]

On Mon, Jul 22, 2019 at 01:56:07PM -0700, Matthew Dillon wrote:
> John Marino (marino) pioneered the 'synth' system for dports and continues
> to help out, but his focus is on RavenPorts for now.  Rimvydas Jasinskas
> (zrj) and Antonio Huete Jimenez (tuxillo) have done a huge amount of work
> bringing dports back into operational form and getting the FreeBSD ports
> sync stuff working better.DragonFlyBSD is still using synth, and will
> probably remain on synth for the foreseeable future, though there is always
> some discussion about how best to move dports forwards.  It's an excellent
> build platform for us.

At first, let me thank you and everyone else involved for all the great
work that went into this project in the recent years! I am happily using
DragonFly since many years on my main desktop machine and on all my
servers, just recently had to switch my laptop to Linux because I had to
run a Windows VM. DragonFly can be a bit rough at times, especially when
you want to develop Android apps or embedded stuff. Too sad that most
people just care about Linux and don't write portable software :(

As Ravenports made very good progress since it's existence and IMHO is
superior in design, I was hoping that it will become the standard ports
system for DragonFly one day. Reading your comment above makes me think
that this won't happen soon or at all :)

> Francois Tigeot (ftigeot) has done a ton of work taking DRM up to
> Linux-4.7.10 and this has worked very well for Intel iGPUs.  We are now
> finally starting to dive into Linux's 'amdgpu' subsystem which is much
> older, in order to modernize our AMD support (which is still deficient).
>  Numerous other people have spent a considerable amount of time helping
> test GPU support and tracking down bugs.  The work is ongoing.

Does that mean that there is a plan to support the embedded GPU of Zen2?

> I apologize for only writing everyone's names in plain ascii :-)

My name appeared three times in the list below, and I wasn't even
drinking :)

> Right now HAMMER2 makes for an excellent single-device filesystem
> (extremely well given that it supports writable snapshots and compression
> out of the box), but it remains deficient when it comes to expandable
> storage, multiple devices, and clustering.  This will be active work for me
> but honestly the amdgpu support has to come first so it's still going to be
> a long-haul for HAMMER2.

One thing I was really hoping for is a HAMMER2 equivalence to "hammer
mirror-copy", or "zfs send/receive". My server is still on HAMMER1 and I
really enjoy being able to continuously back it up. That's the only
thing I am missing in HAMMER2.

There are four more things on my DragonFly wishlist:

- Working Bluetooth stack (so I can use my headset)

- USB Webcam support (V4L)

- Hardware virtualization ("bhyve", to run Windows :)

- RISC-V port :D

Best regards,

  Michael

Re: Computers for cross-platform development

[Michael Neumann]

On Mon, May 27, 2019 at 04:59:07PM +0200, jasse Jansson wrote:
> 
> On 5/27/2019 10:03 AM, Michael Neumann wrote:
> > On Thu, May 23, 2019 at 11:44:38PM -0400, Pierre Abbat wrote:
> > > I'm planning to get several small computers so that I can test my 
> > > software on
> > > several OSes. One will compile binaries for Windows; the others will run
> > > OpenBSD, NetBSD, probably FreeBSD, and maybe DragonFly (I already have a
> > > DragonFly box, but it's slow compared to my laptop). I'm looking at these:
> > > https://www.newegg.com/Barebone-Mini-Computers/Category/ID-3
> > > How can I make sure that all the hardware works on all the BSDs?
> > If you want small boxes, take a look at LattePanda Alpha's from DFRobot.
> > The old LattePanda's (V1) are very similar to Intel NUC and you get the
> > entry model for 90$ (2GB RAM/32GB Flash). The Alpha's are much more
> > powerful than V1 but also much more expensive (~400$). The LattePanda's
> > have pretty standard Intel hardware, graphics, network and wireless
> > should work out of the box.
> > 
> > You can also take a look at UDOO x86 and Up Board which are both very
> > similar to LattePanda.
> > 
> > Also pretty cheap are HP's MicroServers. I have two of them (N54L).
> 
> I'll avoid HP microservers.
> 
> I have one (gen8) and, for example, won't boot from the USB3 ports.
> 
> Also refuses to boot with one USB2 and one USB3 stick int the USB2 ports.
> 
> I run FreeNAS on mine.

Sad to hear that. I only had the older model and they worked well.

The HP's were the only boxes I found to build a compact x86 NAS.


> They seem a bit "special". I won't buy anymore of these, cheap or not.
> 
> > 
> > I agree with the other commenters that Virtualization might be the
> > better approach unless you need to run your software on real hardware.
> > 
> > Regards,
> > 
> >Michael
> > 
> > 
> > > The reason I say "probably FreeBSD" is that another computer I'm going to 
> > > get
> > > is a Power9 box from Raptor for big-endian testing. I know of two OSes 
> > > that
> > > are big-endian on Power9: Adélie Linux and FreeBSD. However, while it is 
> > > Tier
> > > 1 on Adélie, it is Tier 2 on FreeBSD. So I may or may not set it up as 
> > > dual-
> > > boot.
> > > 
> > > Pierre
> > > -- 
> > > I believe in Yellow when I'm in Sweden and in Black when I'm in Wales.
> > > 
> > > 
> > > 
> > 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 

Re: Computers for cross-platform development

[Michael Neumann]

On Thu, May 23, 2019 at 11:44:38PM -0400, Pierre Abbat wrote:
> I'm planning to get several small computers so that I can test my software on 
> several OSes. One will compile binaries for Windows; the others will run 
> OpenBSD, NetBSD, probably FreeBSD, and maybe DragonFly (I already have a 
> DragonFly box, but it's slow compared to my laptop). I'm looking at these:
> https://www.newegg.com/Barebone-Mini-Computers/Category/ID-3
> How can I make sure that all the hardware works on all the BSDs?

If you want small boxes, take a look at LattePanda Alpha's from DFRobot.
The old LattePanda's (V1) are very similar to Intel NUC and you get the
entry model for 90$ (2GB RAM/32GB Flash). The Alpha's are much more
powerful than V1 but also much more expensive (~400$). The LattePanda's
have pretty standard Intel hardware, graphics, network and wireless
should work out of the box.

You can also take a look at UDOO x86 and Up Board which are both very
similar to LattePanda.

Also pretty cheap are HP's MicroServers. I have two of them (N54L).

I agree with the other commenters that Virtualization might be the
better approach unless you need to run your software on real hardware.

Regards,

  Michael


> 
> The reason I say "probably FreeBSD" is that another computer I'm going to get 
> is a Power9 box from Raptor for big-endian testing. I know of two OSes that 
> are big-endian on Power9: Adélie Linux and FreeBSD. However, while it is Tier 
> 1 on Adélie, it is Tier 2 on FreeBSD. So I may or may not set it up as dual-
> boot.
> 
> Pierre
> -- 
> I believe in Yellow when I'm in Sweden and in Black when I'm in Wales.
> 
> 
> 

Re: Installation 'halts' at boot after initialising UEFI framebuffer

[Michael Neumann]

On Mon, Jan 07, 2019 at 03:56:52PM +, cbz wrote:
> On Mon, 7 Jan 2019 at 15:38, Michael Neumann  wrote:
> > Yes, I had a similar issue. I think what you are seeing is similar to
> > this:
> >
> > https://www.dragonflybsd.org/~mneumann/IMG_20181126_181023.jpg
> 
> I get a similar screen - so yes I'd say it's stopping at the same
> point in the build cycle.
> 
> > I have a patch below that works for me. You need to apply it to /usr/src
> > ( cd /usr/src && patch -p1 < patch-fb-machdep.c) recompile and reinstall
> > the kernel. Let us know if you have trouble with the patching procedure.
> >
> > https://www.dragonflybsd.org/~mneumann/patch-fb-machdep.c
> >
> > You need to set the loader tunable "sc.probe_early=1" before booting in
> > the boot loader.
> 
> I'm doing an initial install - on the first machine I have to run
> dragonflybsd so don't have an environment on which I could rebuild the
> install media.  So I assume my options are to install Linux or
> similar, put dragonflybsd in a VM and then use that to rebuild the
> kernel in the install media?

Or, I will commit the patch above and then you wait a day and download
a daily snapshot of the image. I think that would be easier for you.

If you are not in a hurry, please wait a bit :) 

Regards,

  Michael

Re: Installation 'halts' at boot after initialising UEFI framebuffer

[Michael Neumann]

On Mon, Jan 07, 2019 at 02:01:50PM +, cbz wrote:
> Hi -
> 
> Currently when I try to use the installation media the boot process appears
> to halt right after initialising the EFI framebuffer.  The messages I get
> are identical to the ones here, except that the resolution is different.  I
> can screenshot if there is sufficient interest:
> 
> https://lists.freebsd.org/pipermail/freebsd-questions/2016-July/272697.html
> 
> Looking here, it appears that this was a problem with FreeBSD in the past,
> and possibly one that was later fixed (there are various references on the
> web to alternatively using the 'gop' command in the boot loader, or setting
> variables like kern.vty):
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821
> 
> Has anyone seen anything similar with dragonfly and been able to fix it ?
> Switching back to legacy (non-UEFI) mode is not an option in this case as
> the motherboard doesn't support this.  Are there any boot
> variables/settings I can change to use a non EFI framebuffer console?
> 
> I quoted 'halts' in the subject, as my belief is that the installer process
> actually works, it's just that the framebuffer device isn't working
> correctly (as per the first link above).

Hi!

Yes, I had a similar issue. I think what you are seeing is similar to
this:

https://www.dragonflybsd.org/~mneumann/IMG_20181126_181023.jpg

It took me many nights to hack debug code into the boot loader and early
kernel startup (hard to debug without serial console or any screen
display :D) to figure out that it is actually booting, but that the
framebuffer is not correctly initialized, so you just don't see anything
on screen (it might kernel panic later on... but it definitively starts
the kernel and probes the devices).

I have a patch below that works for me. You need to apply it to /usr/src
( cd /usr/src && patch -p1 < patch-fb-machdep.c) recompile and reinstall
the kernel. Let us know if you have trouble with the patching procedure.

https://www.dragonflybsd.org/~mneumann/patch-fb-machdep.c

You need to set the loader tunable "sc.probe_early=1" before booting in
the boot loader.

Would be great if you could open up a bug report on
bugs.dragonflybsd.org with your bug description.

BTW, when I boot FreeBSD with the same Laptop, I actually see something
on the screen, but it is totally scrambled.

Regards,

  Michael

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: DragonFly 5.4.1 released

[Michael Neumann]

On Mon, Dec 24, 2018 at 08:57:43AM -0500, Justin Sherrill wrote:
> Here's the tag commit, for what has changed from 5.4.0 to 5.4.1:
> 
> http://lists.dragonflybsd.org/pipermail/commits/2018-December/718276.html

Thanks for the release and merry christmas to everyone!

Regards,

  Michael

Re: Keyboard not working in 5.4

[Michael Neumann]

On Thu, Dec 06, 2018 at 01:40:15PM +0100, Martin Ivanov wrote:
> 
>   Hello, after successfully installing and using dragonfly 5.2 on my laptop:
> 
> 
>   ASUS ZENBOOK PRO I7-7700HQ/16GB/512GB SSD BLACK, Notebook, Core™ i7
>   Prozessor, 16 GB RAM, 512 GB SSD, GeForce GTX 1050, Matte Black,
> 
> I decided to give 5.4 a try. So I created a bootable USB stick and 
> started the new installation. Unfortunately, after the kernel boots and 
> releases the shell, I cannot type anything, it seems that the keyboard 
> is not recognized. Any suggestions will be appreciated! Please do not be 
> appalled by the nvidia card, it is just on top of an intel card that 
> actually works with dragonfly.

Hi Martin,

Do you have a USB keyboard lying around? Please plug it in so that you
can send us your dmesg output. Looks like a pretty nice latop! Btw, I
got the Tuxedo laptop last week and most things are working except X11
:(

Regards,

  Michael

> 
> Thanks in advance!
> 
> 
> -- 
> Dr. Martin A. Ivanov
> GreenPocket GmbH - Kundennähe durch Smart Metering -
> Labor 3.09 | Schanzenstraße 6-20 | 51063 Köln
> Telefon   +49 | 221 | 355095-0
> Fax   +49 | 221 | 355095-99
> E-Mail  martin.iva...@greenpocket.de
> 
> Webadresse  www.greenpocket.de
> 

-- 
Michael Neumann
NTECS Consulting
www.ntecs.de

Re: Ruby 2.5.3 build freeze

[Michael Neumann]

On Tue, Oct 30, 2018 at 05:42:34PM +0200, Agis Theodoropoulos wrote:
> Hi!
> 
> I am trying to build Ruby 2.5.3 on my DragonFly 5.2 machine and I get a
> freeze during the RDoc generation step. Specifically, on the jacobian.rb
> file.
> 
> When I top, I see the ruby process consuming 100.0% of core 0. Whatever
> it's doing, it's not getting anywhere (had to kill it after 10 minutes).
> 
> Has anybody come across this or something similar?

I had similar issues with building the h2o webserver which depends on
miniruby (or ruby). I had issues building the onigurama (regexp) engine.
I didn't track the cause further down...

Regards,

   Michael

Re: Coupla questions on DragonFly as a desktop OS

[Michael Neumann]

On Sun, Oct 28, 2018 at 12:22:38PM +, John Long wrote:
> Sorry, some additional info and questions:
> 
> Box is a Dell Poweredge T30 with 2x1T drives (for now)
> 
> Should I pick HAMMER or HAMMER2 (installer seems to suggest HAMMER) and
> should I use Dell's onboard RAID 0 or AHCI?
> 
> I'm doing a trial install now with HAMMER2, AHCI... I used NetBSD (and
> Free and still running OpenBSD on various boxes) for a while years ago
> so the basics are somewhat familiar. I'm sure HAMMER/2 is totally new
> and great :)

HAMMER2 is rock solid IMHO. Unless you want streaming backups, go for
HAMMER2.

Regards,

  Michael

Re: Coupla questions on DragonFly as a desktop OS

[Michael Neumann]

On Sun, Oct 28, 2018 at 08:04:39AM +, John Long wrote:
> Hi,
> 
> I have some miscellaneous questions on the way to finding a new desktop
> OS. Thanks to anybody who would help with this:


Hi John,

Welcome to DragonFly :).

In general, don't expect DragonFly to be as polished as other systems,
especially when it comes to desktop use.

I run it with success for a couple of years as my main desktop and I am
happy with it.

> Acrobat reader: I have a lot of manuals in .pdf format and I haven't
> found anything I can tolerate other than acroread. I'm not saying there
> isn't anything good, I just haven't seen it. I don't need forms support
> or change tracking or any fancy stuff. I want 2-up display and I need
> internal links to work. I also have a bunch of .djvu but the djview
> reader is mostly ok.

I use evince and I love it. okular is good IIRC when you need to
bookmark pages.

> Computer languages: Are Fortran and Ada available? I looked in the
> dports directory at UK Mirror Service and I didn't find any of the
> common names (gfortran, gcc-ada, gnat (the language, not the bug
> tracker)).

Ada should have damn good support as J. Marino uses it on DragonFly to
write synth and ravenadm, two package tools.

lang/gcc6-aux supports both Ada and Fortran.

> Virtualization: Is there a way to run Linux in a VM?
> 
> HAMMER2: Is it possible to set up a root mirror in the installer and if
> not can I add a disk to mirror the root after installing? I don't know
> anything about HAMMER/HAMMER2 but I use ZFS on Solaris and I am hoping
> to get some of the same management features with HAMMER2, mostly the
> stuff about filesystems taking only the space they need, and having
> good software mirroring that makes it easy to pull out a bad drive,
> swap in a new one, and everything works with no data loss.

HAMMER2 is great, but for backup I still prefer the mirror-stream
capability of HAMMER. Currently I backup HAMMER2 using rsync.

HAMMER/HAMMER2 uses logical replication instead of replication on the
block level. With HAMMER1 I was able to stream any change to the
filesystem to one or more slaves in "realtime". HAMMER2 doesn't
currently have these features.

You have to setup these things manually. For HAMMER1 this was pretty
easy. As I said, for HAMMER2 you have to use (e.g.) rsync to backup your
files.

> Are web browsers like Opera and Chrome available? Don't get me wrong, I
> hate google bitterly, but Chrome's translation feature is handy when it
> works. I like Opera's UI but I can live with Firefox.

Chrome works best on DragonFly. Firefox is currently no longer in the
ports, I guess because of Rust.

Regards,

  Michael

Re: Laptop or Notebook recommendation?

[Michael Neumann]

On Tue, Oct 02, 2018 at 04:59:51PM +, Dr. Martin Ivanov wrote:
> Hello everybody,
> 
> 
> I have been using Slackware Linux for more than 12 years. Now I am considering
> giving a BSD a try and my choice has fallen on DragonFly. Unfortunately, the
> laptops I have are all with Nvidia video cards, which turn to be best 
> supported
> by Linux, but as I realize not at all supported by DragonFly. So, I am
> considering buying a new laptop that will be fully compatible with DragonFly
> BSD. Any recommendations? The Supported Hardware page in the DragonFly website
> claims to be obsolete. Therefore, I will be happy to receive more up-to-date
> information about the hardware compatibility and probably specific laptop or
> notebook recommendations. I would be particularly happy if there happen to be
> newer models (not older than say 2-3 years) that are supported by DragonFly.
> 
> 
> Thank you very much for your attention!

Welcome to DragonFly!

If you are based in Germany, you might give Tuxedo Computers a try. I
don't own one yet, but plan on buying one. They are designed
specifically to work well on Linux, and according to the specs, graphics
and WLAN should work on DragonFly.

Regards,

  Michael

Re: Chromium update and porting instructions

[Michael Neumann]

On Wed, Sep 12, 2018 at 08:16:35PM +, Antonio Huete Jim??nez wrote:
> Hi,
> 
> Recently we've updated www/chromium in dports from 60.0.3112.116 to  
> 68.0.3440.106.
> 
> Basically what we have done is to use the FreeBSD patches for  
> www/chromium and changed the relevant DragonFly bits on top of that.  
> For those who would like to contribute to future Chromium upgrades,  
> fix bugs, etc we have created a document which describes the process  
> we have followed:  
> https://www.dragonflybsd.org/docs/howtos/HowToUpdateChromium/
> 
> Many thanks to the FreeBSD folks for taking in consideration other  
> BSDs in their work with is_bsd, OS_BSD and friends :-)

Thanks for keeping this up-to-date!

I wish there were more "is_bsd" is some other projects :/

Regards,

  Michael

Re: A few questions about HAMMER master/slave PFS

[Michael Neumann]

On Mon, Aug 27, 2018 at 06:08:10PM +0200, Laurent Vivier wrote:
> Hello DFlyers,
> 
> I am running DragonFly 5.2.2 as an NFS server with 2x 2TB LUKS-backed HDD's 
> with HAMMER1 v7 as FS in a PFS master/slave mirror-stream setup and it's been 
> working great so far :)
> 
> The setup looks like this :
> 
> Disk1 -> LUKS -> HAMMER1_2TB -> PFS# 0 (root) 
> Disk2 -> LUKS -> HAMMER_SLAVE -> PFS# 0 (root) + PFS 1 (slave to HAMMER1_2TB 
> / PFS# 0)
> 
> Now that I am using the system for a little while, I have a few questions 
> regarding its behavior :
> 
> 1) I realized that the HAMMER slave PFS has several snapshots (not created by 
> me) that seems seemingly impossible to remove e.g

HAMMER1 uses fine-grained snapshots, which means that it basically
automatically creates an "unnamed" snapshot whenever it flushes
something to disk (roughly every 30 seconds). Usually, you don't want to
keep all these fine-grained snapshots and instead keep one snapshot per
day (or one per week...). This is what "hammer cleanup" does. You can
configure it's history retention policy by running "hammer viconfig".
>From the man page of "hammer cleanup":

   snapshots  1d 60d  # 0d 0d  for PFS /tmp, /var/tmp, /usr/obj
   prune  1d 5m
   rebalance  1d 5m
   #dedup  1d 5m  # not enabled by default
   reblock1d 5m
   recopy 30d 10m

This means, when you run "hammer cleanup", it takes one snapshot every
day, and retains the last 60 daily snapshots. hammer cleanup performs
other tasks, for instance pruning (1d = every day, for 5 minutes).
Pruning deletes all the intermediate fine-grained snapshots between the
"named" daily snapshots. It also rebalances the B-tree, dedups, reblocks
and recopies. These are all operations to optimize performance. Dedup is
to save space. 

If you want to delete snapshots, just change "snapshots 1d 60d" to, for
instance, "snapshots 1d 7d" and run "hammer cleanup". If you want to
delete all historical data, you might use "hammer prune-everything", but
be careful and read the man page!!!

One nice feature of HAMMER1 is that the master PFS and slave PFS can
have different history retention policies in place.

> 
> Hikaeme# hammer info /HAMMER_SLAVE
> Volume identification
> ?? Label hammer1_secure_slave
> ?? No. Volumes 1
> ?? HAMMER Volumes?? /dev/mapper/knox2
> ?? Root Volume /dev/mapper/knox2
> ?? FSID?? 0198767f-7139-11e8-9608-6d626d258b95
> ?? HAMMER Version?? 7
> Big-block information
> ?? Total?? 238335
> ?? Used 192009 (80.56%)
> ?? Reserved 32 (0.01%)
> ?? Free?? 46294 (19.42%)
> Space information
> ?? No. Inodes?? 35668
> ?? Total size 1.8T (1999298887680 bytes)
> ?? Used 1.5T (80.56%)
> ?? Reserved 256M (0.01%)
> ?? Free 362G (19.42%)
> PFS information
> ?? ?? PFS#?? Mode?? Snaps
> ??  0?? MASTER?? 0 (root PFS)
> ??  1?? SLAVE 3
> Hikaeme# hammer snapls /HAMMER_SLAVE/pfs/hanma
> Snapshots on /HAMMER_SLAVE/pfs/hanma?? PFS#1
> Transaction ID?? ?? Timestamp?? ?? Note
> 0x0001034045c0?? 2018-07-04 18:19:42 CEST?? -
> 0x0001034406c0?? 2018-07-09 19:28:04 CEST?? -
> 0x00010383bc30?? 2018-08-12 10:51:07 CEST?? -
> Hikaeme# hammer snaprm 0x0001034045c0
> hammer: hammer snaprm 0x0001034045c0: Operation not supported

Have you tried hammer snaprm /HAMMER_SLAVE/pfs/hanma@@0x0001034045c0

> My question here is should I worry about it/is that an intended behavior ? 
> 
> 2) When executing hammer info and looking at the used space between master 
> and slave PFS, I have quite a big difference (22GB, even after running hammer 
> cleanup)
> 
> Hikaeme# hammer info
> Volume identification
> ?? Label HAMMER1_2TB
> ?? No. Volumes 1
> ?? HAMMER Volumes?? /dev/mapper/knox
> ?? Root Volume /dev/mapper/knox
> ?? FSID?? 81e9d5eb-6be7-11e8-802d-6d626d258b95
> ?? HAMMER Version?? 7
> Big-block information
> ?? Total?? 238335
> ?? Used 194636 (81.66%)
> ?? Reserved 32 (0.01%)
> ?? Free?? 43667 (18.32%)
> Space information
> ?? No. Inodes?? 35665
> ?? Total size 1.8T (1999298887680 bytes)
> ?? Used 1.5T (81.66%)
> ?? Reserved 256M (0.01%)
> ?? Free 341G (18.32%)
> PFS information
> ?? ?? PFS#?? Mode?? Snaps
> ??  0?? MASTER?? 0 (root 

Re: Tiered/cached storage and DragonFlyBSD

[Michael Neumann]

On Tue, Aug 21, 2018 at 10:40:14PM +0800, Aaron LI wrote:
> On Tue, 21 Aug 2018 16:12:37 +0200
> "my123 (@never_released)"  wrote:
> 
> > On my laptop, I use a DragonFlyBSD VM with NFS to use HAMMER2 features. 
> > (ZFS for example doesn't support on-demand deduplication).
> > 
> > Is there any way to combine a part of my SSD with the comparatively huge 
> > HDD to make burst writes better (and have them committed to HDD later, 
> > in times of low loads)? Linux supports this usecase better, but it 
> > doesn't have a good filesystem for my usecase.
> > 
> 
> Hi,
> 
> Thanks for using DragonFly.
> 
> I believe our swapcache(8) is what you need.  Please read the nice
> swapcache(8) man page (http://mdoc.su/d/swapcache ), and you can find
> detailed description and examples.

Except that swapcache(8) doesn't handle writes ;-). If you are looking
for something equivalent to ZFS's ZIL which you can put on a SSD, there
isn't one. Still, swapcache(8) is a great way to improve your harddisk
reads.

Regards,

  Michael

Re: df(1) showing different statistics for different users

[Michael Neumann]

On Mon, Aug 20, 2018 at 10:42:38AM -0700, Matthew Dillon wrote:
> Yes.  Root gets more headroom than non-root users, because system demons
> tend to implode if they run out of disk space and we don't want regular
> users to mess up root that way.

Makes sense. Thanks!

Regards,

  Michael

> 
> -Matt
> 
> On Mon, Aug 20, 2018 at 10:15 AM, Michael Neumann  wrote:
> 
> > Hi,
> >
> > When I run "df" as root it shows a capacity of 93%, while as
> > unpriviledged user, it shows 98%:
> >
> > # df -k /dev/serno/S3EWNCAHC00357M-1.s1e@DATA
> > Filesystem1K-blocks Used   Avail
> > Capacity  Mounted on
> > /dev/serno/S3EWNCAHC00357M-1.s1e@DATA  20357120 19002752 1354368
> > 93%/build
> >
> > > df -k /dev/serno/S3EWNCAHC00357M-1.s1e@DATA
> > Filesystem1K-blocks Used  Avail
> > Capacity  Mounted on
> > /dev/serno/S3EWNCAHC00357M-1.s1e@DATA  19339264 19002752 336512
> > 98%/build
> >
> > I did run "hammer2 cleanup" before, as I got a lot of these errors on
> > the console:
> >
> > hammer2_alloc_indirect: error 0020 No Space on Device
> > xop_strategy_write: error 32 loff=0061
> >
> > Before running hammer2 cleanup, I checked disk usage with "df",
> > and it showed me 97% capacity, so I was very confused why these
> > messages occured.
> >
> > Is it a feature to show less free capacity when logged in as
> > unpriviledged user?
> >
> > Regards,
> >
> >   Michael
> >

-- 
NTECS Consulting
Michael Neumann
www.ntecs.de

df(1) showing different statistics for different users

[Michael Neumann]

Hi,

When I run "df" as root it shows a capacity of 93%, while as
unpriviledged user, it shows 98%:

# df -k /dev/serno/S3EWNCAHC00357M-1.s1e@DATA
Filesystem1K-blocks Used   Avail 
Capacity  Mounted on
/dev/serno/S3EWNCAHC00357M-1.s1e@DATA  20357120 19002752 135436893%
/build

> df -k /dev/serno/S3EWNCAHC00357M-1.s1e@DATA
Filesystem1K-blocks Used  Avail Capacity  
Mounted on
/dev/serno/S3EWNCAHC00357M-1.s1e@DATA  19339264 19002752 33651298%
/build

I did run "hammer2 cleanup" before, as I got a lot of these errors on
the console:

hammer2_alloc_indirect: error 0020 No Space on Device
xop_strategy_write: error 32 loff=0061

Before running hammer2 cleanup, I checked disk usage with "df",
and it showed me 97% capacity, so I was very confused why these
messages occured.

Is it a feature to show less free capacity when logged in as
unpriviledged user?

Regards,

  Michael

Re: The future of HAMMER1

[Michael Neumann]

HAMMER1 was rock- solid from the early beginning (it took much less than 10 years).  HAMMER2 is a completely different architecture, AFAICT on-media it is much simpler. But a lot of the complexity lies in the multi-master operation. I still run HAMMER1 on my server. I love "mirror-stream" for backups. That's the only thing I really miss from HAMMER2. But if I would setup a new server I would probably use HAMMER2.Regards,Michael

Re: Statically linking libexecinfo

[Michael Neumann]

On Mon, May 14, 2018 at 08:31:58AM -0500, John Marino wrote:
> On 5/14/2018 08:30, Michael Neumann wrote:
> > On Mon, May 14, 2018 at 08:24:06AM -0500, John Marino wrote:
> >> On 5/14/2018 08:17, Michael Neumann wrote:
> >>> Hi,
> >>>
> >>> While trying to port "rust" to Ravenports, I noticed that Ravenports
> >>> uses libexecinfo.so.2 (from "ravenports"), whereas the base DragonFly
> >>> system uses libexecinfo.so.1 from /usr/src.  Because of that, the
> >>> bootstrapped rust compiler failed to run under Ravenports :(
> >>>
> >>> My solution was to add a -fPIC to the Makefiles of /usr/src/lib/libelf
> >>> and /usr/src/lib/libexecinfo, and statically link the dependent shared
> >>> object against it.
> >>>
> >>> My question is, can we ship with something like libexecinfo_pic.a?
> >>>
> >>> Regards,
> >>>
> >>>   Michael
> >>>
> >>
> >> we could always add libexecinfo.so.2 to the dragonfly build environment.
> >>   That shouldn't disrupt anything.
> >
> > libexecinfo.so.2 is already in the Ravenports build environment,
> > installed by some dependent port required to build rust (I think
> > llvm60). What is missing is libexecinfo.so.1, as the bootstrap rust
> > compiler needs that for execution.
> >
> 
> I mispoke.  I mean add libexecinfo.so.1 from dragonfly to the dragonfly 
> build environment as a system library.

That would work!

Regards,

  Michael

Re: Statically linking libexecinfo

[Michael Neumann]

On Mon, May 14, 2018 at 08:24:06AM -0500, John Marino wrote:
> On 5/14/2018 08:17, Michael Neumann wrote:
> > Hi,
> >
> > While trying to port "rust" to Ravenports, I noticed that Ravenports
> > uses libexecinfo.so.2 (from "ravenports"), whereas the base DragonFly
> > system uses libexecinfo.so.1 from /usr/src.  Because of that, the
> > bootstrapped rust compiler failed to run under Ravenports :(
> >
> > My solution was to add a -fPIC to the Makefiles of /usr/src/lib/libelf
> > and /usr/src/lib/libexecinfo, and statically link the dependent shared
> > object against it.
> >
> > My question is, can we ship with something like libexecinfo_pic.a?
> >
> > Regards,
> >
> >   Michael
> >
> 
> we could always add libexecinfo.so.2 to the dragonfly build environment. 
>   That shouldn't disrupt anything.

libexecinfo.so.2 is already in the Ravenports build environment,
installed by some dependent port required to build rust (I think
llvm60). What is missing is libexecinfo.so.1, as the bootstrap rust
compiler needs that for execution.

Regards,

  Michael

Statically linking libexecinfo

[Michael Neumann]

Hi,

While trying to port "rust" to Ravenports, I noticed that Ravenports
uses libexecinfo.so.2 (from "ravenports"), whereas the base DragonFly
system uses libexecinfo.so.1 from /usr/src.  Because of that, the
bootstrapped rust compiler failed to run under Ravenports :(

My solution was to add a -fPIC to the Makefiles of /usr/src/lib/libelf
and /usr/src/lib/libexecinfo, and statically link the dependent shared
object against it.

My question is, can we ship with something like libexecinfo_pic.a?

Regards,

  Michael

Re: mirror-copy not working

[Michael Neumann]

On Tue, Jan 16, 2018 at 09:48:57PM +0100, Konrad wrote:
> > You are doing nothing wrong here! Hm, looks to me as if data corruption
> > is happening while the data is being transfered from one machine to the
> > other. Does this happen every time you run mirror-copy? You could test
> > to run mirror-copy locally first (hammer mirror-copy /pfs/hg
> > /pfs/test-hg), but in case your filesystem is pretty large this is
> > something you might not want to do.
> 
> A local copy worked perfectly. 
> 
> K. 

Sorry for my late response.

Do both systems run recent versions of DragonFly? We had a change back
in 2010 [1] that would fail between two 64-bit machines. But I strongly
doubt this is the reason. Well then maybe your network is unreliable? 

Another thing you could test is to do a fresh mirror-copy, i.e.

   hammer mirror-copy /pfs/hg remotemachine@/pfs/new-hg

where /pfs/new-hg on remotemachine does not exist. If this works, it's
no network related problem.

Regards,

  Michael

[1]: 
https://gitweb.dragonflybsd.org/dragonfly.git/commit/c7380858c7d940d981d93b5e17984bc652a3cb5c

Re: mirror-copy not working

[Michael Neumann]

On Mon, Jan 15, 2018 at 10:28:18AM +0100, Konrad wrote:
> Dear reader, 
> 
> I???m running into a problem setting up hammer mirroring that I don???t 
> understand. I???ve set up two filesystems, master on one machine and slave on 
> another. To my understanding, that setup looks good: 
> 
> zoii# hammer pfs-status /pfs/hg
> /pfs/hg PFS#1 {
>sync-beg-tid=0x0001
>sync-end-tid=0x00010e046740
>shared-uuid=7229d076-f45c-11e7-b4cb-010c29f043b1
>unique-uuid=7229d083-f45c-11e7-b4cb-010c29f043b1
>label=""
>prune-min=00:00:00
>operating as a MASTER
>snapshots directory defaults to /var/hammer/
> }
> 
> # hammer pfs-status zoii-hg
> zoii-hg   PFS#8 {
>sync-beg-tid=0x0001
>sync-end-tid=0x0001
>shared-uuid=7229d076-f45c-11e7-b4cb-010c29f043b1
>unique-uuid=4737dd98-f9d2-11e7-b3fd-3da82a9fd340
>label=""
>prune-min=00:00:00
>operating as a SLAVE
>snapshots directory defaults to /var/hammer/
> }
> 
> ssh communications work well, I???ve also checked that. But:
> 
> zoii# hammer mirror-copy /pfs/hg root@192.168.11.11:/pfs/zoii-hg
> Prescan to break up bulk transfer
> Prescan 2 chunks, total 4646 MBytes (4818387768, 53692688)
> hammer: Mirror-write /pfs/zoii-hg fatal error 22
> 
> The only other thing I can find is (on the machine with the slave filesystem)
> 
> Jan 15 09:59:27 df1 kernel: hammer_create_at_cursor: CRC DATA @ 
> 90da3c8d16f0/128 MISMATCH ON PIPE

You are doing nothing wrong here! Hm, looks to me as if data corruption
is happening while the data is being transfered from one machine to the
other. Does this happen every time you run mirror-copy? You could test
to run mirror-copy locally first (hammer mirror-copy /pfs/hg
/pfs/test-hg), but in case your filesystem is pretty large this is
something you might not want to do.

Regards,

  Michael

Re: HAMMER2 stability

[Michael Neumann]

On 10/23/17 10:58, karu.pruun wrote:

Hello

Good to hear you got DragonFly running. I suppose it was HAMMER2 that
caused problems, not HAMMER---the latter is stable.

Apart from HAMMER2, could you possibly tell more about what are you
missing (list or privately)? This may help improve things in the
future.


One thing I always wanted to have again is a revival of the GUI iso
image. It would be ideal to test newly bought hardware like laptops 
without the need to install it permanently on disk (I feel uneasy to 
return that piece of hardware in case I have installed sth. on disk).


Regards,

  Michael


Cheers

Peeter

--



On Mon, Oct 23, 2017 at 11:02 AM, Pedro Andres Aranda Gutierrez
<paag...@gmail.com> wrote:

Hi folks,

After I got DFly running on my old Optimus laptop, I got an exception from
the hammer module and wasn't able to recover it. I gave  FreeBSD 11.1 a try
and have almost everything I need running much more out of the box than with
DFly. You are getting better and I will put my notes on getting it running
on Optimus in the WIKI, but it's not yet where I need it to be.

Sorry, /PA

El 23 oct. 2017 1:59, "Antonio Olivares" <olivares14...@gmail.com> escribió:




On Sunday, October 22, 2017, Carsten Mattner <carstenmatt...@gmail.com>
wrote:


Is HAMMER2 considered experimental and not for production data?



That is what the 5.0 release page states:

  https://www.dragonflybsd.org/release50/


Do we have debug_fs file restoration tools, in case things goes south?



This is being worked on.  A new iso with the restoration tools is in the
works, I have to find out where I read this to point it out.

Best Regards,


Antonio





--
NTECS Consulting
www.ntecs.de
Michael Neumann
+49 (0) 178 167 0649
mneum...@ntecs.de

Re: mirror- stream different drive size

[Michael Neumann]

On 10/20/17 14:43, Predrag Punosevac wrote:

Michael Neumann <mneum...@ntecs.de> wrote:


No. HAMMER1 mirroring works on the logical level, the physical drive
size is not important. You can think of it as if you would replay the
SQL statements in a database vs block level replication. With HAMMER1
mirroring you end up with two physically distinct filesystems with
identical content (where it matters).
mirror-stream is damn cool. I once did a live presentation of it at my
university, where I were replicating a PFS of my box from the data
center via WiFi to this tiny little Asus EEEpc. Students could upload
to my remote box and the name would pop up on my laptop via OSD once
the file was replicated to my laptop. It became funny as people started
to chat with me via OSD during my presentation by constructing file
names and uploading them ;).
Regards,
Michael


One would think that a person with as many years of schooling as I have
knows at least how to use Internet search engine. These slides from your
HAMMER talk

https://www.ntecs.de/talks/HAMMER.pdf

are pure gem. Thank you so much for your e-mail and clarifications


You found it! :). You are welcome!

To clarify slide 4: You can either start "hammer mirror-stream" from the 
masterhost OR from the slavehost. You don't need both.



Regards,

  Michael

Re: mirror- stream different drive size

[Michael Neumann]

No. HAMMER1 mirroring works on the logical level, the physical drive size is not important. You can think of it as if you would replay the SQL statements in a database vs block level replication. With HAMMER1 mirroring you end up with two physically distinct filesystems with identical content (where it matters).mirror-stream is damn cool. I once did a live presentation of it at my university, where I were replicating a PFS of my box from the data center via WiFi to this tiny little Asus EEEpc. Students could upload to my remote box and the name would pop up on my laptop via OSD once the file was replicated to my laptop. It became funny as people started to chat with me via OSD during my presentation by constructing file names and uploading them ;).Regards,Michael

Re: DragonFly 5.0 released!

[Michael Neumann]

On 10/17/17 15:09, Predrag Punosevac wrote:

Gerald Henriksen wrote:

On Mon, 16 Oct 2017 23:41:25 -0400, Predrag Punosevac wrote:


Only nVidia supports its own product with binary blob drivers. Somebody
have mentioned Nouveau driver in one of the posts. That is beating a
dead horse.


Nope.  Nouveau is alive and well.



Who cares? Why are we even talking about stupid proprietary NVidia crap
on DF mailing lists at the moment of release of the most advanced file
system on the face of the planet?


Exactly! Still, if I had a NVIDIA card I would love to use it with DFly.

Btw, would be great to have someone knowledgable write a short article 
about all the advantages of HAMMER2 vs. HAMMER1 and maybe the basics of 
using HAMMER2 (e.g. how to do snapshots, how to backup data to a slave

etc.). I know, HAMMER2 is considered experimental, still I think a lot
of people are soo curious and want to try it out, me included :)


Regards,

  Michael

Re: Lumina Desktop coming up blank screen

[Michael Neumann]

On 07/19/17 01:40, Bernard Mentink wrote:
> Hi Guys,
>
> I am just trying out Lumina Desktop and it launches, but just comes up
> blank screen, .. nothing else.
>
> My default xorg install worked fine, my Radeon card looks supported.
>
> I have launched Lumina by using slim ... i.e slim_enable="YES" in rc.conf
>
> Any idea's?

Please try "start-lumina-desktop" from shell, and Lumina should come up!

Regards,

  Michael

Re: State of Rust on DragonFly

[Michael Neumann]

On 06/29/17 21:18, Carsten Mattner wrote:
> On Thu, Jun 29, 2017 at 5:24 PM, Zachary Crownover
> <zachary.crowno...@gmail.com> wrote:
>> That won't happen unless we have an active maintainer for it with Rust that
>> can get the project to move DragonFly from tier 3 to at least tier 2. I'd
>> like to take an active role in that though.
> 
> Cool, and I'd like to encourage you.
> 
>> On Jun 29, 2017 9:55 AM, "Carsten Mattner" <carstenmatt...@gmail.com> wrote:
>>>
>>> On Wed, Jun 28, 2017 at 6:49 AM, Michael Neumann <mneum...@ntecs.de>
>>> wrote:
>>>> Hi,
>>>>
>>>> I am working on getting Rust 1.18.0 into the ports. There was an issue
>>>> with errors happening in parallel builds triggered by cargo (Rust's
>>>> package manager also used to build Rust itself). By disabling parallel
>>>> builds I were able to successfully bootstrap Rust 1.18.0 from 1.17.0.
>>>>
>>>> I need to produce dependency-free versions of cargo before I can work on
>>>> integrating everything into the ports tree.
>>>>
>>>> All scripts to bootstrap can be found on [1]. To build Rust 1.18.0, just
>>>> run "sh build-1.18.0.sh /working/directory/for/build". Because of the
>>>> version of cargo I am currently using, this might only work if you have
>>>> the same version of DragonFly (I am working on a statically linked
>>>> version of cargo).
>>>>
>>>> I will keep you updated on the progress. And sorry for the delay. I just
>>>> found the issue with cargo two days ago. This issue blocked all my
>>>> further efforts.
>>>
>>> Great work Michael!
>>>
>>> Please keep it up and ideally get it to the level of FreeBSD so
>>> that we can just use rustup to have all of the versions and
>>> toolchains and targets available. That would be a dream.

That's also my dream. Having continuous builds for DragonFly would be
great to detect breaks. It should be all that hard btw. We were able to
cross build rustc from Linux in the past. That's how it would work.

*State update* I opened up pull requests [1] and [2] to DeltaPorts.
Waiting for jrmarino to merge and/or further comments/change requests
:). So Rust and Cargo should soon be in dports again.

Scripts to build the bootstrap components can be found here [3].

Regards,

  Michael

[1]: https://github.com/DragonFlyBSD/DeltaPorts/pull/782
[2]: https://github.com/DragonFlyBSD/DeltaPorts/pull/783
[3]: https://github.com/mneumann/dragonfly-rust-bootstrap

State of Rust on DragonFly

[Michael Neumann]

Hi,

I am working on getting Rust 1.18.0 into the ports. There was an issue
with errors happening in parallel builds triggered by cargo (Rust's
package manager also used to build Rust itself). By disabling parallel
builds I were able to successfully bootstrap Rust 1.18.0 from 1.17.0.

I need to produce dependency-free versions of cargo before I can work on
integrating everything into the ports tree.

All scripts to bootstrap can be found on [1]. To build Rust 1.18.0, just
run "sh build-1.18.0.sh /working/directory/for/build". Because of the
version of cargo I am currently using, this might only work if you have
the same version of DragonFly (I am working on a statically linked
version of cargo).

I will keep you updated on the progress. And sorry for the delay. I just
found the issue with cargo two days ago. This issue blocked all my
further efforts.

Regards,

  Michael


[1]: https://github.com/mneumann/dragonfly-rust-bootstrap

Re: random freezes, xterm not displaying everything correctly what to do?

[Michael Neumann]

 HDMI-0 disconnected
> 
> [ 256.339] (II) RADEON(0): Output DVI-0 connected
> 
> [ 256.339] (II) RADEON(0): Using exact sizes for initial modes
> 
> [ 256.339] (II) RADEON(0): Output DVI-0 using initial mode 1024x768 +0+0
> 
> [ 256.339] (II) RADEON(0): Using default gamma of (1.0, 1.0, 1.0)
> unless otherwise stated.
> 
> [ 256.339] (II) RADEON(0): mem size init: gart size :3fbce000 vram
> size: s:4000 visible:3f886000
> 
> [ 256.339] (==) RADEON(0): DPI set to (96, 96)
> 
> [ 256.339] (II) Loading sub module "ramdac"
> 
> [ 256.339] (II) LoadModule: "ramdac"
> 
> [ 256.339] (II) Module "ramdac" already built-in
> 
> [ 256.339] (II) UnloadModule: "modesetting"
> 
> [ 256.339] (II) Unloading modesetting
> 
> [ 256.339] (II) UnloadModule: "vesa"
> 
> [ 256.339] (II) Unloading vesa
> 
> [ 256.339] (--) Depth 24 pixmap format is 32 bpp
> 
> [ 256.340] (II) RADEON(0): [DRI2] Setup complete
> 
> [ 256.340] (II) RADEON(0): [DRI2] DRI driver: radeonsi
> 
> [ 256.340] (II) RADEON(0): [DRI2] VDPAU driver: radeonsi
> 
> [ 256.340] (II) RADEON(0): Front buffer size: 3072K
> 
> [ 256.340] (II) RADEON(0): VRAM usage limit set to 933976K
> 
> [ 256.340] (II) RADEON(0): SYNC extension fences enabled
> 
> [ 256.340] (II) RADEON(0): Present extension enabled
> 
> [ 256.340] (II) RADEON(0): Can't initialize DRI3 because dri3.h not
> available at build time
> 
> [ 256.340] (WW) RADEON(0): DRI3 disabled
> 
> [ 256.340] (==) RADEON(0): Backing store enabled
> 
> [ 256.340] (II) RADEON(0): Direct rendering enabled
> 
> [ 256.481] (II) RADEON(0): Use GLAMOR acceleration.
> 
> [ 256.482] (II) RADEON(0): Acceleration enabled
> 
> [ 256.482] (==) RADEON(0): DPMS enabled
> 
> [ 256.482] (==) RADEON(0): Silken mouse enabled
> 
> [ 256.482] (II) RADEON(0): Set up textured video (glamor)
> 
> [ 256.482] (II) RADEON(0): [XvMC] Associated with GLAMOR Textured Video.
> 
> [ 256.482] (II) RADEON(0): [XvMC] Extension initialized.
> 
> [ 256.482] (II) RADEON(0): RandR 1.2 enabled, ignore the following
> RandR disabled message.
> 
> [ 256.482] (--) RandR disabled
> 
> [ 256.489] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
> 
> [ 256.489] (II) AIGLX: enabled GLX_ARB_create_context
> 
> [ 256.489] (II) AIGLX: enabled GLX_ARB_create_context_profile
> 
> [ 256.489] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile
> 
> [ 256.489] (II) AIGLX: enabled GLX_INTEL_swap_event
> 
> [ 256.489] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
> 
> [ 256.489] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB
> 
> [ 256.489] (II) AIGLX: enabled GLX_ARB_fbconfig_float
> 
> [ 256.489] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float
> 
> [ 256.489] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
> 
> [ 256.490] (II) AIGLX: Loaded and initialized radeonsi
> 
> [ 256.490] (II) GLX: Initialized DRI2 GL provider for screen 0
> 
> [ 256.490] (II) RADEON(0): Setting screen physical size to 270 x 203
> 
> [ 256.605] (II) config/devd: probing input devices...
> 
> [ 256.605] (II) config/devd: adding input device (null) (/dev/kbdmux)
> 
> [ 256.605] (II) LoadModule: "kbd"
> 
> [ 256.605] (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so
> 
> [ 256.605] (II) Module kbd: vendor="X.Org Foundation"
> 
> [ 256.605] compiled for 1.18.4, module version = 1.9.0
> 
> [ 256.605] Module class: X.Org XInput Driver
> 
> [ 256.605] ABI class: X.Org XInput driver, version 22.1
> 
> [ 256.605] (II) Using input driver 'kbd' for 'kbdmux'
> 
> [ 256.605] (**) kbdmux: always reports core events
> 
> [ 256.605] (**) kbdmux: always reports core events
> 
> [ 256.605] (**) Option "Protocol" "standard"
> 
> [ 256.605] (**) Option "XkbRules" "base"
> 
> [ 256.605] (**) Option "XkbModel" "pc105"
> 
> [ 256.605] (**) Option "XkbLayout" "us"
> 
> [ 256.605] (**) Option "config_info" "devd:kbdmux"
> 
> [ 256.606] (II) XINPUT: Adding extended input device "kbdmux" (type:
> KEYBOARD, id 6)
> 
> [ 256.933] (II) config/devd: kbdmux is enabled, ignoring device ukbd0
> 
> [ 256.933] (II) config/devd: kbdmux is enabled, ignoring device atkbd0
> 
> [ 256.934] (II) config/devd: adding input device (null) (/dev/sysmouse)
> 
> [ 256.934] (II) LoadModule: "mouse"
> 
> [ 256.934] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
> 
> [ 256.934] (II) Module mouse: vendor="X.Org Foundation"

Re: SSL CA cert issue

[Michael Neumann]

On 04/30/17 20:07, Tim Darby wrote:
> fetch works.

I am also having lots of problems after the upgrade, for example
chromium does not start anymore. Also firefox seems to hang from time to
time. I think libressl is at fault.

Regards,

  Michael

Re: lumina-DE from source

[Michael Neumann]

On 07/26/16 08:30, Francois Tigeot wrote:

On Mon, Jul 25, 2016 at 10:45:32AM -0700, jungle Boogie wrote:
>
> Issue on lumina's github:
> https://github.com/trueos/lumina/issues/238
>
> developer reporting that it looks like a graphics driver issue.

Your last picture on that bug report says "Server terminated successfully".

I had a similar issue some time ago, but I do not exactly remember what it was.
Out of memory, I have two ideas:

* pulseaudio: Deinstall it completely.
* Rename the ".lumina" folder to something else, so lumina-DE tries to create a 
new one.

Regards,

  Michael



This doesn't look like a graphics driver issue, it's more likely your
local X11 configuration is broken.

Can you paste the contents of your ~/.xinitrc file ?

Re: Does anybody care about mono on DF?

[Michael Neumann]

On 06/19/16 19:03, John Marino wrote:

Ever since the version of Mono in ports was upgraded to version 4.x,
it's been a bit of a nightmare for me.  It's extremely unstable when
it's host machine is under contention, such as we see in the pkgbox64
environment.

A log like this happened twice in two days:
http://pkgbox64.dragonflybsd.org/bulk/Release44-default/20160619_024658/logs/errors/mono-4.2.3.4.log


It's not just mono, but any port that is written in c-sharp (or whatever
Mono really is) crashes randomly with these sigaborts.

It's such a pain, I'm seriously considering removing Mono from the
dports tree, along with it's ~48 ports that depend on it.  If somebody
is using mono and/or cares about it, I suggest they "adopt" it and fix
it permanently.  Zrj has spent a lot of time on it as well.

I suspect that nobody is using it and nobody will miss it if we go with
the nuclear option, but I'm posting this just in case that assumption is
wrong.


Well, I installed it recently out of curiosity. It worked pretty well 
for small GUI apps, but I don't really need it and I don't want to 
invest energy myself. Of course, it would be great if someone would 
maintain it.


Regards,

  Michael

Re: PFS in HAMMER1

[Michael Neumann]

On 06/17/16 14:15, Tomohiro Kusumi wrote:

Technically speaking, we could change the format of "@@-1:1" to
"@@-1something1" without breaking userspace unless userspace use
raw PFS name "@@-1:1" for some reasons.


that would be great. maybe something else than the "empty word" would be 
better.



In the previous post, I intentionally used raw PFS name, but users or
userspace programs basically never directly use this format, so it
really doesn't matter if the separator is ":" or something else as
long as there is something between.

In other words, when we have

# ls -l /pfs/var.tmp
lrwxr-xr-x  1 root  wheel  10 Aug 26  2015 /pfs/var.tmp -> @@-1:6
# grep "/var/tmp" /etc/fstab
/pfs/var.tmp/var/tmpnullrw  0   0

users would do

# cd /pfs/var.tmp
or
# cd /var/tmp

but users most likely never do

# cd /pfs/@@-1:6
or
# cd /@@-1:6
or
# cd /var/tmp/@@-1:6
or
# cd /pfs/@@-1:6/@@-1:6/@@-1:6/@@-1:6
or
# cd /@@-1:1/@@-1:2/@@-1:3/@@-1:4/@@-1:5/@@-1:6

which are all the same.


it's correct that users wouldn't do that directly, but the sysctl 
KERN_PROC_PATHNAME returns such a path which is used by programs like 
rust. they assume that paths can be separated by ":" and as such are not 
allowed to themselves contain a ":".


the current solution is to patch rust is a very ugly way, by hardcoding 
the path "/usr/local/bin/rust" to avoid the sysctl (or reading from 
/proc filesystem). this clearly is not a good solution.


Regards,

  Michael




2016-06-17 0:28 GMT+09:00 Michael Neumann <mneum...@ntecs.de>:



On 06/16/16 02:26, Tomohiro Kusumi wrote:


There was discussion about @@ in PFS path on irc channel a few days
ago. This post has nothing to do with it, but explains what that @@
really means. This is very tricky, so most users probably had
difficult time understanding what this @@ means.



This is a bit off-topic, but related to the PFS naming. Having ":" in the
path causes a lot of trouble. Dunno if this issue has been brought up by
jmarino. One such situation is the sysctl KERN_PROC_PATHNAME, e.g. used by
rust to find the path of the executable. The problem arises when this is
used in a PATH variable, as ":" is used there as a separator as well. The
alternative is using /proc/curproc/cmdline, but this requires a mounted
/proc filesystem which causes problems with the synth builder.

Regards,

  Michael

Re: PFS in HAMMER1

[Michael Neumann]

On 06/16/16 02:26, Tomohiro Kusumi wrote:

There was discussion about @@ in PFS path on irc channel a few days
ago. This post has nothing to do with it, but explains what that @@
really means. This is very tricky, so most users probably had
difficult time understanding what this @@ means.


This is a bit off-topic, but related to the PFS naming. Having ":" in 
the path causes a lot of trouble. Dunno if this issue has been brought 
up by jmarino. One such situation is the sysctl KERN_PROC_PATHNAME, e.g. 
used by rust to find the path of the executable. The problem arises when 
this is used in a PATH variable, as ":" is used there as a separator as 
well. The alternative is using /proc/curproc/cmdline, but this requires 
a mounted /proc filesystem which causes problems with the synth builder.


Regards,

  Michael

Re: Random server crashes every few weeks (smp_invltlb: endless loop […] retrysmp_invltlb: ipi sent)

[Michael Neumann]

I am running DragonFly on linux-kvm with virtio-blk for years, and I've 
only seen rarely issues (maybe 1-2 times a year there is a crash). I 
will give it a try once I update the machine.


Regards,

  Michael

On 05/28/16 02:23, Matthew Dillon wrote:

Ok, Zachary noted that ivadasz had a patch.  Imre and I went over it on
IRC and he committed the patch to master.  I also committed some
additional changes so it would be great if anyone using master + virtio
in a virtual-hosted environment can [re]test the changes.

There are likely going to be numerous other issues with virtual hosting
not yet addressed.

-Matt

On Fri, May 27, 2016 at 10:08 AM, Matthew Dillon > wrote:

Virtio (for block storage devices) could be the cause.  There are
known bugs in the DragonFly driver for virtio which haven't been
tracked down yet (not enough of the devs are using virtual hosting
to be able to reproduce the problem in a debugable way).

-Matt

On Fri, May 27, 2016 at 7:39 AM, Steve Petrie, P.Eng.
> wrote:

Greetings To DragonFlyBSD List,

The subject of random server crashes with DragonFly running
running on a virtualized host machine, is of great interest (and
concern) to me. Caveat: I am an (almost) complete DragonFly newbie.

Please see my commens inline below.

Steve

- Original Message - From: "Stefan Unterweger"
<232.20...@chiffre.aleturo.com
>
To: "Matthew Dillon" >
Cc: >
Sent: Friday, May 27, 2016 3:38 AM
Subject: Re: Random server crashes every few weeks (smp_invltlb:
endless loop […] retrysmp_invltlb: ipi sent)



* Matthew Dillon on Thu, May 26, 2016 at 11:00:18AM -0700:

It's really hard to say from something which is
virtually hosted.  It kinda
sounds like the virtual host isn't assigning enough of
its own cpus to the
virtual host.  The fact that DragonFly is complaining
about smp_invltlb()
implies that the host's virtualized cpu threads are not
getting scheduled
properly.

One thing to note is that we do not do any instruction
escapes to hint to
virtual hosts when a cpu is in a tight loop waiting for
synchronization.
It would be nice if we had some support for that, it
would probably make
DFly play better on virtualized systems.


This is an interesting suggestion, which at least would
explain at least
some of the cases where I’ve experienced the crashes (the
daily HAMMER
cronjob, heavy paging under stress, I/O bursts and so on).

So in effect, could it be that the crashes are more likely
as either my
own server comes under load or some -other- server who
happens to run in
the same hypervisor?

Would this warrant opening a ticket with Profitbricks, or is
it just as
likely that I’m wasting my time and will only get a response
along the
lines of ‘Use Linux; Dragonfly BSD most certainly is not
supported’?

I suggest setting the number of cores to 1.  That will
get rid of all SMP
interplay and hopefully remove the issues the virtual
host is choking on.


Interestingly enough, I have seen the opposite so far.  At
first, I have
run the server on only one core, to save money and because
it doesn’t
really yet need any more.  When on one core, it still
freezes, along
approximately the same pattern, but I never got a trace there.

My guess then was that perhaps there would have been some
odd race
condition between paging, HAMMER and dm_crypt—adding another
core
temporarily seemed more stable and then regressed back to
the mean.

I will try to set up another VM to see whether I can
reliably reproduce
such a crash.


After a great deal of research, I chose DragonFly as the OS for
a new website (not yet online). Three main attributes drew me to
DragonFly: 1. reputation for reliability and speed, 2. hammer
file system, 3. responsiveness of DragonFly open source community.

However, my business plan for this new website (not yet online),
requires starting out hosting it on a VM 

Re: DFly versus PC-BSD on a Laptop

[Michael Neumann]

On 05/25/16 05:08, Justin Sherrill wrote:

On Tue, May 24, 2016 at 6:01 PM, Bernard Mentink  wrote:


Currently I am running PC-BSD on a Sony Vaio Laptop with Gnome desktop and
it runs quite well.
I was wondering about re-installing DFly on it instead. Can anyone tell me
if I am going to get performance increase(i.e better kernel) and faster file
system with Hammer versus ZFS?

I need to have lot's of incentive to make the move ;)


It'll be fast.  Really fast.  SUPER FAST.  The kernel will have so
many megaflops that the chassis of your laptop will actually start to
vibrate and rise above the surface of your desk, quietly humming.
It'll hover there, causing pens and small children to rattle in the
vicinity, until you reach out with a wondering hand and try to open
the DVD-ROM cause you left your favorite Chet Faker CD in there and
you don't want anything bad to happen to it and then BOOM.


Could we add this answer to the DragonFly FAQ??? It's so funny to read :)

Regards,

   Michael


The mere act of brushing against it will upset the careful equilibrium
set by Hammer's rebalancing mechanism, and the raw power unleashed
will cause your laptop to shoot off through the wall of your home,
through the nice fence your neighbor put up last year, and right
through some branches on that odd tree that always takes forever to
pop out leaves each spring, making you suspect it might not be that
healthy but it's not on your property so you can't do much about it.

Your laptop, shooting through space by now, leaves a sort of green
trailing afterimage that persists for several minutes and happens to
match the green in the DragonFly logo *exactly*.

I realize this is a nonsense answer, and hope that you do too.
However, there's no way to tell from what you wrote what model
computer you have, what "speed" it's running at now, what you actually
do with this computer, or if you can configure xorg and a number of
other programs yourself, since PC-BSD does that for you and DragonFly
does not.

Don't take the above items as questions that I want you to answer so
that I can then evaluate your future computer use for you.  Download a
DragonFly image and start it up - it's 'live' and you can try it out,
though it will be somewhat limited.

Re: deleting files when no disk space is available

[Michael Neumann]

On 04/09/16 18:08, Tomohiro Kusumi wrote:

If you're using hammer, rm file isn't deleting anything from your
filesystem capacity.

But aside from the fact rm isn't deleting anything, I think there is a
bug in ENOSPC handling.
I've once saw kernel panic soon after hitting ENOSPC.


2016-04-09 22:16 GMT+09:00 Christoph Harder :

Hello,

I do have a small problem, I've written a program that filled all available
disk space (I know not very smart...).
Well now I have a few SQLite database files that I can't get rid of.

When executing "rm *" or just calling "rm a.9.db" for a single file I do get
the error message "rm: a.9.db: No space left on device".
I suspect there is some space required to undo the delete which might
require extra space.


"hammer cleanup" or hammer prune[-everything] will help.

Regards,

  Michael

Re: getting cpu info w/o parsing /var/run/dmesg.boot

[Michael Neumann]

On 10/09/15 12:38, Hleb Valoshka wrote:

Hi all.

I want to get info about cpu without parsing /var/run/dmesg.boot, is
it possible?

I'm porting ohai (https://github.com/chef/ohai/pull/626/files#r41601905).


You can use sysctl to extract information, e.g.:

sysctl hw.cpu_topology.tree
hw.cpu_topology.tree:
\-PACKAGE MEMBERS: cpus(0-7)
  \-CHIP ID 0: cpus(0-7)
|-CORE ID 0: cpus(0, 4)
| |-THREAD ID 0: cpus(0)
| \-THREAD ID 1: cpus(4)
|-CORE ID 1: cpus(1, 5)
| |-THREAD ID 0: cpus(1)
| \-THREAD ID 1: cpus(5)
|-CORE ID 2: cpus(2, 6)
| |-THREAD ID 0: cpus(2)
| \-THREAD ID 1: cpus(6)
\-CORE ID 3: cpus(3, 7)
  |-THREAD ID 0: cpus(3)
  \-THREAD ID 1: cpus(7)

What information you are looking for exactly?

Regards,

  Michael

Re: Issues with node.js

[Michael Neumann]

Am 30.07.2015 um 09:27 schrieb Robin Hahling:

On 29-07-2015 01:38, Marco Righele wrote:

Greetings,

is anybody using node.js with DragonFlyBSD ?
I have a strange issue when I spawn it from another instance of node.js.

(...)

Hi,

Node deserves some love in order to work properly on DragonFly. To be
more specific, libuv, which is required by node, needs DragonFly
specific fixes.
I started working on it several months ago but ceased due to other
priorities and not desperately needing it. There is a whole test
suite included with libuv. If you run it on DragonFly, you will notice
that many tests fail. This is probably a good place to start hacking. ;)

Cheers,
Robin Hahling


I've pushed some fixes upstream for libuv.

https://github.com/mneumann/libuv/commit/48447019aeeea66f1f6b1ad966ad99c18bff889c
https://github.com/mneumann/libuv/commit/ec2f4ccef8b553588149045cecf0e27118a72812
https://github.com/mneumann/libuv/commit/3fd16a09d31b785efa9f3bdfdcdf218d263471ae
https://github.com/mneumann/libuv/commit/49e19702d861c780c27e6c5fe219c7b04fee3a97

Except the last, they are already in libuv/libuv branch v1.x. But still, 
there are many tests that fail.


Npm works on my machine, but I would not use node.js in production :).
I am only using some Javscript tool chain (postcss, babel etc.), which 
works very well, but

as soon as you try to fork some processes, node.js fails.

Regards,

  Michael

Re: Storing hundreds of millions of files in HAMMER (1 or 2)

[Michael Neumann]

Am 15.07.2015 um 18:53 schrieb Matthew Dillon:
You should use a database, frankly.   A HAMMER1 inode is 128 bytes and 
for small files I think the data will run on 16-byte boundaries.  Not 
sure of that.  Be sure to mount with 'noatime', and also use the 
double buffer option because the kernel generally can't cache that 
many tiny files itself.


The main issue with using millions of tiny files is that each one 
imposes a great deal of *ram* overhead for caching, since each one 
needs an in-memory vnode, in-memory inode, and all related file 
tracking infrastructure.


Secondarily, hammer's I/O optimizations are designed for large files, 
not small files, so the I/O is going to be a lot more random.


Thanks for the insight. I take a database :). It's a pitty that none of 
the databases out there support HAMMER-like queue-less streaming out of 
the box.

I wish you would have finished backplane database :).

Regards,

  Michael



-Matt

On Wed, Jul 15, 2015 at 8:58 AM, Michael Neumann mneum...@ntecs.de 
mailto:mneum...@ntecs.de wrote:


Hi,

Lets say I want to store 100 million small files (each one about
1k in size) in a HAMMER file system.
Files are only written once, then kept unmodified and accessed
randomly (older files will be access less often).
It is basically a simple file based key/value store, but
accessible by multiple processes.

a) What is the overhead in size for HAMMER1? For HAMMER2 I expect
each file to take exactly 1k when the file
is below 512 bytes.

b) Can I store all files in one huge directory? Or is it better to
fan out the files into several sub-directories?

c) What other issues I should expect to run into? For sure I
should enable swapcache :)

I probably should use a real database like LMDB, but I like the
versatility of files.

Regards,

  Michael

Storing hundreds of millions of files in HAMMER (1 or 2)

[Michael Neumann]

Hi,

Lets say I want to store 100 million small files (each one about 1k in 
size) in a HAMMER file system.
Files are only written once, then kept unmodified and accessed randomly 
(older files will be access less often).
It is basically a simple file based key/value store, but accessible by 
multiple processes.


a) What is the overhead in size for HAMMER1? For HAMMER2 I expect each 
file to take exactly 1k when the file

is below 512 bytes.

b) Can I store all files in one huge directory? Or is it better to fan 
out the files into several sub-directories?


c) What other issues I should expect to run into? For sure I should 
enable swapcache :)


I probably should use a real database like LMDB, but I like the 
versatility of files.


Regards,

  Michael

Re: Questions about current stable version of dragonflybsd regarding drivers and desktop environment

[Michael Neumann]

Am 03.07.2015 um 08:26 schrieb John Marino:

On 7/3/2015 8:17 AM, Bret Busby wrote:

Hello.
Please also advise whether GNOME 2 is available for the current stable version
of dragonflybsd.


I can answer this question.
There is no GNOME 2 in ports.  FreeBSD doesn't have it either.

There is mate and cinnamon which is a continuation of GNOME 2.  They
build but I'm not sure how well they work.  I would suspect they have
issues.  However, nobody seems to uses these so the issues aren't
getting reported or fixed.

DragonFly for the most part has the same window managers / desktops that
FreeBSD does.


I am using xfce4, which is a very slim and cleaned up desktop.
It works great on DragonFly. It's easy to start from command-line
with startxfce4 without the need of a login manager.

Regards,

  Michael

Re: Intel Sandybridge graphics support?

[Michael Neumann]

Am 20.02.2015 um 10:10 schrieb Baurzhan Muftakhidinov:

On Fri, Feb 20, 2015 at 11:25 AM, Baurzhan Muftakhidinov
baurthefi...@gmail.com wrote:

On Fri, Feb 20, 2015 at 11:14 AM, Robin Hahling
robin.hahl...@gw-computing.net wrote:

On Friday 20 February 2015 09.30:44 Baurzhan Muftakhidinov wrote:

Hi,

I tried both 4.0.3 and most recent snapshot (17 feb), but,
unfortunately, cannot get to a desktop, after
starting X I only see black-ish screen. Even
not possible to kill X session with Ctrl-Alt-Backspace.
The CPU is Intel Core i5 2520M (laptop).

Any suggestion?

Thanks,

Hi,

This sandy bridge CPU has an Intel HD3000 graphics processor, which is
actually the same that I have in my laptop (Intel Core i7 2620M).

It shall be well supported both in 4.0.3 and master so you might have missed a
step or something. Is xf86-video-intel29 installed (it's a more recent version
than xf86-video-intel) ? What is the content of your ~/.xinitrc? Are you sure
there is no mistake there?

I suppose this is what I am missing - xf86-video-intel29. Didn't know it exists,
will try and report back,


Personally, I don't even have a xorg.conf file since it is not required. It
shall really work out of the box.

Cheers,
Robin

Thanks,

Nope, that wasn't the case, I had xf86-video-intel version 29 already installed.
I have neither xorg.conf nor ~/.xinitrc files.


Install xfce (pkg install xfce), then run startxfce4. Then you don't 
need to edit your xinitrc files :)


Regards,

  Michael

Re: git: sshlockout - use a PF table instead of IPFW

[Michael Neumann]

Am 18.01.2015 um 12:31 schrieb bycn82:

/Hi,/
/
/
/I just implemented a feature which can work nicely with your sshlockout. /
/You can manually insert a state as below and the state will be maintain
by ipfw itself./
/
/
/ipfw state add rulenum 100 udp 192.168.1.1:0 http://192.168.1.1:0
8.8.8.8:53 http://8.8.8.8:53 expiry +600/
/
/
/so you dont need to implement the logic to maintain the IP addresses or
configure any crontab to remove../


Cool!

I think I will extend sshlockout so that it runs arbitrary commands.

At the moment you run:

sshlockout lockout

which would then be equal to:

sshlockout pfctl -tlockout -Tadd %s

So it will works with ipfw:

sshlockout ipfw state add rulenum 100 udp 192.168.1.1:0 %s:53 
expiry +600


What do you think?

Regards,

  Michael



/
/
/different state can have different expiry or life time./
/
/
/any comment?/
/
/

/Regards,/
/Bill Yuan/

On 14 January 2015 at 02:25, Michael Neumann
mneum...@crater.dragonflybsd.org
mailto:mneum...@crater.dragonflybsd.org wrote:


commit ed17c1722f7702eb6422f73152c0091819a1900f
Author: Michael Neumann mneum...@ntecs.de mailto:mneum...@ntecs.de
Date:   Tue Jan 13 13:04:29 2015 +0100

 sshlockout - use a PF table instead of IPFW

Summary of changes:
  usr.sbin/sshlockout/sshlockout.8 | 27 +++---
  usr.sbin/sshlockout/sshlockout.c | 59
+++-
  2 files changed, 57 insertions(+), 29 deletions(-)


http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/ed17c1722f7702eb6422f73152c0091819a1900f


--
DragonFly BSD source repository

Re: Using swapcache to speed up external disk writes?

[Michael Neumann]

Am 17.12.2014 um 03:52 schrieb Justin Sherrill:
 Short answer: yes, set up swapcache on the SSD and you'll benefit.
 That's the goal of swapcache.  See the swapcache man page for a guide
 on how large to make your partition, and use the rest for / or however
 you want to arrange it.

But keep in mind swapcache does not work as a write-cache. It's only
caching reads.

USB 2.0 sets a limit which is higher than the 20 MB/sec you get, so I
assume it's your disk that is not the fastest (which I guess is quite
common for USB disks). I doubt you get more out of that disk on any
other operating system.

FreeBSD/ZFS has something called ZFS Intent Log, which does write
caching. But I doubt you want to use it on your laptop as in general ZFS
is a bit more hungry in terms of resources.

I'd suggest you to buy a good/fast harddisk and attach it via eSATA or 
USB 3.0
(is it supported by DragonFly / your laptop?). Fast disks usually are 
powered

by an external power supply and not via the USB power (things might have
changed during the years). Swapcache can then help you to improve read
performance, which also helps write performance as it takes off read 
load from
the disk. A good harddisk should be able to give your 100 MB/sec of 
sequential
writes, but for random reads the performance is abysmal, this is where 
the SSD

shines.

Regards,

  Michael

[ANN] Rust ported to DragonFlyBSD

[Michael Neumann]

Hi all,

I am happy to announce that I succeeded in porting Rust to the DragonFly
operating system. [This article][1] describes `how` and might also be of
interest to others porting Rust to NetBSD or OpenBSD. Within the next
week I submit patches to the LLVM project (segmented stack support for
DragonFly) and also to the rust repo itself. My `dragonfly` branch of
the Rust repository can be found [here][2].

If someone is interested to try out early, I can provide some binaries
until I set up some automatic builds.

Regards,

  Michael

[1]: http://www.ntecs.de/blog/2014/07/29/rust-ported-to-dragonflybsd/
[2]: https://github.com/mneumann/rust/tree/dragonfly

Re: [ANN] Rust ported to DragonFlyBSD

[Michael Neumann]

Am 29.07.2014 um 15:07 schrieb Markus Pfeiffer:

Hi Michael,

great work, and thanks for doing this!

*goes off to prod around rust*

Markus


You are welcome :)

Re: Using github for issues/collaboration

[Michael Neumann]

Am 14.02.2014 08:32, schrieb Matthew Dillon:
  I feel quite strongly that we should host the issues system 
ourselves.

  One huge disadvantage of using distributed services is that large
  pieces of the project can get lost over time as these services 
change
  or the project evolves, is merged with some other, or otherwise 
retired.
  So for posterity, I really want us to host the major project 
scaffolding

  ourselves.

I agree with you that it's better to not depend on external services for
the reasons you mention.

While for the core developers using something like Github wouldn't make
a big difference, the situation for students who want to hack on
DragonFly would be improved as they can send pull requests and anyone
can review and comment on the changes, even on certain lines of the
patches.  I think this is quite important and also for the GSoC mentors
this would be a big win. Right now these discussions might take place on
IRC, maybe to a lesser degree on the mailing list or via private mail,
but most information gets lost or is intransparent for others.  With
GitHub (or something like that) this would be much more transparent.

Regards,

  Michael

Re: Using github for issues/collaboration

[Michael Neumann]

Am 17.02.2014 20:31, schrieb Carsten Mattner:
 On Thu, Feb 13, 2014 at 5:06 PM, John Marino dragonfly...@marino.st 
wrote:

 On 2/13/2014 15:48, Michael Neumann wrote:


 Am 13.02.2014 15:26, schrieb Antonio Huete Jimenez:
 Hi Michael,

 Honestly I don't see any compelling reasons in your email for us to
 switch to Github. But I'd be interested in knowing what are those
 collaboration barriers you see in Redmine.

 Hm, the visual experience on github is IMHO the main aspect for me. 
 And

 it's simplicity. You can use markup language to format the issue.

 Unfortunately it's too simple.
 The inability to add an attachment is a non-starter.
 And frankly, the markdown by default causes a lot of problems.
 Everytime somebody pastes in a script with # as comments, and don't
 know to set it as a block of code, it turns into gigantic headlines.
 Just a PITA.

 *IF* there was good attachment system and if markdown was opt-in, 
then

 maybe there would be a discussion.

 Btw, DPorts issues are handled at GitHub.

 John

 Also Markdown is broken and has many issues. Wikicreole or
 Restructured text are options that don't make you face syntax
 issues or deficiencies. I'm sorry but not everything Github does
 is right. For example they're making ui changes but not upgrading
 their openssh version to a modern one.

Just out of curiosity, what exactly is broken in Markdown? It's working
quite well for me. I think for simple bug reports, discussions or blog
articles Markdown is good enough. You might not be possible to write
your thesis in which you probably can with Restructured. Restructured
text is nice, but IIRC it is only implemented for Python and it's a huge
spec and also pretty hard to parse. For the rest of the world, Markdown
is pretty much the defacto standard.

Regards,

  Michael

Using github for issues/collaboration

[Michael Neumann]

Hi,

What do the developers think about using github for collaboration on the 
DragonFly project?
I don't want to step on anyone's foots, but personally I prefer it over 
redmine.
For me it lowers the barrier of collaboration and communication 
significantly.
For example GSoC projects could be suggested on the issues system and 
people can comment on it

much more easily as it is right now possible in our Wiki.

I understand that having the issues system under our control has some 
advantages. But
github is a very open system, so all data can be easily retrieved by an 
API (to backup etc).


All I can say is that other open-source projects use it with great 
success (for example mozilla/rust),
and I'd like to make it easier for users to submit bug reports or to 
collaborate on ideas.


If there is general consensus that this is a good idea, I'd volunteer to 
migrate the issues from redmine to
a test repository on github, so that people can see how it would look 
like.  I think one functionality that we'd loose
is the ability to answer issues via the bugs@dragonfly mailing list. But 
replying to an issue sent via github would

of course work.

Regards,

  Michael