Re: Include hostname in shell prompts by default
On 2017-12-09 1:10 PM, Theo de Raadt wrote: the default prompt works exactly because it doesn;t try to second guess what the user wants, or what is or isn;t good for them. the mechanism for changing the prompt is trivial. i don;t think it makes sense to change the shells in this way. Having seen bug reports with data from the wrong machine multiple times in the last year, especially related to Mike's new work in vmm, I'm sorry I have to disagree. Some developers have even rebooted the wrong machines. Is there anyone who hasn't? Not everyone has time to configure their development machines as you suggest. If it truly can't be fixed in /etc/profile and/or /etc/ksh.kshrc, then it should be fixed it in the code. This change has *no impact* on the people who already take the time to change their prompt. It improves the lives of those who don't have time to do so. Yup.
Re: usbtv driver port (questions)
On 2016-05-25 7:57 AM, Marcus Glocker wrote: On Tue, May 24, 2016 at 04:46:57PM -0700, patrick keshishian wrote: Hi, I have a "mostly working" driver port for Fushicai Audio-Video Grabber (vendor 0x1b71 product 0x3002). I've had the video bit working for a few days on amd64 and macppc. I finally managed to get the audio bit working this morning on amd64, but still an encoding issue (LE vs BE) on macppc. ... 2. Return values inside parenthesis or not? The ongoing religious question :-) Some people say return and sizeof shouldn't be used with parenthesis because they are not functions. I still find it more readable with parenthesis. We have both variations in the tree. Your choice. "Obviously without" :-) 3. Original source filenames were hyphenated (e.g., usbtv-video.c). OK to use underscore instead? I think it is preferred. (Next question may trump this one) How's about something a bit shorter, like uvcap.c (USB Video Capture) and then also call the driver uvcap? Anyway just a proposal. Otherwise yes, replace the '-' by '_' in the filename. There are (at least) three other popular usb video capture devices with totally different chipsets (Syntek, Empia, Somagic, besides this Fushicai one, "usbtv007"), so calling one of them uvcap might be annoying, like if one of our many network drivers were called "network". See https://linuxtv.org/wiki/index.php/Easycap. Does it make sense to start a naming convention like: utvsyn, utvemp, utvsom, utvfu, ...? Myself I own a Syntek one, which is why I'm aware of this issue: port 4 addr 3: high speed, power 500 mA, config 1, USB 2.0 Video Capture Controller(0x0408), Syntek Semiconductor(0x05e1), rev 0.05
Re: rcctl ls faulty -> failed
On Tue, Mar 29, 2016 at 03:29:27PM +0200, Antoine Jacoutot wrote: > Hi. > > We'd like to rename the 'faulty' listing to 'failed'. > i.e. rcctl ls failed > > Index: etc/daily > === > RCS file: /cvs/src/etc/daily,v > retrieving revision 1.85 > diff -u -p -u -p -r1.85 daily > --- etc/daily 28 Jan 2016 15:45:34 - 1.85 > +++ etc/daily 29 Mar 2016 13:25:59 - > @@ -127,7 +127,7 @@ while [ "X$ROOTBACKUP" = X1 ]; do > done > > next_part "Services that should run but don't:" While you're there, can you please change "should run but don't" to "should be running but aren't" ? The current wording is awkward, and also implies that they don't run (ie. they fail to start) when in fact they may have been running but been shut down manually, or failed. Language should be precise as well as concise.
Re: grep -R without directory argument
On 2015-04-30 04:16, Mark Kettenis wrote: Date: Thu, 30 Apr 2015 07:51:55 +0200 From: Martin Natano nat...@natano.net grep reads from standard input when no files are specified. It also does so when -R is used, which doesn't really make sense. I think using the current working directory as a fallback when no directories are specified would make sense. POSIX says If no file operands are specified, the standard input shall be used., but -R is an extension to POSIX, so I guess it is not bound by that. Far too often I've started a grep -R and waiting for the output, only to recognize minutes later, that I forgot to add the '.' at the end of the command and it is reading from stdin. I do that without the -R option too ;). Any thoughts? OK? Not convinced this is an improvement. Some other *Nixes print a warning in that event, which I find more useful than grepping a directory I didn't mean. On OS X f'rinstance: $ grep -r foo grep: warning: recursive search of stdin $
Re: ahci BSY retry
On 2014-04-23 3:50 PM, Chris Cappuccio wrote: Peter J. Philipp recently ran into this on his Intel AHCI+Intel SSD system (see misc from yesterday): ahci2 at pci0 dev 31 function 2 Intel 8 Series AHCI rev 0x05: msi, AHCI 1.3 ahci2: device on port 1 didn't come ready, TFD: 0x80BSY ahci2: stopping the port, softreset slot 31 was still active. ahci2: unable to communicate with device on port 1 I've seen this on boot with Intel AHCI and Transcend SSD and others have seen it with Intel AHCI+Intel SSD on soekris net6501. Here's a simple fix based on Dragonfly's fix for the same problem. (Try to restablish communication one more time.) Seems to unbreak suspend/resume on my Dell Studio with Intel AHCI (before your fix it had to be in legacy/ATA mode in the BIOS).
Re: typo security.8
On Tue, Apr 22, 2014 at 06:32:12PM +0200, Henning Brauer wrote: * Fritjof Bornebusch frit...@alokat.org [2014-04-22 18:29]: it's Trojan horse not Trojan horsed, right? yup. a trojan horse. the binary has been trojan horsed. As Henning notes, it was gramatically correct as written (if you are willing to accept trojan horse as a neologisticized verb), although potentially confusing to non-native speakers. I wonder if it might be better style to say smth like: a trojan-infested binary or ?
Re: ln -s example
On 12-09-20 8:34 AM, Amit Kulkarni wrote: This is very helpful. Usually in OpenBSD, you create a symbolic link /var/www which has limited space and have it point to /home/www where actual data is stored and which has more space. This particular example could be Create a symbolic link named /var/www and point it to /home/www: # ln -s /home/www /var/www A good example is one that actually works. Since /var/www exists in the default configuration on OpenBSD, your example will create a symlink in the real /var/ww called www, pointing to /home/www, and will never get used. $ sudo ln -s /home/www /var/www $ ls -l /var/www/www lrwxr-xr-x 1 root daemon 9 Sep 20 12:36 /var/www/www - /home/www $ To make it work, you'd have to explain the rationale, show the command for moving the contents (bikeshed warning!), then rmdir /var/www, and finally do your symlink. It's not worth it. Pick a simpler example.
Re: ld.so speedup for large binaries with many shared libraries
Makes Eclipse start in 13-14 secs instead of 19. Thanks.
Re: last patch, idea
while going through my wtmp with last(1) I noticed there could be a better way than always gunzip'ing wtmp files and then using last -f. I've made a patch for your consideration that does the following: b) it writes the gzipped file to a /tmp location uncompressed so that the normal way of operation can be done on the tmp file. Having tried to do things like gzcat /var/log/wtmp.0.gz | last -f /dev/stdin before, I'd certainly find it useful and this is less intrusive than modifying last(8) so it could work with standard input. Unless you run an extermely large shop like Beck does, or have extremely tiny disks, why not just remove all the Z flags from newsyslog.conf? This has the side effect of not having to gunzip /var/log/daemon* friends. I guess we inherited this log gzipping from 4BSD, but in those days a 300MB disk cost a month's salary. Plus another week's salary or so for the trucking charges.
Re: allow ugen(4) to attach to unused interfaces
On 01/04/11 00:13, Yojiro UO wrote: as the ugen(4) is too flexible (and unsafe) than other usb device drivers, i don't like this work to extend ugen(4)'s area. I know many userland applications which supports multiple platform using ugen type interface (because they usually use libusb or ugen apis), but it is no reason to support them without considerations. Here is one very strong consideration: Inasmuch as this change makes at least some MFC devices just work with CUPS and xsane, for normal users, without having to e.g., build a custom kernel, I am in favor of it, unless there is a *specific* risk to other drivers.
Re: no printing cache info
Best thing would be to print it once per socket, i.e. for the first core of each physical CPU. Oh, and the flags can be subtly different for other CPUs in the system, even if they are exactly the same model, because the BIOS can enable/disable some features. Yes to the first, and the second, also because the repair guy put in a different chip revision in one socket, or anybody else that had their fingers inside the case. Per-socket seems like it would be good.
Re: update pms driver
1) (might or might not be related to pms) When I terminate X and try to re-start it (either under XDM or by running sudo startx twice), the second X does not always start - it tries, but it hangs just after the basket weave background and the X cursor, before any apps or the XDM login screen. Other times it works fine. Since restarting X is not something I normally do (I'm usually the only user of this machine, and I usually either suspend or power it off when not using), I cannot say if this started when the pms/pmsi merger went in. The last time I can be sure that I had several X's in a row without rebooting is Sept 20, according to last(1). So I can try triaging (actually we're bisecting, not triaging, when we do this :-) ) on the weekend when I am home and have a cvsync repo to build multiple kernels against, and time to do so. 2) (probably related to pms) With wsmoused running, the second X session (as above) fails to get /dev/wsmouse. Sadly I captured the wrong Xorg.log on this one so I'll have to replicate, but I'm out of time for tonight. this error does not pms driver, but failure mechanism is similar to one that I found. At first I will finish with pms, and then take over these problems. I think the objection would not be? :) I really doubt if anyone would object to your fixing problems! :-) Thanks for your contributions. Keep at it! Ian
Re: merge pms and pmsi + added support for some of mouse
On Wed, Sep 22, 2010 at 03:24:28AM +0600, Alexandr Shadchin wrote: Sorry, forgot to fix previous diff. Attached correct diff The revised version not only works for me (Dell Studio amd64 laptop), but even cures the bug that the internal trackpad (pms) locks up during suspend/resume. Thanks!
Re: dhclient-script patch to preserve resolv.conf.save
patrick keshishian wrote: I believe there is no good reason for dhclient-script to override an already existing /etc/resolv.conf.save file. This would not be good for other use cases for dhcp, for example, I often use my netbook at 3 or more locations in the same day. Why would I want to enshrine the first one in resolv.conf.save forever, rather than the previous one? Just make a static copy, say, /etc/resolv.conf.home, and copy that over when you're at home. Or, set up a dhcp server at home. Run OpenBSD on your firewall and it's easy to set up :-) with fixed-address entries in dhcpd.conf.
Re: kernel hacking
Robert Yuri wrote: I'll learn just reading kernel code ? so, many night you need to understand it ? Oh yes. Many.
Re: Novatel Wireless Modem (umsm)
Most of these gadgets need some kind of kick to tell them I'm done using the vapid Windows install disk you provide, now please do what I bought you for. And they of course change their USB device class and ID when kicked. Try doing eject cd1 and see if it re-attaches as umsm. If it does, odds are the DEV_UMASS4 quirk will make it work.
Re: Missing header file in synopsis section of authenticate(3) man page.
Ingo Schwarze wrote: Hi Jason, Jason McIntyre wrote on Sun, Jul 05, 2009 at 05:46:06PM +0100: On Tue, Jun 30, 2009 at 08:56:36AM -0300, Joao Salvatti wrote: Isn't the header file sys/types.h absent in the manual page authenticate(3)? Yes, it is absent, but grepping /usr/share/man/cat3 for types.h tells me that sys/types.h is not mentioned in a single section 3 manual page. There's no value getting the wrong answer quickly. cd /usr/src/lib; find . -name \*.3 | xargs grep 'sys.types.h' | wc -l 51 Anyway, it's on hold til after the unlock.
