Re: Haskell compilation issues
Matthias Kilian wrote: > ps: please note that I'm not subscribed to misc@ with my 'real' > mail account, only with a crappy gmail account I'm only reading on > my tablet (from which I forwarded your mail to my real address). So > better cc' me if you've any other questions ;-) FYI, the way you replied to the original message broke the reply chain in my mail reader (Mutt). You should include an "In-Reply-To" message header that references the Message-ID of the mail to which you are replying. I know it might be a little tricky from your tablet setup, but wanted to bring it to your attention if you weren't aware. In your particular case it would have been: In-Reply-To:
Re: Haskell compilation issues
Omar Polo wrote: > What I think it's required to compile and run haskell program is to > wxallow the partition. If you're using the standard layout the /tmp > and /home should be wxallowed. Yep, GHC creates binaries with W^X violations. The GHC developers are working on this problem in [0], but for now Haskell binaries have to be run from a filesystem mounted as wxallowed. 0: https://gitlab.haskell.org/ghc/ghc/issues/14069
Re: Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces
On 19/05/2019 02:08, Don Jackson wrote: > I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 > motherboard. > > When i attempt to install 6.5, (via PXE or USB), none of the network > interfaces are detected. > A dmesg appears below, followed by a dmesg and ifconfig -a from successful > attempt installing FreeBSD 12.0 > > Any advice/recommendations about how I can get OpenBSD to see the network > interfaces? > I’m hoping there is a BIOS setting that will help, but haven’t found it yet….. Hi Don, I had a very similar problem yesterday. It presented itself after a firmware upgrade. There are many anecdotes on the web about firmware upgrades on Supermicro boards causing these types of problems. I don't know what to suggest apart from the fact that there might be some correlation between firmware and these problems. Also, the X11SDV and C3000 boards are relatively new. They are still not fully supported by many operating systems. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces
I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 motherboard. When i attempt to install 6.5, (via PXE or USB), none of the network interfaces are detected. A dmesg appears below, followed by a dmesg and ifconfig -a from successful attempt installing FreeBSD 12.0 Any advice/recommendations about how I can get OpenBSD to see the network interfaces? I’m hoping there is a BIOS setting that will help, but haven’t found it yet….. In addition, I haven’t been able to get OpenBSD to see the M.2 nvme drive in this chassis, so installed a SATA SSD for now….Any way to get OpenBSD to see/use/boot from the M.2 nvme drive? = OpenBSD 6.5 dmesg: = OpenBSD 6.5 (RAMDISK_CD) #3: Sat Apr 13 14:55:38 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 68336508928 (65170MB) avail mem = 66261471232 (63191MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6de8d000 (62 entries) bios0: vendor American Megatrends Inc. version "1.1" date 01/19/2019 bios0: King Star Computer, inc. X11SDV-8C-TP8F acpi0 at bios0: rev 2, can't enable ACPI cpu0 at mainbus0: (uniprocessor) cpu0: Intel(R) Xeon(R) D-2146NT CPU @ 2.30GHz, 2295.15 MHz, 06-55-04 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,AVX512CD,AVX512BW,AVX512VL,PKU,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE pci0 at mainbus0 bus 0 0:4:0: mem address conflict 0x3831c000/0x4000 0:4:1: mem address conflict 0x38318000/0x4000 0:4:2: mem address conflict 0x38314000/0x4000 0:4:3: mem address conflict 0x3831/0x4000 0:4:4: mem address conflict 0x3830c000/0x4000 0:4:5: mem address conflict 0x38308000/0x4000 0:4:6: mem address conflict 0x38304000/0x4000 0:4:7: mem address conflict 0x3830/0x4000 0:20:2: mem address conflict 0x38323000/0x1000 0:22:0: mem address conflict 0x38322000/0x1000 0:22:1: mem address conflict 0x38321000/0x1000 0:22:4: mem address conflict 0x3832/0x1000 0:31:5: mem address conflict 0xfe01/0x1000 pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x2020 rev 0x04 vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 0 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 1 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 2 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 3 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 4 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 5 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 6 not configured vendor "Intel", unknown product 0x2021 (class system subclass miscellaneous, rev 0x04) at pci0 dev 4 function 7 not configured vendor "Intel", unknown product 0x2024 (class system subclass miscellaneous, rev 0x04) at pci0 dev 5 function 0 not configured vendor "Intel", unknown product 0x2025 (class system subclass miscellaneous, rev 0x04) at pci0 dev 5 function 2 not configured vendor "Intel", unknown product 0x2026 (class system subclass interrupt, rev 0x04) at pci0 dev 5 function 4 not configured vendor "Intel", unknown product 0x2014 (class system subclass miscellaneous, rev 0x04) at pci0 dev 8 function 0 not configured vendor "Intel", unknown product 0x2015 (class DASP subclass Time and Frequency, rev 0x04) at pci0 dev 8 function 1 not configured vendor "Intel", unknown product 0x2016 (class system subclass miscellaneous, rev 0x04) at pci0 dev 8 function 2 not configured "Intel C620 MROM" rev 0x04 at pci0 dev 17 function 0 not configured vendor "Intel", unknown product 0xa1ed (class undefined unknown subclass 0x00, rev 0x04) at pci0 dev 17 function 1 not configured ahci0 at pci0 dev 17 function 5 "Intel C620 AHCI" rev 0x04: irq 11, AHCI 1.3.1 ahci0: port 2: 6.0Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5001b44e1c7b8a66 sd0: 915715MB, 512 bytes/sector, 1875385008 sectors, thin xhci0 at pci0 dev 20 function 0 "Intel C620 xHCI" rev 0x04: irq 11, xHCI 1.0 usb0 at xhci0: USB revision 3.0
LLVM ERROR: inconsistency in registered CommandLine options
Hi, I used amd64/install6.5.iso from ftp server, OpenBSD 6.5 (guest on Virtualbox). FreeBSD-12.0 (host) I would like to use qtcreator. After I installed qt-creator from package ( #pkg_add qt-creator), I got the following error. $ qtcreator QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-masayoshi' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-masayoshi' qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVN4llvm15SIFrameLoweringE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVN4llvm26X86ReturnProtectorLoweringE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFbRKN4llvm15TargetInstrInfoERKNS2_19TargetSubtargetInfoEPKNS2_12MachineInstrERSA_ENS_9allocatorISE_EESD_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFNS_6vectorINS_4pairItN4llvm15LegalizeActions14LegalizeActionEEENS_9allocatorIS7_RKSA_ENS8_ISE_EESD_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFN4llvm19TargetTransformInfoERKNS2_8FunctionEENS_9allocatorIS8_EES7_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFvRN4llvm3orc3VSOENS_10unique_ptrINS3_19MaterializationUnitENS_14default_deleteIS7_ENS_9allocatorISC_EESB_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFvN4llvm5ErrorEENS_9allocatorIS5_EES4_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIN4llvm3orc19OrcMCJITReplacement19NotifyObjectLoadedTENS_9allocatorIS5_EEFvyRKNS2_6object10ObjectFileERKNS2_11RuntimeDyld16LoadedObjectInfo) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFvRKN4llvm18PassManagerBuilderERNS2_6legacy15PassManagerBaseEENS_9allocatorISA_EES9_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVN4llvm16X86FrameLoweringE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIPFbRKN4llvm11GlobalValueEENS_9allocatorIS7_EES6_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVN4llvm19AMDGPUFrameLoweringE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVN4llvm17R600FrameLoweringE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIN4llvm12function_refIFvNS2_5ErrorNS_9allocatorIS6_EES5_EE) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIN4llvm3orc19OrcMCJITReplacement16NotifyFinalizedTENS_9allocatorIS5_EEFvyRKNS2_6object10ObjectFileERKNS2_11RuntimeDyld16LoadedObjectInfo) size mismatch, relink your program qtcreator:/usr/local/lib/libLLVM-7.so: /usr/lib/libLLVM.so.0.0 : WARNING: symbol(_ZTVNSt3__110__function6__funcIZN4llvm18LegalityPredicates3allINS_8functionIFbRKNS2_13LegalityQueryEET_SB_SB_EUlS8_E_NS_9allocatorISC_EES9_EE) size mismatch, relink your program : CommandLine Error: Option 'pm-max-devirt-iterations' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Sent with [ProtonMail](https://protonmail.com) Secure Email.
Re: productivity/khard (or python) seem slow
On Sat 18/05 19:15, Strahil wrote: > I run vanilla openBSD 6.5 on oVirt (KVM) with gluster as storage and it seems > OK for my needs but I never used khard. > What kind of slowness do you experience? > Maybe I can run some tests and see if the situation is the same on KVM. > Well, it takes several seconds to run. Nearly 3 seconds to list only 100 cards. >From 3 to 5 seconds to issue a search from Mutt.
Re: productivity/khard (or python) seem slow
On Sat 18/05 11:39, David Mimms wrote: > On 2019.05.17 11:41, Paco Esteban wrote: > > On Thu, 16 May 2019, Joel Carnat wrote: > > > > > On Thu 16/05 08:55, Paco Esteban wrote: > > > > Can't say about your VM. On my desktop: > > > > > > > > $ time (khard list | wc -l) > > > >104 > > > > ( khard list | wc -l; ) 0.51s user 0.25s system 97% cpu 0.779 total > > > > > > > > > > Is this on OpenBSD ? The time output looks different. > > > > Of course it is ... (-current though) > > That should be zsh that uses an internal builtin instead of > > /usr/bin/time I guess (did not check). > > > > Here it is on ksh with base time: > > > > $ time (khard list | wc -l) > > 104 > > 0m00.81s real 0m00.59s user 0m00.21s system > > > > Interestingly a bit slower. > > What CPU and storage are you running? > The ThinkPad is: CPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz RAM: 8GB DISK: C300-CTFDDAC256M connected on "Intel 100 Series AHCI" @6.0Gb/s ROOT: The VM runs on Synology KVM: CPU: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz RAM: 16GB DISK: Samsung SSD 850 EVO 1TB
Solved: Unbound DNS request timeout
On 15/05/2019 0.17, Pekka Niiranen wrote: Hello misc, Anybody else encountered this issue: I am using OpenBSD v6.3/6.4 with its Unbound as DNS server in local subnet. It does not do any recursive DNS queries. Reverse lookup works for VMware Esxi and Linux machines but not for Windows 2016 or Dell EMC Compellent SCOS 7.3.x arrays. The Windows console message is: DNS request timed out. timeout was 2 seconds -pekka- Adding local-zone: "." static helped. Sorry about the noise. -pekka-
Re: 6.5: rc.firsttime failed, how to restart?
> This could be improved for 6.6. Maybe you should set a marker in > the filesystem instead, indicating that rc.firsttime was already run. > The upgrade procedure could remove the marker. This is pretty common during new installs. I think in 6.5 fw_update is run automatically when the system boots, so it should just take care of itself. If not, just run 'doas fw_update' once you have network connectivity.
Re: ffs undelete was: Re: single user question
> you can write a shell script to move given parameters into a special folder > and make alias rm="that_script" > and a rc script which empty this folder at boot/shutdown. That is indeed the recommended approach for those who need it. An example was published in the O'Reilly book Unix Power Tools... back in the 1980's, among many other places. No kernel changes needed.
Re: productivity/khard (or python) seem slow
I run vanilla openBSD 6.5 on oVirt (KVM) with gluster as storage and it seems OK for my needs but I never used khard. What kind of slowness do you experience? Maybe I can run some tests and see if the situation is the same on KVM. Best Regards, Strahil NikolovOn May 18, 2019 18:39, David Mimms wrote: > > On 2019.05.17 11:41, Paco Esteban wrote: > >On Thu, 16 May 2019, Joel Carnat wrote: > > > >> On Thu 16/05 08:55, Paco Esteban wrote: > >> > Can't say about your VM. On my desktop: > >> > > >> > $ time (khard list | wc -l) > >> > 104 > >> > ( khard list | wc -l; ) 0.51s user 0.25s system 97% cpu 0.779 total > >> > > >> > >> Is this on OpenBSD ? The time output looks different. > > > >Of course it is ... (-current though) > >That should be zsh that uses an internal builtin instead of > >/usr/bin/time I guess (did not check). > > > >Here it is on ksh with base time: > > > > $ time (khard list | wc -l) > > 104 > > 0m00.81s real 0m00.59s user 0m00.21s system > > > >Interestingly a bit slower. > > What CPU and storage are you running? > > My ThinkPad P50: > * Intel Xeon E3-1505M @ 2.80GHz > * 2 x Samsung 960 PRO PCIe NVMe (OpenZFS mirror) > * O/S: Debian Buster > > Results: > $ time (khard list | wc -l) > 265 > ( khard list | wc -l; ) 0.91s user 0.04s system 100% cpu 0.950 total > > > My ThinkPad X1 Carbon (4th gen) > * Intel Core i7-6600U @ 2.60GHz (Hyper-threading disabled) > * 1 x Samsung MZ-NLN512 SATA > * O/S: OpenBSD 6.5 -current > > Results: > $ time (khard list | wc -l) > 265 > ( khard list | wc -l; ) 2.44s user 2.03s system 100% cpu 4.459 total > > The OpenZFS mirror is noticeably slower than a single 960 PRO formatted > as ext4. Since the X1 has a SATA drive in it, I'll eventually have to > install OpenBSD on my spare Samsung 960 PRO in order to improve overall > performance. > > I also tested OpenBSD 6.[45] in VMware Workstation Pro on my P50, and > it ran extremely slow. So slow that it was unusable. I figure it's > not optimized for virtualization? FreeBSD, Linux, and Windows all run > fine in my VMware. > > Best regards, > > David Mimms > https://mim.ms >
Re: productivity/khard (or python) seem slow
On 2019.05.17 11:41, Paco Esteban wrote: On Thu, 16 May 2019, Joel Carnat wrote: On Thu 16/05 08:55, Paco Esteban wrote: > Can't say about your VM. On my desktop: > > $ time (khard list | wc -l) >104 > ( khard list | wc -l; ) 0.51s user 0.25s system 97% cpu 0.779 total > Is this on OpenBSD ? The time output looks different. Of course it is ... (-current though) That should be zsh that uses an internal builtin instead of /usr/bin/time I guess (did not check). Here it is on ksh with base time: $ time (khard list | wc -l) 104 0m00.81s real 0m00.59s user 0m00.21s system Interestingly a bit slower. What CPU and storage are you running? My ThinkPad P50: * Intel Xeon E3-1505M @ 2.80GHz * 2 x Samsung 960 PRO PCIe NVMe (OpenZFS mirror) * O/S: Debian Buster Results: $ time (khard list | wc -l) 265 ( khard list | wc -l; ) 0.91s user 0.04s system 100% cpu 0.950 total My ThinkPad X1 Carbon (4th gen) * Intel Core i7-6600U @ 2.60GHz (Hyper-threading disabled) * 1 x Samsung MZ-NLN512 SATA * O/S: OpenBSD 6.5 -current Results: $ time (khard list | wc -l) 265 ( khard list | wc -l; ) 2.44s user 2.03s system 100% cpu 4.459 total The OpenZFS mirror is noticeably slower than a single 960 PRO formatted as ext4. Since the X1 has a SATA drive in it, I'll eventually have to install OpenBSD on my spare Samsung 960 PRO in order to improve overall performance. I also tested OpenBSD 6.[45] in VMware Workstation Pro on my P50, and it ran extremely slow. So slow that it was unusable. I figure it's not optimized for virtualization? FreeBSD, Linux, and Windows all run fine in my VMware. Best regards, David Mimms https://mim.ms
6.5: rc.firsttime failed, how to restart?
Hi folks, after the upgrade to 6.5 rc.firsttime was lucky to send me an EMail: Path to firmware: http://firmware.openbsd.org/firmware/6.5/ Installing: inteldrm-firmware intel-firmware vmm-firmware rtwn-firmware http://firmware.openbsd.org/firmware/6.5/: ftp: firmware.openbsd.org: no address associated with name http://firmware.openbsd.org/firmware/6.5/: empty Can't find inteldrm-firmware Can't find intel-firmware Can't find vmm-firmware Can't find rtwn-firmware Checking for available binary patches... ftp: ftp.halifax.rwth-aachen.de: no address associated with name Apparently it is a bad idea to remove it if it didn't succeed. My assumption is that the network connection to my DSL provider is not ready yet when rc.firsttime is run. This could be improved for 6.6. Maybe you should set a marker in the filesystem instead, indicating that rc.firsttime was already run. The upgrade procedure could remove the marker. Harri
Re: Current / Security & Stability
Hi Roderick, Roderick wrote on Sat, May 18, 2019 at 08:47:09AM +: > On Sat, 11 May 2019, Otto Moerbeek wrote: >> Once in a while things break in current, but we keep that to a minimum. >> *If* it happens, swift action is taken. >> >> Experiments are mostly done outside the tree and only are committed >> after we are confident it's an improvement. > Is there an advantage in security of running current? Security depends more on how well a system is maintained. Both -current and -stable have roughly the same level of security when well maintained, even though the way to maintain them is somewhat different. Which one is easier to maintain depends on taste and on how many and what kind of packages are in use. Both -current and -stable can become insecure when poorly maintained. > Till now I use OpenBSD as desktop and my greatest fear is to > end with a broken system that distracts me from my work. That sounds as if you clearly prefer -stable, and there is nothing wrong with that. Even though -current breaks rarely, it can happen, and if that is your greatest fear, maybe you don't want to incur that risk. Yours, Ingo
Re: ffs undelete was: Re: single user question
On May 18, 2019 4:08 AM, Solène Rapenne wrote: > > Le 2019-05-17 22:47, Edgar Pettijohn a écrit : > > On May 17, 2019 3:14 PM, gwes wrote: > >> > >> > >> > >> On 5/17/19 2:34 PM, Nathan Hartman wrote: > >> > On Fri, May 17, 2019 at 12:28 PM ropers wrote: > >> > > >> > > >> > In the history of the (Berkeley) Fast File System, has there ever been > >> > an attempt to implement DOS-like undelete for FFS/UFS? > >> > > >> > Maybe that could work for "normal delete" while making available a > >> > separate > >> > "secure delete" that cannot be un-deleted and furthermore overwrites the > >> > deleted data with random garbage. Administrators could optionally force > >> > the > >> > secure overwrite delete. > >> > > >> I haven't looked at e.g. zfs in a long time. > >> > >> A journal-like system which held the deleted/overwritten files > >> or a system of renaming wouldn't be *that* hard to instantiate > >> There are some problems: > >> (a) denial of service by writing and deleting huge [numbers, size] > >> files. > >> (b) retention policy - under what conditions does the system > >> guarantee existence of backup files? > >> (c) versioning - If I create & delete 'a' six times, how many copies > >> are > >> held. > >> (d) cost of undelete operation - it's not clear how to make > >> that efficient. > >> > >> I'm sure people can find more. > >> > >> A test version substituting a new open(2) and unlink(2) in libc would > >> be > >> easy to make. > >> > >> geoff steckel > >> > > > > I'm thinking something like a trashcan. Where rm(1) actually just > > moves the files to some predetermined location then on shutdown all > > files older than some configureable date are actually unlinked. > > > > Edgar > > you can write a shell script to move given parameters into a special > folder > and make alias rm="that_script" > and a rc script which empty this folder at boot/shutdown. > Im thinking putting the script in ~/bin/rm may be better long term. Either way just shows there isn't a pressing need to make code changes for what a couple lines of shell scripts can do fairly easily. Edgar
Re: ffs undelete was: Re: single user question
Le 2019-05-17 22:47, Edgar Pettijohn a écrit : On May 17, 2019 3:14 PM, gwes wrote: On 5/17/19 2:34 PM, Nathan Hartman wrote: > On Fri, May 17, 2019 at 12:28 PM ropers wrote: > > > In the history of the (Berkeley) Fast File System, has there ever been > an attempt to implement DOS-like undelete for FFS/UFS? > > Maybe that could work for "normal delete" while making available a separate > "secure delete" that cannot be un-deleted and furthermore overwrites the > deleted data with random garbage. Administrators could optionally force the > secure overwrite delete. > I haven't looked at e.g. zfs in a long time. A journal-like system which held the deleted/overwritten files or a system of renaming wouldn't be *that* hard to instantiate There are some problems: (a) denial of service by writing and deleting huge [numbers, size] files. (b) retention policy - under what conditions does the system guarantee existence of backup files? (c) versioning - If I create & delete 'a' six times, how many copies are held. (d) cost of undelete operation - it's not clear how to make that efficient. I'm sure people can find more. A test version substituting a new open(2) and unlink(2) in libc would be easy to make. geoff steckel I'm thinking something like a trashcan. Where rm(1) actually just moves the files to some predetermined location then on shutdown all files older than some configureable date are actually unlinked. Edgar you can write a shell script to move given parameters into a special folder and make alias rm="that_script" and a rc script which empty this folder at boot/shutdown.
Current / Security & Stability (Re: When will be created a great desktop experience for OpenBSD?
On Sat, 11 May 2019, Otto Moerbeek wrote: Once in a while things break in current, but we keep that to a minimum. *If* it happens, swift action is taken. Experiments are mostly done outside the tree and only are committed after we are confident it's an improvement. Is there an advantage in security of running current? Till now I use OpenBSD as desktop and my greatest fear is to end with a broken system that distracts me from my work. Rodrigo
Re: When will be created a great desktop experience for OpenBSD?
On 14/5/19 6:07 pm, ULF wrote:
> On a mac, on a recent gnome, on a kde, etc. it's easier for a user to keep
> track of multiple jobs without thinking about the OS, but rather thinking
> about contents. It's a matter of fact that computers are mostly used to do
> things that have nothing to do with programming and sysadmin, and also
> developers here must, while programming/administering the machine, maybe
> write a letter to the insurance, browse 20+ pages while looking at a
> calendar (maybe shared) during a phone call, opening the accounting program
> for taxes and so on...
>
> In 2019, doing all of the above with fvwm, twm, (whatever-tiny)wm not only
> feels awkward, but also time consuming and less flexible. The argument that
> one just has to type "command &" is not as valid as just clicking an icon
> when one of your hands is busy holding the phone or a document.
>
> And, btw, let's say it: fvwm looks like 70s/80s, it's full of charm for
> retrocomputing but it's pretty ugly to see in 2019. And many people prefer
> just right clicking on a picture to change background rather than finding
> which config file they gotta change and then change it.
I find FVWM 2.6.5 does reasonably well for my needs. Yes, I'm
multitasking between a web browser, a terminal session, an email client,
sometimes dozens of text editor (gVim) windows, office suites and
various specialist tools.
My day job involves software development mostly in C, JavaScript and
Python (occasionally C++, PHP, Java, CSS/HTML), and my productivity is
right up there with others that use full-blown desktops (Unity) and IDEs
(Webstorm).
Granted, I've taken the time to actually tune it to my work flow, and no
the journey for doing that is not what I'd call "novice friendly" (note
I didn't say "user friendly", because users come in all levels of
experience).
Prior to that I was running KDE. Notably KDE up to the early 4.0
series, because I found after that point, the desktop ran too slow on
the hardware I had available to use: trying to coax a Pentium II 300MHz
laptop upgraded to its maximum specs (160MB RAM, 160GB HDD) to run the
software I needed for university studies circa 2008 was bad enough, I
didn't need to bog the machine down with a bloated desktop to boot!
Thus, out of necessity, I went from KDE back to FVWM (which ironically
is where I started, as it was the standard desktop for Red Hat Linux 4.0
circa 1996) and adapted it to more-or-less behave the way I needed it to
work. I've even made it work on touch-screens (Raspberry Pi 7").
Eye-candy be damned, I want to *use* my computer!
Really, user friendliness is about being able to adapt the machine to
the user in whatever situation they may find themselves in, whether it
be being stuck with old hardware for financial reasons that you must
make work; having a temporary or permanent inability to use certain body
parts for data entry purposes; or sensory issues preventing the use of
(or needing special configuration of) specific output devices.
KDE 3 was good for that, and was reasonably configurable, but a lack of
flexibility in v4 and a move to a more bloated core made it untenable.
Gnome has been rigid in its capabilities from the start (used it on
several occasions, including v1.0 with Enlightenment), although I hear
it's good with accessibility. awesome wasn't so "awesome" after a month
or two's use. XFCE hasn't really grown on me either.
There was an attempt to make a user-friendly desktop out of FVWM:
fvwm-crystal. If anything, the more important thing is providing an
easy way for users to select some sane defaults, then provide tools for
customisation -- including the "get out of my way and let me DIY" option.
It really is a horses for courses market, and I don't think we'll get
away from that. It's the reason why the commercial desk-top market is
largely a two-horse race (Apple/Microsoft) and why the open-source
movement is awash with different operating system distributions and
window managers.
I did try OpenBSD as a desktop -- on a Lemote Yeeloong, and while it
didn't work out for my needs, I did find it refreshing compared to what
I was used to on Linux. I'd use it more if it weren't for my need to
run things like Docker at work. (Not sure if the old Linux binary
support could be re-instated to run that… but I understand there were
good reasons for culling it, maintenance being one.)
I do not think we should just be "doing ${something}" because everyone
else does -- I think there is a real point to OpenBSD's KISS approach to
system design and would prefer that continues. :-)
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
