Re: When will be created a great desktop experience for OpenBSD?
> user-friendly and easy-to-use > Sounds like the exact description of current OpenBSD...
Re: When will be created a great desktop experience for OpenBSD?
Great desktop experience for OpenBSD is a user-friendly and easy-to-use variant of OpenBSD!
Re: When will be created a great desktop experience for OpenBSD?
On Tue, May 07, 2019 at 02:01:34AM -0300, Clark Block wrote: > In 2019 still there is not a great desktop experience for NetBSD. However, > the new "OS108" is seeking to improve this with a NetBSD operating system > paired with the MATE desktop environment. > So, OS108, a derivative of NetBSD, has just been released: > https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) > > When will be created a great desktop experience for OpenBSD? "Great desktop experience" is subjective, and the current state is enough for me for example. I don't really see how adding a window manager this can improve the "desktop experience" though.
Re: When will be created a great desktop experience for OpenBSD?
Can you define "great desktop experience" ? what window managers have you tried on OpenBSD, there are are a few included in base..and you can also load more with pkg_add for ease of use / transitioning from windows ..I find xfce quite nice... All the Best, Tom Smyth On Tue, 7 May 2019 at 06:05, Clark Block wrote: > > In 2019 still there is not a great desktop experience for NetBSD. However, > the new "OS108" is seeking to improve this with a NetBSD operating system > paired with the MATE desktop environment. > So, OS108, a derivative of NetBSD, has just been released: > https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) > > When will be created a great desktop experience for OpenBSD? -- Kindest regards, Tom Smyth.
When will be created a great desktop experience for OpenBSD?
In 2019 still there is not a great desktop experience for NetBSD. However, the new "OS108" is seeking to improve this with a NetBSD operating system paired with the MATE desktop environment. So, OS108, a derivative of NetBSD, has just been released: https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) When will be created a great desktop experience for OpenBSD?
Checking hardware compatibility
Hi all, I am buliding an Internet-facing firewall plus router on the bare metal of a small and quiet machine at home. I am investigating OpenBSD+pf and NetBSD+npf, and will choose either one depending on many factors. I considered pfSense, but I would rather use a plain operating system and keeps things simple. I have a Supermicro A1SRi-2358F and an A1SRi-2558F laid aside for these sorts of tasks. (See https://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2358F.cfm and https://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm . ) I am well aware of the boot cycle bricking problem (Erratum 54 in the C2000 spec). I have researched this, etc. Do these boards work well with OpenBSD? In other words, are they well supported? Thanks! Kind regards, Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 signature.asc Description: OpenPGP digital signature
Re: xbox 360 wireless controller on amd64 working?
On May 6, 2019 8:55:41 PM UTC, Wolfgang Pfeiffer wrote: >Hi all > > Has anyone actually tried to use that controller on a fresh or older >OpenBSD? If yes: successful? > > I found hints in the 6.5 ports tree relating to that controller (and >the sdl2 package seems to be part of the regular packages tree, too) > >../ports/devel/premake4/files/scripts.c >../ports/devel/sdl2/patches/patch-src_joystick_SDL_gamecontroller_c > >Strongest hints at: >.. ports/devel/sdl2/pkg/README: > >== > >$OpenBSD: README,v 1.2 2018/09/04 12:46:11 espie Exp $ > >+--- >| Customizing ${PKGSTEM} gamecontroller layout on OpenBSD >+--- > >The mapping for SDL2's gamecontroller API is currently based on a >workaround. >It defaults to: > >"none,X360 Wireless >Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b11,\ >dpright:b12,dpup:b13,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,\ >leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,\ >righty:a4,start:b7,x:b2,y:b3," > >A custom mapping can be used via the SDL_GAMECONTROLLERCONFIG env var. >Note >that the first value (for guid) should be 'none' and the second one can >be any >name under which SDL2 will list the gamecontroller device. > >Example mapping (for Logitech Dual Action gamepad): > >$ export >SDL_GAMECONTROLLERCONFIG="none,X360WirelessController,a:b1,b:b2,\ >back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,leftshoulder:b4,\ >leftstick:b10,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,\ >righttrigger:b7,rightx:a2,righty:a3,start:b9,x:b0,y:b3," > >= > >Thanks in anticipation, > Wolfgang Sorry, wireless won't work without a Bluetooth implementation. The reason why this admittedly misleading gamepad name is in the sdl2 README is that this is what was in the example for the SDL_GAMECONTROLLERCONFIG environment variable that I found elsewhere at the time. A _wired_ XBox 360 gamepad works, however.
Re: xbox 360 wireless controller on amd64 working?
Sent from ProtonMail Mobile On Mon, May 6, 2019 at 16:55, Wolfgang Pfeiffer wrote: > Hi all > > Has anyone actually tried to use that controller on a fresh or older > OpenBSD? If yes: successful? > > I found hints in the 6.5 ports tree relating to that controller (and > the sdl2 package seems to be part of the regular packages tree, too) > > ../ports/devel/premake4/files/scripts.c > ../ports/devel/sdl2/patches/patch-src_joystick_SDL_gamecontroller_c > > Strongest hints at: > .. ports/devel/sdl2/pkg/README: > > == > > $OpenBSD: README,v 1.2 2018/09/04 12:46:11 espie Exp $ > > +--- > | Customizing ${PKGSTEM} gamecontroller layout on OpenBSD > +--- > > The mapping for SDL2's gamecontroller API is currently based on a workaround. > It defaults to: > > "none,X360 Wireless Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b11, > dpright:b12,dpup:b13,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2, > leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3, > righty:a4,start:b7,x:b2,y:b3," > > A custom mapping can be used via the SDL_GAMECONTROLLERCONFIG env var. Note > that the first value (for guid) should be 'none' and the second one can be any > name under which SDL2 will list the gamecontroller device. > > Example mapping (for Logitech Dual Action gamepad): > > $ export SDL_GAMECONTROLLERCONFIG="none,X360WirelessController,a:b1,b:b2, > back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,leftshoulder:b4, > leftstick:b10,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11, > righttrigger:b7,rightx:a2,righty:a3,start:b9,x:b0,y:b3," > > = > > Thanks in anticipation, > Wolfgang
10th Year Anniversary
C4SEM Enterprises Inc | 3001 S Madison St, | Muncie Indiana | 47302 US Manage your subscription: http://app.scsend.com/?e=email/subscription/14ooqlk0tJ5kwBsAdYK7uOzKRd9X9LW533xUlmtnc5VgQdnZUCZ3o0tg Update your preferences: http://app.scsend.com/?e=email/updateinfo/14ooqlk0tJ5kwBsAdYK7uOzKRd9X9LW533xUlmtnc5VgQdnZUCZ3o0tg
xbox 360 wireless controller on amd64 working?
Hi all Has anyone actually tried to use that controller on a fresh or older OpenBSD? If yes: successful? I found hints in the 6.5 ports tree relating to that controller (and the sdl2 package seems to be part of the regular packages tree, too) ../ports/devel/premake4/files/scripts.c ../ports/devel/sdl2/patches/patch-src_joystick_SDL_gamecontroller_c Strongest hints at: .. ports/devel/sdl2/pkg/README: == $OpenBSD: README,v 1.2 2018/09/04 12:46:11 espie Exp $ +--- | Customizing ${PKGSTEM} gamecontroller layout on OpenBSD +--- The mapping for SDL2's gamecontroller API is currently based on a workaround. It defaults to: "none,X360 Wireless Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b11,\ dpright:b12,dpup:b13,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,\ leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,\ righty:a4,start:b7,x:b2,y:b3," A custom mapping can be used via the SDL_GAMECONTROLLERCONFIG env var. Note that the first value (for guid) should be 'none' and the second one can be any name under which SDL2 will list the gamecontroller device. Example mapping (for Logitech Dual Action gamepad): $ export SDL_GAMECONTROLLERCONFIG="none,X360WirelessController,a:b1,b:b2,\ back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,leftshoulder:b4,\ leftstick:b10,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b11,\ righttrigger:b7,rightx:a2,righty:a3,start:b9,x:b0,y:b3," = Thanks in anticipation, Wolfgang
Re: Upgrade procedure encrypted filesystem (6.4 -> 6.5)
On 05/06, shadrock uhuru wrote: hi everyone when upgrading my laptop which is encrypted with a keydisk i assume that i boot the 6.5 kernel which will be on a usb stick with the keydisk inserted, will the hard drive still be decrypted and upgraded, yes also will the encryption step need to be redone no or will the keydisk continue to unlock the 6.5 filesystem on subsequent reboots. yes That's how it worked for my anyway. I'm not an OpenBSD dev and I've not read the code, so YMMV.
Double nat with pf ?
Hello, Is it possible to nat both source and destination IP on the same openbsd pf instance aka double nat ? If yes do someone has an example of it ? Thank you
Upgrade procedure encrypted filesystem (6.4 -> 6.5)
hi everyone when upgrading my laptop which is encrypted with a keydisk i assume that i boot the 6.5 kernel which will be on a usb stick with the keydisk inserted, will the hard drive still be decrypted and upgraded, also will the encryption step need to be redone or will the keydisk continue to unlock the 6.5 filesystem on subsequent reboots. thanks shadrock
Re: Upgrade procedure (6.4 -> 6.5)
Ingo, and Everyone, On Sun, May 05, 2019 at 02:58:18PM +0200, Ingo Schwarze wrote: Hi Wolfgang, Wolfgang Pfeiffer wrote on Sat, May 04, 2019 at 06:34:04PM +0200: On Sat, May 04, 2019 at 01:07:34AM -0400, Nick Holland wrote: Spend a little time learning OpenBSD, Yes: time needed, I think: Took me a while until I got that ... :) [ .. ] Bottom line, chances are that the time you need for learning is vastly outweighted by the time you save because the system is so much simpler to use. So likely, you will save time starting on day one. First: Thanks a lot for taking the time for your answer. But I disagree. Bigly. While my experience with OBSD certainly isn't extended enough, yet, to tell how much time I will save by using the system, my guess would be that you are right: I don't think I ever experienced an install that quick and smooth like the OBSD one I did on two Macintosh computers some time ago. With hickups, IIRK, yes, but nevertheless great. The point where I differ is where you seem to indicate that first it is some sort of a loss when we have to study the system, and that this effort is outweighed later on by the time we save. Half-true it is ... :) Because: if we seriously work through the big holes of missing knowledge in whatever territory, it will nearly always end up a win situation. Provided one doesn't give up. Because while we study we become more knowledgeable. That's the first win, coming nearly always with minimal intelligence and enough effort. The second one will come the moment we start to master the territory we studied. So: Double-win, hopefully ... :) Extended version: We need to be interested in the territory of our studies: if grandma' just needs a computer to send emails to her friends, or video-calling her grand-kids it's okay to just install her some Linux or Windows. Provided - at least in the latter case - she doesn't intend to do her internet banking with such an OS. But if she really wanted to understand the tool she's using, she will need to learn before asking lazy questions on a computer mailing list. Because the people on this list - probably any mailing list - are not here to do the work she needs to do herself. Theo de Raadt recently wrote that OBSD is "software we primarily develop for ourselves -- in the hope that other people are like us and need similar things." [1] I think this is an important approach to any work: if we're not interested in what we do, if we strive to help others, if we sacrifice our life to others, if we pretend that others are more important than us, and all of this out of some concept of moral duty, we will in the end have cannibalized ourselves. Which is another form of suicide (Ayn Rand has more on that: "altruism"). And OBSD might die an ugly death - I obviously don't want that. And instead try to do my homework. HTH, Kind Regards, and Thanks again, Ingo, Wolfgang [1] https://marc.info/?l=openbsd-misc&m=155634461814603&w=2 Yours, Ingo
Re: Firefox bug: 66.0.3 disables all extensions
They already fixed it a couple of hours after the issue. Em seg, 6 de mai de 2019 às 11:45, Juan Francisco Cantero Hurtado < i...@juanfra.info> escreveu: > On Mon, May 06, 2019 at 11:54:04AM +0300, Dumitru Moldovan wrote: > > On Sat, May 04, 2019 at 10:13:39PM +0200, Juan Francisco Cantero Hurtado > wrote: > > > On Sat, May 04, 2019 at 07:01:55PM +0100, Anthony Campbell wrote: > > > > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > > > > were inactivated. A quick search showed that this is a widespread > > > > problem, apparently due to a bug in FF. I was able to fix it > > > > temporarily by means of a suggestion on ghacks.net to change > > > > > > > > xpinstall.signatures.required > > > > > > > > in about.config to "false". > > > > > > > > Presumably it will be fixed soon upstream. > > > > > > Disabling signature checks is almost always a bad idea. > > > > > > Open this url with firefox and install the extension. > > > > > > > https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi > > > > > > Installing random extensions from the big bad Internet is almost always > > a bad idea. :-D > > The extension is signed by Mozilla. Just in case someone doesn't know, > the xpi extensions are just zip files. If you're worried about what > you're installing, unzip the file and check the content. The changes are > in the file "experiments/skeleton/api.js". > > > > > > This issue was fixed upstream in Firefox 66.0.4. Use Landry Breuil's > > repo to keep Firefox updated in -stable or -release. More at > > https://undeadly.org/cgi?action=article&sid=20170425173917. > > > > Final result from pkg_add should be: > > > >firefox-66.0.2->66.0.4: ok > > > > -- > Juan Francisco Cantero Hurtado http://juanfra.info > >
Re: Firefox bug: 66.0.3 disables all extensions
On Mon, May 06, 2019 at 11:54:04AM +0300, Dumitru Moldovan wrote: > On Sat, May 04, 2019 at 10:13:39PM +0200, Juan Francisco Cantero Hurtado > wrote: > > On Sat, May 04, 2019 at 07:01:55PM +0100, Anthony Campbell wrote: > > > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > > > were inactivated. A quick search showed that this is a widespread > > > problem, apparently due to a bug in FF. I was able to fix it > > > temporarily by means of a suggestion on ghacks.net to change > > > > > > xpinstall.signatures.required > > > > > > in about.config to "false". > > > > > > Presumably it will be fixed soon upstream. > > > > Disabling signature checks is almost always a bad idea. > > > > Open this url with firefox and install the extension. > > > > https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi > > > Installing random extensions from the big bad Internet is almost always > a bad idea. :-D The extension is signed by Mozilla. Just in case someone doesn't know, the xpi extensions are just zip files. If you're worried about what you're installing, unzip the file and check the content. The changes are in the file "experiments/skeleton/api.js". > > This issue was fixed upstream in Firefox 66.0.4. Use Landry Breuil's > repo to keep Firefox updated in -stable or -release. More at > https://undeadly.org/cgi?action=article&sid=20170425173917. > > Final result from pkg_add should be: > >firefox-66.0.2->66.0.4: ok > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Activating second crypted (or other raid) device
On Sun, May 05, 2019 at 05:41:38PM -0400, trondd wrote: | It's really not that big of a deal to call 'fsck' and 'mount' yourself in | rc.local. It's not, but it would be nice if this could be done automatically somehow, for services that start at boot (e.g. httpd) that need data on other softraid crypto devices. Doing an `rcctl restart httpd` in /etc/rc.local right after the fsck and mount seems a bit silly. | Unless you have system data on /srv (which would be it's own inconsistency | with a standard system) needed during rc. How about a huge /var/www or /var/ that's not on your primary softraid crypto device? | In fstab, I set the RAID partition to noauto and disable automatic fsck. | Then in rc.local call 'bioctl blah && fsck UUID.partition && mount /srv' | | I use a password so it's interative for me and I see if anything goes | wrong. Log a message with 'logger' or send an email or whatever if | something fails for your situation. Then you're done dealing with this. I use the -p option to bioctl in a hotplugd(8) attach script to automatically mount partitions on hot-plugged (USB) disks that use softraid crypto. Having a way to do this for extra disks at boot is something I've briefly looked at in the past but didn't find a nice solution for. Maybe Matthew finds something interesting :) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Activating second crypted (or other raid) device
trondd writes: > On Sun, May 5, 2019 3:57 pm, cho...@jtan.com wrote: > > My goals are: > > > > * /etc/rc already handles fsck of plaintext devices mentioned in > > /etc/fstab. > > * /etc/rc already handles mount of plaintext devices mentioned in > > /etc/fstab. > > * I would like to activate an encrypted/RAIDed device before /etc/rc > > performs > > either of those (so that code somebody else has written can do them > > for me). > > * /etc/rc.local is called too late. > > > > It's really not that big of a deal to call 'fsck' and 'mount' yourself in > rc.local. Sorry I guess I wasn't clear. I know I can use /etc/rc.local to do the post-bioctl steps but that's boring; if I only wanted to get the partition mounted I wouldn't have emailed. The idea here is to also fool around with the system for shits and giggles to see if any new knowledge falls out. It's my personal laptop, I know the risks and I can pick up the pieces if it all falls apart. I would like to to find way to fit my custom system into the same subsystems and process that already exist to bring a standard system up. I couldn't see anything in /etc/rc which would do this which is why I customised mine but I would like to know if I've missed something in there or if there's something elsewhere I don't know about that would activate softraid volumes based on some configuration file. If not then I also want to gauge thoughts on adding the ability bring up softraid devices declaratively (and at the correct boot stage) similar to how other devices are configured using eg. fstab, ttys, hostname.*. Cheers, Matthew
Re: Upgrade procedure for VMM virtualization server
‐‐‐ Original Message ‐‐‐ On Monday, May 6, 2019 1:32 PM, Solene Rapenne wrote: > There are no order. But I would upgrade the host, then the VM, this > requires only one downtime for the whole stack. Thanks for confirming, I will then do so.
Re: Upgrade procedure for VMM virtualization server
On Mon, May 06, 2019 at 11:16:18AM +, mabi wrote: > Hello, > > Now that 6.5 is out I was wondering what is the best approach of upgrading my > OpenBSD 6.4 VMM virtualization server, should I first upgrade the VMM > hypervisor host from 6.4 to 6.5 and then afterwards the virtual machines from > 6.4 to 6.5? That would make sense to me but I just wanted to double check. > > Best, > Mabi > There are no order. But I would upgrade the host, then the VM, this requires only one downtime for the whole stack. Don't forget backups of course.
Upgrade procedure for VMM virtualization server
Hello, Now that 6.5 is out I was wondering what is the best approach of upgrading my OpenBSD 6.4 VMM virtualization server, should I first upgrade the VMM hypervisor host from 6.4 to 6.5 and then afterwards the virtual machines from 6.4 to 6.5? That would make sense to me but I just wanted to double check. Best, Mabi
Re: athn0 Ifail on an old ALIX
On Sun, May 05, 2019 at 10:51:02PM +0200, Jan Stary wrote: > This is 6.5-current on an old ALIX 2D3 (full dmesg below) using > athn0 at pci0 dev 12 function 0 "Atheros AR9280" rev 0x01: irq 9 > athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:01:d6:86 > > It is my home router. I am seeing a lot of Ifails on the athn0. I see a lot of them too but they don't seem to hurt. Perhaps digging into particular failure cases could teach us something new and lead to driver improvements. Feel welcome to investigate and let us know what you find. > How can I debug this? 'netstat -W athn0' shows several counters related to input failures and should tell you where these input failures are coming from. >From one of my athn APs (also running on an alix board): 1915 input packets with mismatched ssid 24807 input packet duplicates discarded The first looks like confused client devices. The second looks like some ACKs we sent got lost for some reason. Neither is a fatal problem. Not every wireless frame dies happily.
Re: Firefox bug: 66.0.3 disables all extensions
On Sat, May 04, 2019 at 10:13:39PM +0200, Juan Francisco Cantero Hurtado wrote: On Sat, May 04, 2019 at 07:01:55PM +0100, Anthony Campbell wrote: After upgrading Firefox today to 66.0.3 in -current, all my add-ons were inactivated. A quick search showed that this is a widespread problem, apparently due to a bug in FF. I was able to fix it temporarily by means of a suggestion on ghacks.net to change xpinstall.signatures.required in about.config to "false". Presumably it will be fixed soon upstream. Disabling signature checks is almost always a bad idea. Open this url with firefox and install the extension. https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi Installing random extensions from the big bad Internet is almost always a bad idea. :-D This issue was fixed upstream in Firefox 66.0.4. Use Landry Breuil's repo to keep Firefox updated in -stable or -release. More at https://undeadly.org/cgi?action=article&sid=20170425173917. Final result from pkg_add should be: firefox-66.0.2->66.0.4: ok