Re: Future of X.org?
On Mon, 1 Jul 2019, Juan Francisco Cantero Hurtado wrote: Xorg is the most insecure software in base. Why? Because it has bugs? Or because, in oppossite to wayland, it can listen to outside connections if configured so (by default it does not)? If you only care about the remote apps, with wayland you can still run the apps within wayland. "ssh -X" will work fine. I never do ssh -X. Nonsense in a LAN. If X11 is so bad for you, then sure also nfs. Should it also be deletet? it is not a big lost for obvious reasons. It is not a big lost *for you*. Rodrigo.
Re: Future of X.org?
Roderick writes: > > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: > > > You can run (local or remote) X11 applications inside of a Wayland > > compositor. > > The following contradicts your above assertion: > > https://wayland.freedesktop.org/faq.html#heading_toc_j_8 Wayland. The software product brought to you by the people with a FAQ containing this answer: To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. followed by this question: Why wasn't D-Bus used instead of the Wayland IPC mechanism? and then finally this answer: The alternative is to write a Wayland specific GL binding API, say, WaylandGL. I don't think I'll be relying on software from such confused individuals any time soon. Matthew
Re: Future of X.org?
On Sun, Jun 30, 2019 at 09:09:08PM +, Roderick wrote: > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: > > > Nope, you misunderstood the text. > > No. It is *you* that do not understand what X11 is and want it death. > A very destructive attitude. You're the only one with a destructive attitude here. I'm trying to help you because usually people doesn't understand how wayland works. X11 and Wayland are both protocols. Xorg is just a server and will die because nobody contributes to it. As usual, a lot of people complains but nobody expend their time working on those projects. The X11 protocol will live for decades. Xorg will die. Xorg is the most insecure software in base. Running your X11 apps inside of Wayland will be more secure than running the same apps inside of a full installation of Xorg. > > > "This doesn't mean that remote rendering won't be possible with Wayland, > > it just means that you will have to put a remote rendering server on top > > of Wayland. One such server could be the X.org server". > > You quote the text and are unable to get the conclusion: having > wayland, if you need X11, then you must implement an X11 server. The X11 server for wayland has been available for years. > > Is it not clear from the text that for upgrading wayland to X11, > you must implement X11, and the autor avoided it for keeping it simple? The author wanted a secure and low latency alternative to X11 for local use, not remote. He didn't want a reimplementation of X11. There is not a "upgrading" thing. Anything using GTK, EFL or QT will work transparently on wayland. And you still have compatibility with X11 available. > > Is it not clear that wayland is *never* a substitute of X11? > > You confuse X11 with a graphical display, such the old ones of > Amiga or MacOS. It was always possible to have it in unix. But > that was never the purpose of X11. The graphic display is only > a byproduct of X11. > > I remember in the 1990s that it was possible to run a comercial > X11 in Macs: They had their graphical display, but that was neither X11 > nor a substituite of it. But you are trying to convince us that > wayland is a substitute of X11, that X11 must die. Again. Nope. Wayland is a substitute for the layer bellow of the local graphical apps. The most common use of X11 nowadays. If you only care about the remote apps, with wayland you can still run the apps within wayland. "ssh -X" will work fine. The only missing part here is the client-server architecture to send unencrypted traffic over the network. Which for a OS like OpenBSD, it's not a big lost for obvious reasons. I'm not trying to convince you. I only replied because you said: "I also have no much idea of what is wayland". And now you're ranting and complaining how destructive I am. I'm not the problem here. > > And Xorg / xenocara is not bloat: it runs on meager X11 terminals. > The bloat will come with wayland. Right. The Xorg project code is quite small. > > And X11 imposes an standard. Programs done as X11 clients may run in > any OS display in other. Wayland will bring chaos. X11 brought insecurity. Have a nice day and for the next time, try not to be an ass with people who is trying to help you. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Future of X.org?
I make a mistake by writting this mail, but: On Sun, Jun 30, 2019 at 09:09:08PM +, Roderick wrote: > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: > > > Nope, you misunderstood the text. > > No. It is *you* that do not understand what X11 is and want it death. > A very destructive attitude. > No, it's your attitude is destructive. > > "This doesn't mean that remote rendering won't be possible with Wayland, > > it just means that you will have to put a remote rendering server on top > > of Wayland. One such server could be the X.org server". > > You quote the text and are unable to get the conclusion: having > wayland, if you need X11, then you must implement an X11 server. > > Is it not clear from the text that for upgrading wayland to X11, > you must implement X11, and the autor avoided it for keeping it simple? > > Is it not clear that wayland is *never* a substitute of X11? > > You confuse X11 with a graphical display, such the old ones of > Amiga or MacOS. It was always possible to have it in unix. But > that was never the purpose of X11. The graphic display is only > a byproduct of X11. > > I remember in the 1990s that it was possible to run a comercial > X11 in Macs: They had their graphical display, but that was neither X11 > nor a substituite of it. But you are trying to convince us that > wayland is a substitute of X11, that X11 must die. > > And Xorg / xenocara is not bloat: it runs on meager X11 terminals. > The bloat will come with wayland. > > And X11 imposes an standard. Programs done as X11 clients may run in > any OS display in other. Wayland will bring chaos. > > Rodrigo > You are a liar, the Xenocara is a bloat. X11 is a bloat and its implementation called X.org is a greater bloat. Mesa is a bloat, it's a shit fat C++ library. X Window System is just a shit windowing system while Wayland is a simple, fast and secure display server protocol. (Well, almost simple, this XML dependance is overkill.) You people protecting X make me doubt that OpenBSD aims security, I am agree with Linus Torvalds who called us monkeys.
Re: Future of X.org?
On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: Nope, you misunderstood the text. No. It is *you* that do not understand what X11 is and want it death. A very destructive attitude. "This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server". You quote the text and are unable to get the conclusion: having wayland, if you need X11, then you must implement an X11 server. Is it not clear from the text that for upgrading wayland to X11, you must implement X11, and the autor avoided it for keeping it simple? Is it not clear that wayland is *never* a substitute of X11? You confuse X11 with a graphical display, such the old ones of Amiga or MacOS. It was always possible to have it in unix. But that was never the purpose of X11. The graphic display is only a byproduct of X11. I remember in the 1990s that it was possible to run a comercial X11 in Macs: They had their graphical display, but that was neither X11 nor a substituite of it. But you are trying to convince us that wayland is a substitute of X11, that X11 must die. And Xorg / xenocara is not bloat: it runs on meager X11 terminals. The bloat will come with wayland. And X11 imposes an standard. Programs done as X11 clients may run in any OS display in other. Wayland will bring chaos. Rodrigo
Re: Future of X.org?
On Sun, Jun 30, 2019 at 03:59:55PM +, Roderick wrote: > > > On Fri, 28 Jun 2019, gwes wrote: > > > I regularly run programs on one machine connected to a display > > on another machine. AFAIK, the current state of Wayland makes > > that difficult. I confess to not following it closely. > > I also do it, and I also have no much idea of what is wayland. > > But I have the impression that some people want to substitute X11 > with something that is not a replacement for it, that has other > functionality. They confuse X11 with a mere graphical surface. You can run (local or remote) X11 applications inside of a Wayland compositor. -- Juan Francisco Cantero Hurtado http://juanfra.info
6.5 pkg_add "Fatal error: Can't write session into tmp directory"
I have 6.5/i386 installed on a PC Engines alix board (hostname 'sodium'), acting as a home firewall and router. I'd like to install some packages the firewall it to make system adminstration easier. So... I downloaded the appropriate 6./i386 packages from a nearby OpenBSD mirror, ssh-ed them to /tmp on the firewall, and then (logged into the firewall as root) tried to pkg_add them. Alas, pkg_add failed with an error message about being unable to write into a temp directory: sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz Fatal error: Can't write session into tmp directory at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 1025. sodium# I've checked that the firewall has adequate free memory & swap space, that all the obviously-relevant filesystems are mounted read-write and have free inodes and disk space, and that 'touch foo' can create a new file in each of /tmp, /var/tmp, and /usr/tmp. Is there something obvious I'm overlooked here? A Fine Man Page I should be rereading before I start hacking debug prints into the pkg_add (perl) source code? Further information (cut-and-pasted from ssh session on the firewall): sodium# uname -a OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#1 i386 sodium# df -hi Filesystem SizeUsed Avail Capacity iused ifree %iused Mounted on /dev/wd0a 378M 47.7M311M13%1771 47379 4% / mfs:54350 62.9M2.0M 57.7M 3% 88182 0% /tmp /dev/wd0e 677M 15.1M628M 2% 352 87710 0% /var /dev/wd0f 1.5G698M734M49% 16248 191622 8% /usr mfs:42325 62.9M2.0K 59.7M 0% 18189 0% /usr/tmp /dev/wd0g 516M138M352M28%8980 5860213% /usr/X11R6 /dev/wd0h 1.7G218K1.6G 0% 110 233744 0% /usr/local /dev/wd0j 5.1G2.0K4.8G 0% 1 701565 0% /usr/obj /dev/wd0i 1.3G2.0K1.3G 0% 1 181885 0% /usr/src sodium# cat /etc/fstab 5fd63b50b0c6cb1d.a /ffs rw,softdep,noatime 1 1 5fd63b50b0c6cb1d.d /tmp mfs rw,async,nodev,nosuid,-s=64m0 0 5fd63b50b0c6cb1d.e /var ffs rw,softdep,noatime,nodev,nosuid 1 2 5fd63b50b0c6cb1d.f /usr ffs rw,softdep,noatime,nodev1 2 5fd63b50b0c6cb1d.d /usr/tmp mfs rw,async,nodev,nosuid,-s=64m0 0 5fd63b50b0c6cb1d.g /usr/X11R6 ffs rw,softdep,noatime,nodev1 2 5fd63b50b0c6cb1d.h /usr/local ffs rw,softdep,noatime,wxallowed,nodev 1 2 5fd63b50b0c6cb1d.j /usr/obj ffs rw,softdep,noatime,nodev,nosuid 1 2 5fd63b50b0c6cb1d.i /usr/src ffs rw,softdep,noatime,nodev,nosuid 1 2 sodium# top|head load averages: 0.08, 0.02, 0.01sodium.bkis-orchard.net 13:12:00 52 processes: 1 running, 50 idle, 1 on processor up 14 days, 5:21 CPU: 0.1% user, 0.0% nice, 0.3% sys, 0.0% spin, 0.3% intr, 99.3% idle Memory: Real: 35M/110M act/tot Free: 127M Cache: 46M Swap: 0K/548M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 59735 root 1000K 19M sleep bored44:53 0.44% softnet 65312 root -2200K 19M sleep - 339.9H 0.00% idle0 57981 root 1000K 19M sleep bored 7:56 0.00% sensors 39371 _unbound 20 12M 10M sleep kqread1:33 0.00% unbound sodium# cd /tmp sodium# ls -l total 4144 drwxrwxrwt 2 root wheel 512 Jun 16 07:51 .ICE-unix drwxrwxrwt 2 root wheel 512 Jun 16 07:51 .X11-unix -rw-r--r-- 1 root wheel 1499861 Jun 30 12:31 lynx-2.8.9rel1.tgz drwxr-xr-x 2 root wheel 512 Jun 16 07:51 sndio -rw-r--r-- 1 root wheel 564428 Jun 30 12:31 tcsh-6.20.00p1-static.tgz drwxrwxrwt 2 root wheel 512 Jun 30 12:33 vi.recover sodium# sodium# pkg_info sodium# sodium# which pkg_add /usr/sbin/pkg_add sodium# pkg_add -vv tcsh-6.20.00p1-static.tgz Fatal error: Can't write session into tmp directory at /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 1025. sodium# env _=/usr/bin/env LOGNAME=root PWD=/tmp HOME=/root OLDPWD=/tmp SSH_TTY=/dev/ttyp0 TOP=-S -i -s1 MAIL=/var/mail/root SSH_CLIENT=192.168.105.0 4099 22 PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin TERM=xterm SHELL=/bin/ksh SSH_CONNECTION=192.168.105.0 4099 192.168.105.62 22 USER=root sodium# cd /tmp sodium# touch foo sodium# ls -l foo -rw-r--r-- 1 root wheel 0 Jun 30 13:07 foo sodium# /bin/rm foo sodium# sodium# cd /var/tmp sodium# touch foo sodium# ls -l foo -rw-r--r-- 1 root wheel 0 Jun 30 13:08 foo sodium# /bin/rm foo sodium# sodium# cd /usr/tmp sodium# touch foo sodium# ls -l foo -rw-r--r-- 1 root wheel 0 Jun 30 13:13 foo sodium# /bin/rm foo sodium# Thanks in advance for any assistance, -- -- "Jonathan Thornburg [remove -animal to rep
Re: man bgpd.conf + question
Thank you for your answer Claudio
Le samedi 29 juin 2019 à 19:56:41 UTC+2, Claudio Jeker
a écrit :
On Fri, Jun 28, 2019 at 10:52:01PM +, Mik J wrote:
> Hello,
> I have a syntax error with announce none
> group "spam-bgp" {
> remote-as $spamASN
> multihop 64
> announce none
>
> I was told recently that everything is filtered by default from 6.4 and read
> on Internet that announce none is deprecated
> However man bgpd.conf (Openbsd 6.5) still has this command in section
> "NEIGHBORS AND GROUPS"announce (IPv4|IPv6) (none|unicast|vpn)
>
> Do you know what is correct ?
There is a difference between:
announce none
and
announce IPv4 none
or
announce IPv6 none
The frist one no longer exists. The 2nd one still works and disables the
multiprotocol capability for the define AFI (IPv4 or IPv6).
By default the session enables the unicast AFI for the IP family that the
session uses. (e.g. announce IPv6 unicast for IPv6 sessions) and the other
AFI is disabled.
--
:wq Claudio
Re: Future of X.org?
On Sun, Jun 30, 2019 at 06:55:42PM +, Roderick wrote: > > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: > > > You can run (local or remote) X11 applications inside of a Wayland > > compositor. > > The following contradicts your above assertion: > > https://wayland.freedesktop.org/faq.html#heading_toc_j_8 Nope, you misunderstood the text. "This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server". So, you will need a nested X11 server. Like you need on Windows or MacOS. That's all. You will see a desktop (compositor) running on top of Wayland, a browser (just an example) window using also Wayland and your X11 applications running like native applications. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Future of X.org?
On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: You can run (local or remote) X11 applications inside of a Wayland compositor. The following contradicts your above assertion: https://wayland.freedesktop.org/faq.html#heading_toc_j_8 Rod.
L2TP/IPSec PSK with Android -- INVALID_ID_INFORMATION
Hi all! I know (saw) this has come up numerous times, and someone has been successful, others weren't. I thought I'd try this out myself, and not surprisingly it wasn't successful :) I've been using these howtos [1] -- I know these can be outdated and/or simply wrong, I just wanted to get the general idea on how to tackle this. I've made it through a couple of hurdles but now I'm stuck and thought I'd ask some questions here. So this is my configuration: OpenBSD 6.5-stable /etc/ipsec.conf: ike passive esp transport \ proto udp \ from any to any port l2tp \ main auth "hmac-sha2" enc "aes-256" group modp1024 \ quick auth "hmac-sha2" enc "aes-256" \ psk "thisismykey" (I found that some howtos specified the group attribute for the line `quick` as well, but that didn't work for me, then it seemed this whole thing just wouldn't match my connection) I'm starting isakmpd(8) as /sbin/isakmpd -d -v -K Then doing an: /sbin/ipsecctl -vf /etc/ipsec.conf =8<= C set [Phase 1]:Default=peer-default force C set [peer-default]:Phase=1 force C set [peer-default]:Authentication=thisismykey force C set [peer-default]:Configuration=phase1-peer-default force C set [phase1-peer-default]:EXCHANGE_TYPE=ID_PROT force C add [phase1-peer-default]:Transforms=phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024 force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:HASH_ALGORITHM=SHA2_256 force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:ENCRYPTION_ALGORITHM=AES_CBC force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:KEY_LENGTH=256,256:256 force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:Life=LIFE_MAIN_MODE force C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Phase=2 force C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:ISAKMP-peer=peer-default force C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Configuration=phase2-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 force C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Local-ID=from-0.0.0.0/0=17 force C set [from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Remote-ID=to-0.0.0.0/0=17:1701 force C set [phase2-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:EXCHANGE_TYPE=QUICK_MODE force C set [phase2-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Suites=phase2-suite-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 force C set [phase2-suite-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Protocols=phase2-protocol-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 force C set [phase2-protocol-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:PROTOCOL_ID=IPSEC_ESP force C set [phase2-protocol-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701]:Transforms=phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT force C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:TRANSFORM_ID=AES force C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:KEY_LENGTH=256,256:256 force C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:ENCAPSULATION_MODE=TRANSPORT force C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 force C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:GROUP_DESCRIPTION=MODP_3072 force C set [phase2-transform-from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701-AES256-SHA2_256-MODP_3072-TRANSPORT]:Life=LIFE_QUICK_MODE force C set [from-0.0.0.0/0=17]:ID-type=IPV4_ADDR_SUBNET force C set [from-0.0.0.0/0=17]:Network=0.0.0.0 force C set [from-0.0.0.0/0=17]:Netmask=0.0.0.0 force C set [to-0.0.0.0/0=17:1701]:ID-type=IPV4_ADDR_SUBNET force C set [to-0.0.0.0/0=17:1701]:Network=0.0.0.0 force C set [to-0.0.0.0/0=17:1701]:Netmask=0.0.0.0 force C set [from-0.0.0.0/0=17]:Protocol=17 force C set [to-0.0.0.0/0=17:1701]:Protocol=17 force C set [to-0.0.0.0/0=17:1701]:Port=1701 force C add [Phase 2]:Passive-Connections=from-0.0.0.0/0=17-to-0.0.0.0/0=17:1701 C set [Phase 1]:Default=peer-default force C set [peer-default]:Phase=1 force C set [peer-default]:Authentication=thisismykey force C set [peer-default]:Configuration=phase1-peer-default force C set [phase1-peer-default]:EXCHANGE_TYPE=ID_PROT force C add [phase1-peer-default]:Transforms=phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024 force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force C set [phase1-transform-peer-default-PRE_SHARED-SHA2_256-AES256-MODP_1024]:HASH_ALGORITHM=SH
Re: cd command, chdir syscall, shell behavour
Hi Edgar, Edgar Pettijohn wrote on Sat, Jun 29, 2019 at 07:48:35PM -0500: > Ingo Schwarze wrote: >> If you want to search for a manual page, use man(1). >> If you want to search for packages, use pkglocate(1). > I don't think this would be needed on openbsd as the default > install has everything you need for a basic system and it's easy > to add additional packages. However, as I learned when I set up > a Debian box for my son to play Minecraft it didn't. So it was > kinda nice when I typed ifconfig it informed me what package to > install That argument doesn't really apply even to Debian. Just like i said If you want to search for packages, use pkglocate(1). for OpenBSD, you would say $ apt-cache search ifconfig on Debian. Different systems have different tools, but the concept that each tool should focus on its own job still applies. Besides, ip(8) was probably already installed and likely good enough for your job. > and I eventually got everything working no thanks to the > piss poor manual pages provided. And that even though in the Linux world, few systems insist that everything should have a manual page as much as Debian does... Yours, Ingo
Re: cd command, chdir syscall, shell behavour
Hi Ian, ropers wrote on Sun, Jun 30, 2019 at 02:18:56PM +0200: > In bash, `help` is a shell builtin and does do something, though IMO, > the something that it does isn't initially as helpful as OpenBSD's > help(1), especially to newbies. [1] Yes. When a user types "help", it is unlikely they are confused only about shell builtins (or even about the shell at large), but it sounds more like they need getting started with the OS as a whole. > However, what it does do, i.e. > * print a list of bash builtins in response to `help`, or > * print bash builtin-specific help in response to `help [builtin]` > could well be helpful later and relates to what we discussed earlier. > Is man(1) plus info(1) plus bash's help some kind of triple > book-keeping or wheel-reinvention? More like quadruple because there is also the usage message. But yes, that having a one- or two-line usage message on the one hand and a complete and concise manual page on the other hand, and no third copy of the same, is the current official OpenBSD position because the information isn't really that hard to find in the manual page, and a third copy would cause additional maintenance effort and risk getting outdated. All the same, developers occasionally discuss whether exceptions of having -h or --help options for a few unusually complicated programs might make sense (for example right now on tech@), but so far, it was usually rejected. > Perhaps, but in terms of convenience, bash's `help` and `help [builtin]` > are stiff competition to [...] `man -k Ic,Nm=[term]` and `man -O > tag=[term]`. Except that features like `help` and `help [builtin]` work differently for each and every program, so you can't really get used to them, neither to how to call them nor to which usually incomplete selection of information they might throw at you, whereas semantic tags work in a general and uniform way, and not only for .Ic, which is just one of many examples. > footnote: > [1] This also means that if an OpenBSD sysadmin tries to be "helpful > to newbies" by installing the bash they're maybe used to, they will by > default clobber access to OpenBSD's excellent help(1), and it would > take extra care to re-enable that and to then figure out a nice way to > still provide access to bash's builtin help too... aaargh! Maybe bash > on OpenBSD isn't the best choice really. Indeed, in particular not as a login shell. On the other hand, if a user explicitly types "bash", they get what they ask for, and there is nothing wrong with that. Yours, Ingo
Re: Future of X.org?
On Fri, 28 Jun 2019, gwes wrote: I regularly run programs on one machine connected to a display on another machine. AFAIK, the current state of Wayland makes that difficult. I confess to not following it closely. I also do it, and I also have no much idea of what is wayland. But I have the impression that some people want to substitute X11 with something that is not a replacement for it, that has other functionality. They confuse X11 with a mere graphical surface. Rodrigo
Re: cd command, chdir syscall, shell behavour
Oops, I just mistakenly attributed Ingo's earlier reply to Edgar. Apologies to both, and thanks very much for the help. Ian On 30/06/2019, ropers wrote: > On 30/06/2019, Edgar Pettijohn wrote: Then you need to say (...snip; see earlier email...) > > Thank you. That contained several useful hints I hadn't even figured > out I could look for there, although this too seems obvious in > retrospect. Maybe I'm not thinking about these things carefully enough > in advance. :) > >>> This is perfectly fine, exactly as it should be: >>> >>> schwarze@isnote $ man bash >>> man: No entry for bash in the manual. >>> schwarze@isnote $ pkglocate bin/bash | head -n1 >>> bash-5.0.7p0:shells/bash:/usr/local/bin/bash >>> >>> > To end on a positive: Can I add how much I appreciate that OpenBSD >>> > hard-links help(1) to man(1), >>> >>> Heh; deraadt@ did that on Sep 14, 1998 for OpenBSD 2.4 ... >>> >>> > and that man will default to `man help` when called as help? >>> >>> and aaron@ added the help(1) manual page on Oct 18, 1999 >>> for OpenBSD 2.6. >>> >>> > This elegant way of having OpenBSD respond to `help` is really >>> > n00b-friendly. >>> >>> And yet, even among those tiny innovations that are somehow neat, >>> not all get picked up elsewhere: >>> >>> https://man.openbsd.org/FreeBSD-12.0/help >>> https://man.openbsd.org/NetBSD-8.0/help >>> https://man.openbsd.org/Linux-5.01/help > > In bash, `help` is a shell builtin and does do something, though IMO, > the something that it does isn't initially as helpful as OpenBSD's > help(1), especially to newbies. [1] > > However, what it does do, i.e. > * print a list of bash builtins in response to `help`, or > * print bash builtin-specific help in response to `help [builtin]` > could well be helpful later and relates to what we discussed earlier. > Is man(1) plus info(1) plus bash's help some kind of triple > book-keeping or wheel-reinvention? Perhaps, but in terms of > convenience, bash's `help` and `help [builtin]` are stiff competition > to Edgar's earlier hints of `man -k Ic,Nm=[term]` and `man -O > tag=[term]`. > Don't get me wrong; I'm VERY grateful for the hints, and I don't think > I have or know of an ideal solution. All the same, I think this is > still an area where considerable possibility for user confusion yet > abounds. > > Ian > > footnote: > [1] This also means that if an OpenBSD sysadmin tries to be "helpful > to newbies" by installing the bash they're maybe used to, they will by > default clobber access to OpenBSD's excellent help(1), and it would > take extra care to re-enable that and to then figure out a nice way to > still provide access to bash's builtin help too... aaargh! Maybe bash > on OpenBSD isn't the best choice really. >
Re: cd command, chdir syscall, shell behavour
On 30/06/2019, Edgar Pettijohn wrote: >>> Then you need to say (...snip; see earlier email...) Thank you. That contained several useful hints I hadn't even figured out I could look for there, although this too seems obvious in retrospect. Maybe I'm not thinking about these things carefully enough in advance. :) >> This is perfectly fine, exactly as it should be: >> >> schwarze@isnote $ man bash >> man: No entry for bash in the manual. >> schwarze@isnote $ pkglocate bin/bash | head -n1 >> bash-5.0.7p0:shells/bash:/usr/local/bin/bash >> >> > To end on a positive: Can I add how much I appreciate that OpenBSD >> > hard-links help(1) to man(1), >> >> Heh; deraadt@ did that on Sep 14, 1998 for OpenBSD 2.4 ... >> >> > and that man will default to `man help` when called as help? >> >> and aaron@ added the help(1) manual page on Oct 18, 1999 >> for OpenBSD 2.6. >> >> > This elegant way of having OpenBSD respond to `help` is really >> > n00b-friendly. >> >> And yet, even among those tiny innovations that are somehow neat, >> not all get picked up elsewhere: >> >> https://man.openbsd.org/FreeBSD-12.0/help >> https://man.openbsd.org/NetBSD-8.0/help >> https://man.openbsd.org/Linux-5.01/help In bash, `help` is a shell builtin and does do something, though IMO, the something that it does isn't initially as helpful as OpenBSD's help(1), especially to newbies. [1] However, what it does do, i.e. * print a list of bash builtins in response to `help`, or * print bash builtin-specific help in response to `help [builtin]` could well be helpful later and relates to what we discussed earlier. Is man(1) plus info(1) plus bash's help some kind of triple book-keeping or wheel-reinvention? Perhaps, but in terms of convenience, bash's `help` and `help [builtin]` are stiff competition to Edgar's earlier hints of `man -k Ic,Nm=[term]` and `man -O tag=[term]`. Don't get me wrong; I'm VERY grateful for the hints, and I don't think I have or know of an ideal solution. All the same, I think this is still an area where considerable possibility for user confusion yet abounds. Ian footnote: [1] This also means that if an OpenBSD sysadmin tries to be "helpful to newbies" by installing the bash they're maybe used to, they will by default clobber access to OpenBSD's excellent help(1), and it would take extra care to re-enable that and to then figure out a nice way to still provide access to bash's builtin help too... aaargh! Maybe bash on OpenBSD isn't the best choice really.
