Re: auto_upgrade.conf ignored?
On Jan 07 11:49:41, dera...@openbsd.org wrote: > Jan Stary wrote: > > > > 1) If you edit that file yourself, > > > > Is there any other way this file is supposed to come to existence > > (except the one containing the default answers, which sysupgrade > > writes itself) beside editing it by hand? > > sysupgrade creates it, exactly as it wants it to be. > > If you edit it, you are no longer using sysupgrade. You are on your > own. > > > > how can you say you are using sysupgrade? > > > > Perhaps I was unclear: I took the response log of a sysupgrade run > > (as mailed afterwards) and created /auto_upgrade.conf from it. > > I am not touching sysupgrade itself, obviously. > > Ah, you edited the file. > > Then you are not using sysupgrade. You are using your own process, and > you need to understand all the consequences. misc@ owes you nothing. > > > > sysupgrade manages the whole process. When you subvert a program, you are > > > responsible. > > > > Is creating /auto_upgrade.conf considered subversion? > > No. You can create your own /auto_upgrade.conf > > But if you create it, it is not sysupgrade that created it OK, this is where my whole premise is wrong it seems: namely, that /auto_upgrade.conf is a user-edited config of the sysupgrade process. Sorry for the noise. > Buy a bigger machine. Or use Linux, Now that is just rude ...
Re: What password manager do you recommend?
On Fri, Jan 07, 2022 at 01:44:51PM -0800, Sean Kamath wrote:
> > On Jan 7, 2022, at 13:38, Crystal Kolipe wrote:
> >
> > On Fri, Jan 07, 2022 at 01:23:30PM -0800, Sean Kamath wrote:
> >> gpg < file.gpg
> >
> > Why gpg and not openssl?
>
> 21 years of muscle memory?
>
> But that is a good point. . . Hrm.
OK, so I decided to see how easily this could be implemented using just what's
in the OpenBSD base install.
Passphrase manager in 584 bytes:
#!/bin/sh
F="$HOME/.pwm/secrets"
mkdir -m 700 ~/.pwm 2> /dev/null
if [[ -z "$1" ]] ; then exit ; fi
read P?'Passphrase? '
if [[ ! -e $F ]] ; then echo FiLeMaGiC | openssl enc -k "$P" -chacha -out $F ;
fi
typeset -L16 name=$1
openssl enc -k "$P" -d -chacha -in $F -out "$F"_
head -1 "$F"_ | grep -q FiLeMaGiC || { echo "Wrong passphrase!" ; rm "$F"_ ;
exit ; }
grep "^$name" "$F"_ && { rm "$F"_ ; exit ; }
echo $name not found, creating new entry:
N=`openssl rand -base64 - 12 | cut -b 1-16`
echo "$name"$N
echo "$name"$N | cat "$F"_ - | openssl enc -k "$P" -chacha -out $F
rm "$F"_
It's quite simple, you call it with one argument, which is your reference for
the place that the passphrase corresponds to. If it already exists in the
database, it's printed. If not, a new passphrase is created:
$ ./pwm bank
Passphrase? foobar
bank not found, creating new entry:
bankpFjrBm8hEuUcupj0
$ ./pwm email_provider
Passphrase? foobar
email_provider not found, creating new entry:
email_provider VKLuZTUcQjkh+jLc
$ ./pwm bank
Passphrase? foobar
bankpFjrBm8hEuUcupj0
$ ./pwm bank
Passphrase? baz
Wrong passphrase!
$ hexdump -C .pwm/secrets
53 61 6c 74 65 64 5f 5f c0 dc ac 04 28 5f 68 96 |Salted__(_h.|
0010 7c 27 c3 c8 c8 ed 32 81 c3 e1 5a cb 73 41 78 0d ||'2...Z.sAx.|
0020 e8 30 39 ce 49 91 eb 1c 87 51 84 59 15 93 05 87 |.09.IQ.Y|
0030 c8 56 1e fe 77 21 f3 d3 b0 6e 60 ea 06 fd 6a 4c |.V..w!...n`...jL|
0040 c0 ca 60 dd dd ee 47 3b a2 e8 43 2d 2c 5f ed e0 |..`...G;..C-,_..|
0050 a9 e4 e7 be b8 91 48 b5 36 da 9c 91 |..H.6...|
It's obviously not intended for serious use, but it demonstrates the principle
that there isn't always a need to go rushing to the ports tree for simple
tasks. A lot of good tools are already in the base install.
Re: laptop touchpad works fine for a while, then stops working
When the touchpad stops working, you could enable wsmouse logging, make
one or two movements on the touchpad, and extract and post the relevant
part of /var/log/messages. It might help to determine where the problem
is.
# Enable logging
$ doas wsconsctl mouse0.param=256:1,257:1
# Disable logging
$ doas wsconsctl mouse0.param=256:0,257:0
# grep the output
$ grep wsmouse0- /var/log/messages
With regular input and output, log lines look like:
... [wsmouse0-in][3993] abs:650,560
... [wsmouse0-ev][3993] 6:-5 7:-1 18:0
... [wsmouse0-in][4003] abs:644,558
... [wsmouse0-ev][4003] 6:-4 7:-1 18:0
... [wsmouse0-in][4003] abs:636,558
... [wsmouse0-ev][4003] 6:-5 18:0
Does the problem persist when you throw away your xorg.conf? And BTW,
you have different hardware now, is it still necessary to avoid those
cursor jumps?
On 1/7/22 07:21, Jonathan Thornburg wrote:
> I'm having a problem with my laptop touchpad under X (7.0-stable/amd64,
> GENERIC.MP, Lenovo Thinkpad T580, full dmesg and Xorg.0.log given below):
> When X is first started or restarted the touchpad is fine, but after X
> has been running for "a while" (anywhere from 2 hours to some days),
> the touchpad will suddenly stop working. In the "touchpad not working"
> state: * horizontal finger motions on the touchpad have no effect on
> the X cursor ("pointer")
> * vertical finger motions on the touchpad usually have no effect, but
> on some "touchpad not working" events vertical finger motions cause
> vertical scrolls of the current window (e.g., an xterm or within a
> web page being viewed with firefox); I haven't been able to figure out
> what determines whether vertical motions are no-ops or scrolls in any
> given "touchpad not working" event
> * the "trackpoint" (a.k.a "nipple") located between the G, H, and B keys
> on the keyboard works (i.e., moves the X cursor) normally
> [I don't normally use the trackpoint, and have in fact
> removed the red plastic "nipple" so as to avoid hitting it
> accidentally when typing. But the underlying 4-way switch
> is still present, and can still be pressed with a fingernail.]
> * if I plug in a USB mouse, it works (i.e., moves the X cursor) normally
> * apart from the non-functioning touchpad, everything else about X continues
> to work normally: existing windows continue to update as usual, keyboard
> input into whichever window has the focus is normal, and if the X cursor
> is stuck at a location with several overlapping windows, I can change
> the stacking order of these windows (and hence which of these windows
> has the focus) using function keys which I have bound to window-raise
> and window-lower commands in my window manager (ctwm)
> * if I switch to a virtual console with CTRL/ALT/F[1-4] I can login
> normally, and 'top -S' doesn't show anything obviously wrong
> * I don't see anything amiss in /var/log/messages, /var/log/daemon, or
> /var/log/Xorg.0.log (I give /var/log/Xorg.0.log below).
>
> Once X is in the "touchpad not working" state I can find no way of
> restoring normal touchpad operation other than either restarting the X
> server (CTRL/ALT/BACKSPACE) (which usually works) or rebooting (which
> has been necessary once or twice). I have never had restart/reboot
> fail to restore normal touchpad operation.
>
> In the "touchpad not working" state, neither switching to a virtual
> console and then back to X, nor suspending/resuming (which works
> perfectly) have any effect on the touchpad problem.
>
> So... questions:
> * is this a known bug?
> * if not,
> - should I file a bug report with sendbug?
> - is there any extra logging or debug information I could gather
> which would be useful in trying to track down the bug?
> * is there any known solution or workaround?
>
>
> Some other information which may be relevant:
>
> I track -stable via syspatch; currently syspatches 001-008 are installed.
>
> The system normally runs X, started from xenodm.
>
> X autoconfigures fine, but (for reasons described below) I have an
> /etc/xorg.conf as follows:
> % cat /etc/xorg.conf
> Section "InputClass"
> Identifier "wsmouse touchpad"
> Driver "synaptics"
> MatchIsTouchpad "on"
> EndSection
> %
>
> The reason I have an /etc/xorg.conf is to work around a different X
> touchpad problem (which occurs for twm and ctwm window managers, but
> not for fvwm), described in
>
> This /etc/xorg.conf as a workaround was suggested by Ulf Brosziewski in
>
>
> --- begin dmesg ---
> OpenBSD 7.0 (GENERIC.MP) #3: Wed Dec 15 13:14:26 MST 2021
>
> r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16755720192 (15979MB)
> avail mem = 16231866368 (15479MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256
Re: What password manager do you recommend?
I use https://www.passwordstore.org/ pkg_add password-store On Fri, Jan 7, 2022 at 2:03 PM wrote: > Hello. I hope this these types of questions are okay for an mailing list.. > I completely understand if they are not.. > > There's password-store, but it does need some shitty dependencies.. > Then there's opm, but since it doesn't seem to be popular fuck-knows-who > if it's secure(ish).. > > If I were to use password-store, I'd have dmenu pipe in the query, then > just pipe the password to `xclip -i -selection clipboard` which is a > decent setup I guess.. > >
Re: What password manager do you recommend?
> On Jan 7, 2022, at 13:38, Crystal Kolipe wrote: > > On Fri, Jan 07, 2022 at 01:23:30PM -0800, Sean Kamath wrote: >> gpg < file.gpg > > Why gpg and not openssl? 21 years of muscle memory? But that is a good point. . . Hrm.
Re: What password manager do you recommend?
On Fri, Jan 07, 2022 at 01:23:30PM -0800, Sean Kamath wrote: > gpg < file.gpg Why gpg and not openssl?
PCI configuration space documentation question
I'm reading pci_mapreg_type(9) and I'm wondering about the returns of this function. The documentation says it can return either PCI_MAPREG_TYPE_IO or PCI_MAPREG_TYPE_MEM. But I also see at least one driver checking the type for PCI_MAPREG_MEM_TYPE_64BIT Looking at the definitions of these in sys/dev/pci/pcireg.h I see the two defines listed above but also some others that seem specific to memory mapped registers. #define PCI_MAPREG_TYPE(mr) \ ((mr) & PCI_MAPREG_TYPE_MASK) #define PCI_MAPREG_TYPE_MASK0x0001 #define PCI_MAPREG_TYPE_MEM 0x #define PCI_MAPREG_TYPE_IO 0x0001 #define PCI_MAPREG_MEM_TYPE(mr) \ ((mr) & PCI_MAPREG_MEM_TYPE_MASK) #define PCI_MAPREG_MEM_TYPE_MASK0x0006 #define PCI_MAPREG_MEM_TYPE_32BIT 0x #define PCI_MAPREG_MEM_TYPE_32BIT_1M0x0002 #define PCI_MAPREG_MEM_TYPE_64BIT 0x0004 So, I am curious about the correct way to be using these, pci_mapreg_type(9) doesn't seem to light the way very far here. Please send help I'm in a maze of twisty little passages, all alike. -- Ted Bullock
Re: What password manager do you recommend?
> On Jan 7, 2022, at 11:53, fo...@dnmx.org wrote: > > Hello. I hope this these types of questions are okay for an mailing list.. > I completely understand if they are not.. > > There's password-store, but it does need some shitty dependencies.. > Then there's opm, but since it doesn't seem to be popular fuck-knows-who > if it's secure(ish).. > > If I were to use password-store, I'd have dmenu pipe in the query, then > just pipe the password to `xclip -i -selection clipboard` which is a > decent setup I guess.. gpg < file.gpg Sean PS OK, it’s more complicated than that, but that’s what it boils down to.
Re: cu/screen non-functional on 115200 (9600 ok)
On Fri, Jan 07, 2022 at 06:31:38PM +, Laura Smith wrote: > > Is there any hardware handshaking on this serial connection? > > Not AFAIK, vendor spec for connection is "serial port settings are 115200, 8 > data bits, and no parity" > I'm using a good old "Cisco-style" cable (serial at one end, RJ45 at the > other) It probably does have hardware handshaking then, which is a good thing. > Not AFAIK. I had vendor support guy on the line and I was screensharing. His > expectation was everything should be at 115200. What serial interface are you using on the OpenBSD machine? Is it a puc device by any chance? It's possible that the serial port on your OpenBSD machine is actually running at 115200, even though you have it set to 9600. I'm also wondering if it's possible that when the switch is reset, the serial line is going low for long enough to be recognised as a break and confusing misbehaviour that way.
Re: auto_upgrade.conf ignored?
Jan Stary wrote: > > 1) If you edit that file yourself, > > Is there any other way this file is supposed to come to existence > (except the one containing the default answers, which sysupgrade > writes itself) beside editing it by hand? sysupgrade creates it, exactly as it wants it to be. If you edit it, you are no longer using sysupgrade. You are on your own. > > how can you say you are using sysupgrade? > > Perhaps I was unclear: I took the response log of a sysupgrade run > (as mailed afterwards) and created /auto_upgrade.conf from it. > I am not touching sysupgrade itself, obviously. Ah, you edited the file. Then you are not using sysupgrade. You are using your own process, and you need to understand all the consequences. misc@ owes you nothing. > > sysupgrade manages the whole process. When you subvert a program, you are > > responsible. > > Is creating /auto_upgrade.conf considered subversion? No. You can create your own /auto_upgrade.conf But if you create it, it is not sysupgrade that created it If you create a file which doesn't work, have you considered blaming the creator of the file? > > Especially when it is not documented what will happen. > > sysupgrade(8) says > > /auto_upgrade.conf Response file for the ramdisk kernel. > > I agree that only documents the file is recognized to exist. But you are not using sysupgrade. Why do you refer to the sysupgrade manual page? You have placed *your own ideas* of what should be in that file. sysupgrade does not use ambigious question=answer lines. But you do. You are acting completely clueless here. > > 2) You assume you can provide multiple answers to a question -- > >how do you expect this to work? > > I naively assumed the undocumented file replaces > the interactive dialogue of a bsd.rd upgrade. My bad. If it was replacing the dialogue 1:1, then the lines would only need to be answers. But every line is question = answer. Obviously, the parsing of this won't keep-state then, and it acts as either first-match or last-match, so you cannot repeat questions. > > 3) see _autorespond in install.sub > > Thank you. > > My original problem is that some machines are small/slow enough > to warant not having e.g. the X sets, and I am trying to persuade > sysupgrade to do that. Is there a user-visible way to do that > via /auto_upgrade.conf? what the hell does "slow" have to do with installing files you won't use? Buy a bigger machine. Or use Linux, which will mean you need to buy a bigger machine. I'm dead serious -- OpenBSD is a small enough operating system that we don't need to bend-over for people who want to use it on ridiculously miserly systems. We have tradeoffs to make and I see NO POINT in focusing on people who's machines are that small.
Re: auto_upgrade.conf ignored?
On Jan 07 11:15:20, dera...@openbsd.org wrote: > Jan Stary wrote: > > > On Jan 07 10:52:51, dera...@openbsd.org wrote: > > > Set name(s) = -x* > > > Set name(s) = done > > > > > > By giving two seperate answers to the same question, you are making a > > > gigantic assumption. > > > > Yes, that's probably wrong. > > But the same happens with just > > > > Set name(s) = -x* > > > > Is the grammar of th eauto update response discribed somewhere? > > Naively, I just tweaked the response log of a previous sysupgrade. > > 1) If you edit that file yourself, Is there any other way this file is supposed to come to existence (except the one containing the default answers, which sysupgrade writes itself) beside editing it by hand? > how can you say you are using sysupgrade? Perhaps I was unclear: I took the response log of a sysupgrade run (as mailed afterwards) and created /auto_upgrade.conf from it. I am not touching sysupgrade itself, obviously. > sysupgrade manages the whole process. When you subvert a program, you are > responsible. Is creating /auto_upgrade.conf considered subversion? > Especially when it is not documented what will happen. sysupgrade(8) says /auto_upgrade.conf Response file for the ramdisk kernel. I agree that only documents the file is recognized to exist. > 2) You assume you can provide multiple answers to a question -- >how do you expect this to work? I naively assumed the undocumented file replaces the interactive dialogue of a bsd.rd upgrade. My bad. > 3) see _autorespond in install.sub Thank you. My original problem is that some machines are small/slow enough to warant not having e.g. the X sets, and I am trying to persuade sysupgrade to do that. Is there a user-visible way to do that via /auto_upgrade.conf?
Re: cu/screen non-functional on 115200 (9600 ok)
On Fri, Jan 07, 2022 at 06:01:39PM +, Laura Smith wrote: > Hi > > I'm having a really weird experience on a 6.9 box trying to connect to a > switch serial console. > > If I run "cu -r" then I can see the switch (when the switch is running its > fine, I can interact with the CLI, but if the switch reboots, I just get > random characters) So is it just during the boot sequence that you get noise, and then at some point you can access it again at 9600, or does rebooting it make it impossible to access again until you restart cu? Is there any hardware handshaking on this serial connection? Is the line noise actually always random characters or mostly ÿÿÿ ? It sounds like the switch is simply using one baud rate during boot, and switching to 9600 afterwards. However, I have noticed when using cu on a 115200 baud link with no handshaking, that when sending more than about 2 or 3 kilobytes of text continuously at maximum speed, (using the local ~> escape), that the cu session can freeze and only be recovered by exiting and restarting cu. I also saw a kernel panic on one occasion, but was unable to reproduce it. I had assumed that this was a bug in the USB serial driver, but I haven't investigated it further and it may be something else.
Re: auto_upgrade.conf ignored?
Jan Stary wrote: > On Jan 07 10:52:51, dera...@openbsd.org wrote: > > Set name(s) = -x* > > Set name(s) = done > > > > By giving two seperate answers to the same question, you are making a > > gigantic assumption. > > Yes, that's probably wrong. > But the same happens with just > > Set name(s) = -x* > > Is the grammar of th eauto update response discribed somewhere? > Naively, I just tweaked the response log of a previous sysupgrade. 1) If you edit that file yourself, how can you say you are using sysupgrade? sysupgrade manages the whole process. When you subvert a program, you are responsible. Especially when it is not documented what will happen. 2) You assume you can provide multiple answers to a question -- how do you expect this to work? 3) see _autorespond in install.sub
Re: No firefox on OpenBSD 7.0 i386?
On Fri, 7 Jan 2022, Roderick wrote: It seems there is a way to disable the search in chrome "omnibox", but it is still not clear to me how to do it. I added a "search engine" in settings with URL "http://localhost?q=%s;, set it as default and deleted all other search engines. Do you know a better solution? I find search in the URL field dangerous. In any case the automatic suggestions something aganst privacy. R.
Re: auto_upgrade.conf ignored?
On Jan 07 10:52:51, dera...@openbsd.org wrote: > Set name(s) = -x* > Set name(s) = done > > By giving two seperate answers to the same question, you are making a > gigantic assumption. Yes, that's probably wrong. But the same happens with just Set name(s) = -x* Is the grammar of th eauto update response discribed somewhere? Naively, I just tweaked the response log of a previous sysupgrade.
Re: auto_upgrade.conf ignored?
Set name(s) = -x* Set name(s) = done By giving two seperate answers to the same question, you are making a gigantic assumption.
auto_upgrade.conf ignored?
This is current/arm64 (I have the same problem on current/amd64).
I am trying toi sysupgrade with the following /auto_uprade.conf:
Which disk is the root disk = sd0
Force checking of clean non-root filesystems = no
Location of sets = disk
Is the disk partition already mounted = yes
Pathname to the sets = /home/_sysupgrade/
Set name(s) = -x*
Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes
Location of sets = done
Is seems that these responses are ignored (upgrade log below).
However, the file does not exist after the sysupgrade,
so something must have touched it ...
Am I missing something obvious?
Jan
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2022 OpenBSD. All rights reserved. https://www.OpenBSD.org
Welcome to the OpenBSD/arm64 7.0 installation program.
Performing non-interactive upgrade...
Terminal type? [vt220] vt220
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0] sd0
Checking root filesystem (fsck -fp /dev/sd0a)... OK.
Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK.
Force checking of clean non-root filesystems? [no] no
fsck -p 9bf87e93dfb93353.j... OK.
fsck -p 9bf87e93dfb93353.k... OK.
fsck -p 9bf87e93dfb93353.d... OK.
fsck -p 9bf87e93dfb93353.e... OK.
fsck -p 9bf87e93dfb93353.f... OK.
fsck -p 9bf87e93dfb93353.g... OK.
fsck -p 9bf87e93dfb93353.h... OK.
fsck -p 9bf87e93dfb93353.p... OK.
fsck -p beab8e6b584570ba.a... OK.
/dev/sd0a (9bf87e93dfb93353.a) on /mnt type ffs (rw, local, noatime)
/dev/sd0j (9bf87e93dfb93353.j) on /mnt/usr type ffs (rw, local, noatime, nodev)
/dev/sd0k (9bf87e93dfb93353.k) on /mnt/usr/local type ffs (rw, local, noatime,
nodev, wxallowed)
/dev/sd0d (9bf87e93dfb93353.d) on /mnt/tmp type ffs (rw, local, noatime, nodev,
nosuid)
/dev/sd0e (9bf87e93dfb93353.e) on /mnt/var type ffs (rw, local, noatime, nodev,
nosuid)
/dev/sd0f (9bf87e93dfb93353.f) on /mnt/var/log type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0g (9bf87e93dfb93353.g) on /mnt/var/www type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0h (9bf87e93dfb93353.h) on /mnt/var/mail type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd0p (9bf87e93dfb93353.p) on /mnt/home type ffs (rw, local, noatime,
nodev, nosuid)
/dev/sd1a (beab8e6b584570ba.a) on /mnt/backup type ffs (rw, local, noatime,
nodev, nosuid)
Let's upgrade the sets!
Location of sets? (disk http nfs or 'done') [http] disk
Is the disk partition already mounted? [yes] yes
Pathname to the sets? (or 'done') [7.0/arm64] /home/_sysupgrade/
Select sets by entering a set name, a file name pattern or 'all'. De-select
sets by prepending a '-', e.g.: '-game*'. Selected sets are labelled '[X]'.
[X] bsd [X] base70.tgz[X] game70.tgz[X] xfont70.tgz
[X] bsd.mp[X] comp70.tgz[X] xbase70.tgz [X] xserv70.tgz
[X] bsd.rd[X] man70.tgz [X] xshare70.tgz
Set name(s)? (or 'abort' or 'done') [done] done
Directory does not contain SHA256.sig. Continue without verification? [no] yes
Installing bsd 100% |**| 13704 KB00:02 ETA
Installing bsd.mp 100% |**| 13778 KB00:02 ETA
Installing bsd.rd 100% |**| 17063 KB00:02 ETA
Installing base70.tgz 100% |**| 99237 MB - 01:43eETA
Installing comp70.tgz 100% |**| 70834 KB01:10 ETA
Installing man70.tgz100% |**| 7588 KB00:15 ETA
Installing game70.tgz 100% |**| 2715 KB00:01 ETA
Installing xbase70.tgz 100% |**| 48628 KB00:25 ETA
Installing xshare70.tgz 100% |**| 4545 KB00:22 ETA
Installing xfont70.tgz 100% |**| 22965 KB00:10 ETA
Installing xserv70.tgz 100% |**| 13087 KB00:05 ETA
Location of sets? (disk http nfs or 'done') [done] done
Making all device nodes... done.
fw_update: added none; updated none; kept bwfm
Multiprocessor machine; using bsd.mp instead of bsd.
Relinking to create unique kernel... done.
CONGRATULATIONS! Your OpenBSD upgrade has been successfully completed!
syncing disks... done
rebooting...
Re: No firefox on OpenBSD 7.0 i386?
Surf is actually excellent BUT it has no ad blocker and some sites don’t load properly, ala YouTube. On Friday, January 7, 2022, Crystal Kolipe wrote: > On Fri, Jan 07, 2022 at 04:36:36PM +, Roderick wrote: > > > > On Fri, 7 Jan 2022, Crystal Kolipe wrote: > > > > >>But you might encounter increasingly more websites that do not work > > >>with them, as the web grows in complexity. > > > > > >Agreed. > > > > And this is the main point. I need the web browser for example for > > internetbanking, not just "surfing". > > Well, if your needs are for a few specific sites rather than general > browsing, it might be worth testing surf to see if they are usable or > not. I pointed out some particular issues with Surf that I am aware > of, but overall it's compatibility is fairly good. > >
Re: No firefox on OpenBSD 7.0 i386?
On Fri, Jan 07, 2022 at 11:39:43AM -0500, Daniel Wilkins wrote: > Crystal Kolipe wrote: > >>* https://sourceforge.net/projects/midori-browser/ (as on Raspbian) > >Midori might be worth looking at as a light-weight browser replacement for > >Firefox, although I haven't used it for a number of years. > > > Worth nothing that this version of Midori has been abandoned for the > better part of a decade by this point. True, I didn't notice that the link I quoted was an old one pointing to sourceforge.net. The version of Midori that we have in ports is V9.0, released in July 2019. Admittedly it still doesn't look very actively maintained.
Re: No firefox on OpenBSD 7.0 i386?
I do internet banking with epiphany. On 1/7/22, Raymond, David wrote: > I use epiphany quite a bit, and like it a lot, though there are > websites on which it crashes. It uses the same toolkit as midori and > in my opinion has a somewhat better user interface. Don't know > whether it works on i386 at this point. > > Dave Raymond > > On 1/7/22, Crystal Kolipe wrote: >> On Fri, Jan 07, 2022 at 05:06:24PM +0100, Josuah Demangeon wrote: >> >>> * https://surf.suckless.org/ (webkit/gtk+) >> >> Surf would work well on his hardware, but it's minimal interface is >> somewhat >> different to a traditional web browser, and probably not what he is >> expecting. >> >> It also has some fairly unique issues with some websites due to the way >> non-html links are passed to curl. Session cookies are not passed to the >> curl instance, so downloading anything that requires authentication from >> any >> kind of portal that you're logged in to generally doesn't work, (think >> statements on internet banking, etc). Surf also often chokes on pop-up >> windows that have a javascript target URI, and there are a few other >> oddities as well. >> >> Having said that, I use surf a lot, our website definitely works well in >> Surf, and the way you can drive Surf completely via keyboard navigation >> is >> excellent. >> >>> * https://sourceforge.net/projects/midori-browser/ (as on Raspbian) >> >> Midori might be worth looking at as a light-weight browser replacement >> for >> Firefox, although I haven't used it for a number of years. >> >>> But you might encounter increasingly more websites that do not work >>> with them, as the web grows in complexity. >> >> Agreed. >> >> > > > -- > David J. Raymond > david.raym...@nmt.edu > http://kestrel.nmt.edu/~raymond > -- David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Re: No firefox on OpenBSD 7.0 i386?
I use epiphany quite a bit, and like it a lot, though there are websites on which it crashes. It uses the same toolkit as midori and in my opinion has a somewhat better user interface. Don't know whether it works on i386 at this point. Dave Raymond On 1/7/22, Crystal Kolipe wrote: > On Fri, Jan 07, 2022 at 05:06:24PM +0100, Josuah Demangeon wrote: > >> * https://surf.suckless.org/ (webkit/gtk+) > > Surf would work well on his hardware, but it's minimal interface is somewhat > different to a traditional web browser, and probably not what he is > expecting. > > It also has some fairly unique issues with some websites due to the way > non-html links are passed to curl. Session cookies are not passed to the > curl instance, so downloading anything that requires authentication from any > kind of portal that you're logged in to generally doesn't work, (think > statements on internet banking, etc). Surf also often chokes on pop-up > windows that have a javascript target URI, and there are a few other > oddities as well. > > Having said that, I use surf a lot, our website definitely works well in > Surf, and the way you can drive Surf completely via keyboard navigation is > excellent. > >> * https://sourceforge.net/projects/midori-browser/ (as on Raspbian) > > Midori might be worth looking at as a light-weight browser replacement for > Firefox, although I haven't used it for a number of years. > >> But you might encounter increasingly more websites that do not work >> with them, as the web grows in complexity. > > Agreed. > > -- David J. Raymond david.raym...@nmt.edu http://kestrel.nmt.edu/~raymond
Re: No firefox on OpenBSD 7.0 i386?
On Fri, Jan 07, 2022 at 04:36:36PM +, Roderick wrote: > > On Fri, 7 Jan 2022, Crystal Kolipe wrote: > > >>But you might encounter increasingly more websites that do not work > >>with them, as the web grows in complexity. > > > >Agreed. > > And this is the main point. I need the web browser for example for > internetbanking, not just "surfing". Well, if your needs are for a few specific sites rather than general browsing, it might be worth testing surf to see if they are usable or not. I pointed out some particular issues with Surf that I am aware of, but overall it's compatibility is fairly good.
Re: controlling terminal - to have and have not
On Fri, Jan 07, 2022 at 05:08:16PM +0100, Jan Stary wrote: > This is how ps(1) differentiates between displaying > processes that have a terminal and those that have not: > > -a Display information about processes > for all users with controlling terminals. > > -x Display information about processes > without controlling terminals. > > Strangely, some processes appear in both listings: > > $ ps -a | grep man > 22867 p6 Ip 0:00.02 man ps > 82326 p6 I+p 0:00.02 less -T /tmp/man.TkUznrbk0K /tmp/man.qGVXE5xsvJ > 43736 p7 R+p/30:00.00 grep man > > $ ps -x | grep man > 22867 p6 Ip 0:00.02 man ps > 82326 p6 I+p 0:00.02 less -T /tmp/man.TkUznrbk0K /tmp/man.qGVXE5xsvJ > 50867 p7 R+p/20:00.05 grep man > > Is this intended? Am I missing something obvious? > Or does the wording mean "users with controlling terminals"? > > Jan > > The man page should say something like: -a include processes other than your own, but skip processes without controlling terminal, unless -x is also specified -x include processes without controlling terminal. -Otto
Re: controlling terminal - to have and have not
On Fri, Jan 07, 2022 at 05:08:16PM +0100, Jan Stary wrote: > This is how ps(1) differentiates between displaying > processes that have a terminal and those that have not: > > -a Display information about processes > for all users with controlling terminals. > > -x Display information about processes > without controlling terminals. > > Strangely, some processes appear in both listings: > > $ ps -a | grep man > 22867 p6 Ip 0:00.02 man ps > 82326 p6 I+p 0:00.02 less -T /tmp/man.TkUznrbk0K /tmp/man.qGVXE5xsvJ > 43736 p7 R+p/30:00.00 grep man > > $ ps -x | grep man > 22867 p6 Ip 0:00.02 man ps > 82326 p6 I+p 0:00.02 less -T /tmp/man.TkUznrbk0K /tmp/man.qGVXE5xsvJ > 50867 p7 R+p/20:00.05 grep man > > Is this intended? Am I missing something obvious? > Or does the wording mean "users with controlling terminals"? -x doesn't limit the display to ONLY processes with controlling terminals, it includes them in addition to the processes that would otherwise be listed. Have a look at ps.c, the code is quite straightforward. The -a and -x options just set the all and xflg flags, which are tested later on when the list of processes is parsed.
Re: No firefox on OpenBSD 7.0 i386?
Crystal Kolipe wrote: * https://sourceforge.net/projects/midori-browser/ (as on Raspbian) Midori might be worth looking at as a light-weight browser replacement for Firefox, although I haven't used it for a number of years. Worth nothing that this version of Midori has been abandoned for the better part of a decade by this point. Modern Midori's a web app (https://astian.org/en/midori-browser/) so it's probably not a viable choice for this case.
Re: No firefox on OpenBSD 7.0 i386?
On Fri, 7 Jan 2022, Crystal Kolipe wrote: But you might encounter increasingly more websites that do not work with them, as the web grows in complexity. Agreed. And this is the main point. I need the web browser for example for internetbanking, not just "surfing". The web developers decide, what browser I must use, not I. I do not see an alternative to the bloated chrome or firefox browsers. It seems there is a way to disable the search in chrome "omnibox", but it is still not clear to me how to do it. R.
Re: No firefox on OpenBSD 7.0 i386?
On Fri, Jan 07, 2022 at 05:06:24PM +0100, Josuah Demangeon wrote: > * https://surf.suckless.org/ (webkit/gtk+) Surf would work well on his hardware, but it's minimal interface is somewhat different to a traditional web browser, and probably not what he is expecting. It also has some fairly unique issues with some websites due to the way non-html links are passed to curl. Session cookies are not passed to the curl instance, so downloading anything that requires authentication from any kind of portal that you're logged in to generally doesn't work, (think statements on internet banking, etc). Surf also often chokes on pop-up windows that have a javascript target URI, and there are a few other oddities as well. Having said that, I use surf a lot, our website definitely works well in Surf, and the way you can drive Surf completely via keyboard navigation is excellent. > * https://sourceforge.net/projects/midori-browser/ (as on Raspbian) Midori might be worth looking at as a light-weight browser replacement for Firefox, although I haven't used it for a number of years. > But you might encounter increasingly more websites that do not work > with them, as the web grows in complexity. Agreed.
controlling terminal - to have and have not
This is how ps(1) differentiates between displaying processes that have a terminal and those that have not: -a Display information about processes for all users with controlling terminals. -x Display information about processes without controlling terminals. Strangely, some processes appear in both listings: $ ps -a | grep man 22867 p6 Ip 0:00.02 man ps 82326 p6 I+p 0:00.02 less -T /tmp/man.TkUznrbk0K /tmp/man.qGVXE5xsvJ 43736 p7 R+p/30:00.00 grep man $ ps -x | grep man 22867 p6 Ip 0:00.02 man ps 82326 p6 I+p 0:00.02 less -T /tmp/man.TkUznrbk0K /tmp/man.qGVXE5xsvJ 50867 p7 R+p/20:00.05 grep man Is this intended? Am I missing something obvious? Or does the wording mean "users with controlling terminals"? Jan
Re: No firefox on OpenBSD 7.0 i386?
Roderick wrote: > I just updated OpenBSD to 7.0. After pkg_add -u, it seems > firefox was not updated: I did not have this problem with firefox installed before my 6.9 -> 7.0 upgrade, but I'm on amd64 : lap1$ uname -a OpenBSD lap1.josuah.net 7.0 GENERIC.MP#3 amd64 lap1$ doas pkg_delete firefox firefox-95.0.1: ok Running tags: ok Read shared items: ok lap1$ doas pkg_add firefox quirks-4.53 signed on 2022-01-05T19:08:35Z .libs1-firefox-82.0.3+.libs1-firefox-88.0.1->firefox-95.0.1: ok Running tags: ok Read shared items: ok New and changed readme(s): /usr/local/share/doc/pkg-readmes/firefox lap1$ > firefox core dumped, I deleted it, but I cannot reinstall it > (cannot find that package). What would a pkg_add -u do? Also, if you have > With chrome I have a problem, because it does not separate URL > entry from search entry. And I do not know an alternative to firefox. Alternatives include all these tiny programmable web browsers based on webkit or alike: * https://pwmt.org/projects/jumanji/ (webkit/gtk+) * https://surf.suckless.org/ (webkit/gtk+) * https://nyxt.atlas.engineer/ (webkit/gtk+ or blink/gtk+) * https://qutebrowser.org/ (webkit/qt) * https://fanglingsu.github.io/vimb/ (webkit/gtk+) * ... Or some long-timers projects that are quite stable and cover quite enough to get most website content : * http://www.netsurf-browser.org/ (extremely portable!) * https://sourceforge.net/projects/midori-browser/ (as on Raspbian) * ... But you might encounter increasingly more websites that do not work with them, as the web grows in complexity.
Re: No firefox on OpenBSD 7.0 i386?
On Fri, 7 Jan 2022, Crystal Kolipe wrote: Are you actually running on hardware that doesn't support amd64? That is the case. A light and small samsumg nc10 nettop. No amd64, only 2 GB RAM. The problem is that important Web-Sites are done for chrome and firefox. I do not see much choice. I would use other browser, if I can import my bookmarks and if it has sparated URL and search entries. Rodrigo
Re: No firefox on OpenBSD 7.0 i386?
On Fri, Jan 07, 2022 at 03:38:11PM +, Roderick wrote: > I just updated OpenBSD to 7.0. After pkg_add -u, it seems > firefox was not updated: Firefox no longer builds on i386, since shortly after the release of OpenBSD 6.9. > Any hint? Are you actually running on hardware that doesn't support amd64?
No firefox on OpenBSD 7.0 i386?
I just updated OpenBSD to 7.0. After pkg_add -u, it seems firefox was not updated: firefox core dumped, I deleted it, but I cannot reinstall it (cannot find that package). With chrome I have a problem, because it does not separate URL entry from search entry. And I do not know an alternative to firefox. Any hint? Thanks Rodrigo
