Re: Etnernal & infernal browser woes
Hi Chris, Chris Bennett wrote on Sat, Apr 29, 2017 at 07:10:05AM -0500: > Firefox [...] takes a long period to actually finish crashing It dumps core. That takes a long time because firefox tends to waste huge amounts of memory, and it's favourite pretext for crashing is ENOMEM, see errno(2), so especially at the time when it finally crashes, the core is often huge. schwarze@isnote $ cd schwarze@isnote $ ll *core -rw--- 1 schwarze schwarze 208248 Apr 19 21:03 firefox.core -rw--- 1 schwarze schwarze 4464720 Apr 18 16:48 man.core -rw--- 1 schwarze schwarze 488064 Feb 10 17:45 mandoc.core Yes, that core file over there is 2 GB. Yours, Ingo
Re: Status of OpenCVS
Hi, multiplex'd wrote on Thu, May 11, 2017 at 04:48:36PM +0100: > I recently stumbled across the OpenCVS webpages and I was wondering > what the status of the project is. It is dormant. While it is *almost* ready for production, actually trying to use it in production revealed instabilities that were non-trivial to debug, and nobody did the work to get if from "almost ready" to "reliable". Nobody can predict how much work that would require. If somebody seriously tried, it might get done in a month, or take a year, or fail completely. It is not typical for OpenBSD projects that they go dormant shortly before being ready for production, but this is one of the sad cases where that did happen. > The webpage says that it is to be released soon, > however commits to the CVS tree seem to be few and far between. > Is the codebase in a state where it could be ported to other > operating systems yet? Porting OpenBSD userland code to other operating systems (that are reasonably similar to POSIX) is in general not a big problem if you follow the practices established by OpenSSH and mandoc and LibreSSL, unless that code heavily relies on special OpenBSD kernel facilities, which certainly isn't the case here. You can certainly port it and run it elsewhere. But i wouldn't expect it to be more stable than on OpenBSD, so using it to manage important data is risky, unless you pay very close attention and are prepared to fix non-trivial bugs yourself (and send patches). Yours, Ingo
Re: unexpected behavior
Hi Edgar, Edgar Pettijohn wrote on Mon, May 15, 2017 at 06:57:57PM -0500: > I think this may be normal, but I can't seem to find it documented anywhere. > While viewing a man page in xterm if I hit the 'v' key it appears to open it > for editing in vi. I did so accidentally recently and at first I thought I > broke something because of all the "F^HFI^HIL^HLE^,etc" which I assume are > man markup characters. I looked around for documentation on this "feature", > but I'm not sure where to look vi, mandoc, xterm? So is this a bug somewhere > or expected behavior? It may be less(1) expected than you think, but it is. Actually editing the file is not very useful because it's a tmp file. To get out of vi(1) again, just use the normal ":q". For documentation, see http://man.openbsd.org/less#v or type "man less", then hit the keys ENTER, COLON, t, v, ENTER. If you don't like all that, you can set $ export LESSEDIT=false Yours, Ingo
Re: Sad story
L. R. S. wrote on Mon, Jun 05, 2017 at 12:14:51PM +0200: > Forgot the passphrase of a full-disk encrypted OpenBSD system ;_; > So many documents will be lost, like [coughs] accesses to NULL. Simply restore from backup. Or is that sad part of your story that your enemy stole that, the night before you forgot the passphrase, and it was unencrypted? SCNR, Ingo
Re: Can I use OpenBSD as a desktop system?
Johan Mellberg wrote on Fri, Jun 09, 2017 at 10:06:18PM +0200: > 2017-06-09 21:39 GMT+02:00 SOUL_OF_ROOT 55 : >> Can I use OpenBSD as a desktop system? > Yes. To provide an example: On my private desktops and laptops, i never ran anything else since 2001. And even at work, i only made two exceptions: >From 2003 to 2006, i had one Windows desktop at work because i had to run a specific commercial binary-only accounting software. And for a few months in 2007, i ran Debian GNU/Linux on one desktop at a new job in a software company before i defied the official company policy of "you can run whatever you want on your desktop, but it must be Linux" and installed OpenBSD instead. If anybody had ever asked, my answer would have been "I consider OpenBSD a Linux distribution: for all practical purposes, i can run the same software on it, and i can work much more efficiently with it." But nobody ever asked. For the last ten years, nothing else on the desktop, neither privately nor at work... Yours, Ingo
Re: Current FreeBSD looking to switch to OpenBSD
Hi, Baho Utot wrote on Sat, Jun 10, 2017 at 01:30:46PM -0400: > 1.Where can I get a list of graphics card that are supported? $ man -s 4 -k graphic drm radeon On modern amd64, it is mostly intel(4) and radeon(4). Stay away from NVidia unless you want to use vga(4). > 2.Where can I find information on dual booting OpenBSD > and Windows? Don't do it. Use separate hardware. Dual booting is only asking for trouble. It's not impossible if you know what you are doing, but even then, it's not worth it. If you have to ask how it works, just don't do it. > 4.Is the manul that is online, can it be obtained on a pdf? $ time man -M/usr/share/man -Tpdf -ak Nd~. > all.pdf 1m03.33s real 0m52.16s user 0m03.22s system $ wc all.pdf 165640334 587327767 3457322371 all.pdf That's only the base system manual (without X11 = Xenocara). Even though building it with mandoc(1) only takes a minute on my notebook, i'm not sure it's a great idea to put all that information into a single file. It's a 15458 page, 3.5 Gigabyte PDF. If you want to read specific sections, you can use more specific commands, see apropos(1). Or you can view individual typeset pages like this: $ doas pkg_add gv $ man -Tps pledge | gv - > 5.Where can I find information on wifi support? $ man -k wireless https://www.openbsd.org/faq/faq6.html#Wireless Yours, Ingo
Re: Current FreeBSD looking to switch to OpenBSD
Hi Erling,
Erling Westenvik wrote on Sat, Jun 10, 2017 at 10:08:57PM +0200:
> Probably a stupid question but:
> Why isn't the -T switch documented in man(1)?
Not a stupid question at all.
First answer:
It is, look at man(1) and you will find this sentence:
The options -IKOTW are also supported and are documented in mandoc(1).
Second answer:
The reason why it isn't in the SYNOPSIS, in the usage(), and in the
main options list is that jmc@ insisted that the man(1) manual page
better be short and simple, and advanced stuff that is more fully
documented in mandoc(1), and more often needed in mandoc(1), not
be duplicated there. He kind of has a point. The man(1) manual
is most important for beginners and should better not overwhelm
them. Advanced users are likely to also find their way if finding
the advanced features requires carefully studying the *whole* text.
I designed the user interface of the OpenBSD versions of man(1),
apropos(1), whatis(1), and mandoc(1) such that all four support
exactly the same options, such that you only need to learn one set
of options, which is not true on other operating systems. If you
like a bit of confusion now and then, take a look at:
http://mdocml.bsd.lv/man/man.options.1.html
Yes, -AxY are the only three option letters not yet taken, and all
except -BGJjNOUXyZz have conflicting meanings; the record holders
are -c with nine different meanings, -p and -s with eight, -f and
-w with seven, and several with six different meanings. Talk about
history -- as if nobody ever looked at what anybody else did...
On OpenBSD, if you like, you can access all functionality of the
four utilities with man(1):
apropos == man -k
whatis == man -f
mandoc == man -cl
Also, our options are designed to naturally form four groups
and are firmly grounded in BSD history, with one exception
adopted from Colin Watson's Debian Linux man-db package:
1. Search options decide which directories are used for searches:
-M override MANPATH ("manpath", 4.3BSD man, 1986)
-m augment MANPATH ("manpath", 4.3BSD-Reno man, 1990)
-S restrict architecture ("subsection", OpenBSD 2.3 man, 1998)
-s restrict manual section ("section", OpenBSD 2.3 man, 1998)
2. Input options decide how command line arguments are interpreted:
-k use full search query syntax ("keywords", 4BSD man, 1980)
(default for -k) search substrings in title lines only
-f complete words to be matched in names only ("find", 4BSD man, 1980)
(default for man(1)) exact match of complete names
-l accept file names, ignore search options ("local", man-db 2.2a7, 1994)
3. Parse options influence interpretation of the input files:
-I set default value for .Os macro ("input", OpenBSD 5.2 mandoc, 2012)
-K force an input character encoding ("enKoding", groff-1.20, 2005)
-m force an input macro language ("macro language", v7 troff, 1979)
4. Output options decide how output is presented:
-a show all matching pages, formatted ("all", 4.3BSD-Tahoe man, 1988)
(default for man(1)) show the first matching page, formatted
-T select an output format for formatting ("terminal", v7 nroff, 1979)
-O set output format specific options ("output", OpenBSD 4.8 mandoc, 2009)
-c do no use a pager ("copy to stdout", 4.3BSD-Reno man, 1990)
-h show the SYNOPSIS sections only ("head", 4.3BSD-Net/2 man, 1991)
(default for -k and -h) show title lines only
-w show file names only ("where", v7 man, 1979)
-W select a message level ("warn", OpenBSD 4.8 mandoc, 2009)
5. One special option can influence search, parse, and output options:
-C select alternate config file ("config", 4.4BSD-Lite1 apropos, 1994)
Unfortunately, this structure cannot easily be represented in
the manual pages without bloating them and making them less readable.
Several of the option letters could be more mnemonic. But they
come from six different programs (troff, nroff, groff, man, apropos,
mandoc) and five different operating systems (Version 7 AT&T Unix,
4.xBSD, groff, Debian man-db, OpenBSD) and the oldest (-mTw) have
been established since 1979, so people have become so used to them
for several decades that it's much too late to change any of them.
Yours,
Ingo
Re: dokuwiki - /dev/urandom issue
Hi Asbel, Asbel Kiprop wrote on Sun, Jun 11, 2017 at 09:24:23PM +0300: > cat: /var/www/dev/urandom: Device not configured By default, /var is mounted nodev. See mount(8), fstab(5). Yours, Ingo
Re: bug tracking system for OpenBSD
Hi, Harald Dunkel wrote on Mon, Jun 19, 2017 at 06:51:24PM +0200: > would it be possible to establish a real bug tracking system > for OpenBSD? There is exactly one reason it hasn't happened yet: No developer has been able and willing to invest the additional time required to set it up and to commit to maintaining it. Also, it doesn't help that no bugtracking software exists that OpenBSD developers are enthusiastic about. But that is a very minor problem. If a developer would decide to set up a bugtracker, i have no doubt that they would find usable software for it. So please do not discuss which is the best bugtracker software, that would be a completely pointless discussion. Besides, maybe Kristaps will write it on some cold, rainy July day in La Valetta. *eg* Yours, Ingo
Re: bug tracking system for OpenBSD
Hi, Carlin Bingham wrote on Tue, Jun 20, 2017 at 11:20:10PM +1200: > On Mon, Jun 19, 2017 at 06:51:24PM +0200, Harald Dunkel wrote: >> would it be possible to establish a real bug tracking system for >> OpenBSD? Something with bug owner, severity, attachments, assignee, >> and (very important) some reliable response time and a databse >> to search for known problems? > There was a GSOC project proposed for this in 2014 but it apparently > didn't get any takers. It had fairly clear requirements: > > "A bug tracking system that integrates with sendbug(1) and doesn't suck > dead bunnies through bent straws." > > https://web.archive.org/web/20140303013316/http://www.openbsdfoundation.org/gsoc2014.html#bug-tracking When i read those sentences back then, i instantly wondered how a GSOC project might help with the maintenance task. While a few GSOC projects do produce useful code (my subjective impression being that far more fail completely), even those few that succeed are notorious for causing substantial workload for developers - both for the paperworks with Google and to get the code into the tree. The most common reason for failure is that even though some interesting code does get written, it never gets hammered into shape sufficiently for commit. The GSOC student often cannot do it due to lack of skill and experience, and also due to lack of time after the end of the summer; the mentoring developers are often overwhelmed with the amount of work required: getting good and "almost ready" code *really* ready for commit is often much more work than people unfamiliar with OpenBSD development would believe. Getting from "almost ready" to "ready" can be more work than getting from "nothing" to "almost ready". As a drastic example, converting apropos(1) from dbopen(3) to SQLite3 took Kristaps a few weeks to get it almost ready, and after that it took me a year to get it ready and committed. The most successful OpenBSD GSOC project ever, mandoc -Tps, reduced the workload by having the paperwork done by NetBSD, and i only had to do seven commits in the time from June 10 to July 31, 2010, without having to tweak the code because it was so good, and which i didn't even need OKs for, so it barely caused any work at all. That was not at all typical to a very unusual degree. But yet, long-term maintenance of the -Tps and -Tpdf code was both seriously neglected (not a huge problem because it is not exactly business- critical functionality) and it did cause some maintenance work for me now and then (not so much that it even became a problem, but it was noticeable at some points). So, while GSOC might have occasional benefits, - it definitely never reduces the workload for existing developers, quite to the contrary - it has an extremely low efficiency in bringing in new developers (even though that does happen in rare, exceptional cases) - it rarely results in code that matures enough to get used in practice (even though that does happen in a few cases) - i'm not aware of a single example where it resulted in viable long-term project infrastructure Yours, Ingo
Re: Advice on partiotion scheme
Hi, pipfsta...@openmailbox.org wrote on Sat, Jul 01, 2017 at 10:15:19AM +: > I want to use openbsd for daily tasks on my laptop, I'm planning to build > ports by hand and I want to try some development of the system itself. > > At the moment I'm just playing around and I faced a little problem: space > allocated by default partitioning to /usr ran out in a blink of an eye. > Current df: > > $ df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd0a 1005M 61.1M893M 6%/ > /dev/sd0k 98.8G3.2G 90.6G 3%/home > /dev/sd0d 3.9G724M3.0G19%/tmp > /dev/sd0f 2.0G2.0G -91.1M 105%/usr > /dev/sd0g 1005M177M778M19%/usr/X11R6 > /dev/sd0h 9.8G1.0G8.3G11%/usr/local > /dev/sd0j 2.0G850K1.9G 0%/usr/obj If you want to do base system development including building different kernels and building releases, you might run out of space here, too. I'm currently using: /dev/sd0d 3.9G2.1G1.6G57%/usr/obj > /dev/sd0i 2.0G861M1.0G45%/usr/src > /dev/sd0e 18.3G 12.0M 17.3G 0%/var You did not mention whether you want to work on Xenocara, too. If so, here is what i am using: /dev/sd0k 2.0G855M1.0G45%/usr/xenocara /dev/sd0l 2.0G2.0K1.9G 0%/usr/xobj Even if you don't want to work on Xenocara right now, i'd recommend to leave at least 4 GB unallocated in case you change your mind later - or even better, much more than 4 GB, because other needs you didn't think of in time might come up later. > I want to reinstall OpenBSD from a snapshot and pick a custom > partition scheme. Based on the needs described above, what > partitions should I keep All of them. > and what sizes should I peek? None of them except making /usr/obj/ larger. > I know about the workaround with the /usr > partition by setting a few variables (WRKOBJDIR, ...) > in /etc/mk.conf, but I'm not sure if it's the best solution. It is not. Setting up additional partitions for your needs is much more robust and less error-prone. > May be just give more space for /usr/? No, you really don't want /usr/bin/ and /usr/ports/pobj/ to reside on the same file system. For occasional, mild work on ports, here is what i am using: /dev/sd0m 5.9G4.8G794M86%/usr/ports /dev/sd0n 19.7G 17.2G1.5G92%/usr/ports/pobj I cleaned out /usr/ports/pobj/ recently, by the way, deleting more than 10G. You see, in sharp contrast to most other partitions, /usr/ports/ and /usr/ports/pobj/ always tend to fill up. Ports are pigs. If you want to work on stuff like KDE, Gnome, or LibreOffice, the above partition sizes would be completely inadequate. For most other partitions, simply allocating the maximum that reasonable use might require is often a good solution, even if you don't plan to do the related work just yet. Not so for ports. Allocating ports partitions that feel comfortable for full bulk builds on a notebook might consume more space than you want to afford. So it really depends on what it is that you want to build in ports land, and how many build directories of large ports you need to keep around at the same time... If you feel completely at a loss now, i'd recommend to start with about 8 plus 40 GB and leave many hundred GB unallocated, such that you can allocate a much larger /usr/ports/pobj/ when needed. And then see for yourself how much *you* need in practice. That may be more or less than *I* need. > Also, is so much space for /var really needed? It empty at the > moment, will daily desktop usage/little OpenBSD development fill > it up? It depends on what you are doing. Keep in mind that OpenBSD is a general-purpose system, so the default install is also supposed to be adequate for Internet servers unless they have special needs. On a laptop, you may get away with much less space for /var/, maybe with as little as a few 100M, but in general, i don't recommend tuning the defaults *down*. Even on a laptop, at some point, you may want to test httpd(8), put some data into /var/www/, and -- oops... Or other things you don't anticipate right now. Also, /var/ is the place where running out of space is *least* funny. If that happens to you, system logging comes to a grinding halt, email may no longer arrive, pkg_add(1), sysmerge(8), syspatch(8) go out of commission, and so on and so forth, which doesn't exactly help to get the system back into working order. > Also, I'm confused with such a small amount of space for /. > Is 1G enough? Absolutely. I contains a HUGE safety margin. I have often run machines with HALF a GB at / or even less and don't remember problems with that - but nowadays, thinking about units less than a GB is really not very useful. Here is what i currently have: /dev/sd0a 1005M206M749M22%/ Yours, Ingo
Re: A question of lock usage in OpenBSD kernel code
Hi, J Doe wrote on Tue, Jul 04, 2017 at 12:02:42AM -0400: > I would like to target OpenBSD with some networking code I am > writing in C++ (again, in user land, not kernel networking code). > I'd like to follow the OpenBSD way The OpenBSD way is to write userland network daemons in C, not in C++. > and make use of the safer family of C functions and best practices > that OpenBSD makes use of. There are no OpenBSD best practices for C++. Most developers - certainly not all - dislike C++ as overengineered, overcomplicated, slow to compile, hard to debug, and for its utterly inconsistent design and excessively heavy tool chain. While nobody denies that there may be use cases for C++, even those who like the language do not use it when writing software for OpenBSD. Code written in C++ (except, maybe, if part of a C++ compiler or closely related tools) is unlikely to be accepted in the base system, and each time something in base that is written in C++ gets replaced by something that is not, i hear cheering. > I was thinking the best way to get started would be to spend two > to three months reading No. Certainly not. By all means, do read code, that is very important, but do it in parallel to getting hands-on experience by fixing bugs (and maybe implementing very simple features, which is *much* harder, in particular because new features are often rejected - it is not easy for beginners to figure out which new feature will be considered useful and which won't). Also, don't stop reading code after a few months; never stop doing that, at least not before you die. > there might be a man page that codifies best practices for OpenBSD > development - not the coding style but more of an overview of best > practices - such as, "Prefer OpenBSD specific functionXYZ() as > opposed to strncpy()" (a contrived example but something in that > respect). Such a manpage definitely doesn't exist, or i would have heard about it. If best practice recommendations exist with respect to a specific function, they are often explained in the manual page of that function. For example, i added a notice to prefer getline(3) to the top of the fgetln(3) manual just a few days ago. Such recommendations are sometimes placed at the top of the DESCRIPTION, sometimes in EXAMPLES or CAVEATS, and may also appear in other places. Sometimes, they are missing completely. For example, to my surprise, strcpy(3) only mentions strlcpy(3) below SEE ALSO. > Separate from the possible man page, are there any relatively > up-to-date examples that developers have been using to learn best > practices for writing software for OpenBSD? No. Developers are learning by doing, and by advice from fellow developers which they receive when posting their patches for review. Yours, Ingo
Re: Pq rendering in ports(7)
Hi Jan,
Jan Stary wrote on Mon, Jul 10, 2017 at 05:57:08PM +0200:
> This is how ports.7 is rendered on my 6.1-current:
>
> For more information about using ports, see The OpenBSD Ports System (
> https://www.openbsd.org/faq/faq15.html#Ports
> ).For information about creating new ports, see the OpenBSD
> Porter's
> Handbook (
> https://www.openbsd.org/faq/ports/
> ).
That is much better than what groff renders, which is:
For more information about using ports, see The OpenBSD Ports System (
For information about creating new ports, see the
OpenBSD https://www.openbsd.org/faq/faq15.html#Ports). Porter's Handbook
(
For a detailed description of the build process, see
https://www.openbsd.org/faq/ports/).
The groff rendering is completely broken, the mandoc rendering is much
better...
> The code snippet is
>
> .Pp
> For more information about using ports, see
> The
> .Ox
> Ports System
> .Pq Lk https://www.openbsd.org/faq/faq15.html#Ports .
> For information about creating new ports, see
> the
> .Ox
> Porter's Handbook
> .Pq Lk https://www.openbsd.org/faq/ports/ .
... so that mdoc(7) source code is not portable.
Maybe mandoc should warn about the portability issue? Possibly,
but i would have to understand what exactly is broken in groff, so
what the permissible syntax is. Or even better, we should fix groff?
That may be hard.
> The Pq rendering doesn't seem right: in the first case,
> the whole "( http:/// )" would fit nicely on the second line;
> in the second case, it would in fact fit nicely on the same line
> - the breaks after the '(' and before the ')' seem superfluous.
In groff, there is a length threshold. Shorter links are rendered
inline, longer ones in what resembles a .D1 display. That is not
completely unreasonable, so mandoc should follow. I recently did
quite some work on .Lk rendering, and most valid constructs - i.e.
those rendering reasonably with groff - now render identically with
groff and mandoc. There may still be bugs, of course. At some
point, i got tired of how complicated this macro is to implement
and stopped digging for more edge cases.
Note that the .Pq is *outside* the .Lk, so it is logical that the
parentheses appear *outside* the display. If you want the parentheses
inside the display, you might feel tempted to write something like
For more information about using ports, see
The
.Ox
Ports System
.Lk ( https://www.openbsd.org/faq/faq15.html#Ports ) .
For information about creating new ports, see
the
.Ox
Porter's Handbook
.Lk ( https://www.openbsd.org/faq/ports/ ) .
But that also breaks with groff:
For more information about using ports, see The OpenBSD Ports System
https://www.openbsd.org/faq/faq15.html#Ports: (). For information about
creating new ports, see the OpenBSD Porter's Handbook
https://www.openbsd.org/faq/ports/: ().
Since leading opening delimiters fail with groff, i was lazy and did
not implement keeping them in scope in mandoc either, but the mandoc
rendering is still better than the groff rendering:
For more information about using ports, see The OpenBSD Ports System (
https://www.openbsd.org/faq/faq15.html#Ports).
For information about creating new ports, see the OpenBSD Porter's
Handbook (
https://www.openbsd.org/faq/ports/).
The .Lk macro is relatively young. If i read the source history
correctly, it was added as part of the big groff-1.17 mdoc rewrite
in 2000. Lk is more fragile than most other mdoc(7) macros.
Probably, some work should be done to make the implementation more
robust or at least to document the valid syntax more strictly. The
current groff implementation looks rather sloppy to me. I already
got two improvements committed to groff back in April 2017, but the
situation with .Lk is still far from satisfactory.
All that said, see below for what i just committed to improve the
quality and in particular the portability of the manual, using the
standard idiom rather than some hand-rolled approach.
Yours,
Ingo
CVSROOT:/cvs
Module name:src
Changes by: schwa...@cvs.openbsd.org2017/07/10 16:48:00
Modified files:
share/man/man7 : ports.7
Log message:
Fix non-portable .Lk usage that results in complete garbage with groff
and looks better, but still not good with mandoc.
Issue pointed out by Jan Stary .
Index: ports.7
===
RCS file: /cvs/src/share/man/man7/ports.7,v
retrieving revision 1.112
diff -u -r1.112 ports.7
--- ports.7 28 Jun 2017 10:24:23 - 1.112
+++ ports.7 10 Jul 2017 22:43:40 -
@@ -60,15 +60,9 @@
to install the application.
.Pp
For more information about using ports, see
-The
-.Ox
-Ports System
-.Pq Lk https
Re: Pq rendering in ports(7)
Hi Jan, Jan Stary wrote on Tue, Jul 11, 2017 at 11:50:01AM +0200: > Ingo Schwarze wrote: >> Maybe mandoc should warn about the portability issue? Possibly, >> but i would have to understand what exactly is broken in groff, so >> what the permissible syntax is. Or even better, we should fix groff? >> That may be hard. > Would you please kindly bring it up on the groff list, > if you think groff should address this too? (I can do it, > but it would get more momentum comming from you.) No, i won't, and please don't. Groff has no maintainer, and all the people working on it are continuously overwhelmed with work. So such a bug report will not result in getting anything fixed, a bug report without a patch is nothing but noise and distraction on the list and even in the bugtracker. Of course, people who don't know how badly groff is pressed for manpower might still do it. But people who know better really shouldn't. Even when i send patches that are fixing simple bugs, unconcontroversial, small, and easy to verify, and that i have already tested according to OpenBSD quality standards, it is very hard to get them them into groff. It often takes months for someone to come round and commit them, even with occasional, non-intrusive reminders. In one case, it took about two years. I have been offered groff commit access, which would mitigate the problem, because with commit access, i would both commit my own patches that are obviously uncontroversial and commit good patches that now rot in the bugtracker. But the FSF required me to sign an FSF Copyright assignment contract according to Massachusetts Law that i deem illegal according to International Law (and also according to German Law) and that contains provisions that in some admittedly unlikely cases of neglect, i may become liable to pay damages to the FSF if i fail to comply with some of their legal rules. So that is two reasons why i feel unable and unwilling to sign that contract. The former groff maintainer, Werner Lemberg, asked the FSF Board of Directors to allow contributions from occasional contributors without a copyright assignment, simply covered by either a ISC-style license - which allows integration into a GPL project with no problems whatsoever - or a public domain dedication - which might also work, whichever of the two the FSF Directors and their lawyers prefer. Werner argued to the Board of Directors that allowing that was required for the viability of the project, to help the already very difficult task of acquiring urgently needed new contributors. He wasn't the first maintainer of a core GNU project to argue that way. The FSF Copyright Clerk wrote to me in January 2014, "We are going to look into allowing contributions with a license. This will take time as it is a policy change. Thank you for your patience." That is the last i heard about that matter so far. >> Note that the .Pq is *outside* the .Lk, so it is logical that the >> parentheses appear *outside* the display. > Ah, so is this being "outside of the display" > (meaning "outside of the kind-of-D1-line" here) > that introduces the line breaks? Yes. >> If you want the parentheses >> inside the display, you might feel tempted to write something like >> >> For more information about using ports, see >> The >> .Ox >> Ports System >> .Lk ( https://www.openbsd.org/faq/faq15.html#Ports ) . >> For information about creating new ports, see >> the >> .Ox >> Porter's Handbook >> .Lk ( https://www.openbsd.org/faq/ports/ ) . >> >> But that also breaks with groff: >> >> For more information about using ports, see The OpenBSD Ports System >> https://www.openbsd.org/faq/faq15.html#Ports: (). For information about >> creating new ports, see the OpenBSD Porter's Handbook >> https://www.openbsd.org/faq/ports/: (). > It would also be semantically wrong, right? > The parentheses surely are not part of the link. Not necessarily semantically wrong, no. The mdoc(7) language uses a convention that leading opening and trailing closing delimiters found on the input line of many macros fall out of the logical scope of those macros, see the subsection "Delimiters" in the mdoc(7) manual for details. In mandoc, the .Lk macro already handles closing delimiters in an even more special way than most other macros: They fall out of the (semantic) link description scope, but remain in the (physical, .D1-like) display scope. Note that the trailing full stop in many of the examples we are discussing here already uses that, and nobody asked how it works because it just feels natural in mdoc(7). In mandoc, even the opening parenthesis falls out of the .Lk scope; i m
Re: Security report with mail permissions
Hi Mik, not quoting anything because your posting is too ill-formatted. Yours is a frequently answered question. The directory /var/mail/ is intended for individual user mailboxes. If you need a directory for a different purpose - like mailbox subhierarchies for virtual domains - create a different directory. If you want to do daily checks on that different directory checking for a different format, implement your own checks in daily.local(8). Yours, Ingo
Re: Minium System Requirements
Hi, Max Power wrote on Sat, Jul 22, 2017 at 07:45:15PM +0200: > I'm looking for on http://www.openbsd.org but... > Where Can I find the official documentation about > the 'minimum system requirements' about OpenBSD? That varies from architecture to architecture and from time to time, so there is no official statement. To provide an example for i386, i ran OpenBSD in production on 486-SX25 with 16 MB of RAM and 200 MB of HD disk space several years ago, and less than 100 MB of the disk space were actually used. Nowadays, you would probably need at least 486DX, about 64 MB of RAM, and about 1 GB of HD disk space. For other architectures, your mileage may vary. In any case, you need an FPU and an RTC. That said, your question rarely matters in practice. For almost any practical application, what matters is the resource hunger of the application programs you want to run, not the minimum requirements of OpenBSD. You want to run a graphical web browser? Well, don't try that with 64 MB of RAM and 1 GB of disk. Yours, Ingo
Re: Minium System Requirements
Max Power wrote on Sat, Jul 22, 2017 at 10:49:05PM +0200: > but In addition to your advice... > possible that there is no official documentation? > This is the questions...! And i already answered that: No, there isn't, because: 1. It varies from platform to platform. 2. It varies from time to time. 3. It is rarely relevant because application software usually is the bottleneck in practice, *not* the OS. So, 1 & 2 mean that maintaining such a list would cause considerable work for developers, and 3 means that it would be virtually useless. That's why we don't do it. Yours, Ingo
Re: Supporting OpenBSD
Hi Radoslav, Radoslav Mirza wrote on Wed, Aug 02, 2017 at 01:21:44PM +0930: > Are there any resources that point to where I can begin to help > with the project? We don't maintain any global TODO lists, it's too little benefit for too much work. > Such as junior jobs, documentation etc. The quality of OpenBSD documentation implies that finding bugs in documentation is not much easier than finding bugs in code. We do not consider documentation a junior job, but something to be done together with the code, by the developers who write the code. I am aware of a number of documentation tasks, but all of them are seriously difficult: For example, improving event(3), improving sysctl(3), documenting undocumented functions in LibreSSL, cleaning up LibreSSL manual pages in general, and figuring out how to fix OpenGL documentation. That said, there happens to be a TODO list for documentation tools, as opposed to documentation tasks: http://mandoc.bsd.lv/cgi-bin/cvsweb/TODO?rev=HEAD Most entries on that list are of high difficulty, but a few are easy. The most important qualification round here is the ability to find out what you are interested in, what you are capable of, to identify tasks *yourself* that you want to spend time on and are capable of making progress with. Nobody can tell you what that is. Very many different areas could benefit from work. And after that, the next most important qualification is being able to learn from doing, from reading code, from listening to advice, and from following ongoing discussions (in about that order). > plan to head down the networking path Fine, so watch your own networking needs (or the networking needs that come up in the context of your research & studies), use OpenBSD for them, identify bug or feature gaps, try to fix them, send patches if you succeed, or ask *specific* questions for advice if you get stuck on a problem and can't make progress. In particular at first, avoid spending long times (more than a few days) on a problem before talking to somebody about the (even preliminary) results, because spending weeks, then finding out that the basic approach was misguided, is frustrating. Yours, Ingo
Re: event.3: libevent no longer prints to stderr
Hi Rob, thanks for looking at libevent documentation. It is in dire need of improvements in multiple respects. Rob Pierce wrote on Fri, Aug 04, 2017 at 10:21:16AM -0400: > As of the last commit to src/lib/libevent/log.c the library > no longer prints to stderr. Update man page accordingly. > > Ok? But honestly, i'm not convinced that this patch is right. Look at event.c. EVENT_SHOW_METHOD is still inspected (line 154), and if it is set, the library does issue a message. But looking at the code and at the documentation, i instantly see lots and lots of issues that need fixing. Unsorted: * EVENT_SHOW_METHOD ought to be documented in the ENVIRONMENT section. The section name "ADDITIONAL NOTES" is bogus. * If you document an ENVIRONMENT variable, you should also say which value(s) it is supposed to have (in this case, the value is ignored, and even an empty value counts as "set", which is not at all obvious). * The information is missing that that the variable is ignored in setuid and setgid programs as defined by issetugid(2). * Talking about "displaying" something is useless in library documentation. You also have to explain where the message will appear. Certainly not on stdout, right? * In this case, the message won't appear anywhere at all by default, not even in the system logs. * To make *any* messages from libevent appear anywhere at all, the application program has to supply a logging callback function using the public interface function event_set_log_callback(3). Unfortunately, man -k tells me that function isn't documented anywhere at all. A classic case of user-level RTFS... :-( * Don't you dare add yet more functions to event(3). It is already of excessive size and conflating documentation for classes of functions almost unrelated to each other - like, what's the point of having signal_set(3) and bufferevent_read(3) in the same manual page? I dimly remeber that somebody tried and started to clean this mess up some years ago, but wasn't persistent enough to go anywhere with it. If you want to look at that and don't find it instantly, i can dig it up for you. Or you can simply start from scratch, the old discussion didn't go so far that much would be lost starting over. If you want to tackle this, expect several days of work, involving much reading of code. Yours, Ingo > Index: event.3 > === > RCS file: /cvs/src/lib/libevent/event.3,v > retrieving revision 1.53 > diff -u -p -r1.53 event.3 > --- event.3 29 Jun 2017 01:25:59 - 1.53 > +++ event.3 4 Aug 2017 14:08:44 - > @@ -517,10 +517,6 @@ by setting the environment variable > or > .Va EVENT_NOSELECT , > respectively. > -By setting the environment variable > -.Va EVENT_SHOW_METHOD , > -.Nm libevent > -displays the kernel notification method that it uses. > .Sh RETURN VALUES > Upon successful completion > .Fn event_add
Re: Please Advise on licencing
Hi, Reyk Floeter wrote on Fri, Aug 04, 2017 at 08:41:18AM +0200: > Am 04.08.2017 um 05:11 schrieb Siju George : >> I want this information to be available to all without discrimination. >> Which is the best licence I can give them? > the license is your choice ;-) While that is both true and important, there is also a definitive and objective answer to the question, quoting from what i wrote on http://www.openbsd.org/policy.html The above observations regarding moral rights imply that putting code under an ISC or two-clause BSD license essentially makes the code as free as it can possibly get. Modifying the wording of these licenses can only result in one of the three following effects: 1. making the code less free by adding additional restrictions regarding its use, copying, modification or distribution; 2. or effectively not changing anything by merely changing the wording, but not changing anything substantial regarding the legal content; 3. or making the license illegal by attempting to deprive the authors of rights they cannot legally give away. Some examples: * The GPL is an example of case 1 (not free). * Allowing anybody to relicence is an example of case 2 when added as an additional right to an ISC license. At first, it might seem that grants an additional right. But that right is utterly useless: The license is already as free as it can be, so relicensing cannot grant additional rights, and relicensing under more restrictive terms is pointless because the code is already available under ISC and will remain so. Note that relicensing permission is *only* irrelevant for ISC and Berkeley 2-clause. If code is under a not fully free license (like GPL or Apache 2.0 or CDDL), then granting the right to relicense suddenly makes the code fully free, because anybody can then go ahead and (legally and morally legitimately) re-release under ISC. * "Do whatever you like with this code" is an example of case 3. It is misleading in so far as the author *still* retains some rights under international law, specifically the Berne Convention, and there are things you are *still* prohibited from doing with the code, and it is not a good idea to mislead the unwary. Besides, it is dangerous because nobody knows whether some judge in some obscure jurisdiction might rule that "whatever you like" is not specific enough to include "distribute changed versions for profit as part of your private business" (or not specific enough for whatever might be considered to require *explicit* permission in that jurisdiction). Or some judge might even rule that is outright invalid in the first place because of the obvious violation of the Berne Convention and consequently grants no rights whatsoever. Using non-standard or fuzzy wording may potentially open you up to surprises in some jurisdictions. Yours, Ingo
Re: Please Advise on licencing
Hi Siju, Siju George wrote on Sat, Aug 05, 2017 at 06:50:12AM +0530: > In a code repository should the licence wording be on every file ? Best practice is: 1. To have at least one line containing "Copyright (c) ..." at the top of each file containing copyrightable content. 2. Each author (natural person, NOT legal entity like corporations or foundations) who made copyrightable contributions to the file of which at least parts are still contained in the file must be mentioned on such a line. If an author did transfer their economic rights (which doesn't really make much sense for ISC or BSD 2-clause licensed code, but nonetheless, it is occasionally done), you can list the legal entity that acquired the economic rights, but then it becomes important to add a line, below the Copyright notice, reading, for example: Parts of this file were written by (name of natural person) for (name of legal entity). The reason is that the actual authors retain some inalienable rights, even when working for hire or contract, and the right to be know of as the author is one of these rights that can neither be sold nor be given away. 3. Each Copyright line must contain one year number, separated with commas, for each year in which that author made copyrightable additions to the file that are still present in the file. Ranges of years separated with dashes are only acceptable if that author also made such contributions in each of the years between the endpoints of the range. Usually, only use ranges on lines that would otherwise become too long. Look at /usr/src/usr.bin/mandoc/mdoc_term.c for an example demonstrating all these rules. The full text of the license should follow this Copyright notice in each file. That said, from a legal standpoint, it is sufficient to have one license for each Work, so having one Copyright notice for the whole Work (e.g., program or package) is legally sufficient, too. But that is not a particularly good idea for several reasons: 1. It is less clear and can cause doubt as to which files are covered by the central Copyright notice and license. 2. It is very hard to maintain correctly. Care is already needed when maintaining the notices in individual files, and maintaining a central notice correctly is even harder because it is no longer even clear in which files to look for the contributions of the various authors. 3. In practice, you will probably sooner or later include files from third parties that are available under free licenses. In that case, leaving the Copyright notices and licenses in place in those included files is usually required by the third party licenses, and those licenses often differs slightly from the one you are using for your own Work. So you end up with some files with Copyright notices and licenses and some without, which exacerbates the problem explained in item 1. 4. People maintaining other software will occasionally pick files from your software and copy them to their own package. If you failed to add a Copyright notice and license to a file that gets picked in this way, there is a higher risk that the person taking the file forgets to copy your Copyright notice and license into the file before redistributing it. And worse, how is that person even supposed to figure out who, and during which years, contributed to that particular file? Basically, that poor soul will be forced to analyze the complete VCS commit history for the file and reconstruct the Copyright notice from scratch. > Or just in a file named "Licence" in the root folder ? Best practice is to do that *in addition*, because with many files, it can be hard to figure out the full list of Copyright holders and applicable licenses, and also because you almost certainly want to state *somewhere* which the preferred license is for new contributions to the project. For an example of such an additional central file demonstrating many useful features of such a central file, refer to http://mandoc.bsd.lv/LICENSE Oh, and very important: Never add any Copyright or license goo to the displayed text of any manual page or the stdout or stderr output of any program. Copyright notices and licenses belong into the source code (of programs and documentation), *NEVER UNDER ANY CIRCUMSTANCES* into any text displayed to the user. I regard displaying Copyright notices or licenses to the user as exceedingly impolite, because you are basically slapping the user into the face with this sneer: i value your time so little that i encumber the output i show to you with irrelevant text, with text that i know for sure you will *not* need each and every time you run the program or open the documentation. Yours, Ingo
Re: OpenBSD Traning Docs / How Tos
Hi Tom, you are aware that the term "HOWTO" is very strongly detested round here, right? It is considered a synonym for so-called documentation that is imprecise, unsystematic, and tells the user to type some random commands they won't understand because the HOWTO doesn't really explain how things actually work. Tom Smyth wrote on Mon, Aug 07, 2017 at 11:46:46PM +0100: > Im currently working on internal training documentation for > our operations and field teams for dealing with OpenBSD based > equipment. These documents would focus on OpenBSDs Network stack > and its capabilities, diagnostics and configuration manipulation It would probably be hard to pick an area where working on the documentation is harder than in the vicinity of the network stack. Some important manual pages in that area are below-average quality both regarding content and markup (including pf.conf(5) and ifconfig(8)), and that is not a coincidence: The subject matter is unusually difficult, the number of features to explain is unusually large, the number of people qualified to judge the accuracy of the manual pages and proposed changes is unusually small, and many of them are unusually busy. > Since Im going to that trouble I thought maybe my effort could > be aligned with the goals of the project, As a matter of principle, OpenBSD documentation is reference documentation. So if you want to help the project, that would mean improving manual pages (or maybe occasionally the FAQ, but much less frequently). Both aim for exactness and conciseness above all else, so writing substantial amounts of new text is unlikely to help. > and perhaps reduce the workload from some of the developers I'm not aware of any developers who currently spend significant time on network stack documentation, so the effect would be improving documentation, not reducing workload. But that is fine, we consider documentation important. It will *increase* the workload on the developers in question because they will have to check your diffs - jmc@ and myself will usually be unable to do that alone because we don't understand the network stack well enough. > advocates of the OpenBSD Project. I'm not aware of the existance of advocates, and there are certainly no advocates who work on documentation. > I was discussing this with some developers at BSDCan but I didnt > come away with a clear view of how to approach it. Give the manual pages to your field engineers as training documentation for specific tasks, see how they fare with them, and if they fail to set things up properly, figure out why. If the reason is that they don't read carefully enough (being used to low-quality documentation), work with them to improve their reading skills. If the reason is that some features are not described, or with too little precision, or wrongly, send patches to fix the gaps and bugs. If the reason is that everything is described exactly but the subject matter is so complicated that assembling actual commands or configuration from the description alone is very hard, work on adding or improving examples, focussing on *conciseness*. In any case, the shorter the patches you send, the better. Anything containing long newly-written text is probably of little use, at least until you will have collected a lot of experience working on OpenBSD documentation. It seems likely to me that all three elements will be needed, and that both the first and the second will require more time and effort than the third. > Could the members of OpenBSD who are responsible for OpenBSD > Documentation, and indeed anyone who is interested in advancing / > improving the documentation of OpenBSD get in touch so that I can > adopt an approach that is compatible with the overall direction of > the project and that I can finally provide practical support for > a project that I have benefited from for so long. There is only one way. Get started, find bugs and gaps in the manual pages, send patches (to tech@ or to developers who you know are interested), gain experience that way, and consequently improve the quality of your patches over time. > My initial thinking is > 1) learn mandoc You mean mdoc(7), probably. That certainly cannot hurt, but don't waste too much time on that, focus on *content*. When you send patches, people like jmc@ and myself will point out markup details to you, and then you can read up on the pieces you actually need. Also, mdoc(7) isn't all that difficult. If you want, look at the slides 15 to 21 of my Sofia EuroBSDCon talk: http://mandoc.bsd.lv/press.html (2014 Sep 26) and if you want, look at slides 1 to 13 for a general background. But the markup language isn't critical, really. > 2) work with interested parties who would like to see some concept >driven / example driven documentation I don't have the slightest idea what you are talking about. I'm not aware of any such parties. > 3) I really like the snappy slick presentation of the training slides >
Re: possible YP faq-doc bug ?
Hi Harold, harold felton wrote on Tue, Aug 08, 2017 at 04:19:59AM -0700: > yp-server step 9: i think requires cmd '# rcctl enable ypserv' > rather than just the file-listed to survive a reboot... > yp-client step 3: requires similar cmd '# rcctl enable ypbind' > rather than just the file-listed... True, the FAQ was outdated in several respects, including these ones. Thanks for reporting, i just updated it. > while testing this, i seemed to find that checking quotas during > bootup with only ypbind (without ypserv) on my local machine > became locked-up... hitting ^C while locked-up then would > immediately cause the normal done-message to appear... Right now, i have no idea what is going on in that repsect. I never used quotas, so i just fixed the easier parts. > as i said, i do not know much (about yp) and am still trying to > setup yp-password-changing - which seems to want a non-existent > yppasswdd (daemon) next ??? That was deleted about two years ago: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec/rpc.yppasswdd/Attic/Makefile Yours, Ingo
Re: How to find out which files were changed in -CURRENT and -STABLE between two releases?
Hi, pipfsta...@openmailbox.org wrote on Thu, Aug 10, 2017 at 08:07:44PM -: > I want to fill https://openbsd.org/plus61.html Wow, that would be useful, but it's a lot of work. Multiple days of full-time work, probably. In the past, people who did that have usually started from a mailing list archive like http://marc.info/?l=openbsd-cvs, and then looked at CVS as required. Starting from cvs2cl would be fine, too, and mostly equivalent. Maybe even a bit easier because you see the revision numbers right away. You only need to look at changes involving two-component revision numbers (x.y), those are on the MAIN branch, where all of -current and all releases happen. Four-component revision number (x.y.z.t) are on branches, hence irrelevant. To see whether an individual revision of a file was before or after release, just look at the log for that file, and where the tag is. Note that in rare cases, a release version of one file can be *newer* than a post-release version of another file - but at most by a few days, and only in those cases where Theo manually retagged a file to put a last-minute bugfix into the release. In extremely rare cases, one person may have changed several files with one "cvs commit" command (and hence all with the same date and commit message), and some of the resulting file revisions may be part of the release, while others may not. To get a rough first impression about the time range in which the cutoff happened, look at: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/conf/newvers.sh Stuff *newer* than the "unlock" change is *usually* post-release (except when Theo retagged something), stuff *older* than the "unlock" change is *usually* in the release - but a few changes may have gone in before the unlock change. So be careful with changes in the timerange of about two days before to about seven days after. Some of them may be in the release, some post-release, independent of their chronological ordering, even though they are all on the same branch! > Thus I need to obtain all commit messages for commits done between > 6.0 release and 6.1 release. > But cvs2cl just spits out all commits done in every branch without > marking them with tags they are assigned to. Again, ignore everthing with four-component numbers, use all the rest. > So I can't see if a commit was done before or after 6.0 release, Not from cvs2cl, no. That is a limitation of that particular (quick and dirty) script, not a limitation of CVS itself. > or if it is a part of the -STABLE branch for the 6.0 release, You *can* see that from cvs2cl output. Those would have four-component revision numbers. > or whatever else there is going on in the source tree. Nothing else is going on in the tree. In OpenBSD, side branches for development are strongly frowned upon and are used extremely rarely, and none have been active for some years now as far as i remember. > Even just getting info on the points (commit IDs) where the code > was frozen for the release would be very useful. But I failed > to find it in mail archives. Your biggest problem is that you are trying to figure out how a tiger looks like by asking specific questions about its roots, its stem, and its leaves. In git, everything revolves around commits and files are of very little importance. In CVS, the basic concept is completely different. Everything revolves around files and their revisions. The revisions of one file are independent of the revisions of any other file, and the notion of a "commit" is practically meaningless. Most definitely, commits do not have parents and children, ordering them chronologically is completely useless, and in particular tells you nothing about which revisions of which files are or are not part of a release. Yours, Ingo
Re: expr / (( )) different behavior
Hi,
Alessandro DE LAURENZIS wrote on Fri, Aug 11, 2017 at 01:14:48PM +0200:
> On Fri 11/08/2017 13:07, Janne Johansson wrote:
>> 0 is parsed as octal in places, so 09 would be bogus if octal.
> Thanks for the clarification; does that mean expr(1) can treat 10-base
> numbers only? No info in man page on this matter...
POSIX restricts expr(1) to handle decimal integers only and has some
complicated wording about which strings will be treated as integers
and which won't. I consider that too cumbersome to explain it in
the manual, in particular since it will rarely matter in practice.
But being specific about the number base adds precision and clarity
without harming readability.
OK?
Ingo
Index: expr.1
===
RCS file: /cvs/src/bin/expr/expr.1,v
retrieving revision 1.23
diff -u -p -r1.23 expr.1
--- expr.1 16 Jan 2015 15:30:10 - 1.23
+++ expr.1 11 Aug 2017 16:45:29 -
@@ -39,16 +39,17 @@ Returns the evaluation of
if neither expression evaluates to an empty string or zero;
otherwise, returns zero.
.It Ar expr1 Li "{=, >, >=, <, <=, !=}" Ar expr2
-Returns the results of integer comparison if both arguments are integers;
-otherwise, returns the results of string comparison using the locale-specific
-collation sequence.
+Returns the results of integer comparison if both arguments are
+decimal integers; otherwise, returns the results of string comparison
+using the locale-specific collation sequence.
The result of each comparison is 1 if the specified relation is true,
or 0 if the relation is false.
.It Ar expr1 Li "{+, -}" Ar expr2
-Returns the results of addition or subtraction of integer-valued arguments.
+Returns the results of addition or subtraction of decimal integer-valued
+arguments.
.It Ar expr1 Li "{*, /, %}" Ar expr2
Returns the results of multiplication, integer division, or remainder of
-integer-valued arguments.
+decimal integer-valued arguments.
.It Ar expr1 Li \&: Ar expr2
The
.Ql \&:
Re: amd(8): outdated FILES manpage's section?
Hi Alessandro,
Alessandro DE LAURENZIS wrote on Mon, Aug 21, 2017 at 06:46:02PM +0200:
> Since this old commit [0] the default location for the real amd(8)'s
> mount points has been changed from "/a" to "/tmp_mnt".
>
> This is correctly referenced in the man page, when the "-a" option is
> described, but the FILES section still lists "/a"; should it be updated
> as well? Something like:
Committed, thanks.
> --- /usr/src/usr.sbin/amd/amd/amd.8.orig Tue Jul 16 13:13:33 2013
> +++ /usr/src/usr.sbin/amd/amd/amd.8 Mon Aug 21 18:32:51 2017
> @@ -188,8 +188,8 @@
> .Va ${domain} .
> .El
> .Sh FILES
> -.Bl -tag -width /axx
> -.It Pa /a
> +.Bl -tag -width /tmp_mntxx
> +.It Pa /tmp_mnt
> directory under which filesystems are dynamically mounted
> .El
> .Sh SEE ALSO
>
> Actually, neither the reference "Amd - The 4.4 BSD Automounter" reflects
> this change, but I think that's normal, because the "original" document
> should be preserved.
No, we are still installing that, and documentation must be kept up
to date, so i fixed it, too.
Yours,
Ingo
> [0]:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/amd/amd/amd.c?rev=1.15&content-type=text/x-cvsweb-markup
Re: Query regarding exec in mandocdb.c
Hi George,
George Brown wrote on Thu, Aug 24, 2017 at 02:01:05PM +0100:
> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
> process.
Indeed, i never really liked that, yet i didn't spend much time
thinking about it either.
> It seems that if the logic from these programs were duplicated
> the pledge in mandocdb.c could be further restricted and even not
> bother with forking.
You have a point that the need for the "proc exec" pledges is ugly
in particular, and it would be nice to get rid of those pledges.
> Would such a change be pointless churn however?
At least the removal of the forking for "rm -rf" was not
pointless churn. Simplification is never pointless.
> Both cmp(1) and rm(1)
> are simple programs and are pledge'd themselves. Not to mention the
> creation of the mandoc database is in itself a short lived process.
>
> To be clear I'm not proposing a change (indeed I have no diff) but
> rather I am simply curious to the opinion of others in the OpenBSD
> community.
See below for what i committed so far. I shall look into removing
the fork and exec for cmp(1) as well. I'm not completely sure yet
that it will work out, but i suspect it won't make the code
substantially longer and only duplicate such a minimal and simple
part of cmp(1) that the duplication won't matter, and be outweighed
by the stricter pledge.
Thanks for reading the code!
Ingo
Log Message:
---
No need to fork and exec rm(1) -rf, we know that we have exactly
one file and exactly one directory to remove. While here, increase
the size of the buffer such that the file name actually fits.
Minus 17 lines of code, no functional change.
Opportunity for simplification reported by George Brown <321 dot
george at gmail dot com> on misc@.
Modified Files:
--
mandoc:
mandocdb.c
Revision Data
-
Index: mandocdb.c
===
RCS file: /home/cvs/mandoc/mandoc/mandocdb.c,v
retrieving revision 1.253
retrieving revision 1.254
diff -Lmandocdb.c -Lmandocdb.c -u -p -r1.253 -r1.254
--- mandocdb.c
+++ mandocdb.c
@@ -2119,7 +2119,7 @@ dbprune(struct dba *dba)
static void
dbwrite(struct dba *dba)
{
- char tfn[32];
+ char tfn[33];
int status;
pid_tchild;
@@ -2193,26 +2193,9 @@ dbwrite(struct dba *dba)
}
out:
+ unlink(tfn);
*strrchr(tfn, '/') = '\0';
- switch (child = fork()) {
- case -1:
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say("", "&fork rm");
- return;
- case 0:
- execlp("rm", "rm", "-rf", tfn, (char *)NULL);
- say("", "&exec rm");
- exit((int)MANDOCLEVEL_SYSERR);
- default:
- break;
- }
- if (waitpid(child, &status, 0) == -1) {
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say("", "&wait rm");
- } else if (WIFSIGNALED(status) || WEXITSTATUS(status)) {
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say("", "%s: Cannot remove temporary directory", tfn);
- }
+ rmdir(tfn);
}
static int
Re: code duplication
Hi, there isn't the one answer that fits all situations. The goal in this respect is simplicity and maintainability. Often, it is simpler to maintain two copies of similar code. For example, the libc and kernel implementations of malloc(3) and malloc(9) are distinct. Reacharound between kernel and userland sources is usually a bad idea, causing #ifdefs, confusion, and bugs, but not simplicity. Duplicate code *is* maintainable if you don't overdo it. When a new type of bug is found, OpenBSD developers have a habit of scanning the complete tree to see whether similar bugs lurk at other places, too. Often, it is simpler to create a library for functionality that has become stable enough and that has come into use at many places. For example, the imsg functions - see imsg_init(3) - were moved into libutil in 2010, after several years of development and stabilization. A smaller, more recent example is the reallocarray(3) family of functions in libc. But making something a library doesn't always simplify things. Layering and abstraction often increase complexity. Sooner or later, you detect duplication inside your library, so you make it use a library which in turn uses a library. CPAN style interminable dependency chains are not simplicity. Or just look at the maze of libraries in FreeBSD. Everybody has to learn POSIX anyway. But if you invent hundred additional interfaces abstracting combinations of functionality that you need here and there, people who want to read and maintain code suddenly have to learn 100 more interfaces. That is not necessarily simpler. It really depends on the situation, and the balancing act between abstration and duplication needs experience and taste, not rigid principles. Yours, Ingo P.S. There is no good reason to insult Todd for running spamd(8), which is a standard tool and less annoying than some others. Managing completely open mailing lists is a very difficult, a tiresome, and a thankless job, in particular for popular lists like the OpenBSD ones, and i'm quite glad the service has been running so smoothly all these years.
Re: Query regarding exec in mandocdb.c
Hi George,
George Brown wrote on Thu, Aug 24, 2017 at 02:01:05PM +0100:
> In mandocdb.c it appears cmp(1) and rm(1) are executed in a child
> process. It seems that if the logic from these programs were duplicated
> the pledge in mandocdb.c could be further restricted and even not bother
> with forking.
Done as well, see the commit below.
Thanks again for the suggestion,
Ingo
Log Message:
---
Do not fork and exec cmp(1); instead, simply fstat(2), mmap(2), and
compare the files directly, allowing a much stricter pledge(2), at
very little cost: merely 15 additional lines of very simple code.
Suggested by George Brown <321 dot george at gmail dot com> on misc@.
Modified Files:
--
mandoc:
mandocdb.c
Revision Data
-
Index: mandocdb.c
===
RCS file: /home/cvs/mandoc/mandoc/mandocdb.c,v
retrieving revision 1.254
retrieving revision 1.255
diff -Lmandocdb.c -Lmandocdb.c -u -p -r1.254 -r1.255
--- mandocdb.c
+++ mandocdb.c
@@ -19,8 +19,8 @@
#include "config.h"
#include
+#include
#include
-#include
#include
#include
@@ -319,7 +319,7 @@ mandocdb(int argc, char *argv[])
int ch, i;
#if HAVE_PLEDGE
- if (pledge("stdio rpath wpath cpath fattr flock proc exec", NULL) ==
-1) {
+ if (pledge("stdio rpath wpath cpath", NULL) == -1) {
warn("pledge");
return (int)MANDOCLEVEL_SYSERR;
}
@@ -440,15 +440,6 @@ mandocdb(int argc, char *argv[])
* The existing database is usable. Process
* all files specified on the command-line.
*/
-#if HAVE_PLEDGE
- if (!nodb) {
- if (pledge("stdio rpath wpath cpath fattr
flock", NULL) == -1) {
- warn("pledge");
- exitcode = (int)MANDOCLEVEL_SYSERR;
- goto out;
- }
- }
-#endif
use_all = 1;
for (i = 0; i < argc; i++)
filescan(argv[i]);
@@ -2119,9 +2110,10 @@ dbprune(struct dba *dba)
static void
dbwrite(struct dba *dba)
{
- char tfn[33];
- int status;
- pid_tchild;
+ struct stat sb1, sb2;
+ char tfn[33], *cp1, *cp2;
+ off_ti;
+ int fd1, fd2;
/*
* Do not write empty databases, and delete existing ones
@@ -2160,39 +2152,59 @@ dbwrite(struct dba *dba)
say("", "&%s", tfn);
return;
}
-
+ cp1 = cp2 = NULL;
+ fd1 = fd2 = -1;
(void)strlcat(tfn, "/" MANDOC_DB, sizeof(tfn));
if (dba_write(tfn, dba) == -1) {
- exitcode = (int)MANDOCLEVEL_SYSERR;
say(tfn, "&dba_write");
- goto out;
- }
-
- switch (child = fork()) {
- case -1:
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say("", "&fork cmp");
- return;
- case 0:
- execlp("cmp", "cmp", "-s", tfn, MANDOC_DB, (char *)NULL);
- say("", "&exec cmp");
- exit(0);
- default:
- break;
- }
- if (waitpid(child, &status, 0) == -1) {
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say("", "&wait cmp");
- } else if (WIFSIGNALED(status)) {
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say("", "cmp died from signal %d", WTERMSIG(status));
- } else if (WEXITSTATUS(status)) {
- exitcode = (int)MANDOCLEVEL_SYSERR;
- say(MANDOC_DB,
- "Data changed, but cannot replace database");
+ goto err;
}
+ if ((fd1 = open(MANDOC_DB, O_RDONLY, 0)) == -1) {
+ say(MANDOC_DB, "&open");
+ goto err;
+ }
+ if ((fd2 = open(tfn, O_RDONLY, 0)) == -1) {
+ say(tfn, "&open");
+ goto err;
+ }
+ if (fstat(fd1, &sb1) == -1) {
+ say(MANDOC_DB, "&fstat");
+ goto err;
+ }
+ if (fstat(fd2, &sb2) == -1) {
+ say(tfn, "&fstat");
+ goto err;
+ }
+ if (sb1.st_size != sb2.st_size)
+ goto err;
+ if ((cp1 = mmap(NULL, sb1.st_size, PROT_READ, MAP_PRIVATE,
+ fd1, 0)) == NULL) {
+ say(MANDOC_DB, "&mmap");
+ goto err;
+ }
+ if ((cp2 = mmap(NULL, sb2.st_size, PROT_READ, MAP_PRIVATE,
+ fd2, 0)) == NULL) {
+ say(tfn, "&mmap");
+ goto err;
+ }
+ for (i = 0; i < sb1.st_size; i++)
+ if (cp1[i] != cp2[i])
+ goto err;
+ goto out;
+
+err:
+
Re: Query regarding exec in mandocdb.c
Hi Ted,
Ted Unangst wrote on Sat, Aug 26, 2017 at 02:35:01PM -0400:
> Ingo Schwarze wrote:
>> +if ((cp1 = mmap(NULL, sb1.st_size, PROT_READ, MAP_PRIVATE,
>> +fd1, 0)) == NULL) {
>> +say(MANDOC_DB, "&mmap");
>> +goto err;
>> +}
>> +if ((cp2 = mmap(NULL, sb2.st_size, PROT_READ, MAP_PRIVATE,
>> +fd2, 0)) == NULL) {
>> +say(tfn, "&mmap");
>> +goto err;
>> +}
> mmap returns MAP_FAILED (-1), not null, on failure.
Ooops, indeed. The check is correct in read.c and dbm_map.c,
but i stumbled here. Fixed now, thanks.
>> +for (i = 0; i < sb1.st_size; i++)
>> +if (cp1[i] != cp2[i])
>> +goto err;
> this could just be memcmp.
I avoided that over quibbles about the argument type (off_t vs.
size_t), though i admit that database files larger than a Gigabyte
make no sense at all.
If you consider that an improvement, i'm not opposed to using
memcmp(3). But i don't really have a good idea what to do if
st_size does happen to exceed SIZE_MAX. Maybe just error out?
Yours,
Ingo
Re: FYI: man.openbsd.org uses an invalid security certificate.
Hi Peter, Steiner Peter wrote on Mon, Sep 11, 2017 at 09:35:32AM +: > man.openbsd.org uses an invalid security certificate. > The certificate expired on 11.09.2017 06:27. > The current time is 11.09.2017 11:31. Fixed. Sorry for the disruption and thanks for the heads-up. Yours, Ingo
Re: Open /dev/mem file failed when running as a root priviledge
Hi,
Nan Xiao wrote on Tue, Sep 12, 2017 at 08:58:25AM +0800:
> I want to run dmidecode (https://github.com/mirror/dmidecode)
> on OpenBSD 6.1, but executing it will report following errors:
>
> # ./dmidecode
> # dmidecode 3.1
> Scanning /dev/mem for entry point.
> /dev/mem: Operation not permitted
>
> After single-step debugging, I find the error is from open /dev/mem:
>
> if ((fd = open(filename, O_RDONLY)) == -1)
> {
> if (errno != ENOENT)
> perror(filename);
> return NULL;
> }
>
> I execute program as a root, and the attributes of `/dev/mem`:
>
> # ls -lt /dev/mem
> crw-r- 1 root kmem2, 0 Aug 25 18:38 /dev/mem
>
> So it should open successfully.
> Could anyone give some clues of this issue?
Thanks for reporting. I just fixed the documentation.
It now reads as follows:
schwarze@isnote $ man 4 mem | grep -A2 Even
Even with sufficient file system permissions, these devices can
only be opened when the securelevel(7) is insecure or when the
kern.allowkmem sysctl(3) variable is set.
schwarze@isnote $ man securelevel | col -b | grep -A3 'Secure '
1 Secure mode
- default mode when system is multi-user
- securelevel may no longer be lowered except by init
- /dev/mem and /dev/kmem cannot be opened
Yes, if you really want to use /dev/mem, you have to allow that
during boot, as it makes the system insecure. So if you have already
booted, you have to reboot to put the system in such an insecure
mode of operation. But do *NOT* do that on any kind of production
system, only do that on a system exclusively used for experimentation
and debugging. Enabling this is intentionally hard to discourage
using it.
Also, even if you get this to work now, don't hold your breath that
we will continue supporting it in the future. It seems likely to me
that even more restrictions may be placed on /dev/mem in the future,
and you should not expect that dmidecode will continue to work.
Yours,
Ingo
- Forwarded message from Ingo Schwarze -
From: Ingo Schwarze
Date: Mon, 11 Sep 2017 20:22:16 -0600 (MDT)
To: source-chan...@openbsd.org
Subject: CVS: cvs.openbsd.org: src
CVSROOT:/cvs
Module name:src
Changes by: schwa...@cvs.openbsd.org2017/09/11 20:22:16
Modified files:
lib/libc/gen : sysctl.3
share/man/man7 : securelevel.7
share/man/man4/man4.alpha: mem.4
share/man/man4/man4.amd64: mem.4
share/man/man4/man4.hppa: mem.4
share/man/man4/man4.i386: mem.4
share/man/man4/man4.landisk: mem.4
share/man/man4/man4.loongson: mem.4
share/man/man4/man4.luna88k: mem.4
share/man/man4/man4.macppc: mem.4
share/man/man4/man4.socppc: mem.4
share/man/man4/man4.sparc64: mem.4
Log message:
Update the documentation regarding /dev/mem and /dev/kmem;
Theo already clamped down on these devices last year.
Triggered by a question from Nan Xiao .
OK deraadt@
- End forwarded message -
Re: Maintaining process clarification
Hi Zbyszek, Zbyszek wrote on Thu, Sep 28, 2017 at 11:43:35AM +0200: > I am new to OpenBSD Welcome. > Example: In 6.1 I assume that means you are using -stable. > there is package openvpn-2.4.1, how updates to the package are > handled? If there is critical issue with the package, then > "openvpn-2.4.1" is updated or it get new version numbering? It gets a new version number, typically openvpn-2.4.1p0. If the fix is done via a new upstream release, the number may look something like openvpn-2.4.2. In this particular case, it actually is openvpn-2.4.3p1 in both -stable and -current. > And yes - i know i can recompile by myself and i do not mind doing > that, but i would avoid recompiling almost all all the time if there > is already process Using -stable, you will have to compile port updates yourself: https://www.openbsd.org/faq/faq15.html#PortsSecurity Or use the third-party, but IMHO trustworthy third-party precompiled stable packages fro MTier: https://stable.mtier.org/ If you use -current instead of stable, just updating to a newer snapshot is sufficient: https://www.openbsd.org/faq/faq5.html#Flavors That said, use the manual pages and the FAQ before asking questions, and do not use web search engines to search for answers to questions regarding OpenBSD. Unlike in Linux, almost everything is documented precisely and concisely in the canonical places in the manual pages or FAQ, and documentation is almost always up to date. Yours, Ingo
Re: Is there git-flow-completion for ksh?
Hi, Nan Xiao wrote on Mon, Oct 09, 2017 at 05:33:17PM +0800: > I know there is git-flow-completion for bash. > For default ksh on OpenBSD, is there any out-of-box > git-flow-completion? Hell no. No plugins in the shell, please. You want a shell that you can trust, right? If you want an environment that is optimized for maximal attack surface and maximal potential impact of bugs, run Linux, or run shells/bash on OpenBSD. When the complete_command feature (see the manual page) was introduced to ksh(1), i already complained that it is bloat and featurism, and as such inviting bugs, yet too many developers wanted it. But plugins? I thoroughly hope that is never going to happen. Yours, Ingo
Re: Tar and bzip2 maximum compression
Hi Philippe, Philippe Meunier wrote on Mon, Oct 09, 2017 at 08:03:12AM -0400: > leo_...@volny.cz wrote: >> % tar cvvf - > On a related note, it would be nice if tar(1)'s man page indicated that the > -v option can be specified more than once to get extra information. Until > seeing this discussion thread I had never realized this was possible. Thanks for mentioning that: millert@ just improved the manual as a result. Yours, Ingo
Re: Porter's Handbook obsolete info
Hi Steve, Steve Shockley wrote on Wed, Oct 11, 2017 at 08:11:24PM -0400: > FYI, http://www.openbsd.org/faq/ports/specialtopics.html refers to the > security/nessus port, which was retired some time ago. The section does > show a useful example though, but I'm not sure what would make a good > replacement example. Fixed by using mail/dovecot instead. Thanks for the heads-up, Ingo
Re: use /dev/arandom on the Linux
Hi Philipp, hi Markus, Philip Guenther wrote on Sat, Oct 14, 2017 at 12:05:55AM -0700: > On Fri, Oct 13, 2017 at 11:54 PM, Mohammad BadieZadegan > arandom entropy is better than urandom and I need arandom for better >> entropy and better speed in comparison about /dev/random. > Umm, I don't understand. /dev/arandom was an OpenBSD "innovation" that we > have since regretted and rescinded: on modern OpenBSD, /dev/arandom and > /dev/urandom behave *exactly the same*. Go look in sys/dev/rnd.c and > you'll see that the minor device number is ignored. RTFS is all well and good, but trying to understand your postings, i also tried to RTFM. schwarze@isnote $ man urandom man: No entry for urandom in the manual. This is ungood. So i looked at random(4) and found multiple issues. * srandom and urandom are missing from NAME. That's particularly unfortunate for urandom(4) because that's the best of the four for portable software, IIUC. * I think we want a strong deprecation notice here, like for crypt(3). We usually put that at the top of the DESCRIPTION, such that people won't study all the text before realizing that they have to start over with a different page. * Given that these devices are only useful for (some situations) of portable code, it seems quite counter-productive to only talk about what OpenBSD does, and the failure to make clear which of the statements apply to OpenBSD only is even worse. * It should certainly be said that if at all, urandom(4) is the one to use. * There is no need to say twice that these devices produce high-quality random data. * Add the missing FILES entries. * Kill the reference to the deprecated random(3) APIs. * We don't need to get into the argument whether Linux is an operating system or just a kernel. Instead, we usually mention the release something first appeared in. But i'm too lazy to research Linux kernel version numbers, and maybe they are not even all that interesting, so i'm just putting the year. * Author names belong in AUTHORS, not HISTORY. Instead, HISTORY should say when ARC4 was introduced here. * It's weird to mention who implemented a former algorithm, but to not say the same for the current one. This patch in likely not perfect yet, there is more weirdness, but i don't know the best way to fix that. If this is a bad patch, i hope it triggers a good one. * Are the .Xr's to md5(3) and md5(9) still relevant? How does reading md5(3) and md5(9) potentially help somebody who is considering to use /dev/urandom? I'd like to delete these, but if we want to keep them, shouldn't we explain why they are relevant? * I strongly suspect the sentence "This is a cloned interface" is completely misplaced in HISTORY. But i'm not quite sure what it means and whether it is true, so i have no idea where to move it. Feedback? Or even an OK? Ingo Index: random.4 === RCS file: /cvs/src/share/man/man4/random.4,v retrieving revision 1.31 diff -u -p -r1.31 random.4 --- random.410 Sep 2015 17:55:21 - 1.31 +++ random.414 Oct 2017 16:59:14 - @@ -28,34 +28,62 @@ .Os .Sh NAME .Nm random , -.Nm arandom +.Nm arandom , +.Nm srandom , +.Nm urandom .Nd random data source devices .Sh SYNOPSIS .In sys/types.h .In dev/rndvar.h .Sh DESCRIPTION -The various +These devices are deprecated. +Use the +.Xr arc4random 3 +family of functions instead, which can be called in almost all +coding environments, including +.Xr pthreads 3 , +.Xr chroot 2 , +and +.Xr pledge 2 , +and which avoids accessing a device every time. +.Pp +On +.Ox , +all these various .Nm -devices produce high quality random output data. +devices behave identically and produce high quality pseudo-random +output data. Entropy data is collected from system activity (such as disk, network, and clock device interrupts), and then used to key the ChaCha stream cipher to generate the output. -All the random devices are expected to provide high quality -pseudo-random output data. .Pp +On other operating systems, some devices may exhibit various defects. +For example, +.Nm +and +.Nm srandom +might block, or +.Nm random +might only return data from hardware random generators. The -.Xr arc4random 3 -function in userland libraries should be used instead, as it works -without the need to access these devices every time. +.Nm arandom +variant is a deprecated +.Ox +extension that should no longer be used. +.Pp +If using one of these devices cannot be avoided in a portable +program, prefer +.Nm urandom . .Sh FILES .Bl -tag -width /dev/arandom -compact .It Pa /dev/random .It Pa /dev/arandom +.It Pa /dev/srandom +.It Pa /dev/urandom .El .Sh SEE ALSO .Xr arc4random 3 , .Xr md5 3 , -.Xr random 3 , .Xr amdpm 4 , .Xr glxsb 4 , .Xr pchb 4 , @@ -64,11 +92,17 @@ without the need to access these devices .Sh HISTORY A .Nm -device first appeared in t
while awaiting the 6.2 release song...
Hi, now that OpenBSD 6.2 has been out for a bit but there are still some weeks of anticipation for the 6.2 release song, and now that CD sets are no longer being made in order to avoid the overhead and instead focus on ongoing development, here is a small distraction for the time being: OpenBSD songs 3.0-6.2 potpourri with artwork and release history https://youtu.be/tuWadwmXCys Don't forget that "no more CDs" doesn't imply no more need for infrastructure, electricity, hackathons, and funding of special development projects. It's already October and http://www.openbsdfoundation.org/campaign2017.html is still a bit short of the target, so have a look at: https://www.openbsd.org/donations.html Thanks and enjoy, Ingo
Re: is there something missing in pledge?
Hi Peter, Peter J. Philipp wrote on Tue, Oct 24, 2017 at 04:35:12PM +0200: > Index: open.2 > === > RCS file: /cvs/src/lib/libc/sys/open.2,v > retrieving revision 1.49 > diff -u -p -u -r1.49 open.2 > --- open.219 Jan 2015 15:54:11 - 1.49 > +++ open.224 Oct 2017 14:28:30 - > @@ -235,6 +235,10 @@ and > .Fn openat > functions will fail if: > .Bl -tag -width Er > +.It Bq Er EPERM > +When opening a special file and the program has requested certain > +.Xr pledge 2 > +promises. > .It Bq Er ENOTDIR > A component of the path prefix is not a directory. > .It Bq Er ENOTDIR I'm not convinced. 1) I don't like the idea of scattering pledge(2) documentation all over the place. 2) To me, this feel like a detail that might easily change without notice, and then we risk leaving a bug behind in the manual. 3) ERRORS sections are in a bad shape in general, both in POSIX and in our manuals. In POSIX, they are quite incomplete, which makes POSIX quite confusing if you really want to code errno checks in a portable manner. We have huge amounts of extensions in this area, many of them allowed by the standard, some forbidden, many documented, many undocumented, some documented in ways that are outright wrong, and we explain almost nowhere which ERRORS are standard and which are extensions. We should, because otherwise people can't check them portably, and telling people to read POSIX itself just isn't realistic with respect to ERRORS, given the mess people will find there. What you add here is an extremely minor detail in an area that is severely under-documented and disorganized in much more relevant respects. Besides, the number of ERRORS entries in the open(2) manual in particular is already excessive without this addition. So your patch feels a bit like lipstick on a grazing hippo, somewhere near the rear end, in the late afternoon shortly before it goes back into the water. I'm not saying such stuff should remain undocumented, but i *am* at a loss where to start. Probably not with this particular detail. Yours, Ingo
Re: PDF produced by mandoc
Hi Jan, Jan Stary wrote on Fri, Oct 06, 2017 at 01:34:03PM +0200: > This is current/amd64. I just produced a pdf of bc(1) with > "man -Tpdf bc > bc.pdf". > > Trying to view that pdf with mupdf(1) complains thusly: > (I can view and print the PDF fine though) > > warning: expected 'endobj' or 'stream' keyword (27 0 R) > warning: expected 'endobj' or 'stream' keyword (9 0 R) > warning: expected 'endobj' or 'stream' keyword (4 0 R) > warning: expected 'endobj' or 'stream' keyword (3 0 R) > warning: expected 'endobj' or 'stream' keyword (5 0 R) > > Trying to view that pdf with gv(1) says > > Error: /typecheck in --setfileposition-- > Operand stack: [...] > and errors out. > > Is seems to happen with any other manpage as well. > Is anyone seeing the same? Apparently, bugs are immortal: they never die from old age. This was a group of three bugs all more than seven years old. Quite an accomplishment to find bugs of that age in mandoc, given how often much of the code kept getting re-written and re-re-written while we slowly learnt how languages work. But it looks like nobody ever bothered to check whether the PDF output generated by mandoc(1) was syntactically valid - which is amazing... Thanks for the report, fixed by the commit below. Ingo Log Message: --- Properly close out the top-level Font object, the end-of-page Resource objects, and the Catalog object, fixing three PDF syntax errors that were present in every PDF file generated with mandoc since the initial checkin of the formatter in July 2010. Bug reported by Jan Stary on misc@. Modified Files: -- mandoc: term_ps.c Revision Data - Index: term_ps.c === RCS file: /home/cvs/mandoc/mandoc/term_ps.c,v retrieving revision 1.85 retrieving revision 1.86 diff -Lterm_ps.c -Lterm_ps.c -u -p -r1.85 -r1.86 --- term_ps.c +++ term_ps.c @@ -759,7 +759,7 @@ ps_closepage(struct termp *p) ps_printf(p, "/Font <<\n"); for (i = 0; i < (int)TERMFONT__MAX; i++) ps_printf(p, "/F%d %d 0 R\n", i, 3 + i); - ps_printf(p, ">>\n>>\n"); + ps_printf(p, ">>\n>>\nendobj\n"); /* Page node. */ pdf_obj(p, base + 3); @@ -824,7 +824,7 @@ ps_end(struct termp *p) ps_printf(p, "<<\n"); ps_printf(p, "/Type /Catalog\n"); ps_printf(p, "/Pages 2 0 R\n"); - ps_printf(p, ">>\n"); + ps_printf(p, ">>\nendobj\n"); xref = p->ps->pdfbytes; ps_printf(p, "xref\n"); ps_printf(p, "0 %zu\n", base + 1); @@ -918,7 +918,7 @@ ps_begin(struct termp *p) ps_printf(p, "/Subtype /Type1\n"); ps_printf(p, "/Name /F%d\n", i); ps_printf(p, "/BaseFont /%s\n", fonts[i].name); - ps_printf(p, ">>\n"); + ps_printf(p, ">>\nendobj\n"); } }
Re: mandoc output paper size
Hi Walter, Walter Alejandro Iglesias wrote on Thu, Oct 26, 2017 at 05:44:16PM +0200: > I have files generated with GNU roff that defaults to letter size. That's the upstream (GNU troff) default when you compile GNU troff from the git repository with automake and autoconf. If i understand correctly, it is the GNU troff default because it is also the default used by GNU autoconf in general. > This doesn't happen on Linux, I ignore why. I doubt this has anything to do with Linux (neither the kernel nor whatever C library or userland applications are used). But it may depend on whatever operating system distribution you are using. It is well-known that many Lnux distributions engage in tweaking upstream defaults, even those settings that are more or less a matter of personal preference. > This is set in DESC config files. > > $ grep -ER 'papersize (letter|a4)' /usr/local/share/groff/* > /usr/local/share/groff/1.22.3/font/devdvi/DESC:papersize letter > /usr/local/share/groff/1.22.3/font/devlj4/DESC:papersize letter > /usr/local/share/groff/1.22.3/font/devps/DESC:papersize letter > /usr/local/share/groff/1.22.3/font/devlbp/DESC:papersize letter > /usr/local/share/groff/1.22.3/font/devpdf/DESC:papersize letter That is automatically generated at GNU troff build time, controlled by files generated by autoconf, controlled by files generated by automake, controlled by files autogenerated by whatever (insert your favourite rabbit hole here). In any case, the fact that groff defaults to "papersize letter" is the reason why mandoc(1) does the same. Unless there are strong reasons to diverge, mandoc aims for compatibility with groff. Yours, Ingo
Re: mandoc output paper size
Hi Amelia, Amelia A Lewis wrote on Thu, Oct 26, 2017 at 10:41:55AM -0400: > On Thu, 26 Oct 2017 16:14:36 +0200 (CEST), Walter Alejandro Iglesias wrote: >> In the ps file generated by mandoc you should have this line: >> >> %%DocumentMedia: Default 595 841 0 () () >> >> Where 595 841 correspond to A4. If you set output paper to "letter" >> that line will say: >> >> %%DocumentMedia: Default 612 790 0 () () > So these measures are in points? Strictly speaking, no, they are in PostScript basic units, and PostScript basic units default to 1/72 of an inch, see the PostScript language reference manual, Adobe Systems Inc. - 3rd edition, Addison-Wesley, Reading 1999 Section 4.3.1, page 183 together with PostScript Language Document Structuring Conventions Specification Version 3.0, 25 September 1992, Adobe Systems Inc., Section 6.1, page 94 > https://en.wikipedia.org/wiki/Point_(typography) For practical purposes, "point" can often be used as a synonym for "PostScript basic unit", but that is imprecise terminology and may cause confusion. Yours, Ingo
Re: mandoc output paper size
Hi Walter, Walter Alejandro Iglesias wrote on Thu, Oct 26, 2017 at 05:11:10PM +0200: > https://www.gnu.org/software/gv/manual/gv.html\ > #Paper-Keywords-and-paper-size-in-points Mandoc uses the exact paper size as specified by ISO 216 in millimeters: A3 297 x 420 A4 210 x 297 A5 148 x 210 For the North American sizes, it uses these approximate values: letter 216 x 279 legal 216 x 356 These values in millimeters are converted to AFM units (assuming a Times-Roman font of size 11) according to the same calculation and rounding rules as any other lengths, using double precision floating point, then truncating to unsigned integer AFM units. There is a rounding difference in the A4 height given in the gv(1) manual of one basic unit, but i don't know which rounding rule gv uses. Yours, Ingo
Re: mandoc output paper size
Hi Jan,
Jan Stary wrote on Thu, Oct 26, 2017 at 10:39:20AM +0200:
> This is -current/amd64. My /etc/man.conf in its entirety is 'output
> paper a4'. The A4 paper size is what we mostly use around these
> parts; otherwise I would not even have a man.conf of course.
>
> I am not sure whether man -Tpdf and man -Tps honour the paper size.
As discussed, it does.
> man -Tpdf sox > man.pdf
> man -Tps sox > man.ps
>
> Viewing the PDF file in gv(1), it says "y841x595" in the size box.
> Viewing the PS file, it says "Default" in the size box.
>
> I don't know the PDF or PS syntax so I can't tell from the files
> themselves, but other PDF and PS files that I know have A4 pages
> show as "A4" in gv(1).
For PostScript files, gv(1) simply trusts a comment in the file,
even if it is in blatant disagreement with the actual size
specified in the file - see
/usr/ports/pobj/gv-3.7.4/gv-3.7.4/src/misc.c
function misc_buildPagemediaMenu():
pagemediaEntry[i] = XtCreateManagedWidget(doc->media[i].name,
smeBSBObjectClass, pagemediaMenu,NULL,(Cardinal)0);
and
/usr/ports/pobj/gv-3.7.4/gv-3.7.4/src/ps.c
function psscan():
doc->media[0].name = ps_gettext(line+length("%%DocumentMedia:"),
&next_char);
Take any file that starts with
%!PS-Adobe-3.0
and change the second word in the line
%%DocumentMedia: A4 595 841 0 () ()
to "foobar" (or something more evil, like "A5"), as in:
%%DocumentMedia: foobar 595 841 0 () ()
Gv will happily show the document size as "foobar", but it will
still display the document with the correct size of 595 841. If
you click on "foobar" in the menu bar, you will also see the "foobar"
menu entry. In the more evil case that you put "A5" there, gv will
show "A5" in the menu bar, and when you click on it, you will see
*two* "A5" menu entries. If you click on the lower one, it will
actually crop the document to A5 (according to its built-in notion
of what A5 is); with the upper one, it will show the whole document
again, according to your personal redefinition of "A5".
Are you really sure that you also see "A4" for some PDF documents?
Judging from
/usr/ports/pobj/gv-3.7.4/gv-3.7.4/src/ps.c psscan()
gv(1) gets the DocumentMedia name by converting the PDF with
/usr/local/share/ghostscript/9.07/lib/pdf2dsc.ps
which, as far as i can see, always writes yNNNxNNN for that.
Also, i was unable to find anything similar to the first
argument of "%%DocumentMedia:" in the PDF-1.7 standard;
in particular, "/MediaBox" only supports four numbers,
but i didn't find anything elsewhere either.
Does anyone know how to specify a name for a page format in PDF?
If there is no way to do that, then probably it isn't worth doing
for only PostScript either...
> I can always override it with tools; but occassionaly a printer
> will choke on a file with "unknown" page size.
I don't understand what you mean by "unknown page size".
Can you provide an example of such a file to me privately -
if possible generated by mandoc(1), otherwise any such file?
Yours,
Ingo
Re: mandoc output paper size
Hi Jan, Jan Stary wrote on Thu, Oct 26, 2017 at 09:31:38PM +0200: In the ps file generated by mandoc you should have this line: %%DocumentMedia: Default 595 841 0 () () Where 595 841 correspond to A4. If you set output paper to "letter" that line will say: %%DocumentMedia: Default 612 790 0 () () > Yes. It seems that these are just _comments_ to the PS interpreter They are comments in the sense of the PostScript programming language, but they have a strictly specified syntax and sematics according to the "PostScript Language Document Structuring Conventions Specification", which is kind of a language of its own: DSC. The first line in the file, "%!PS-Adobe-3.0", actually says that it is a DSC 3.0 document - but it says nothing about the PostScript level. > and the "Default" is just an arbitrary given name, right? I guess so, but i'm not completely sure. I could find no information on that. > (Sorry, I don't know the language.) So GV just shows that, > but it does not _determine_ the actual media size, right? Right. > Looking at term_ps.c, mandoc writes "Default ... " for every paper size. Exactly. I could print "A3", "A4", "A5", "letter", "legal" in that place, and interactive users of gv(1) would likely be happier. But i have no idea what effect it might have on other programs or on printers, or how to do the same for PDF. Yours, Ingo
Re: mandoc output paper size
Hi Walter, Walter Alejandro Iglesias wrote on Fri, Oct 27, 2017 at 12:12:21PM +0200: > First of all, I'm just a user like you trying to figure out > how things work. So am I. That's how it starts. I also read documentation, standards, and code at need, and start fixing them once i understand enough of them. > So, don't expect from me some deep analysis, for that Ingo > is the right person. Not really. I know a lot about mdoc(7), but almost nothing about PostScript, DSC, and PDF. Yours, Ingo
Re: mandoc output paper size
[ sending this particular one back to the list because it contains something useful for everyone and nothing private ] Hi Jan, Jan Stary wrote on Fri, Oct 27, 2017 at 12:46:00PM +0200: > I produced a PS output with "man -Tps rm > rm.ps", > with output paper set to a3, a4, and a5 in man.conf. > This results, respectively, in > > %%DocumentMedia: Default 841 1190 0 () () > %%DocumentMedia: Default 595 841 0 () () > %%DocumentMedia: Default 419 595 0 () () > > which apparently are the right dimensions. However, > the Minolta will print all of them on A4 paper, > although it does have a stash of A3 and A5 too. > > That's where I thought it might take a hint from the DSC comment, > if I changed the "Default" to "A3" or "A4" or "A5", or if mandoc(1) > itself put that in the DSC comments. I rewrote it manually before > each printing, but the Minolta still prints them all on an A4: That's interesting, but anecdotal. It is neither surprising that a specific printer selects paper as configured (in whichever way), as opposed to inspecting fikes it is sent; nor would it be surprising if other printers, or even the same one, or printer drivers on the print server, could be configured to inspect the contents of PostScript files to select paper. The trouble is, i just don't know what firmwares and softwares do, what they should do according to standards, and where to look for standards in this respect. Does anybody else know? > Hm, so I can remove man.conf altogether, > because even the default "letter" manpages > will get printed on A4, which is what I want. That's a bad idea. The purpose of the -Opaper= option is not to select paper, but to adjust the width and height that the document content will require, and the primary purpose of the DocumentMedia DSC instruction isn't selecting paper either. but to inform how the content was arranged. If you use -Opaper=letter, margins will be reasonable for letter size paper, but ugly for A4: Since letter paper is wider than A4 but not as tall, printing on A4 without -Opaper=a4 will usually result in an awkwardly narrow right margin and in wasted space at the bottom. Yours, Ingo
Re: /etc/netstart - order of operations (lo vs physical interfaces)
Hi,
this has been taken care of. I just deleted the misleading sentences
from the lo(4) manual page. No replacement is needed.
Thanks for reporting,
Ingo
Hess THR wrote on Fri, Apr 27, 2018 at 07:23:49PM +0200:
> who is "jmc" in the header? can someone cc him?
> or the people who are doing the doc? :)
>
> Many thanks.
>
> > Sent: Friday, April 27, 2018 at 3:28 PM
> > From: "Amelia A Lewis"
> > To: misc@openbsd.org
> > Subject: Re: /etc/netstart - order of operations (lo vs physical interfaces)
> >
> > A read of the script itself shows loopback initialized prior to
> > hardware interfaces, at least in 6.2 (haven't upgraded yet).
> >
> > On Fri, 27 Apr 2018 08:21:54 -0400, Gabriel Guzman wrote:
> > > Just a quick clarification, lo(4) says that the loopback interface
> > > should be configured last, and /etc/netstart seems to support this
> > > but netstart(8) says that the loopback interface is configured `before`
> > > physical interfaces:
> >
> > Date in the man page for lo(4) is 2013. I'm guessing that the network
> > system has moved on since then, and it's actually the lo(4) source
> > that's out of date.
> >
> > Or, possibly, the netstart authors aren't aware of the potential
> > problems, so started initializing loopback devices first, and ought to
> > change things.
> >
> > :-)
> >
> > Amy!
> > --
> > Amelia A. Lewisamyzing {at} talsever.com
> > There's someone in my head, but it's not me.
> > -- Pink Floyd
Re: no route to host (when there is a route )
Hi Tom, i think i am able to reproduce your problem on -current: # sh /etc/netstart em0 # route -n show -inet default192.168.2.1UGS00 - 8 em0 192.168.2/24 192.168.2.100 UCn10 - 4 em0 192.168.2.1link#1 UHLch 12 - 3 em0 [...] # route add 192.168.2.0/25 192.168.2.1 add net 192.168.2.0/25: gateway 192.168.2.1 # route -n show -inet | grep /25 192.168.2.0/25 192.168.2.1UGS00 - 8 em0 # route delete 192.168.2/24 delete net 192.168.2/24 # route add 192.168.2/24 -iface -cloning -nostatic 192.168.2.100 add net 192.168.2/24: gateway 192.168.2.100 # route -n show -inet|grep /2 192.168.2/24 192.168.2.100 UC 00 -56 em0 192.168.2.0/25 192.168.2.1UGS00 - 8 em0 That is very similar to what you have, see the quote from your posting at the very end. Now ping 192.168.2.1 doesn't work because (1) there is no specific route to 192.168.2.1/32 (2) the closest matching route is to 192.168.2.0/25 (3) but that is a *gateway* route via 192.168.2.1, which doesn't help because how to get to 192.168.2.1 is exactly what we are trying to figure out... I can make it work as follows, continuing the previous example: # route add 192.168.2.1 -iface -cloning 192.168.2.100 add host 192.168.2.1: gateway 192.168.2.100 # route -n show -inet | grep UHCS 192.168.2.1192.168.2.100 UHCS 00 - 8 em0 # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 56 data bytes 64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.651 ms # route delete default delete net default # route add default 192.168.2.1 add net default: gateway 192.168.2.1 # route -n show -inet default192.168.2.1UGS11 - 8 em0 192.168.2/24 192.168.2.100 UC 00 -56 em0 192.168.2.0/25 192.168.2.1UGS0 165 - 8 em0 192.168.2.174:31:70:fd:f0:12 UHLch 14 - 7 em0 192.168.2.1192.168.2.100 UHCS 10 - 8 em0 # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=34.990 ms Like that, we *also* have a specific route to the gateway, given that the closest matching route is unusable for the purpose. Note the "h" flag on the 192.168.2.1 UHLch route. That's because i added the default route after the route to the gateway. The other way round, the "h" would be missing and it wouldn't work. So what you are doing seems fragile to me. It may sometimes work due to order of configuration, timeouts, whatever, i'm not sure. But once part of it gets broken for whatever reason, i don't see how it could possibly automatically recover via the normal RTF_CLONING mechanism. If you must have a static route to a subnet that includes the gateway address (5.134.92.1), thus defeating the purpose of the RTF_CLONING flag on the 5.134.92/22 route, it would seem safest to me to manually add the following route *before* adding the default route: # route add 5.134.92.1 -iface -cloning 5.134.92.142 # route add default 5.134.92.1 Take all this with a grain of salt, even though i committed to the route(8) program lately, i'm not at all an expert on it. Yours, Ingo P.S. Your setup seems weird and is likely still fragile even with the above improvement. Having gateway routes for hosts in directly attached networks is very unusual indeed, to wit: Tom Smyth wrote on Tue, May 01, 2018 at 07:05:39AM +0100: > The only (unusual network config) im using is that im deploying > more specific static routes (than the connected route) to allow > clients on a non broadcast network to route to each other > ie if a client wants to talk to another client send packet to > default gateway (icmp redirects are off on the gateway) > > #ifconfig em0 >inet 5.134.92.142 netmask 0xfc00 broadcast 5.134.95.255 > > # route -n -T0 show > 5.134.92/225.134.92.142 UC 00 - 4 em0 > 5.134.92/235.134.92.1 UGS080897 - 8 em0
Re: Viewport for man.openbsd.org -- readability on phones
Hi,
x...@dr.com wrote on Tue, May 15, 2018 at 07:47:45PM +0200:
> The "viewport" meta tag significantly improves readability and
> usability on my phone when I add it to http://man.openbsd.org pages:
>
> [meta name="viewport" content="width=device-width, initial-scale=1.0"]
There is no way i will use that.
It is not defined in any standard.
And i'm quite selective even with features defined in standards
because HTML and CSS standards are very badly proliferating.
In general, i stick to HTML 5.2 and CSS 2.1.
> My test results:
> - Microsoft Edge on Windows 10 Mobile (phone): significant improvement
I'm absolutely uninterested in test results.
I stick to (reasonably established) standards, and it's the job
of browsers to implement them. If a browser failes to implement
a standard that has been in force for a long time, that's a bug
in the browser and not my problem.
But you fail to state what the actual problem is that you are
trying to solve. You also fail to state whether you have any
idea what the root cause of the unstated problem might be.
For example, is it somehow related to the CSS rule
html { max-width: 100ex; } ?
I'm not saying it is, i'm merely asking because i have no idea
what your problem is.
Yours,
Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi Solene, Solene Rapenne wrote on Wed, May 16, 2018 at 12:26:10AM +0200: > x...@dr.com writes: >> The "viewport" meta tag significantly improves readability and >> usability on my phone when I add it to http://man.openbsd.org pages: > See no offence here, I wonder what is the context leading to read man > pages on a phone? I can see some reasons for that: * Kernel freeze on your desktop computer, trying to figure out how to get into ddb (or whatever else to do). * Sitting next to your boyfriend on the train, who is using his laptop on his lap. The poor guy is obviously struggling and apparently doesn't quite know what he is doing. You quickly look it up on your phone to help him out and set him back on track. * Trying to do sh(1) scripting on your Android phone, which fails to have the required manual pages installed, and the OpenBSD manuals are easier to read and more precise than the Linux ones. * Remote support. Your client calls you on your cell phone while you are travelling and starts asking questions that require a quick look into the manual for precise answers. * ... :-) Salut, Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi, x...@dr.com wrote on Thu, May 17, 2018 at 05:04:12PM +0200: > I think it boils down to the site being optimized > for common PC screen sizes, Absolutely not. Mandoc output is not optimized for any device. Which elements or rules in the current HTML or CSS code make you think it is optimized or it discriminates against any device? > If I understand the "viewport" tag correctly, it basically > says that it is OK to let the viewable content fill the screen. That makes no sense at all. The size of the viewport depends on the device and on how big the user made the browser window. How the browser uses the space that happens to be available to it is *always* up to the browser, no matter whether there is a viewport tag or not - except, of course, if the author requests a specific viewport size with the viewport tag, which i'm not doing, and which you do not propose either. Note that mandoc is specifically *not* restricting the browser's decision on how to use the available space, and it is *not* requiring a large width or a large viewport size or anything. So if the browser sets an unreasonably large viewport size that doesn't match the actual size of the device, i don't think you can blame that on mandoc. Yours, Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi Marc, Marc Espie wrote on Wed, May 16, 2018 at 11:28:31AM +0200: > On Tue, May 15, 2018 at 10:51:43PM +0200, Ingo Schwarze wrote: >> x...@dr.com wrote on Tue, May 15, 2018 at 07:47:45PM +0200: >>> The "viewport" meta tag significantly improves readability and >>> usability on my phone when I add it to http://man.openbsd.org pages: >>> >>> [meta name="viewport" content="width=device-width, initial-scale=1.0"] >> There is no way i will use that. >> It is not defined in any standard. > As someone pointed it out, it is in a proposal, improves things on several > devices, and is harmless on others. > > You quite well know that the web evolves by practice first, and > standardization later. > > We are talking about something that's currently already written, will > likely become a standard in some months, and helps using tools. > > Why resist ? Because web design is full of cruft. If i would put in every micro-optimization tweak that somebody suggests for making something better in some situation, we would soon end up with HTML code and a style sheet that are large and unreadable. For example, just last week, somebody requested that i change "font-family: monospace;" to "font-family: monospace, monospace;" for exactly the same reasons you are putting forward: It (arguably) looks better in some situations, it is (arguably) harmless in some other situations, it is widespread practice in the industry, and it is interpreted in similar ways by several popular browsers. No. The only way to stay sane is to restrict ourselves to elements and rules that are really required. Our HTML and CSS should only contain elements and rules with respect to topics that we do want to say something about. I do *not* want to restrict what the browser does with the viewport, so there is no reason to write code for fiddling with the browser's viewport settings. Yours, Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi Aner,
Aner Perez wrote on Thu, May 17, 2018 at 06:32:44PM -0400:
> On 05/17/2018 05:22 PM, x...@dr.com wrote:
>> "Ingo Schwarze" wrote:
>>> Absolutely not.
>>> Mandoc output is not optimized for any device.
>>>
>>> Which elements or rules in the current HTML or CSS code
>>> make you think it is optimized or it discriminates against
>>> any device?
>> I don't know which element or rule is the problem, however
>> if I delete mandoc.css the text does fill the screen.
>>
>> I understand that what I am trying to do is not supported,
>> so I'll do something else instead.
> First non-comment line of mandoc.css says:
>
> html {max-width: 100ex; }
>
> Removing this line allows the use of the full browser width.
That is a very useful bit of information.
Thanks for investigating and reporting it.
For testing purposes, i removed that line from
https://man.openbsd.org/mandoc.css
xcv@, could you check with your phone whether this solves
your original issue?
> I'm sure that it was put there for a reason
> (maybe to approximate the width of a terminal?).
Correct. The original reason was that for -T ascii and -T utf8
output, the default is -O width=78. The reason for that is that
it's conventional wisom in typography that readability of text
suffers with excessive column width - even though some recent
research raises doubts whether that is really true. Either way,
people tend to feel strongly about it.
I must say i never particularly liked that line in the CSS file.
It always felt like fiddling with details that it might be better
not to touch, given that display devices running browsers differ
more than terminal emulators. And here we are with a suspicion
that it actually causes accessibility issues, even if the suspicion
is still unconfirmed...
Depending on the feedback i get here with respect to how
https://man.openbsd.org/
now looks, i shall consider deleting the offending line for good.
In general, i like the idea of making things better by *removing*
harmful tweaks rather than adding new goo...
Yours,
Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi Ken, Ken M wrote on Thu, May 17, 2018 at 08:50:53PM -0400: > I will probably have to duck and run > for suggesting javascript as the answer here... Precisely. :) > But for the most part the modern industry standard to make pages > scale well across many devices and screen orientations is to use > a responsive design library, most notably bootstrap. We are talking about a simplistic one-column layout here, and avoiding that kind of bloat (in particular javascript) is among the top four design goals, together with support for hyperlinks, support for semantic annotations, and avoiding gratuitous presentational differences when compared to terminal output (just to avoid misunderstandings, not every difference is gratuitous: for example, terminals naturally use fixed-width fonts, HTML naturally uses proportional fonts). But no, javascript is an even worse suggestion than the original idea of "meta viewport". Yours, Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Marc Espie wrote on Wed, May 16, 2018 at 11:28:31AM +0200:
> On Tue, May 15, 2018 at 10:51:43PM +0200, Ingo Schwarze wrote:
>> x...@dr.com wrote on Tue, May 15, 2018 at 07:47:45PM +0200:
>>> The "viewport" meta tag significantly improves readability and
>>> usability on my phone when I add it to http://man.openbsd.org pages:
>>> [meta name="viewport" content="width=device-width, initial-scale=1.0"]
>> There is no way i will use that.
>> It is not defined in any standard.
> As someone pointed it out, it is in a proposal, improves things on
> several devices, and is harmless on others.
>
> You quite well know that the web evolves by practice first, and
> standardization later.
>
> We are talking about something that's currently already written, will
> likely become a standard in some months, and helps using tools.
>
> Why resist ?
Actually, the proposed standard is for something else:
CSS "@viewport { width: auto; }" as opposed to
HTML ,
and almost no browser implements the proposed standard.
The proposed standard merely explains how to migrate from
the non-standard meta tag to the @viewport rule.
That said, i did not even consider the possibility that for
such a basic necessity, no standard exists, nor the possibility
that default behaviour is nearly universally broken. But that's
how it is, apparently...
So i think i was wrong and espie@ and xcv@ were right: With broken
and/or inscrutable default behaviour being almost universal and in
the absence of standards, there is no alternative to using whatever
actually works. Also, my remarks about minor tweaks were not quite
to the point because unreadable text on a whole class of devices
is not a minor issue. It is still possible to resist minor tweaks
once we have readable text...
For technical details, see the commit message below.
I'm still open for better solutions, ideally with CSS standardized
long ago such that it is widely available. Also, i'm still interested
in understanding what exactly in mandoc.css causes mobile browsers
to set the viewport width to 1000px by default, but i have no chance
to test myself because i have no mobile device. Apparently, the
max-width attribute on the html element isn't the reason because
removing it only removed, well, the max-width, but did not change
the viewport width according to xcv@'s testing.
Yours,
Ingo
Log Message:
---
In a nutshell, all mobile browsers are broken.
By default, no matter the physical screen size, they use a fixed
viewport width of about 1000px, then scale down the rendered page
to make that huge viewport fit on the physical screen.
That results in poor rendering for bad websites which assume a
large fixed-size viewport (typically requiring zooming in to be able
to actually read any text), but in atrocious rendering for good
websites that make no assumption about the screen size (unreadably
small text in the top left corner, most of the screen empty).
A standard way to disable that insane behaviour and just render
normally on the actual physical screen size does not exist.
The closest thing is the CSS3 Device Adaptation Module Level 1
https://drafts.csswg.org/css-device-adapt/
but https://caniuse.com/#feat=css-deviceadaptation tells me
that basically no browser implements it, not even on mobile.
The next closest thing is the HTML meta viewport element - even though
the problem has nothing to do with HTML and is purely a CSS issue.
Standardization is not even planned for that one:
* HTML 5.2 mentions it in passing without specifying it:
https://www.w3.org/TR/html/document-metadata.html#the-meta-element
* The Web Hypertext Application Technology Working Group
provides very incomplete information:
https://wiki.whatwg.org/wiki/MetaExtensions
* CSS3 Device Adaptation Module Level 1 already wants to deprecate it,
explaining mostly how to migrate *away* from it to some castle in
the sky that no browser implements:
https://drafts.csswg.org/css-device-adapt/#viewport-meta
While i strongly believe in sticking to well-established standards,
in the absence of standards and with atrocious behaviour being
universal, there appears to be no alternative to using whatever
works. The meta viewport element appears to be the only way to
make real-world mobile browsers decently render any HTML page that
does not have a fixed-width layout of 1000px. So use it, grudgingly.
Originally suggested by xcv at dr dot com.
Direction supported by espie@.
Modified Files:
--
mandoc:
cgi.c
Revision Data
-
Index: cgi.c
===
RCS file: /home/cvs/mandoc/mandoc/cgi.c,v
retrieving revision 1.156
retrieving revision 1.157
diff -Lcgi.c -Lcgi.c -u -p -r1.156 -r1.157
--- cgi.c
+++ cgi.c
@@ -356,6 +356,8 @@ resp_begin_html(int code, const char *ms
"\n"
"\n"
" \n"
+ " \n"
" \n"
" ",
Re: Viewport for man.openbsd.org -- readability on phones
Hi Lars, Lars Nooden wrote on Fri, May 18, 2018 at 06:37:26PM +0300: > 2) Regarding CSS, keeping the viewport settings in the CSS would > allow the presentation and structure to remain more separate. Exactly what i said in my last mail, it doesn't belong into the HTML. > So something more-or-less similar to the change below would keep the > presentation in the CSS and leave the programming to handle the > structure. But as i explained in my last mail, practically no browser supports css-device-adapt-1, not even on mobile platforms. Again, when talking about long-established standards (like CSS 2.1), i don't care about browser support and gladly blame browsers that fail to conform to the standards. But relying on *future* standards that no browser supports makes no sense. Yours, Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi, Mihai Popescu wrote on Fri, May 18, 2018 at 11:50:24PM +0300: > I have tested it on someone's Safari/iOS for iPhone, out of curiosity. > It takes the full screen. Looking at the font in the posted > screenshots i think it is Android in question. I don't understand what you are trying to say. Which version did you test? The current one (i.e. with the meta viewport element and the max-width attribute) or an older version? If so, which one? The one without both? Or the one with the max-width attribute only? What was the result? Was the text shown in a readable size, or was it unreadably small, like in the examples shown by the OP? > If it is not a secret, what runs behind man.openbsd.org? > Like httpd, CGI? Read https://man.openbsd.org/ , it's really not that long. It links to https://man.openbsd.org/man.cgi.8 which links to https://man.openbsd.org/slowcgi.8 and https://man.openbsd.org/httpd.8 . The setup is as documented. Here is the complete configuration, if you are curious: schwarze@man $ cat /usr/src/usr.bin/mandoc/cgi.h #define SCRIPT_NAME "" #define MAN_DIR "/man" #define CSS_DIR "" #define CUSTOMIZE_TITLE "OpenBSD manual pages" #define COMPAT_OLDURI Yes Yours, Ingo
Re: multiple manpaths for man.cgi?
Hi Justina, justina colmena wrote on Sat, May 19, 2018 at 06:01:11PM +: > I was looking for more man pages, so I copied the ones > in /usr/X11R6/man and /usr/local/man over to /var/www/man and listed > them in manpath.conf as instructed. So now they are available here. > > https://amarillo.colmena.biz/cgi-bin/man.cgi > > Several issues here: What you report is all intentional and working as designed. > 1.) The search is not falling through to the second and third manpaths. No. That is intentional. For man.cgi(8), different manpaths are intended to represent completely independent manual page trees, for example for different operating systems or different operating system versions. So if you want to search across a given set of manual pages, put them all into the same manpath. For man(1), from the perspective of search tools, having all the pages in a single path would also be simpler, but it would mix base system, Xenocara, and ports content, so we don't do it. That difference also makes sense from the following perspective: Using man(1) locally on a given machine, you typically want to look at manual pages of the installed version of the installed operating system only, so having only one operating system set up is a sane default. Of course, if you want to install pages for a different system, you can still do so in a user-defined tree. For example, the man-pages-posix port does something like that. On a web server, you often want to serve pages for more than one system, so having easy multi-system support is sane. Of course, you can still put everything into a single manpath if that's what you want. That will even automatically hide the selection dropdown. > 2.) The manpath appears in the URL for the second and third manpaths, > but not the first. That's intentional. We shorten the URI as much as possible because that's very convenient for users. As a matter of fact, i type out URIs by hand more often that using the search form. My main use case for the search form is complicated apropos(1) queries. Besides, the first manpath is intended as the default operating system served by the server, the other for alternative systems requested less frequently. I guess every server has a default system. > 3.) The links are not generated in the "see also" section for pages on > the second and third manpaths. No. It is intentional that you cannot link from one operating system to a different one. That would be seriously confusing. Yours, Ingo
Re: multiple manpaths for man.cgi?
Hi Justina, justina colmena wrote on Sat, May 19, 2018 at 07:52:35PM +: > On Sat, 19 May 2018 18:01:11 + > justina colmena wrote: >> 3.) The links are not generated in the "see also" section for pages on >> the second and third manpaths. > Okay. This looks like more of an issue with the man pages themselves... > which just don't happen to be as fancy as OpenBSD's. > > /usr/local/man/man1/initdb.1 > > .SH "SEE ALSO" > \fBpg_ctl\fR(1), \fBpostgres\fR(1) That is typical man(7) code; BSD systems use the better mdoc(7) language. > The "\fB" and "\fR" are just literal codes for font bold and back to > font regular, not intended to automatically generate links like > OpenBSD's man pages. The feature request has been rotting on the TODO list for some years: http://mandoc.bsd.lv/cgi-bin/cvsweb/TODO?annotate=HEAD Search for "try to guess Xr" in that page. 1.187 406: - jsg on icb, Nov 3, 2014: 407: try to guess Xr in man(7) for hyperlinking 1.226 408: and render them with 409: https://github.com/Debian/debiman/issues/15 410: loc * exist * algo ** size ** imp ** As you see from the classification, it's rated at the lower edge of medium difficulty and medium importance, but people aren't all that eager to spend their time on the obsolete man(7) language, unless their name is esr@, and esr@ didn't contribute to mandoc so far. I guess if you do it the quick and dirty way, it will probably be about twenty to thirty LOC in a single file, i.e. in the man_html.c formatter. If you do it properly, generating AST nodes in the man(7) parser, which i might prefer (not sure yet), it might touch half a dozen files, with the main 20-30 lines going to the man.c parser and the changes to the other files being relatively minor. Yours, Ingo > http://man.openbsd.org/roff > /usr/share/man/man1/ls.1 > > .Sh SEE ALSO > .Xr chflags 1 , > .Xr chmod 1 , > .Xr symlink 7 , > .Xr sticky 8 > > And that ".Xr" is some sort of macro more suitable for processing into > a link.
Re: Viewport for man.openbsd.org -- readability on phones
Hi Justina, justina colmena wrote on Thu, May 24, 2018 at 05:54:45PM +: > On Wed, 23 May 2018 11:47:47 +0200 > Marko Cupać wrote: >> I am sure OpenBSD will correct their errors in html/css code, if any, > Right now, https://man.openbsd.org/relayd.conf.5 fails html validation. > https://validator.w3.org/nu/?doc=https%3A%2F%2Fman.openbsd.org%2Frelayd.conf.5 > There are several html elements with duplicate IDs. Sure, that's on the TODO list: http://mandoc.bsd.lv/cgi-bin/cvsweb/TODO?rev=HEAD --- HTML issues - duplicate names generate duplicate href="#..." anchor attributes possibly use "#..._" suffixes? Jakub Klinkovsky 3 Oct 2017 21:23:36 +0200 see also the thread: gre(4): Rename duplicate sections up to 20 Apr 2018 15:27:33 +0200 loc * exist * algo * size * imp *** It's not the worst HTML syntax violation left in mandoc, and it's among the easier ones to fix. Actually, just skipping dupes may be better than suffixes because permalinks with suffixes don't make much sense. As soon as someone inserts or deletes text, subsequent permalink anchors with suffixes might suddenly point to different places, ehich defeats the very purpose of permalinks. Besides, the main virtue of mandoc permalinks is their simplicity, allowing people to type them by hand without even looking at the manual page first. I just know that https://man.openbsd.org/cat#v will work (and is harmful), without even testing it first. Appending suffixes would compromise that virtue. Yours, Ingo
Re: smtpd.conf new grammar
Hi Rupert, [ deleted tech@ because this is off topic there ] Rupert Gallagher wrote on Thu, May 24, 2018 at 04:38:17PM -0400: > On Thu, May 24, 2018 at 14:18, Gilles Chehade wrote: >> In effect, instead of having: >> accept from any for local deliver to mbox >> >> You will have: >> action "my_action" mbox >> match from any for local action "my_action" > It may solve some obscure technical problem, but is a horrible > thing to read and write. How about keeping the best of both worlds? > Leave the old beautiful PF-like syntax to humans, and translate it > into the newEgyptian(tm) on the fly? That was my (and jmc@'s) initial reaction, too, and gilles@ tried very hard to do just that for a long time. But it doesn't actually work. For example, as long as you do not have an "action name" attached to a directive, you cannot get the benefit of changing the directive, restarting smtpd(8), and having it applied to subsequent delivery attempts - simply because, after editing the rule, it is no longer clear whether it is the same or a different rule, in particular when rules get added or deleted or multiple rules change at the same time. Of course, it would have been possible to add a "rulename" sub-directive to the old syntax, but that would have resulted in a highly redundant syntax because it would suddenly have left you with several equivalent possibilities of writing the same ruleset - with either monolithic or modular rules in various combinations. Also read gilles@ blog posts, this is by far not the only tough problem, just the worst one according to my understanding. Also note that apparent difficulty and actual difficulty of a syntax is not the same thing. If a task is actually technically fairly complex, then an apparently simplistic syntax can actually hide part of the difficulties and not only make it harder to implement, but also harder to use - which is what happened here with the old syntax. Things can actually get simpler with an apparently more complex syntax, even if it is less obvious and not quite easy to document, as in this case - and believe me, i have spent a bit of time on smtpd.conf(5) during the last few days. There is still some work to do on the docs, but we are getting closer. I also discussed the wording, in particular the keywords "match" and "action" with gilles@ and eric@ and while i wasn't convinced from the start, they showed me that other projects came up with similar terms, independently, and they correspond well to the terms mail admins use when discussing such matters, independent of the particular software used. Also, do not underestamite the benefit of simplifying the code - fewer bugs implies better usability - and do not underestimate the cost of maintaining an old syntax poorly suited to a problem - being forced to constantly fiddle with excruciating code causes developer frustration and slows down progress. Yours, Ingo
Re: Viewport for man.openbsd.org -- readability on phones
Hi,
Ingo Schwarze wrote on Thu, May 24, 2018 at 09:15:29PM +0200:
> justina colmena wrote on Thu, May 24, 2018 at 05:54:45PM +:
>> On Wed, 23 May 2018 11:47:47 +0200 Marko Cupac wrote:
>>> I am sure OpenBSD will correct their errors in html/css code, if any,
>> Right now, https://man.openbsd.org/relayd.conf.5 fails html validation.
>> https://validator.w3.org/nu/?doc=https%3A%2F%2Fman.openbsd.org%2Frelayd.conf.5
>> There are several html elements with duplicate IDs.
> Sure, that's on the TODO list:
[...]
> It's not the worst HTML syntax violation left in mandoc,
> and it's among the easier ones to fix.
Anyway, i just fixed it with the commit below (and also installed
the fix on man.openbsd.org).
[...]
> Actually, just skipping dupes may be better than suffixes because
> permalinks with suffixes don't make much sense. As soon as someone
> inserts or deletes text, subsequent permalink anchors with suffixes
> might suddenly point to different places, which defeats the very
> purpose of permalinks.
>
> Besides, the main virtue of mandoc permalinks is their simplicity,
> allowing people to type them by hand without even looking at the
> manual page first. I just know that
>
> https://man.openbsd.org/cat#v
>
> will work (and is harmful), without even testing it first.
> Appending suffixes would compromise that virtue.
After re-reading the discussion with Jakub, i came to the conclusion
that suffixes do *not* compromise that virtue -
https://man.openbsd.org/cat#v
still works just like before even with suffixes because the first
occurence does of course not get a suffix.
Generating the deduplication suffixes is simple, does not force
anybody to actually use them, but they may occasionally be useful
in some situations - probably not so much as links from a static
website to man.openbsd.org, but for example for quickly directing
somebody from a chat to a particular point in the current version
of a specific manual page:
i feel confused... :-(
well i'm talking about
https://man.openbsd.org/relayd.conf#forward_to_6
not about
https://man.openbsd.org/relayd.conf#forward_to_3
Yours,
Ingo
Log Message:
---
Do not write duplicate id= attributes, they violate HTML syntax.
Append suffixes for disambiguation. Issue first reported by Jakub
Klinkovsky (Arch Linux).
Modified Files:
--
mandoc:
TODO
html.c
html.h
man_html.c
mdoc_html.c
Revision Data
-
Index: html.c
===
RCS file: /home/cvs/mandoc/mandoc/html.c,v
retrieving revision 1.228
retrieving revision 1.229
diff -Lhtml.c -Lhtml.c -u -p -r1.228 -r1.229
--- html.c
+++ html.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,7 @@
#include
#include "mandoc_aux.h"
+#include "mandoc_ohash.h"
#include "mandoc.h"
#include "roff.h"
#include "out.h"
@@ -117,6 +119,9 @@ static const char *const roffscales[SCAL
"ex", /* SCALE_FS */
};
+/* Avoid duplicate HTML id= attributes. */
+static struct ohash id_unique;
+
static void a2width(const char *, struct roffsu *);
static void print_byte(struct html *, char);
static void print_endword(struct html *);
@@ -144,6 +149,8 @@ html_alloc(const struct manoutput *outop
if (outopts->fragment)
h->oflags |= HTML_FRAGMENT;
+ mandoc_ohash_init(&id_unique, 4, 0);
+
return h;
}
@@ -152,15 +159,22 @@ html_free(void *p)
{
struct tag *tag;
struct html *h;
+ char*cp;
+ unsigned int slot;
h = (struct html *)p;
-
while ((tag = h->tag) != NULL) {
h->tag = tag->next;
free(tag);
}
-
free(h);
+
+ cp = ohash_first(&id_unique, &slot);
+ while (cp != NULL) {
+ free(cp);
+ cp = ohash_next(&id_unique, &slot);
+ }
+ ohash_delete(&id_unique);
}
void
@@ -257,10 +271,12 @@ print_metaf(struct html *h, enum mandoc_
}
char *
-html_make_id(const struct roff_node *n)
+html_make_id(const struct roff_node *n, int unique)
{
const struct roff_node *nch;
- char*buf, *cp;
+ char*buf, *bufs, *cp;
+ unsigned int slot;
+ int suffix;
for (nch = n->child; nch != NULL; nch = nch->next)
if (nch->type != ROFFT_TEXT)
@@ -277,6 +293,30 @@ html_make_id(const struct roff_node *n)
if (*cp == ' ')
*cp = '_';
+ if (unique == 0)
+ return buf;
+
+
Re: I got smtpd.conf working thanks to the man page
Hi Walter, Walter Alejandro Iglesias wrote on Tue, May 29, 2018 at 05:47:36PM +0200: > My advice to others is not to pay attention to anything > but the man page, While that's often nor bad advice in other areas of OpenBSD, this particular manual page is not perfect yet, as should be obvious to anyone looking at it. So until these manual pages get finished, Gilles' various blog and mailing list posts, and the source code, might be required for missing clues. Of course, only start searching elsewhere after checking the manual. Yours, Ingo
Re: How to search for "hostap" in man pages.
Hi, Karel Gardas wrote on Sat, Jun 16, 2018 at 10:39:51PM +0200: > was looking for "hostap" or "Host AP" using man -k and apropos, > but this somehow does not return expected results: > > $ man -k hostap > hostapd(8) - Host Access Point daemon > hostapd.conf(5) - configuration file for the Host Access Point daemon man -k any=hostap searches in *any* marked up content. Read apropos(1) for details. You cannot search in content that is not marked up in any way, though. Arguably, the word "hostap" ought to be marked up in pages like ral(4) with .Cm; unfortunately, right now, it is not. Sorry if i'm somewhat slow at answering right now, i'm still almost offline for a week. Yours, Ingo
Re: How to search for "hostap" in man pages.
Hi Luke, Luke A. Call wrote on Sat, Jun 16, 2018 at 05:34:45PM -0600: > I think "man -K" would work on gnu/linux, The man(1) implementation used on many (but not all) Linux systems, man-db, does have a -K option since 2009. But what it does is just linearily search through the full text of all manual page files in question, without using any kind of a database - even though it is called man-db. The older man(1) implementation used by some other Linux systems has it, too, since man-1.5e, which was released between 1993 and 1998; that's probably where this option first appeared. It is also available on Solaris 11. I do not consider that option useful. On the one hand, it is so expensive that i wouldn't recommend using it, and even the man-db manual page warns about the seriously bad performance. I don't want options in mandoc that aren't really usable. On the other hand, if you feel like you absolutely must do a full text search across manual pages, you can already do that with grep(1), as you mentioned. So it isn't really needed as an option to mandoc. Actually, i occasionally, but rarely, use grep(1) myself on manual page, but almost exclusively when trying to find pages containing words that ought to be marked up, but where the markup is missing. That's more of a manual tree maintainer job than an end-user job. So i do not intend to implement -K, and would probably even reject patches implementing it, calling them featuritis = bloating the user interface for very little profit, if any. Yours, Ingo
Re: Rewards of Up to $500,000 Offered for OpenBSD Zero-Days (and other dist.)
Hi, Eric wrote on Wed, Jul 04, 2018 at 01:55:17PM -0500: > The solution is obvious. If there are any bug fixes of sufficient > importance, report the bug, collect the $500,000 for the foundation, > and then fix it. i can hardly believe this needs to be said, but given the lack of any smiley, and given the presence of several purportedly "humorous" postings in this thread: Given that the very *purpose* of the company trying to buy these exploits is to earn money from COVERTLY BREACHING THE PRIVACY OF SOFTWARE USERS, i'm calling out that company, and any other company with a similar business plan, as a particularly bad instance of ORGANIZED CYBERCRIME according to any reasonable moral standard. For example, i believe that this kind of criminal activity is SUBSTANTIALLY WORSE than ordinary credit card fraud because such companies put hundreds of millions of people at risk who do not even learn that they were harmed, not even after the fact, whereas with ordinary fraud, the victim at least knows about the completed crime. Besides, what this company does is life-threatening, whereas credit card fraud only puts your money in danger. So i'm adamant that anybody even remotely considering to do any kind of business with such a company must be instantly expelled from any kind of free software project. Besides, you can't be so naive as to think that you will see any money from such a criminal enterprise without signing an NDA to NOT DISCLOSE THE VULNERABILITY TO THE SOFTWARE AUTHOR (or anyone else)? Besides, even if you could retain the right to publish the vulnerability you reported, it is an obvious requirement of basic ethics that you report potentially dangerous bugs as soon as possible TO THE SOFTWARE AUTHOR, in particular, before talking to anybody else about them, and that you do not disclose the problem to third parties before the vulnerability is fixed, unless the author fails to fix the problem within reasonable time, typically a few days, sometimes maybe a few weeks. So the order of actions you are proposing is close to criminal as well. Now, can we please stop this thread? Even joking about these matters is hardly funny because it implies an insinuation that there might be anybody involved in OpenBSD who might remotely consider doing business with such criminal organizations, or that there might be any bribable or corrupt people in the vicinity of the project. Such insinuations are not funny. The question how such criminal organizations could be abolished might be considered politically interesting by some, but even that question is totally off-topic on misc@. It is simply and plainly unrelated to OpenBSD. The only on-topic aspect is the fact that state agencies exist that actively and systematically attempt to compromise the security of any kind of software, including free software, including OpenBSD. But that is not news.
Re: Offline FAQ
Hi Ahmed, Ahmed Khanzada wrote on Thu, Jul 19, 2018 at 03:57:17AM -0700: > I am a programmer with a strong passion for both documentation and > offline computing. Inspired by 9front, I was wondering if there was > any interest in porting the currently online-only FAQ to an offline > FAQ format that could perhaps ship with OpenBSD by default, enabling > a user to have a completely self-documented operating system without > the need for an Internet connection. > > Preferably, this offline FAQ would not be in HTML or anything > browser-centric, but rather in something like a man format friendly > for terminal perusing. I already planned that for years and finally offered one and a half years ago to do the work of the HTML to mdoc(7) conversion myself and fully integrate the FAQ into the base system manual pages, as a new "faq" section alongside the traditional numeric sections. My arguments were: 1. Easier maintenance. No more need to update the FAQ in one big step at release time. Lower risk to lose patches because everything can be committed at any time. Easier for others to contribute because right now, nobody knows what exactly has already been written for the next release. 2. Easier editing. In particular, mdoc(7) .Xrs and .Sxs are much less cumbersome to edit than HTML s, and there are a lots of them. But that applies to almost all markup, even ".Fl x" is shorter and easier to type than "-x". 3. FAQs for -current become available, not only with spending no additional maintenance effort, but even reducing effort. 4. The FAQ becomes available offline because it can simply be installed just like the other manuals. 5. FAQ pages show up in apropos(1). 6. More expressive markup. All mdoc(7) macros can be used, not just and . 7. Semantic searching. FAQ pages can be searched for with apropos(1) searches for specific macro keys. 8. Normal manual pages can more naturally link back to the FAQ by simply using .Xr rather than .Lk. 9. It's always good to have all documentation available in one place and with one tool: users will less easily miss the parts they are looking for. However, the current FAQ maintainers, tj@ and tb@, vetoed the idea arguing as follows: 1. They dismissed argument 1, stating they feel it isn't significantly harder to collect updates non-publicly over time and then commit them all together at release time than to follow the normal "only even edit -current" policy used for the source tree at large, including manual pages. 2. They dismissed argument 2, stating that they personally know HTML better than mdoc(7) and expect more users to know HTML than mdoc(7). 3. They dismissed argument 3, saying that the FAQ is mainly for new users (which i disagree with), these mainly run -stable, and having a -current FAQ would only cause confusion (which i don't believe either - quite to the contrary, i often see confusion because people try to use the FAQ with -current). 4. They dismissed argument 4, saying that they specifically want to keep the FAQ online-only such that corrections are instantly visible to users, while offline versions would retain errors until the next update. 8. They dismissed argument 8, saying that few manual pages link to the FAQ in the first place. There was consensus that arguments 5 to 7 and 9 are relevant, but they considered them less important than the percieved downsides in arguments 1 to 4. Given that i highly appreciate the important work tj@ and tb@ do on the FAQ, i decided to not do the conversion because no matter what others may think, the people actually doing the work (in this case the FAQ maintenance) get to decide how they do it. And in this case, they clearly prefer keeping the FAQ separate and in HTML. So that is what gets done, even though i almost completely fail to understand the reasons. > I would be more than happy to lend my time and efforts to such > a project, if the community deems it appropriate. Much appreciated, but unfortunately, that is not sufficient to let the idea become reality at this point in time. It would be great if you could start sending patches for whatever issues you find in both manual pages and in the FAQ, though. Yours, Ingo
Re: Add my web site to "support" section like "new" one
Committed. May take a short time to propagate to the server. Adrien wrote on Thu, Aug 02, 2018 at 03:51:05PM +0200: > 0 > C France > P Ile de france > T Paris > Z 75020 > O Iglou.eu > I Adrien Kara > A 3/7 rue Albert Marquet > M cont...@iglou.eu > U https://iglou.eu/ > B +33 9 72 61 63 13 > X > N Maintenance et déploiement d'OpenBSD sur serveur client·e·s. > Configuration de services sécurisés (httpd, smtpd, pf, ...). > Réalisation de scripts shell, application web et local sous OpenBSD.
Re: lsof alternative for listing open files?
Hi Edward, Edward Lopez-Acosta wrote on Thu, Aug 09, 2018 at 05:41:04PM -0500: > I am aware of fuser and fstat but these seem to only give me inodes. > Is there an equivalent to the Linux application `lsof`? $ pkg_add lsof Obsolete package: lsof (ancient software that doesn't work) Once a process has a file open, there is no was to get back from the file descriptor to a file name. Actually, the file name may have changed since the file was opened, or the file may not have any name whatsoever any longer, or the name might now point to a different file that is not open. It is by design that you cannot translate an inode number back to a filename. I have no idea what the Linux kernel is doing with symbolic links like /proc/21325/fd/3, but i doubt that it makes much sense. What is the actual problem you are trying to solve? Yours, Ingo
Re: lsof alternative for listing open files?
Hi Edward, Edward Lopez-Acosta wrote on Thu, Aug 09, 2018 at 06:29:04PM -0500: > I was looking to port bleachbit, system cleanup tool, to OpenBSD > and one function is to make sure certain files are not in use before > it proceeds. Strictly speaking, that is impossible due to a TOCTOU race condition. You cannot do the check and the removal atomically in one step. If you do the check and find that no process has it open, then by the time you proceed to removing it, another process may have opened it. Or even worse, someone may have deleted the old file or moved it to a different name and a third person may have created a completely new file for a completely different purpose with the old name. None of that is OpenBSD-specific, by the way, the same arguments hold on Linux. If you are willing to ignore the dangers posed by such race conditions, then both fuser(1) and fstat(1) can be used: both take "file" arguments. By the way, i just confirmed that the /proc/PID/fd/FDNUM filename feature is indeed broken on Linux: $ uname -a Linux donnerwolke.asta-kit.de 4.9.0-0.bpo.3-686 #1 SMP Debian 4.9.30-2+deb9u5~bpo8+1 (2017-09-28) i686 GNU/Linux $ cd /tmp $ touch old.txt $ tail -f old.txt In another terminal: $ cd /tmp $ ln old.txt new.txt $ rm old.txt $ pgrep tail 24052 $ readlink /proc/24052/fd/3 /tmp/old.txt (deleted) $ lsof | grep new.txt $ lsof | grep tail | grep 3r /tmp/old.txt (deleted) So the kernel claims that "new.txt" is not open by any process, and it also claims that the file open by tail(1) can no longer be accessed via the file system. However, typing $ echo test >> new.txt in the second terminal makes "test" appear on the first terminal, so it is a totally normal, fully functional file. So the description "Obsolete package: lsof (ancient software that doesn't work)" is indeed accurate. If lsof says a file isn't open, it may well be open anyway. If lsof says a file was deleted, that may be an outright lie. If lsof reports that a given process has a file open with some name, then that name may be neither the name the process used for opening the file nor any of the names the file has now, though it usually is one of the names that the file may have had at some undefined time in between. You cannot rely on any of those statements from lsof because making such statements is just impossible by the basic way how UNIX (including Linux) works, even without any race conditions. And then you get the race conditions on top of all that. Enjoy the mix! Yours, Ingo
Re: lsof alternative for listing open files?
Hi Theo, Theo de Raadt wrote on Thu, Aug 09, 2018 at 06:11:14PM -0600: > Ingo, you don't understand. Kids these days don't want something that > always works. It only has to work most of the time! Then they can > build a company upon the quicksand! What a pity that you already wasted weeks, if not months by making sure that what unveil(2) does with file and directory names has well-defined behaviour and is fully consistent, and that the behaviour is designed in a way that can be documented fully and clearly, in a way seeming so simple that the tricky design work preceding it is totally hidden from the user. All that time could have been saved by realizing earlier what it is that the kids actually want! (-; Ingo
Re: Base httpd and addons like OpenSMTPD extras in ports?
Hi, what the decision what is in base vs. in ports ultimately boils down to is developer convenience. Consequently, that's one of the rare things non-developers really can't help with. It may also be convenient for users that small, solid, and functional solutions for many common tasks are already available in base, so it's harder to break your system by opting out of installing vital stuff (well, you can still break it if you try hard enough, xbase anybody?). But that's really only a non-critical by-product because it's very easy for users to install the ports they need. But the other way round is really pointless: if something is in base for developer convenience, it really doesn't hurt users, even if many don't use it. For example, you probably shouldn't run bgpd(8) at home unless your name is Theo, yet moving it into ports would be a major PITA, and no developer would even half-seriously consider it. Just as an obvious example. Yours, Ingo
Re: make(1) and multiple outputs
Hi Kristaps, Kristaps Dzonsons BSD.LV wrote on Fri, Aug 31, 2018 at 09:23:33AM +0200: > Short: is there a way to manage multiple outputs from a single command > with OpenBSD's make(1)? > > Longer story. I have a site that generates a few hundred articles using > sblg(1). Each output article is indexNNN.html, which depends upon every > input indexNNN.xml. So a change to any indexNNN.xml must result in > rebuilding all indexNNN.html using a single command. > > In GNU make, I can use the pattern substring match to effect this: > > all: index001.html index002.html > > index001%html index002%html: index001.xml index002.xml > sblg -L index001.xml index002.xml What is wrong with simply index001.html index002.html: index001.xml index002.xml sblg -L index001.xml index002.xml as documented in make(1), https://man.openbsd.org/make.1#DEPENDENCY_LINES It works for me, see the mock-up example below. I have no idea what '%' means, though, and neither the gmake(1) manual page nor the gmake info page appear to mention it. > But obviously that's GNU-only. It is, as a fallback, possible to have > sblg(1) create one output per input and play nice with make(1): > > index001.html: index001.xml index002.xml > sblg -C index001.xml index001.xml index002.xml > > But with hundreds of articles (each of which depends upon parsing > hundreds of articles), those are a lot of wasted cycles. > > I currently just use the GNU make, but I'd rather use only stock > components on the server. Any thoughts? Here is my test: $ cat Makefile all: output1 output2 output1 output2: input1 input2 sh ./sblg $ cat sblg echo running sblg... 1>&2 cat input1 input2 > output1 cat input2 input1 > output2 echo sblg done. 1>&2 $ cat input1 content 1 $ cat input2 content 2 $ make sh ./sblg running sblg... sblg done. $ cat output1 content 1 content 2 $ cat output2 content 2 content 1 $ sed -i 's/2/3/' input2 $ make sh ./sblg running sblg... sblg done. $ cat output1 content 1 content 3 $ cat output2 content 3 content 1 make(1) does the right thing and only runs ./sblg once, even though output from "make -n" is misleading: $ rm -f output* $ make -n sh ./sblg sh ./sblg
Re: resize /usr
Hi Ken, Ken M wrote on Sun, Sep 02, 2018 at 03:47:05PM -0400: > 16 partitions: > #size offset fstype [fsize bsize cpg] > a: 2097152 64 4.2BSD 2048 16384 12958 # / > b: 8241536 2097216swap# none > c:2500696800 unused > d: 8388608 10338752 4.2BSD 2048 16384 12958 # /tmp > e: 23823104 18727360 4.2BSD 2048 16384 12958 # /var > f: 31460960 42550464 4.2BSD 2048 16384 12958 # /usr > g: 41929664 74011424 4.2BSD 2048 16384 12958 # /usr/ports > h:134126688115941088 4.2BSD 2048 16384 12958 # /home > > Frankly what probably makes the most sense is remounting /usr/ports to > be /usr/local. That probably makes the most sense. Frankly first doing > this I am sure I did not make the best decisions as I am still on the new > side of using OpenBSD. How exactly to distribute space among partitions really depends on what you want to use the machine for. The disk you are showing above can be called terribly small nowadays (though i admit that i used disks in production with OpenBSD 2.7 17 years ago that were more than 1000 times smaller), so small that you are likely to run out of space sooner or later even if you don't let waste data lying around. Yes, you always want /usr/local/, except maybe on a pure firewall router where you are not planning to install any ports whatsoever except rsync. I see you do not have /usr/src/, /usr/obj/, /usr/xenocara/, and /usr/xobj/, so you are obviously not planning to work on patches to the base system or to X11. Nothing is wrong with that. If you ever start doing such work on that machine, you will have to bite off the required partitions from home, though. It would have been smarter if you had left at least 10G at the end of the disk unallocated; if you ever needed some partition like that, you could create it without a fuss; if /home/ ever got full, you could move some stuff there. I see you do have /usr/ports/, so obviously, you are planning to do some work on ports. I only work on ports *occasionally*, i'm not a real porter, yet i currently have the following amounts of space *in use* for work on ports: - /usr/local/-- 9 GB (separate partition) - /usr/ports/pobj/ -- 18 GB (separate partition) - /usr/ports/distfiles/ -- 9 GB (partition /usr/ports/) - /usr/ports/packages/ -- 8 GB - /usr/ports/-- 650 MB (rest of the partition) In addition to that, i have about 115 checkouts of source trees of various software that i occasionally work on or look at on another partition, which takes up another 21 GB (but that's more for base that for ports work). Yours, Ingo
Re: Equipment for OBSD based firewall
Hi Bogdan, Bogdan Kulbida wrote on Mon, Sep 03, 2018 at 04:17:51PM -0700: > I need to build a pf OBSD firewall for a small office. What minimally > feasible equipment would you recommend in order to achieve this goal? I seriously doubt that you can find anything in the trash that isn't seriously oversized. In 2001, i ran an OpenBSD 2.7 firewall with ipf(4) on an Intel 486-SX25 (25 MHz) with 24 MB (not GB!) RAM, a system disk of 100 MB (not GB!) and a /var/ disk of another 100 MB. The about ten concurrent users were happy with it for years. OK, that would no longer work because the SX25 had no numerical coprocessor which is now required to run OpenBSD, and it required some fiddling to fit the system installation into 100 MB. But it always routed the traffic fast enough. Currently, one of my office firewalls runs on: - CPU: AMD-K6 234 MHz (yes, a quarter of a GHz) - RAM: 128 MB (yes, an eigth of a GB) - HD: ATA (not SATA!) UDMA-2, 3 GB (not 300 GB!) The only reason the machine is *THAT* large is that at the time it was selected, we no longer had any smaller dismantled desktop machines in the trash. I don't have the slightest doubt that a much smaller machine would also be fine - certainly with half of everything, like 100 MHz, 64 MB RAM, 1 GB disk. And since then, i'm too lazy to pull something newer from the trash to replace it - because it just works. As a matter of fact, i'm sending this email over it... Yours, Ingo
Re: groups new
Hi, Jan Prunk wrote on Thu, Sep 20, 2018 at 06:48:55PM +0200: > 0 > C Slovenia > P SI > T Ljubljana > F irregular > O BSD User Group Slovenia > I > M b...@groups.io > U https://bsdug.wordpress.com > N *BSD I had a look at it and i feel that it is too early to add it. The website does not contain any content whatsoever. The mailing list page says "1 Member, 0 Topics". One person not doing anything is not a group. Consider coming back after this has actually become a group that is doing anything beyond having an empty website. Yours, Ingo
Re: network architecture question
Hi Marko, sorry for the slow response, but given that nobody else answered, maybe it's still relevant. Marko Cupac wrote on Fri, Sep 14, 2018 at 02:45:30PM +0200: > for years I have been using setup with two firewalls: "outer" one - > FW1-BGP - connecting to upstream ISPs and talking BGP to them regarding > my DMZ, and "inner" one - FW2-NAT, doing NAT for my LAN. > > ISP1 ISP2 > \ / >[FW1-BGP] >| > (DMZ) >| >[FW2-NAT] >| > (LAN) That's the normal firewall topology for any network of any significant size and security requirements. > (Actually, it's more complicated due to each of the firewalls having > their CARP twin, but that shouldn't matter for my questions). > > I'm considering moving to setup with just one firewall (ok, two, > because of CARP, once again it should not matter), which would connect > to upstream ISPs, DMZ and LAN. > > ISP1 ISP2 > \ / >[FW1-ALL] > / \ > (DMZ) (LAN) That's a poor-man's solution for somebody who cannot afford the hardware or electricity cost for two machines. I doubt that's the case for you. This is discussed in very great detail, covering several chapters, in the fundamental book by Elizabeth D. Zwicky, "Building Internet Firewalls" (O'Reilly 2000). While in that book, lots of information about specific services is somewhat dated, i think the part about topologies still holds. Of course, i cannot summarize several chapters in one sentence, but the essence is that FW1-BGP is directly exposed to the Internet, so in that sense, it is easy to attack and ought to do as little as possible and be as simple as possible for optimum security, whereas FW2-NAT is the crucial defence for your LAN and necessarily more complex. On the one hand, that is OK because it is protected by FW1-BGP, so it is much harder to attack in the first place. On the other hand, you absolutely do not want FW2-NAT compromised, because then your LAN would be wide open to attack. To summarize, your plan will dramatically reduce the security standard of your network in several ways. It is certainly not a good idea for a corporate or professional firewall protecting a network of any significant size or importance. Zwicky repeatedly and emphatically warns against putting any other services on the internal router (FW2-NAT in your case), in particular against combining it with any of the DMZ hosts or with the external router (FW1-BGP in your case). > Any success / failure stories from admins who already went through > this? Any pitfalls I should avoid? Despite the above, you may be surprised that i have been running exactly your FW1-ALL topology on the firewall router of the student organization of the University of Karlsruhe since 2001 - except that we have only one ISP uplink, and that's not going directly to the Internet, but to the computing center of the university, so there is still the university firewall separating it from the Internet. But the protected network is small, has only a couple dozen users, and is rarely attacked, so we didn't and don't really need a full-blown two-layer firewall. > Or should I just continue with my current two-firewall setup? I find it very likely indeed that is what you want to do. > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. Quite fitting motto in this case. :-) Hope you enjoyed Bucuresti... Yours, Ingo
Re: network architecture question
Hi, Aham Brahmasmi wrote on Mon, Oct 01, 2018 at 11:27:09PM +0200: > Would you recommend any other books in addition to "Building Internet > Firewalls"? I'm usually not very good at recommending books, i mostly learn by reading reference manuals, standard documents, and source code. It is mere chance that i know this one. :-) I mentioned it to show that the strength of two-tier firewalls has been well-established in standard textbooks for a long time. There may be books out there on the topic that are newer than Elizabeth Zwicky's and of similar quality, i don't rightly know. Yours, Ingo
Re: checking source with pvs-studio
Hi, Aaron Mason wrote on Wed, Oct 03, 2018 at 09:07:40AM +1000: > Apparently you've got to go through your source code > and plug the product in every single non-header file. Which is of course trivial to do - you write a script to do a checkout, run "sed -i", run the tool, collect the the results, and delete the checkout. So the harassment by the author is not even effective for his intended purpose. If the developer is *that* stupid in such a major respect, it's probably best to ignore the tool outright - that stupidity gives me the prejudice that the tool is likely to be hostile towards free software, greedy for private profit, and even more stupid in other ways, so it's likely a waste of time in the first place. It's not like there aren't lots of other choices, written by smart people for a change. Yours, Ingo
Re: OpenBSD migration
Hi Martin, Martin Sukany wrote on Sat, Nov 17, 2018 at 09:13:15PM +0100: > I want to migrate OpenBSD 6.4 (stable) from VM to bare metal. I see, as > usual, two options: > > 1) install everything from scratch > 2) create some flashimage (I did such thing on Solaris few years ago) > and apply the image on new hw. I'd recommend option 1), reinstall. I have no idea whether or not option 2) will work. It may or may not. If it doesn't, you end up doing a reinstall anyway, and nobody will be interested in the reasons why it didn't work for you. Such a thing simply isn't supported. Yours, Ingo
Re: Confusing problem with CVS
Hi Chris, Chris Bennett wrote on Fri, Mar 13, 2020 at 04:47:09PM -0400: > I am running -current. > > On one server, src was empty. So I did a cvs checkout. > On another server, src had older files. So I did a cvs up. > > Afterwards, inttypes.h had one size on the checkout, another size on the > updated src. > I rm'ed the updated src and did a checkout. Now both files are the same > size and date. > > What has happened here? I thought that cvs up was the correct procedure. > > cvs -qd$CVSROOT checkout -P src inside of /usr or > cvs -qd$CVSROOT up -Pd inside of /usr/src. > > Updating only changed some of the file dates That sounds as if you had sticky tags at least in parts of one of the trees, but you provide no details, so there is no way to be sure what exactly happened. > and did not work correctly. You provide no evidence whatsoever that there might be a bug, and my guess is that it is unlikely you encountered one. It is among the basic ideas of CVS that running "cvs up" across a whole tree doesn't necessarily update all the subdirectories from the same server, nor from the same repository, nor to the same branch. In addition, "cvs up" commands you ran in the past may have banned some files from being updated at all in the future. In case it isn't obvious, cvs(1) is very different from git(1) in these respects. With CVS, you can configure individual subdirectories and even individual files to behave in custom ways, which git(1) is incapable of. It all depends on what the files in the various directories with the name "CVS" contained, for example the various files called "Root", "Repository", "Entries", and "Tag". Because there are so many different scenarios in which what you describe is the expected behaviour, i can't provide better advice than this: use the command "info cvs" to learn how cvs(1) is supposed to work. In particular, make sure you become familiar with the -A, -C, and -r options of "cvs up", but i'm not saying that will be sufficient to avoid all possible surprises. Also use "/sticky" inside "info cvs" to look for information about sticky tags; it is mentioned at many different places. Yours, Ingo
Re: Confusing problem with CVS
Hi Chris, Chris Bennett wrote on Fri, Mar 13, 2020 at 08:23:22PM -0400: > Thanks, that was helpful. > I did not think of using info cvs. I do use info at times, > just not that often. That is quite understandable. With BSD systems in general, it is both the normal case and also our goal that the man(1) pages should contain the authoritative, complete, correct, concise documentation. But the further you move away from OpenBSD to other operating systems or into ports land, the more documentation gets scattered across various non-compatible file formats. But even in OpenBSD base, there are a few legacy components still in active use where we don't really continue development and where the authoritative documentation is not in manual page format, for example: - GNU as(1) - GNU cvs(1) - gdb(1) - GNU info(1) itself - and a few others With LLVM and related tools replacing GCC and GNU binutils on many platforms, the amount and the importance of info(1) documents is slowly continuing to decline. Yours, Ingo
Re: Start point to learn OpenBSD programming
Hi Martijn,
Martijn van Duren wrote on Mon, Mar 16, 2020 at 08:52:54AM +0100:
> On 3/16/20 8:23 AM, Martin wrote:
>> The best way for beginner to start with OpenbBSD programming?
> This belongs on misc, so moving it there.
>
> My usual routine (and probably of a lot of other OpenBSD developers) is:
You forgot two steps:
> 1) Use it
> 2) Get annoyed by something (bug?)
Between steps 2 and 3, read the manual page to make sure your assumptions
about what it is supposed to do are correct. Often, that will already
reveal they are not: goto 1.
> 3) Dive into /usr/src to see what it actually does
> 4a) Realize I'm wrong in my initial annoyance; goto 1)
After step 4a and before going back to step 1, close the gap in the
manual page and send the patch to tech@; after all, that you even
got to step 4a proves that something a user needs to know wasn't
adequately described in the manual. Goto 5a.
> 4b) Realize you can't fix the bug and ask for help on bugs@; goto 1)
> 4c) Try to fix the bug and sent a patch to tech@
> 5a) Patch falls in between the cracks (no-one responds) and it's not
> that important to you; goto 1)
> 5b) Patch falls in between the cracks and it's important to you;
> send reminder and goto 1) in the meantime.
> 5c) Realize my interpretation was wrong based on feedback; goto 1)
> 5d) Realize my patch was wrong based on feedback; goto 4b)
> 5e) Patch gets committed; goto 1)
>
> If you want reading material find a function you don't understand and
> lookup the manpage. If you want to have a more adventurage approach:
> $ PAGE=$(ls /usr/share/man/man[23] | sort -R | head -1); \
> man ${PAGE##*.} ${PAGE%.*}
That can be simplified:
$ man -l $(ls /usr/share/man/man[23]/*.[23] | sort -R | head -1)
;-)
Ingo
Re: Start point to learn OpenBSD programming
Hi Martijn,
Martijn van Duren wrote on Mon, Mar 16, 2020 at 09:24:26PM +0100:
> On 3/16/20 9:22 AM, Ingo Schwarze wrote:
>> Martijn van Duren wrote on Mon, Mar 16, 2020 at 08:52:54AM +0100:
>>> On 3/16/20 8:23 AM, Martin wrote:
>>> If you want reading material find a function you don't understand and
>>> lookup the manpage. If you want to have a more adventurous approach:
>>> $ PAGE=$(ls /usr/share/man/man[23] | sort -R | head -1); \
>>> man ${PAGE##*.} ${PAGE%.*}
>> That can be simplified:
>> $ man -l $(ls /usr/share/man/man[23]/*.[23] | sort -R | head -1)
> Who said I went for simple?
You said so implicitly, in so far as you are doing good work on
OpenBSD. :)
> I even left a minor bug in there for Martin to find. :-)
Indeed! Which proves again that while randomization is important,
it is easy to cause subtle heisenbugs with it. And i consciously
chose to not point it out but silently fix it, to avoid having to
mark my posting as [SPOILERS].
Yours,
Ingo
Re: How to test for FORTIFY_SOURCE?
Hi Theo, Theo de Raadt wrote on Wed, Mar 18, 2020 at 09:06:25AM -0600: > Jeffrey Walton wrote: >> What is the purpose of supplying man pages for the wrong operating >> system? The purpose is to make it simpler to compare how different systems work without having to jump back and forth among different sites using different URI schemes and running different software. Also, the man.cgi(8) from the mandoc toolset is way better than the software running on netbsd.gw.com, leaf.dragonflybsd.org, illumos.org, and man7.org, which provide neither semantic searching nor tagging/deep linking of comparable quality. Note that www.freebsd.org now also runs the man.cgi(8) from the mandoc toolset - after several years hoping to switch to it, they finally did it. >> It wastes people's time and breaks search. This search does >> not produce expected results: >> https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org. Do not search the web for software documentation. That's a bad idea in the first place. You are likely to end up with documentation for the wrong version of the software in question, which is exactly what happened to you here. Use autoritative documentation for the system you are interested in, instead. >> If you really want to confuse folks, maybe OpenSD can supply >> Windows man pages. > I'm going to stand up and agree. You have a point that non-OpenBSD manual pages are better served from the *portable* mandoc site than from man.openbsd.org. So i just deleted the non-OpenBSD lines from manpath.conf on man.openbsd.org. For now, comparing different systems can be done here: https://mandoc.bsd.lv/cgi-bin/man.cgi/ That URI is quite ugly, i'll try to figure out whether i can move that to simply man.bsd.lv. > Ingo -- I think using man.openbsd.org as a "testbed for all possible > man page hierarchies" incorrect. It was never a testbed, but a production service with several parts provided nowhere else (well, at least until FreeBSD followed our lead and started providing something very similar). For example, for DragonFly, Illumos, and NetBSD, semantic searching is neither supported by their native apropos(1) on the command line nor by their own websites. But since you have a point that such services hardly belong on *.openbsd.org, they are now on *.bsd.lv, where misunderstandings like the one witnessed above are unlikely to happen. Yours, Ingo
Re: How to test for FORTIFY_SOURCE?
Hi Jeffrey, Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400: > I assumed OpenBSD and NetBSD were collaborating and shared code and > docs in some places. To a limited extent, that is true. For example, NetBSD includes mandoc(1) which is predominantly developed on OpenBSD while OpenBSD includes editline(7) which is predominantly developed on NetBSD. But that doesn't mean either system slavishly copies changes from the other, nor that components both contain work in exactly the same way. Developers of both systems use their own judgement to decide what to merge from the other system, and when. So please do use the documentation from the right system even for those components that are very similar on both, or you will sooner or later stumble over some subtle difference. Yours, Ingo
Re: How to test for FORTIFY_SOURCE?
Hi, Theo de Raadt wrote on Wed, Mar 18, 2020 at 12:44:03PM -0600: > Ingo Schwarze wrote: >> Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400: >>> I assumed OpenBSD and NetBSD were collaborating and shared code >>> and docs in some places. >> To a limited extent, that is true. > To a limited extent, it is true that birds and fish are friends. > > In other words, it is untrue. There isn't collaboration. I have definitely collaborated with at least these NetBSD developers in the past: * Joerg Sonnenberger (joerg@) * Thomas Klausner (wiz@) * Christos Zoulas (christos@) "Collaboration" in the sense that there was consistent working together on joint projects for months, with Joerg even for years. Besides, Sevan Janiyan (sevan@) has been one of the most prolific mandoc release testers for four years now, to the point that i might call that collaboration. Eight other NetBSD developers have provided minor contributions over the years, the overall effect of which also feels like systematic collaboration to me. Similar effects exist for FreeBSD (bapt@) and Debian (stapelberg@) and to a lesser degree for Illumos (Yuri Pankov) and Void Linux (Leah Neukirchen). I even attended a mini-hackathon organized by a NetBSD developer in the past, and the code both the NetBSD developer and i wrote there is still part of both OpenBSD and NetBSD. That is certainly worth being called collaboration. > And there isn't sharing. At best there is freely given stuff which > is sometimes taken. I propose not using the word "share" since people > may believe it is one of the stronger meanings of the word. At best > it is the weakest meaning. It seems true that "freely give" is not as easily misunderstood as "share". Yours, Ingo
Re: groups new
Hi Jan, Jan Prunk wrote on Wed, Mar 18, 2020 at 06:08:26PM +0100: > 0 > C Slovenia > P SI > T Ljubljana > F Irregular > O BSD User Group Slovenia > I Jan Prunk > M b...@groups.io > U https://bsdug.wordpress.com > N *BSD I suggest you resubmit when a few meetings have taken place. So far, i see no evidence of any activity. The website looks as if it is unchanged since September 6, 2018, and it says "Website is in a starting phase". The mailing list seems to have four members and two postings, both in December 2018 and both posted by the same person. Yours, Ingo
Re: How to test for FORTIFY_SOURCE?
Hi Luke, Luke A. Call wrote on Wed, Mar 18, 2020 at 12:54:10PM -0600: > On 03-18 19:22, Ingo Schwarze wrote: >> Theo de Raadt wrote: >>> Ingo -- I think using man.openbsd.org as a "testbed for all possible >>> man page hierarchies" incorrect. >> It was never a testbed, but a production service with several parts >> provided nowhere else (well, at least until FreeBSD followed our >> lead and started providing something very similar). >> >> For example, for DragonFly, Illumos, and NetBSD, semantic searching >> is neither supported by their native apropos(1) on the command line >> nor by their own websites. >> >> But since you have a point that such services hardly belong >> on *.openbsd.org, they are now on *.bsd.lv, where misunderstandings >> like the one witnessed above are unlikely to happen. > Providing a simple link from the man.openbsd.org page to the services > on *.bsd.lv might help those who are used to looking in the old > location, while avoiding possible "which bsd" confusion (maybe called > "Some other systems' manuals", or such). Especially for those not > reading this thread. Just a thought. Makes sense, done. Note that in addition to man.openbsd.org, man.bsd.lv is now also up and running, but the latter will only contain release manual pages for a number of systems (including OpenBSD) but not OpenBSD-current. Yours, Ingo
Re: reviewing what is available
Hi Luke,
Luke A. Call wrote on Wed, Apr 01, 2020 at 01:36:49PM -0600:
> On 04-01 12:47, Chris Bennett wrote:
>> On Wed, Apr 01, 2020 at 07:01:15AM -0600, Diana Eichert wrote:
>>> have you considered looking at native OpenBSD tools?
>>> https://man.openbsd.org/egre.4
>> Wow! I had no idea about this.
> I think you know more about obsd than I do, but in case it's useful to
> anyone else:
>
> I didn't know about egre(4) either, but I am trying to go
> gradually thru the process of seeing "what is there" by browsing to
> man.openbsd.org, putting a single period (".") in the search field,
> choose a section, click apropos, and methodically reading.
As jmc@ made me aware recently, an equal sign (or even better: Nm=)
is faster than a period because it doesn't need to evaluate a regular
expression for each and every manual page in the database. ;-)
By the way, you can do that from the command line, too, no need
to access the Internet:
$ man -s 2 -ak Nm=
then type
:tNAME
and hit the "enter" key. If you aleady know about the stuff shown
at the top of the screen, just hit the
t
key once, or as many times as the top of the screen seems familiar.
Even if you decide to study something and move around with arrows
up and down and search with the "/" and "?" keys, hitting the "t"
key again later will get you to next manual page from the place
that you last jumped to with "t". If you get very confused as to
where you stopped and whether you maybe skipped anything, hit "T"
(= Shift-t) until you see something familiar, then move forward
again with "t" as before.
The "man -s 2 -ak Nm=" feature has been working for a long time, for
multiple -stable releases, but for the ":tNAME" and "t" sugar, you
nead a *really* current -current, as in, from a few minutes ago,
or tomorrow's (amd64) snapshots, or later for slower architectures.
Enjoy,
Ingo
> Lots of good
> stuff and some surprises (for me at least) in there. If I hadn't
> done that once with debian (years ago), I wouldn't know about touch(1),
> for example, and a bunch of other things.
>
> Again, you know more than I, so no insult intended. :)
Re: Contributing to spamd
Hi Aisha, Aisha Tammy wrote on Fri, Apr 03, 2020 at 08:54:22AM -0400: > I have been using spamd for quite a while and have been loving it. > I've seen that spamd currently only supports ipv4 and have been > wondering if it was possible to extend it to ipv6. I know that workforce > is always limited so I wanted to know if there is anyway to contribute > help towards this :) The way to contribute to OpenBSD is by sending patches - ideally small, incremental patches that work and are well tested, but when you get stuck, you can also send something like: "I hope to do FOOBAR, and here is what i have so far; the FOO part already seems to work in my preliminary testing, but i have doubts whether my approach to the BAR part is ideal. Feedback is welcome." > I admit I'm not the most knowledgeable about ipv6 so I was wondering if > there is any small place to start to contribute to spamd and build up > from there. > Hoping for some positive response. Being able to learn on your own is among the key qualifications required to contribute to OpenBSD. Learning by doing is recommended: First find an issue you would like to fix. Good judgement of your own abilities is essential here: don't pick a task so much over your head that you have no chance of ever getting it done. Picking something *slightly* more difficult than what you have experience with may be OK if you are willing to learn and can tolerate the frustration that unavoidably comes with the first try likely not being good enough for commit yet. Then again, getting used to the the processes of sending patches, receiving feeback, and improving and re-sending the patches such that they get ready for commit may also require some effort, so it is not a bad idea to start with tasks you are absolutely sure you can easily manage, until you get used to the processes, then progress to more difficult stuff in order to learn and grow. When asking questions, be as specific as possible, ideally showing specific patches or specific sequences of commands and asking specific questions about them. Avoid questions similar to "what should i do" or "where should i start" or "is there a todo list". That depends on what you are interested in and what your abilities are, and you need to know that yourself, no one else who doesn't know you personally can help you with that. Sorry that i can't give you specifics about spamd(8), but your question wasn't very specific anyway. In general, seamless IPv6 support is welcome in OpenBSD, but i'm not sure about the requirements of spamd(8) in particular since i never used it nor worked on it. Yours, Ingo
Re: openbsd.org - certain https URLs downgraded to http in redirection
Hi Constantine, Constantine A. Murenin wrote on Tue, Mar 31, 2020 at 01:24:30PM -0500: > What you say makes no sense I wouldn't go that far; i think Aham has a point, even though it certainly isn't a critical nor an urgent problem. > for one simple reason: man.cgi (and cvsweb) moved out of www.openbsd.org > ages ago, prior to there being any https on www.openbsd.org (correct me > if I'm wrong here), Not sure, maybe. I don't feel like spending time on trying to find out, it doesn't seem that important. > so, there should not be any legitimate organic links that would be > linking to https towards www.openbsd.org/cgi-bin/ in the first place; > as such, there's little reason to change anything here. Who knows what links people may have put into their web pages at which times and for which reasons or what they type in their browser address bars; those are not very pressing questions either. The reason the redirection wasn't changed yet to avoid redirecting incoming HTTPs connections to HTTP URIs elsewhere merely is that the people having the necessary access to the www.openbsd.org server are busy and apparently don't consider it a priority to improve this particular detail. While i do maintain man.openbsd.org, i don't have access to www.openbsd.org, and i'm not sure i even want such access. Yours, Ingo
Re: Nvidia driver for OpenBSD?
Hi, Christopher Turkel wrote on Fri, Apr 10, 2020 at 02:49:56PM -0400: > On Friday, April 10, 2020, Nikita Stepanov wrote: >> Subject: Nvidia driver for OpenBSD? > None exist or are likely to ever exist. The question from the original poster was so imprecise and lazy that no one else bothered to answer, but your answer is just plain wrong, so it has to be corrected. Here is a better answer, and even that is likely incomplete: https://man.openbsd.org/?query=nvidia&apropos=1 That said, OpenBSD developers typically strongly discourage buying NVIDIA graphics cards because NVIDIA traditionally doesn't provide hardware documentation for the graphics cards they produce, so drivers for NVIDIA graphics cards are typically of vastly lower quality than for intel(4) and radeon(4) cards. In particular - but that's far from the only problem as far as i heard - there is no drm(4) support for NVIDIA cards. Yours, Ingo
Re: Does Intel driver supports 3d acceleration?
Hi Otto, Otto Moerbeek wrote on Sat, Apr 11, 2020 at 12:16:40PM +0200: > On Sat, Apr 11, 2020 at 03:52:34PM +0600, Nikita Stepanov wrote: >> Does Intel driver supports 3d acceleration? > What prevents you from looking up the man page and reading it? Lazyness, obviously. All the more so as i already posted the link to that very manual page, in a post replying specifically to him. Replying to him was clearly a mistake, sorry for that. I suggest we now stop feeding that obvious troll. Yours, Ingo
Re: Does Intel driver supports Intel g31?
Hi, infoomatic wrote on Sat, Apr 11, 2020 at 05:41:44PM +0200: > I suggest you read on the documentation instead of throwing one-line > questions to the mailing list. > > The documentation is excellent, just look for the information you need. > > https://man.openbsd.org/ So far, so good. > https://openports.se/ But please do not recommend openports.se for use with OpenBSD. That is a NetBSD site. OpenBSD and NetBSD are different operating systems and work differently in several respects. That includes significant differences in how the ports trees work. The software running on openports.se doesn't properly understand the OpenBSD ports tree, often resulting in incomplete and misleading statements being presented on that site. Rather than taking chances and getting hurt using openports.se, people should use the official sources of information, in particular the following OpenBSD ports: portslist-7.27 full list of pkgpaths in ports sqlports-7.27 sqlite database of ports pkglocatedb-1.5 database of packages for use with locate(1) See also: https://man.openbsd.org/pkg_locate.1 Yours, Ingo
Re: List a package's dependencies
Hi Chris, Chris Rawnsley wrote on Sun, Apr 19, 2020 at 01:34:28PM +0100: > I am looking for a way to show a package's dependencies. As far as i know, the normal ways to do that are: # direct run dependencies only cd /usr/ports/mail/mutt; make run-depends-list cd /usr/ports/mail/mutt; make show=RUN_DEPENDS # direct library package dependencies only cd /usr/ports/mail/mutt; make lib-depends-list cd /usr/ports/mail/mutt; make show=LIB_DEPENDS # direct run and library package dependencies only pkg_info -qf mutt | grep ^@depend grep -F '|mail/mutt|' /usr/local/share/ports-INDEX | cut -d \| -f 8 # direct build dependencies only grep -F '|mail/mutt|' /usr/local/share/ports-INDEX | cut -d \| -f 9 cd /usr/ports/mail/mutt; make build-depends-list # all run dependencies, recursive cd /usr/ports/mail/mutt; make print-run-depends cd /usr/ports/mail/mutt; make full-run-depends cd /usr/ports/mail/mutt; make show-run-depends cd /usr/ports/mail/mutt; make run-dir-depends # all shared library dependencies, recursive pkg_info -qf mutt | grep ^@wantlib # direct run and package library dependencies, and all shared libs recursive pkg_info -qS mutt # all build dependencies, recursive cd /usr/ports/mail/mutt; make print-build-depends cd /usr/ports/mail/mutt; make full-build-depends cd /usr/ports/mail/mutt; make build-dir-depends # all dependencies, recursive cd /usr/ports/mail/mutt; make full-all-depends cd /usr/ports/mail/mutt; make all-dir-depends The above list is not complete. For example, i skipped ways to inspect test dependencies, and i refrained from explaining possibilities that use the port "databases/sqlports", which is very powerful. Finally, i may have missed some ways this can be done. All this is kind of typical for the pkg tools: one question typically allows several different answers. There typically isn't one single, canonical way of doing something. There typically isn't one unified output format, but several different ways to represent information in the output. Part of that is due to the unavoidable complexity of the system. Other parts may be influenced by the fact that espie@ is not tedu@. > Does such a command such as this already exist? I guessed that the > pkg_* tools would have this covered but I was not able to find it > in the manpages. Yes, finding stuff in the pkg/ports manual pages sometimes isn't easy due to their size and complexity - even though they are typically concise, at times even terse. > In making the above example, I created a proof of concept shell > script that demonstrates the desired behaviour. We certainly don't need yet more ways to do the same, and certainly not by creating wrappers around what is already there. Besides, directly inspecting the contents of /var/db/pkg/ by anything that is not part of the pkg tools is fragile and not acceptable. All that said, it might be useful if, in addition to -S, pkg_add(1) could recursively list run-time dependencies. That isn't possible for packages that are not installed, but it should be possible to implement for installed packages. The current situation is arguably not ideal for users since i don't see a way to recursively get run-time dependencies without either * going to /usr/ports/ and running make(1) * using databases/sqlports * writing your own script recursively calling "pkg_info -qS", then postprocessing with sort(1) and uniq(1) Yours, Ingo
Re: List a package's dependencies
Hi Marc, Marc Espie wrote on Mon, Apr 20, 2020 at 03:05:36PM +0200: > Actually, not having recursive depends easily available on an installed > package base is somewhat tedu-ish. Heh. :-) > Most specifically, it's not very useful for anything in common usage. What > would you want it for ?... sure it's nice information, but in practice, > unused dependencies from former ports get gc'd with pkg_delete -a... > > ... and if you're actually tinkering with dependencies, it's generally > related to the ports tree proper, and there is a plethora of targets in > there... along with indeed, sqlports which can give you all the info that > you need, assuming a bit of sql magic. Those look like good points. I think you are right that the occasional times i was looking for lists of recursive dependencies where when i was working on some port, not when i was merely using a package, so going to the ports tree and running make(1) didn't cause any real inconvenience. I think your explanation helps to understand the choice to not provide this particular knob better. And yes, i definitely appreciate that it's a very complex task to keep all the moving parts of the pkg/dpb system working reliably, including for all the special cases needed for such a large tree. Yours, Ingo
Re: timegm()
Hi, Theo de Raadt wrote on Wed, Apr 22, 2020 at 12:11:56AM -0600: > William Ahern wrote: >> On Tue, Apr 21, 2020 at 02:01:10PM +0200, Otto Moerbeek wrote: >>> On Tue, Apr 21, 2020 at 10:51:54AM +, Roderick wrote: Acording to the man page: "timegm() is a deprecated interface that converts [...]" O.K., deprecated. And what is the alternative? >>> The paragraph above it (discussing timelocal()) suggests it's >>> mktime(). >> There is no alternative to timegm that is thread-safe. timegm is widely >> supported, including BSDs, glibc, musl; it shouldn't be deprecated, IMNSHO. >> Solaris even recently reintroduced timegm (with 11.4) after having removed >> it years ago. > It is marked deprecated. > That doesn't mean it is going away. > It's just a pseudo-legal term by a bunch of muppets. The particular muppet here appears to be known by the name of millert@ ;-) revision 1.23 date: 2000/08/22 14:21:23; author: millert; state: Exp; lines: +23 -3; Quickly describe timelocal() and timegm() and note that they are deprecated interfaces. Calling timelocal(3) deprecated makes sense to me because it is nothing but a trivial wrapper around mktime(3), and the latter is standardized, while timelocal(3) is not. But i don't quite see why timegm(3) should be marked as deprecated: sure it was never standardized, but i don't see a better portable way to achieve the same. Consequently, i suggest dropping millert's deprecation notice from timegm(3) and instead adding the missing STANDARDS and HISTORY sections. timegm(3) and timelocal(3) are neither in the final state of the 4.4BSD SCCS repo nor in 386BSD, but first appear here: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/localtime.c?rev=1.1&content-type=text/x-cvsweb-markup/ That is between NetBSD 1.0 (Oct 94) and 1.1 (Nov 95). The STANDARDS stuff is easy to verify from C89, C11, and POSIX, the v5 stuff from TUHS, difftime and mktime from the CSRG history, and the addition of the four *_r() functions from our own CVS history. While here, purge the non-standard section name NOTES; the normal name for such a section is CAVEATS. OK? Ingo Index: ctime.3 === RCS file: /cvs/src/lib/libc/time/ctime.3,v retrieving revision 1.44 diff -u -r1.44 ctime.3 --- ctime.3 14 Sep 2015 13:08:01 - 1.44 +++ ctime.3 23 Apr 2020 02:13:54 - @@ -201,7 +201,7 @@ .Fa tm_isdst . .Pp .Fn timegm -is a deprecated interface that converts the broken-down time, as returned by +converts the broken-down time, as returned by .Fn gmtime , into a calendar time value with the same encoding as that of the values returned by the @@ -295,12 +295,68 @@ .Xr tzset 3 , .Xr tzfile 5 , .Xr zic 8 +.Sh STANDARDS +The functions +.Fn asctime , +.Fn ctime , +.Fn difftime , +.Fn gmtime , +.Fn localtime , +and +.Fn mktime +conform to +.St -ansiC . +.Pp +The functions +.Fn asctime_r , +.Fn ctime_r , +.Fn gmtime_r , +and +.Fn localtime_r +conform to +.St -p1003.1-2008 . +.Pp +The functions +.Fn timegm +and +.Fn timelocal +are extensions to these standards. .Sh HISTORY A .Fn ctime function first appeared in .At v1 . -.Sh NOTES +.Pp +The functions +.Fn asctime , +.Fn gmtime , +and +.Fn localtime +first appeared in +.At v5 . +.Pp +The functions +.Fn difftime +and +.Fn mktime +first appeared in +.Bx 4.3 Reno . +.Pp +The functions +.Fn timegm +and +.Fn timelocal +have been available since +.Nx 1.1 +and +.Fn asctime_r , +.Fn ctime_r , +.Fn gmtime_r , +and +.Fn localtime_r +since +.Ox 2.5 . +.Sh CAVEATS The return values of the non re-entrant functions point to static data;
Re: timegm()
Hi Todd, Todd C. Miller wrote on Wed, Apr 22, 2020 at 09:21:28PM -0600: > On Thu, 23 Apr 2020 04:21:42 +0200, Ingo Schwarze wrote: >> Calling timelocal(3) deprecated makes sense to me because it is >> nothing but a trivial wrapper around mktime(3), and the latter >> is standardized, while timelocal(3) is not. >> >> But i don't quite see why timegm(3) should be marked as deprecated: >> sure it was never standardized, but i don't see a better portable >> way to achieve the same. >> >> Consequently, i suggest dropping millert's deprecation notice >> from timegm(3) and instead adding the missing STANDARDS and >> HISTORY sections. > That's fine with me. Those interfaces appeared in SunOS 4.0 according > to tzcode (which is where we got them from). They did *not* originate > in NetBSD. I've verified that they were present in SunOS 4.1.3U1, > though that code appears to be derived from tzcode too. > > I would suggest that the HISTORY section be updated accordingly if > you feel the need to document their origin. > > If you look at the 4.4BSD ctime.c you'll see that Keith actually > removed timegm() after updating it from tzcode. > > D 5.16 89/03/16 20:34:41 bostic 22 21 > remove offtime, timegm, timeoff > > D 5.15 89/03/12 16:32:29 bostic 21 20 > latest Olson/Harris time package Thanks for doing that research and also for checking the rest of the patch. I tweaked the patch according to your findings and committed it. > The reason they were marked as deprecated is that tzcode has a > comment that "These functions may well disappear in future releases > of the time conversion package". However, that hasn't happened in > at least 30 years so it seems likely that they are here to stay... Sorry for calling you a muppet even though all you actually did was quoting the opinion muppets, a single time about two decades ago. ;-D > Note that we also provide timeoff() but don't document it. I have no strong opinion whether we should document it. Maybe not? I never felt a need to use it, and it isn't standardized. Are you suggesting that maybe we should? I wouldn't oppose that either. Yours, Ingo
