Re: When will be created a great desktop experience for OpenBSD?
Steve Litt wrote: > > However I don't think shipping a > > different WM/DE is going to help. > > Back in 2010 or thereabouts, when I used OpenBSD on a laptop > regularly, OpenBSD offered a bunch of WM/DE's in its package manager. > That's a wonderful thing, because different people have different > workflow techniques. I assume OpenBSD still has several different > WM/DE's. > > I don't know whether OpenBSD has KDE or Gnome, and don't really care. I > kicked KDE off all my boxes in 2012 because it's it's a massively > entangled monolith. As far as Gnome, even if it *could* be used in the > absense of systemd, I view Gnome as a gateway drug to the > Freedesktop.org worldview of having every software strongly linked to > every other software, and I want no part of that noise. > > One point I didn't see in RFC's post is stability. When I used OpenBSD > back in 2010, subjectively it seemed more stable, more consistent, and > less surprising than any Linux I'd ever used (and of course than any > Windows I'd ever used). If my computer were just for web browsing, > social networking, email, and storing photos and videos, Ubuntu or Mint > would be stable enough. But the way I work, I often have over 50 > windows open. I can't afford the massive instability bestowed by "we do > it all for you" user interfaces. Very good points being made here. I'm going to match those points -- and similar to everyone else -- misread what is being said, and agree we should choose *ONE* window manager and delete all the others, and force people into a single working model. Look, it is clear that is what everyone wants. I apologize for the group -- we got distracted by the bogus model of "lots of choice is good choice". We'll get started on that community requested goal immediately. And I can assure, we will succeed: over many years we have assembled an accompolished team of code deleters. Internally we'll make a quick decision about which window manager satisfies you all, delete the rest, and prepare for the mission of convincing you all that we are correct and you should all adapt to that choice or run Linux instead. Personally I am a twm fan, but similar to others in this conversation I'll be humble and limit my viewpoint to 80% validity, as long as kde or anything fancy like that doesn't stand a chance I'm open to any point of view. Thank you all for your input.
Re: Is siteXX.tgz working in snapshots?
On Wed, May 08, 2019 at 09:20:30PM -0700, Greg Steuck wrote: > I have a script[1] which I run when "things change" to keep openbsd > syzbot current. Something changed between Apr 2 and now that made my > install procedure no longer execute install.site which I pack into > siteXX.tgz. I checked that siteXX is making it into the iso image that > I use for installation (the very bottom). > > My basic question is: is siteXX working for other people in recent > snapshots (may 8)? > > [1] > https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh > > Thanks > Greg > > P.S. Complete log from installation attempt with the current snapshot: > % ~/s/syzkaller/tools/create-openbsd-gce-ci.sh > install.site > etc/installurl > etc/rc.conf.local > etc/rc.local > etc/sysctl.conf > 1+0 records in > 1+0 records out > 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000284258 s, 14.4 MB/s > Executing 'genisoimage -C 16,207120 -M /dev/fd/3 -l -R -graft-points > /6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf > /disklabel.template=disklabel.template /etc/boot.conf=boot.conf > /etc/random.seed=random.seed | builtin_dd > of=install65-amd64-patched.iso obs=32k seek=12945' > I: -input-charset not specified, using utf-8 (detected in locale settings) > Rock Ridge signatures found > Total translation table size: 0 > Total rockridge attributes bytes: 2521 > Total directory bytes: 8192 > Path table size(bytes): 48 > Max brk space used 0 > 207305 extents written (404 MB) > builtin_dd: 192*2KB out @ average infx1352KBps > install65-amd64-patched.iso: copying volume descriptor(s) > Formatting 'disk.raw', fmt=raw size=10737418240 > spawn qemu-system-x86_64 -nographic -smp 2 -drive > if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso > -net nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm > >> OpenBSD/amd64 CDBOOT 3.42 > boot> > booting cd0a:/6.5/amd64/bsd.rd: 3695441+1532928+3893112+0+598016 > [372212+128+451392+300364]=0xa59b08 > entry point at 0x1001000 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.5-current (RAMDISK_CD) #14: Wed May 8 19:07:27 MDT 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 4177387520 (3983MB) > avail mem = 4046807040 (3859MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries) > bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: rev 0 > acpi0: tables DSDT FACP APIC HPET > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: QEMU Virtual CPU version 2.5+, 2594.27 MHz, 06-06-03 > cpu0: > FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: apic clock running at 1000MHz > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpicpu at acpi0 not configured > "ACPI0006" at acpi0 not configured > "PNP0A03" at acpi0 not configured > acpicmos0 at acpi0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "ACPI0010" at acpi0 not configured > pvbus0 at mainbus0: KVM > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, > channel 0 wired to compatibility, channel 1 wired to compatibility > pciide0: channel 0 disabled (no drives) > atapiscsi0 at pciide0 channel 1 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom > removable > cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 > "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured > vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02 > vga1: aperture needed > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio0: address 52:54:00:12:34:56 > virtio0: msix shared > virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 > vioblk0 at virtio1 > scsibus1 at vioblk0: 2 targets > sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed > sd0: 10240MB, 512 bytes/sector, 20971520 sectors > virtio1: msix shared > isa0 at mainbus0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com0: console > pckbc0 at isa0 port 0x60/5 irq 1 ir
Re: When will be created a great desktop experience for OpenBSD?
Interjecting. About 80 people are building & maintaining an operating system, and following their whims to fix the problems that they believe to be most relevant. What is this email exchange about? Let me lay it out. 1. We are being told what to do. 2. We are being told what is important. 3. We are being told our choices are wrong. There are no diffs, no source code proposals, nothing. There are only wishes. Can you guys please figure it out? Charles wrote: > I'd like to chime in here, on a slightly different subject. > > I think the OP (Clark) raises a point, but I suggest he's coming it > from the wrong angle. I think there's something here to discuss that I > have not seen mentioned in this thread thus far. > > TL;DR: the OpenBSD (and friends) way of thinking is falling further and > further out of fashion with respect to mainstream computing -- I justify > this statement, posit on the need for action, and propose a starting > point. > > Disclaimer 1: I use OpenBSD at various points to refer to the piece of > code, to the development philosophy, to the development team, and to the > community of users. I try to make clear which I am referencing; sorry if > it's confusing. > > Disclaimer 2: I am not an OpenBSD developer. I have contributed only in > very minor ways. I don't speak on behalf of anyone other than myself as > a user of OpenBSD. If it seems at points that I am speaking on behalf of > "OpenBSD" (by any of the previous definitions), I intend that as an > appeal to my perception of what the community of users and developers > feels and thinks, based on my interactions with them here and elsewhere. > If I am wrong in this respect, I invite corrections. > > It certainly seems that there is a great disconnect from the canonical > (small c) definition of "great desktop experience", and the OpenBSD (and > friends) definition. I feel that the broader notion of what a "great > desktop experience" means within the context of the 2019 zeitgeist has > trended towards pandering to the user, in my view to the point of being > patronizing. > > "The users cannot be trusted to manage their own files, it's too hard and > will confuse them." > > "The users cannot be trusted to install their own programs, it's too hard > and will confuse them." > > ... > > "The users cannot be trusted to make decisions, it's too hard and will > confuse them." > > You get the picture (hopefully). > > Part of this is perhaps because the users are "bad at using computers". > I think most anyone who has helped a computer-illiterate family member > or friend with any technology related problem for more than 5 minutes > will see the truth in this statement. But I think it's not the users > fault; many might argue "but if the users would only learn X, Y, an Z > DE/WM/OS/app/etc". I feel that many _do_ argue this, with all the talk > these days of "pushing the envelope", "modern UX", "innovation", and so > on in big blinking neon letters. Ultimately, what this means is telling > the users "yup, you learned $paradigm, but now we have $paradigm++ > because it's the new big thing". If you're a corporate user on a box you > don't control, or you just don't have the experience to do systems > administration on your own, you have to suck it up and deal with it. > > That probably won't be a relateable sentiment to nearly anyone likely to > ever read this document. But as a thought experiment, let's imagine if > vi got a fresh now UX paradigm every year or so, and let's pretend for > the sake of argument that we can't patch it or revert. I think all of us > would not want to use such a program very much. vi takes a while to > learn, and while I (as a diehard vim user) would argue against the > notion of the vi paradigm as the One True Way to edit text, it is > certainly a very powerful tool... because of the time put in to build > muscle memory and intuition about it, knowing that that knowledge will > be applicable to vi implementations for decades to come. Without the > ability to trust that time spent front-loading learning will not be > wasted when $paradigm goes to $paradigm++ in a year, who would ever > invest effort into learning more than the bare minimum? > > Remember that the typical computer user sees their box the way most of > us probably see our cars. It doesn't matter how it works, as long as it > does, but nobody wants a car where the gas and brake pedals switch every > second Tuesday and you wake up one morning to discover the head unit is > now entirely in Sumerian. > > It would seem that this creates a self-perpetuating feedback loop. The > users have a difficult time using the software because they don't learn > it, so the software changes to accommodate the users better, which > further puts folks off of ever learning any of it very well (by > punishing the ones who try). I suggest that this trend has become so > prolific that it has seeped into the general human population's > consciousness around h
Re: When will be created a great desktop experience for OpenBSD?
On Wed, 8 May 2019 22:43:00 -0400 Charles wrote: > I'd like to chime in here, on a slightly different subject. > > I think the OP (Clark) raises a point, but I suggest he's coming it > from the wrong angle. I think there's something here to discuss that I > have not seen mentioned in this thread thus far. > > TL;DR: the OpenBSD (and friends) way of thinking is falling further > and further out of fashion with respect to mainstream computing -- I > justify this statement, posit on the need for action, and propose a > starting point. Ex-actly! Certain OSes and distros, and OpenBSD is one of them, cater to the hands-on, DIY type of person. Turning OpenBSD into just another Ubuntu would be a disservice to such people. [ snip a bunch of true and insightful writing ] > However I don't think shipping a > different WM/DE is going to help. Back in 2010 or thereabouts, when I used OpenBSD on a laptop regularly, OpenBSD offered a bunch of WM/DE's in its package manager. That's a wonderful thing, because different people have different workflow techniques. I assume OpenBSD still has several different WM/DE's. I don't know whether OpenBSD has KDE or Gnome, and don't really care. I kicked KDE off all my boxes in 2012 because it's it's a massively entangled monolith. As far as Gnome, even if it *could* be used in the absense of systemd, I view Gnome as a gateway drug to the Freedesktop.org worldview of having every software strongly linked to every other software, and I want no part of that noise. One point I didn't see in RFC's post is stability. When I used OpenBSD back in 2010, subjectively it seemed more stable, more consistent, and less surprising than any Linux I'd ever used (and of course than any Windows I'd ever used). If my computer were just for web browsing, social networking, email, and storing photos and videos, Ubuntu or Mint would be stable enough. But the way I work, I often have over 50 windows open. I can't afford the massive instability bestowed by "we do it all for you" user interfaces. SteveT
Re: SSH "Honey Keys" Security
Don’t. Generally, these things should be used to alert if an internal service has been compromised (akin to using Canary Tokens), and the key copied. It is, at best, a way to hear someone knocking. On Wed, May 8, 2019 at 15:59 Stefan R. Filipek wrote: > There's a blog post going around that has an interesting use of SSH > authorized_keys restrict + command: > https://kulinacs.com/ssh-honey-keys/ > > If you don't want to follow the link, it basically uses the > well-documented authorized_keys feature to restrict a login for an ssh > key to invoking a single binary which logs the access attempt: > > restrict,command="/usr/local/bin/honeypot_logger" ssh-rsa 1C8...32Tv== > honeypot_...@example.com > > Without devolving into an argument about the efficacy of honey keys or > honey pots in general, I'm wondering if this is truly safe from a > security perspective to run on a regular server (not a dedicated honey > pot). Is there anything that an attacker can control that 'restrict' > does not cover, assuming the targeted command is a shell script? > Perhaps with a malicious SSH client as well? By the man page, > 'restrict' turns on all restrictions available to the authorized_keys > configuration, but it's not clear if that is really sufficient for > this attack scenario. > > Apologies if you feel this is off-topic for the mailing list, but > there's no general OpenSSH discussion list anymore listed on the > openssh site. > > -Stefan > > -- Semt form my Apqle iPhnoe 4s and gMal Mobble.
Is siteXX.tgz working in snapshots?
I have a script[1] which I run when "things change" to keep openbsd syzbot current. Something changed between Apr 2 and now that made my install procedure no longer execute install.site which I pack into siteXX.tgz. I checked that siteXX is making it into the iso image that I use for installation (the very bottom). My basic question is: is siteXX working for other people in recent snapshots (may 8)? [1] https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh Thanks Greg P.S. Complete log from installation attempt with the current snapshot: % ~/s/syzkaller/tools/create-openbsd-gce-ci.sh install.site etc/installurl etc/rc.conf.local etc/rc.local etc/sysctl.conf 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000284258 s, 14.4 MB/s Executing 'genisoimage -C 16,207120 -M /dev/fd/3 -l -R -graft-points /6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf /disklabel.template=disklabel.template /etc/boot.conf=boot.conf /etc/random.seed=random.seed | builtin_dd of=install65-amd64-patched.iso obs=32k seek=12945' I: -input-charset not specified, using utf-8 (detected in locale settings) Rock Ridge signatures found Total translation table size: 0 Total rockridge attributes bytes: 2521 Total directory bytes: 8192 Path table size(bytes): 48 Max brk space used 0 207305 extents written (404 MB) builtin_dd: 192*2KB out @ average infx1352KBps install65-amd64-patched.iso: copying volume descriptor(s) Formatting 'disk.raw', fmt=raw size=10737418240 spawn qemu-system-x86_64 -nographic -smp 2 -drive if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso -net nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm >> OpenBSD/amd64 CDBOOT 3.42 boot> booting cd0a:/6.5/amd64/bsd.rd: 3695441+1532928+3893112+0+598016 [372212+128+451392+300364]=0xa59b08 entry point at 0x1001000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.5-current (RAMDISK_CD) #14: Wed May 8 19:07:27 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4177387520 (3983MB) avail mem = 4046807040 (3859MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries) bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: rev 0 acpi0: tables DSDT FACP APIC HPET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 2.5+, 2594.27 MHz, 06-06-03 cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: apic clock running at 1000MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu at acpi0 not configured "ACPI0006" at acpi0 not configured "PNP0A03" at acpi0 not configured acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured pvbus0 at mainbus0: KVM pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02 vga1: aperture needed wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio0: address 52:54:00:12:34:56 virtio0: msix shared virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio1 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 10240MB, 512 bytes/sector, 20971520 sectors virtio1: msix shared isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay1 softraid0 at root scsibus2 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/amd64 6.5 installation program. (I)nsta
Re: When will be created a great desktop experience for OpenBSD?
I'd like to chime in here, on a slightly different subject. I think the OP (Clark) raises a point, but I suggest he's coming it from the wrong angle. I think there's something here to discuss that I have not seen mentioned in this thread thus far. TL;DR: the OpenBSD (and friends) way of thinking is falling further and further out of fashion with respect to mainstream computing -- I justify this statement, posit on the need for action, and propose a starting point. Disclaimer 1: I use OpenBSD at various points to refer to the piece of code, to the development philosophy, to the development team, and to the community of users. I try to make clear which I am referencing; sorry if it's confusing. Disclaimer 2: I am not an OpenBSD developer. I have contributed only in very minor ways. I don't speak on behalf of anyone other than myself as a user of OpenBSD. If it seems at points that I am speaking on behalf of "OpenBSD" (by any of the previous definitions), I intend that as an appeal to my perception of what the community of users and developers feels and thinks, based on my interactions with them here and elsewhere. If I am wrong in this respect, I invite corrections. It certainly seems that there is a great disconnect from the canonical (small c) definition of "great desktop experience", and the OpenBSD (and friends) definition. I feel that the broader notion of what a "great desktop experience" means within the context of the 2019 zeitgeist has trended towards pandering to the user, in my view to the point of being patronizing. "The users cannot be trusted to manage their own files, it's too hard and will confuse them." "The users cannot be trusted to install their own programs, it's too hard and will confuse them." ... "The users cannot be trusted to make decisions, it's too hard and will confuse them." You get the picture (hopefully). Part of this is perhaps because the users are "bad at using computers". I think most anyone who has helped a computer-illiterate family member or friend with any technology related problem for more than 5 minutes will see the truth in this statement. But I think it's not the users fault; many might argue "but if the users would only learn X, Y, an Z DE/WM/OS/app/etc". I feel that many _do_ argue this, with all the talk these days of "pushing the envelope", "modern UX", "innovation", and so on in big blinking neon letters. Ultimately, what this means is telling the users "yup, you learned $paradigm, but now we have $paradigm++ because it's the new big thing". If you're a corporate user on a box you don't control, or you just don't have the experience to do systems administration on your own, you have to suck it up and deal with it. That probably won't be a relateable sentiment to nearly anyone likely to ever read this document. But as a thought experiment, let's imagine if vi got a fresh now UX paradigm every year or so, and let's pretend for the sake of argument that we can't patch it or revert. I think all of us would not want to use such a program very much. vi takes a while to learn, and while I (as a diehard vim user) would argue against the notion of the vi paradigm as the One True Way to edit text, it is certainly a very powerful tool... because of the time put in to build muscle memory and intuition about it, knowing that that knowledge will be applicable to vi implementations for decades to come. Without the ability to trust that time spent front-loading learning will not be wasted when $paradigm goes to $paradigm++ in a year, who would ever invest effort into learning more than the bare minimum? Remember that the typical computer user sees their box the way most of us probably see our cars. It doesn't matter how it works, as long as it does, but nobody wants a car where the gas and brake pedals switch every second Tuesday and you wake up one morning to discover the head unit is now entirely in Sumerian. It would seem that this creates a self-perpetuating feedback loop. The users have a difficult time using the software because they don't learn it, so the software changes to accommodate the users better, which further puts folks off of ever learning any of it very well (by punishing the ones who try). I suggest that this trend has become so prolific that it has seeped into the general human population's consciousness around how interacting with computers works. Think about it. How many software packages do you know of where a user could learn how to use it well once and have that knowledge be applicable for years or decades thereafter? This is something we expect (as technical folk) of shells and editors, scripting languages, and so on, but it is not something that the layperson using a GUI can now or at any point in the past reasonably expect. Remember also, that every developer was one a user at some point. It sure seems that the wall you have to climb over to go from user to developer keeps getting higher and higher every year. There are several p
SSH "Honey Keys" Security
There's a blog post going around that has an interesting use of SSH authorized_keys restrict + command: https://kulinacs.com/ssh-honey-keys/ If you don't want to follow the link, it basically uses the well-documented authorized_keys feature to restrict a login for an ssh key to invoking a single binary which logs the access attempt: restrict,command="/usr/local/bin/honeypot_logger" ssh-rsa 1C8...32Tv== honeypot_...@example.com Without devolving into an argument about the efficacy of honey keys or honey pots in general, I'm wondering if this is truly safe from a security perspective to run on a regular server (not a dedicated honey pot). Is there anything that an attacker can control that 'restrict' does not cover, assuming the targeted command is a shell script? Perhaps with a malicious SSH client as well? By the man page, 'restrict' turns on all restrictions available to the authorized_keys configuration, but it's not clear if that is really sufficient for this attack scenario. Apologies if you feel this is off-topic for the mailing list, but there's no general OpenSSH discussion list anymore listed on the openssh site. -Stefan
Re: When will be created a great desktop experience for OpenBSD?
noah pugsley writes: > Updated FVWM or a different default config? > > Sent from mobile. > Original Message > From: Christopher Turkel > Sent: Wednesday, May 8, 2019 04:22 > Cc: OpenBSD Misc > Subject: Re: When will be created a great desktop experience for OpenBSD? > > I'd like to see an updated FVWM as the default WM. Then you'll need this: https://www.openbsd.org/faq/faq5.html Why is this thread still here? Matthew
Re: When will be created a great desktop experience for OpenBSD?
I'm in favor of an updated FVWM with a simple config. On Wed, May 8, 2019 at 5:43 PM Matthew Graybosch wrote: > On Wed, May 8, 2019, at 5:18 PM, Roderick wrote: > > > > On Wed, 8 May 2019, noah pugsley wrote: > > > > > Updated FVWM or a different default config? > > > > I hope, no one comes to the idea to change the configuration. > > I'm not really fussed about the default FVWM config; it's easy enough to > pull a copy into $HOME and start tinkering with it once you've read > fvwmrc(5), or to switch to cwm (1) (my favorite). Hell, it wasn't that hard > to install OpenBSD with MATE and LibreOffice on a neighbor's old Intel NUC > so her kids had a machine to do homework on without getting distracted by > Fortnite (but wait until they discover hack(6)). > > I'm happy with OpenBSD as a desktop machine, even though the OS wasn't > made with me in mind, and I appreciate all of the work the developers have > put into it for their own purposes. Thanks! > > -- > Matthew Graybosch > "'Out of order'?! Even in the future nothing works." > >
Re: When will be created a great desktop experience for OpenBSD?
On Wed, May 8, 2019, at 5:18 PM, Roderick wrote: > > On Wed, 8 May 2019, noah pugsley wrote: > > > Updated FVWM or a different default config? > > I hope, no one comes to the idea to change the configuration. I'm not really fussed about the default FVWM config; it's easy enough to pull a copy into $HOME and start tinkering with it once you've read fvwmrc(5), or to switch to cwm (1) (my favorite). Hell, it wasn't that hard to install OpenBSD with MATE and LibreOffice on a neighbor's old Intel NUC so her kids had a machine to do homework on without getting distracted by Fortnite (but wait until they discover hack(6)). I'm happy with OpenBSD as a desktop machine, even though the OS wasn't made with me in mind, and I appreciate all of the work the developers have put into it for their own purposes. Thanks! -- Matthew Graybosch "'Out of order'?! Even in the future nothing works."
Re: When will be created a great desktop experience for OpenBSD?
On Wed, 8 May 2019, noah pugsley wrote: Updated FVWM or a different default config? I hope, no one comes to the idea to change the configuration. In FreeBSD fvwm is awful configurated and I do not want to waste my time configurating it. That is why I use there twm (easy to configure). Rodrigo
Re: When will be created a great desktop experience for OpenBSD?
Updated FVWM or a different default config? Sent from mobile. Original Message From: Christopher Turkel Sent: Wednesday, May 8, 2019 04:22 Cc: OpenBSD Misc Subject: Re: When will be created a great desktop experience for OpenBSD? I'd like to see an updated FVWM as the default WM. On Wed, May 8, 2019 at 7:18 AM Mohamed Fouad < mohamed.ahmed.fouad@gmail.com> wrote: > if you are suggesting updating the openbsd installer to include dwm as an > option. Even that it adds one more click to the installation process, it > would work as a sharm for some people :P > > On Tue, 7 May 2019, 2:04 am Clark Block > > In 2019 still there is not a great desktop experience for NetBSD. > However, > > the new "OS108" is seeking to improve this with a NetBSD operating system > > paired with the MATE desktop environment. > > So, OS108, a derivative of NetBSD, has just been released: > > https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) > > > > When will be created a great desktop experience for OpenBSD? > > >
Re: When will be created a great desktop experience for OpenBSD?
If you do that, you'd better crank way up on its fonts. Fvwm fonts are so small that if you have bad vision, you can't read the screen well enough to increase the font size. It's easy for a well-sighted person to reduce fonts, but for the poorly sighted person who can't read the screen in the first place, it's a long, difficult process. SteveT On Wed, 8 May 2019 07:20:29 -0400 Christopher Turkel wrote: > I'd like to see an updated FVWM as the default WM. > > On Wed, May 8, 2019 at 7:18 AM Mohamed Fouad < > mohamed.ahmed.fouad@gmail.com> wrote: > > > if you are suggesting updating the openbsd installer to include dwm > > as an option. Even that it adds one more click to the installation > > process, it would work as a sharm for some people :P > > > > On Tue, 7 May 2019, 2:04 am Clark Block > wrote: > > > In 2019 still there is not a great desktop experience for > > > NetBSD. > > However, > > > the new "OS108" is seeking to improve this with a NetBSD > > > operating system paired with the MATE desktop environment. > > > So, OS108, a derivative of NetBSD, has just been released: > > > https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) > > > > > > When will be created a great desktop experience for OpenBSD? > > > > >
Re: May 7 snap broken, ld.so: ld: can't load library 'libc++.so.2.2'
Greg Steuck(g...@nest.cx) on 2019.05.07 19:23:03 -0700: > This is presumably already fixed by "Sync after libc++ bump", but in case > somebody else hits it... > > The amd64 snapshot with this signature: > RWSZaRmt1LEQT+LPpgKcdukqjs3m1yYLE+J4zXB8YQ/iylbA3a/1IW31M6W9qKI+yIOxrbWghPno0HTSgbBfDyBZGwHWggiJBw4= > > ... produces these errors upon reboot into the newly installed system: > reordering libraries:ld.so: ld: can't load library 'libc++.so.2.2' > Killed > Abort trap > install: ld.so.test: No such file or directory > failed. already fixed, wait for the next snapshot. > Thanks > Greg > > P.S.How useful would it be to automatically install amd64/i386 snapshots in > a vmm before declaring them worthy of publishing? Well, that offloads finding of problems from many pair of eyes to one. So no, probably not going to happen. If you use snapshots things like this may happen fromtime to time.
Re: X hangs again while on integrated
On Wed, May 8, 2019, at 03:59, Gregory Edigarov wrote: > > On 07.05.19 11:39, Gregory Edigarov wrote: > > I've got some more info on this. > > > > tried to run X with tiling wms: spectrwm (my main wm), dwm, i3 - all > > hang absolutely the same way. (see my last mail with X backtraced) > > > > then I've tried fvwm - works > > > > cwm - works > > > > kde & gnome - both work flawlessly. > > > > i.e. there is some trouble in the newest versions of Xenocara, making > > it impossible to run with tiling window manager at least on i915. > sorry, > > yesterday fvwm and cwm were both hanging the same way spectrwm does. > > if somebody want to look into the issue - what else information beside > dmesg and backtrace do you need? > > didn't test with kde & gnome ( and anyway I removed them as I don't use > them) > > Thanks. > > > > > > > On 23.04.19 11:43, Gregory Edigarov wrote: > >> Hello misc@ > >> > >> it happens with no traces in logs. > >> > >> most of the time while in chromium, but in firefox too. (with firefox > >> it just needs more time) > >> > >> thought it is memory, but memtest reveal nothing. the same is the > >> video memory tests. it happens only on > >> > >> intel i915. no hangs on radeon(non integrated). > >> > >> when this happen i am always able to login via ssh too the box and > >> kill X. > >> > >> killing chrome or firefox dfwiw, I also have X hangs on -current, though > >> I'm not able to ssh + reboot. My system completely locks up. I have an Intel UHD Graphics 620 card. I've submitted a bug report here: oesn't help. > >> > >> also noticed that with recent build as of Apr 21, kernel is loosing > >> the changes made by config, but still works when i make changes > >> during the boot in UKC. > >> > >> > >> > >> > >> dmesg: > >> fwiw, I also have X hangs on -current, though I'm not able to ssh + reboot. My system completely locks up. I have an Intel UHD Graphics 620 card. I've submitted a bug report here: https://marc.info/?l=openbsd-bugs&m=155716824903439&w=2
Re: When will be created a great desktop experience for OpenBSD?
On Wed, May 8, 2019, at 7:38 AM, Peter N. M. Hansteen wrote:
> > When will be created a great desktop experience for OpenBSD?
>
> I think it is important to keep in mind that in order to achieve
> *anything* in the OpenBSD project (or other open source projects for
> that matter) the way forward is to work *with*, not against, the
> developers and their code.
>
> The short version is, please present your ideas of what you want to do
> with sound reasoning and if at all possible supplement with patches
> posted to tech@.
>
> The patches stand a better chance of being accepted (perhaps along
> with their developer) if the submitter can take comments and valid
> criticisms from competent people (again mainly the developers) in
> stride and seems willing to stay around as maintainer in the longer
> haul (ie not slink back to the shadows after a release or two).
>
> For anyone considering taking up the theme of this thread, please
> consider whether this could somehow be made into the package with only
> minimal impact on the base system.
>
> Such a package could for example leverage all the tools already in the
> base systems to generate something like bsd.graphic.{rd,is,fs} and
> offer a skeleton for a site.tgz for the generated install medium.
>
> If this sounds a lot like what is very achievable with the tools
> already in the OpenBSD base system and seasoned OpenBSD admins would
> do comfortably with a relatively simple autoinstall, it's because that
> is exactly what it is.
>
> But if there is an actual use case spot we're missing, this would be
> the way to filling it with the least amount of extra work for everyone
> involved.
Peter, it's not going to happen because it would require someone to do work.
The whole point is to try to get others to do it for you.
Re: When will be created a great desktop experience for OpenBSD?
On Wed, 8 May 2019, ropers wrote: Tangentially related: Does anyone here routinely use the default fvwm? Yes, routinely default fvwm, also twm, and nothing else. Not only with OpenBSD. Rodrigo
Re: When will be created a great desktop experience for OpenBSD?
I love the default minimalism, simplicity and freedom of OpenBSD to make it
how I want it.
My "Perfect OpenBSD": spectrwm, dmenu, urxvt (with perl tabbing), tmux, etc.
On Wed, May 8, 2019 at 7:40 AM Peter N. M. Hansteen wrote:
> > When will be created a great desktop experience for OpenBSD?
>
> I think it is important to keep in mind that in order to achieve
> *anything* in the OpenBSD project (or other open source projects for
> that matter) the way forward is to work *with*, not against, the
> developers and their code.
>
> The short version is, please present your ideas of what you want to do
> with sound reasoning and if at all possible supplement with patches
> posted to tech@.
>
> The patches stand a better chance of being accepted (perhaps along
> with their developer) if the submitter can take comments and valid
> criticisms from competent people (again mainly the developers) in
> stride and seems willing to stay around as maintainer in the longer
> haul (ie not slink back to the shadows after a release or two).
>
> For anyone considering taking up the theme of this thread, please
> consider whether this could somehow be made into the package with only
> minimal impact on the base system.
>
> Such a package could for example leverage all the tools already in the
> base systems to generate something like bsd.graphic.{rd,is,fs} and
> offer a skeleton for a site.tgz for the generated install medium.
>
> If this sounds a lot like what is very achievable with the tools
> already in the OpenBSD base system and seasoned OpenBSD admins would
> do comfortably with a relatively simple autoinstall, it's because that
> is exactly what it is.
>
> But if there is an actual use case spot we're missing, this would be
> the way to filling it with the least amount of extra work for everyone
> involved.
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
>
Re: When will be created a great desktop experience for OpenBSD?
> When will be created a great desktop experience for OpenBSD?
I think it is important to keep in mind that in order to achieve
*anything* in the OpenBSD project (or other open source projects for
that matter) the way forward is to work *with*, not against, the
developers and their code.
The short version is, please present your ideas of what you want to do
with sound reasoning and if at all possible supplement with patches
posted to tech@.
The patches stand a better chance of being accepted (perhaps along
with their developer) if the submitter can take comments and valid
criticisms from competent people (again mainly the developers) in
stride and seems willing to stay around as maintainer in the longer
haul (ie not slink back to the shadows after a release or two).
For anyone considering taking up the theme of this thread, please
consider whether this could somehow be made into the package with only
minimal impact on the base system.
Such a package could for example leverage all the tools already in the
base systems to generate something like bsd.graphic.{rd,is,fs} and
offer a skeleton for a site.tgz for the generated install medium.
If this sounds a lot like what is very achievable with the tools
already in the OpenBSD base system and seasoned OpenBSD admins would
do comfortably with a relatively simple autoinstall, it's because that
is exactly what it is.
But if there is an actual use case spot we're missing, this would be
the way to filling it with the least amount of extra work for everyone
involved.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: When will be created a great desktop experience for OpenBSD?
I'd like to see an updated FVWM as the default WM. On Wed, May 8, 2019 at 7:18 AM Mohamed Fouad < mohamed.ahmed.fouad@gmail.com> wrote: > if you are suggesting updating the openbsd installer to include dwm as an > option. Even that it adds one more click to the installation process, it > would work as a sharm for some people :P > > On Tue, 7 May 2019, 2:04 am Clark Block > > In 2019 still there is not a great desktop experience for NetBSD. > However, > > the new "OS108" is seeking to improve this with a NetBSD operating system > > paired with the MATE desktop environment. > > So, OS108, a derivative of NetBSD, has just been released: > > https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) > > > > When will be created a great desktop experience for OpenBSD? > > >
Re: When will be created a great desktop experience for OpenBSD?
if you are suggesting updating the openbsd installer to include dwm as an option. Even that it adds one more click to the installation process, it would work as a sharm for some people :P On Tue, 7 May 2019, 2:04 am Clark Block In 2019 still there is not a great desktop experience for NetBSD. However, > the new "OS108" is seeking to improve this with a NetBSD operating system > paired with the MATE desktop environment. > So, OS108, a derivative of NetBSD, has just been released: > https://os108.org/?ez_cid=CLIENT_ID(AMP_ECID_EZOIC) > > When will be created a great desktop experience for OpenBSD? >
Re: When will be created a great desktop experience for OpenBSD?
On 08/05/2019, noah pugsley wrote: > You know, I guess it's just personal convention from habit. I think I > started doing that way back before I could remember how the redirects work > without looking them up. Too lazy to change now. > > So yeah, if you're trying to divine something clever from that, I wouldn't. > :-) Okay, yeah, but maybe I can still "divine" something clever and cater to laziness too. Suppose we created a shell script named x and put that e.g. in ~/bin once that's in our path, and then we made it executable. Contents of ~/bin/x: #!/bin/sh $@ > ~/.x.`basename $1`.log 2>&1 & Then we could just type $ x firefox and get nice combined logs of just the last run in case anything went wrong, but otherwise we'd have peace and quiet. I won't claim this beats dmenu, but still. This does no error-checking, but I'm not sure if the added complexity of that would be an advantage to a proficient user. If anyone sees anything seriously wrong with this, speak now or forever hold your peace. > Original Message > From: ropers > Sent: Tuesday, May 7, 2019 21:07 > To: noah pugsley > Cc: Edgar Pettijohn; Steve Litt; misc@openbsd.org > Subject: Re: When will be created a great desktop experience for OpenBSD? > >> From: ropers >> Tangentially related: Does anyone here routinely use the default fvwm? >> >> Now for a really noobish question: Those that do, do you also launch >> graphical apps by typing something like this in xterm: >> >> $ firefox > /dev/null 2>&1 & >> >> or do you normally do something else that I've totally overlooked? > > On 08/05/2019, noah pugsley wrote: >> Maybe I'm a weirdo, but no matter what I use for a window manager, I >> start >> all programs from the cli. All. >> >> For Firefox or Chrome something like this: >> >> $ firefox & bw ; exit >> >> bw is a shortcut to an xterm with a bunch of options. Kill the one with >> the >> console crap and poop out a fresh one. > > You probably know this, but just for the record/archives, the >> $ firefox > /dev/null 2>&1 & > line that I quoted earlier should normally take care of "the console crap": > It redirects firefox's stdout to /dev/null, then redirects firefox's > stderr to stdout and thus to /dev/null, and then sets firefox to run > in the background. > > (So if, I don't know, bw is perhaps just a script you wrote to avoid > "the console crap", then maybe it's not even necessary? I imagine it > might even be easier to keep your history if you're not constantly > spawning new xterms. > If you're way ahead of me here and if I'm just totally missing the > point, the plot and something obvious, feel free to engage in random > acts of clue-battery. ;) >
Re: X hangs again while on integrated
On 07.05.19 11:39, Gregory Edigarov wrote: I've got some more info on this. tried to run X with tiling wms: spectrwm (my main wm), dwm, i3 - all hang absolutely the same way. (see my last mail with X backtraced) then I've tried fvwm - works cwm - works kde & gnome - both work flawlessly. i.e. there is some trouble in the newest versions of Xenocara, making it impossible to run with tiling window manager at least on i915. sorry, yesterday fvwm and cwm were both hanging the same way spectrwm does. if somebody want to look into the issue - what else information beside dmesg and backtrace do you need? didn't test with kde & gnome ( and anyway I removed them as I don't use them) Thanks. On 23.04.19 11:43, Gregory Edigarov wrote: Hello misc@ it happens with no traces in logs. most of the time while in chromium, but in firefox too. (with firefox it just needs more time) thought it is memory, but memtest reveal nothing. the same is the video memory tests. it happens only on intel i915. no hangs on radeon(non integrated). when this happen i am always able to login via ssh too the box and kill X. killing chrome or firefox doesn't help. also noticed that with recent build as of Apr 21, kernel is loosing the changes made by config, but still works when i make changes during the boot in UKC. dmesg: OpenBSD 6.5-current (GENERIC.MP) #0: Sun Apr 21 14:26:55 EEST 2018 g...@lbld12.duckdns.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xb320 (90 entries) bios0: vendor American Megatrends Inc. version "3805" date 05/10/2018 bios0: ASUSTeK COMPUTER INC. Q170M-C acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ASF! MCFG SSDT FIDT SSDT SSDT HPET SSDT SSDT UEFI SSDT LPIT WSMT SSDT SSDT DBGP DBG2 TPM2 acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) SIO1(S3) UAR1(S4) UAR2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2694.73 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI \ ,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDB \ G,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F1 \ 6C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SME \ P,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2693.78 MHz, 06-5e-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI \ ,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDB \ G,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F1 \ 6C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SME \ P,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2693.78 MHz, 06-5e-03 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI \ ,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDB \ G,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F1 \ 6C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SME \ P,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2693.78 MHz, 06-5e-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI \ ,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDB \ G,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F1 \ 6C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SME \ P,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,
Re: dmenu: was When will be created a great desktop experience for OpenBSD?
On 2019-05-07, Steve Litt wrote: On Tue, 07 May 2019 14:47:15 -0500 Edgar Pettijohn wrote: I use dwm on everything so my desktop experience is the same everywhere. Just the man I want to talk to. Do you have dmenu running on OpenBSD? Did you need to make adjustments for ksh instead of sh or any other property of OpenBSD? Hi, fellow dwm user here. I didn't have to make any ksh adjustments or anything else. I use a number of Suckless programs, including dwm, dmenu and st. They make for a fairly minimal and enjoyable experience on X. I have tweaked dwm and st a bit, mostly using the user-submitted patches. I just cloned the bare git repos to my own server and I create a new branch for each box I use (currently this only sums up to two). The configs are similar, but for example on a smaller screen (laptop) I eliminate the gaps between clients to save screen estate. Also my PC can easily handle transparency for st, but my laptop couldn't. I also have a few very handy shortcuts for launching qutebrowser for example (Super + Shift + U). I also set keybinds for `shutdown -p now` and `shutdown -r now`, because I like to just press three keys when I want to poweroff. Actually, I've been through i3 and bspwm as well and only recently got familiar with dwm. Absolutely beats both IMO. -- Bertalan Zoltán Péter
Re: Upgrade procedure (6.4 -> 6.5)
On Tue, May 07, 2019 at 08:15:16PM -0400, Nick Holland wrote: On 5/7/19 8:32 AM, Dumitru Moldovan wrote: On Sun, May 05, 2019 at 05:05:11PM +0200, Ingo Schwarze wrote: Hi, Consus wrote on Fri, May 03, 2019 at 02:24:10PM +0300: Maybe it's a good idea to note this on the upgrade page? Something like "the upgrade procedure may leave some files behing; you can manually clean them up using sysclean package"? [...] For example, it is definitely useful to remove stale Perl libraries. It is also useful for stale header files if you compile software from source. It is useful (but not terribly important) for stale manual pages. It is usually detrimental for old versions of shared libraries, unless you are *really* short on disk space (which is getting less common nowadays) *and* you are very careful. For most use cases, we do not recommend using sysclean. I think there's a less common scenario not covered in this thread. Suppose you have locally-compiled binaries, linked to previous versions of libraries, belonging to an older version of the OS. Those libs will never get patched after you upgrade, so any vulnerabilities they expose will remain exploitable in the binaries linked to them. Ok, I admire your confidence that the problem in your local binaries are the OpenBSD libraries. :D This swings both ways. When doing an upgrade, if the upgrade deleted all those libraries BEFORE you had a chance to upgrade that binary, it would quit working. While I'm all for "Fail Closed", it might be premature to call it a failure. Or not. It is very hard to please all, and even harder to cover all possible situations. You're mostly right, but just to be clear... Although it's true I'm a purist on this and would prefer that binaries linked to old libs will fail after an OS upgrade, there's no confidence to be admired on my side. This is why I used "I think" and "suppose you have" above. Thanks for the understanding!
Re: When will be created a great desktop experience for OpenBSD?
On 02:01 Tue 07 May, Clark Block wrote: > When will be created a great desktop experience for OpenBSD? After binary package updates will be out-of-box, without using third-party M:Tier.
