Re: Etnernal & infernal browser woes
On Sat, Apr 29, 2017 at 05:28:33PM +0200, Sebastien Marie wrote: > On Sat, Apr 29, 2017 at 11:21:25PM +0900, Bryan Linton wrote: > > On 2017-04-29 15:48:51, Ingo Schwarze wrote: > > > > > > Chris Bennett wrote on Sat, Apr 29, 2017 at 07:10:05AM -0500: > > > > > >> Firefox [...] takes a long period to actually finish crashing > > > > > > It dumps core. That takes a long time because firefox tends > > > to waste huge amounts of memory [...] > > > > > > > One hack I've done when I don't care about actually getting or > > using a corefile from large programs is to do the following: > > > > # rm progname.core > > # touch progname.core > > # chflags uchg progname.core > > > > Of course, I'd only recommend doing so if one is absolutely > > certain they don't want a corefile from said program ever again, > > and will remember to unset that flag should they ever change their > > mind. > > > > If you want to disable core dump for a program, you could (should ?) > configure your RLIMIT_CORE to 0. > > $ ulimit -c 0 > $ firefox > > -- > Sebastien Marie > That's great. I was traveling a few months ago and I had a box of hard drives I was using stolen. Temporarily, I really need to not have any of those huge core files eating up space. Saddest thing is I know they probably just opened the box and threw them away. Chris Bennett
Re: Etnernal & infernal browser woes
Just wanted to mention the firefox extension umatrix. I find it much better than noscript for controlling page speed. That said I only *notice* slowness compared to like xombrero on older machines.
Re: Etnernal & infernal browser woes
> On Thu, 8 Sep 2016 17:53:24 +0200 > "Jens A. Griepentrog" wrote: > ... > I have been using OpenBSD for six years on my desktop > without any problems. Everything works fine on my > ASUS P7F-M WS mainboard including its audio daughterboard; > also graphics hardware acceleration on ATI Radeon HD 6450. > ... > There has been some degradation in speed in OpenBSD 5.9 > when looking online videos with seamonkey/firefox browsers. > Usually, I download longer videos and mplay those offline > without any stuttering. > ... Dear OpenBSD Developer Team, many thanks for the new release! In contrast to the problems originally mentioned in this thread I have the opposite feeling: After my yearly upgrade (from OpenBSD 5.9 to 6.1) there is no degradation in speed at all ... Much better, the stuttering has gone when looking online videos with seamonkey/firefox browsers! With best regards, Jens
Re: Etnernal & infernal browser woes
Am 30.04.2017 00:07 schrieb Mihai Popescu: Do you know a method like this to disable kernel panic screen, too? Also something for hidding the dmesg scroll on boot will be nice. Maybe something to show a nice picture with a text like "sit back and relax while your OS is loading ..." - the last three points must be some kind of animation. Nothing is that stupid, noone would go there. We did that back in early 3.x times to have a full installation (auto_install wasnt even beyond the horizon back then) including suppressed boot>, no dmesg (but a nice 'whirl'), some install-progress and kind of dyndns. All on a single 80x24 screen without scrolling. Needed some serious diffs including meddling in some .S and init(8).. diff is on a backup tape far far away :-) ciao -- pb
Re: Etnernal & infernal browser woes
On Sat, April 29, 2017 6:07 pm, Mihai Popescu wrote: > Do not forget to use (activate) uBlock Origin too, there is in Add-Ons > for Firefox. > > Teh guy with 134 opened tabs at once in firefox was funny. How many > monitors is firefox windows spreading across? > > Thanks. > It's tabs. You only need one window. http://imgur.com/a/Cm4eO uBlock and NoScript are a given. I also use Tab Groups (pictured). Apparently I was the only one with this need, as tab groups were removed from core firefox and even the plugin is being abandoned. It's going to be a rough transition when that stops working...
Re: Etnernal & infernal browser woes
On Sun, Apr 30, 2017 at 12:07 AM, Mihai Popescu wrote: > Do you know a method like this to disable kernel panic screen, too? > Also something for hidding the dmesg scroll on boot will be nice. > > Maybe something to show a nice picture with a text like "sit back and > relax while your OS is loading ..." - the last three points must be > some kind of animation. > Oh, and the text can be changed with more optimistic ones "life is > beautiful today...", etc. > Yes, not wanting pretty much useless 2GB+ core dumps from an application that often crashes is exactly the same as those other things.
Re: Etnernal & infernal browser woes
Do not forget to use (activate) uBlock Origin too, there is in Add-Ons for Firefox. And one more thing, from this thread: > If you want to disable core dump for a program, you could (should ?) > configure your RLIMIT_CORE to 0. > > $ ulimit -c 0 > $ firefox > > Ah, yes. That's a much better solution. I overlooked that that > option was available. Thank you for the pointer! :) Do you know a method like this to disable kernel panic screen, too? Also something for hidding the dmesg scroll on boot will be nice. Maybe something to show a nice picture with a text like "sit back and relax while your OS is loading ..." - the last three points must be some kind of animation. Oh, and the text can be changed with more optimistic ones "life is beautiful today...", etc. Teh guy with 134 opened tabs at once in firefox was funny. How many monitors is firefox windows spreading across? Thanks.
Re: Etnernal & infernal browser woes
On 2017-04-29 17:28:33, Sebastien Marie wrote: > On Sat, Apr 29, 2017 at 11:21:25PM +0900, Bryan Linton wrote: > > > > One hack I've done when I don't care about actually getting or > > using a corefile from large programs is to do the following: > > > > # rm progname.core > > # touch progname.core > > # chflags uchg progname.core > > > > Of course, I'd only recommend doing so if one is absolutely > > certain they don't want a corefile from said program ever again, > > and will remember to unset that flag should they ever change their > > mind. > > > > If you want to disable core dump for a program, you could (should ?) > configure your RLIMIT_CORE to 0. > > $ ulimit -c 0 > $ firefox > Ah, yes. That's a much better solution. I overlooked that that option was available. Thank you for the pointer! :) -- Bryan
Re: Etnernal & infernal browser woes
On Sat, Apr 29, 2017 at 11:21:25PM +0900, Bryan Linton wrote: > On 2017-04-29 15:48:51, Ingo Schwarze wrote: > > > > Chris Bennett wrote on Sat, Apr 29, 2017 at 07:10:05AM -0500: > > > >> Firefox [...] takes a long period to actually finish crashing > > > > It dumps core. That takes a long time because firefox tends > > to waste huge amounts of memory [...] > > > > One hack I've done when I don't care about actually getting or > using a corefile from large programs is to do the following: > > # rm progname.core > # touch progname.core > # chflags uchg progname.core > > Of course, I'd only recommend doing so if one is absolutely > certain they don't want a corefile from said program ever again, > and will remember to unset that flag should they ever change their > mind. > If you want to disable core dump for a program, you could (should ?) configure your RLIMIT_CORE to 0. $ ulimit -c 0 $ firefox -- Sebastien Marie
Re: Etnernal & infernal browser woes
Hi, On 28/04/2017 14:18, Jyri Hovila [iki.fi] wrote: which is properly coded, very stable and secure, but (when it comes to a "normal" user or even an experienced sysadmin) utterly useless when it comes to doing the stuff everyone does these days -- browsing the net. Yes, I know many of you are browsing the net with OpenBSD. So am I. Just to make sure everyone understands what I mean: it is not that it would be impossible, it is just insanely irritating and slow. I am an avid NetBSD and OpenBSD user and the two system perform similar regarding browsers. The first reason of crash is memory limits,: so be sure to raise them. If you use those "hungry" sites you cite, the most common problem is killing of the browser because of memory. The delay you notice is then given by the dump. Personally I do not notice any "slowdown" on OpenBSD when using a comparable NetBSD system or even Linux or FreeBSD system. Actually, except where video, plugins or other similar things are involved, the system works very well. I will say more: on BSDs the machine remains quite usable even if the browser slows down, while e.g. on Windows not. I use gecko engines mostly: SeaMonkey and Firefox and compare on all platforms. I stay away from Chrome/Chromium stuff for various reasons. I haven't tested Midori well on BSD, but on Linux and Windows it isn't that better than Firefox: slow opening and starting, even if then pages perform decently The issue is that the browsers themselves are very much Windows and x86/amd64 oriented, with a little eye on Mac and Linux. Other architectures work worse. PPC is rotting, ARM is not that different. I use Salesforce.com all day long professionally (which has very intensive pages) and notice I can use it very well on my OpenBSD or NetBSD laptop, even gaining some speed compared to a Windows machine! What is slower is that the whole "video" is a bit slower surely due to worse drivers, but e.g. SeaMonkey itself works quite well. Keep an eye with top on your browser memory usage and the limits you se. Riccardo
Re: Etnernal & infernal browser woes
On 2017-04-29 15:48:51, Ingo Schwarze wrote: > > Chris Bennett wrote on Sat, Apr 29, 2017 at 07:10:05AM -0500: > >> Firefox [...] takes a long period to actually finish crashing > > It dumps core. That takes a long time because firefox tends > to waste huge amounts of memory [...] > One hack I've done when I don't care about actually getting or using a corefile from large programs is to do the following: # rm progname.core # touch progname.core # chflags uchg progname.core Of course, I'd only recommend doing so if one is absolutely certain they don't want a corefile from said program ever again, and will remember to unset that flag should they ever change their mind. -- Bryan
Re: Etnernal & infernal browser woes
Hi Chris, Chris Bennett wrote on Sat, Apr 29, 2017 at 07:10:05AM -0500: > Firefox [...] takes a long period to actually finish crashing It dumps core. That takes a long time because firefox tends to waste huge amounts of memory, and it's favourite pretext for crashing is ENOMEM, see errno(2), so especially at the time when it finally crashes, the core is often huge. schwarze@isnote $ cd schwarze@isnote $ ll *core -rw--- 1 schwarze schwarze 208248 Apr 19 21:03 firefox.core -rw--- 1 schwarze schwarze 4464720 Apr 18 16:48 man.core -rw--- 1 schwarze schwarze 488064 Feb 10 17:45 mandoc.core Yes, that core file over there is 2 GB. Yours, Ingo
Re: Etnernal & infernal browser woes
Hi Jyri, would you mind sharing a dmesg with us, or at least any sort of general info in what environment you're experiencing these kinds of problems? Of course running a current chrome on an old iMac won't yield the same performance as running chrome on a laptop fresh out of the box, but the OS hardly makes any difference there... What I've noticed is that on machines with Skylake and similarly newer graphics hardware, you'll have to disable hardware acceleration in your browsers. This is due to the fact that the inteldrm driver does not yet support such devices, which yields non-working HW acceleration. With that disabled, on my i5 box (dmesg after the signature), I can watch 4k videos on youtube just fine using Chrome. I haven't tried LinkedIn, but Xing seems to work very nicely as well, as do Twitter, all sorts of JS-heavy Medium-style sites and so on. FWIW, performance was also good (not 100% up to Linux, but definitely not as bad as you describe) on my T400 (Low-end Core2Duo, 6GB RAM) and on my R60i (even lower end Core2Duo, but 8GB of RAM). -- Gregor OpenBSD 6.1-current (GENERIC.MP) #20: Wed Apr 19 20:57:30 CEST 2017 g...@sputnik.unobtanium.de:/usr/obj/sys/arch/amd64/compile/GENERIC.MP real mem = 17078013952 (16286MB) avail mem = 16554639360 (15787MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x87ed7000 (44 entries) bios0: vendor American Megatrends Inc. version "5.11" date 08/29/2016 bios0: Notebook N24_25JU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT DBGP DBG2 SSDT UEFI SSDT BGRT DMAR TPM2 ASF! acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP01(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-6200U CPU @ 2.30GHz, 2400.00 MHz 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 24 Hz 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.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.00 MHz 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.00 MHz 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.00 MHz 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP17) acpiprt5 at acpi0: bus -1 (RP18) acpiprt6 at acpi0: bus -1 (RP19) acpiprt7 at acpi0: bus -1 (RP20) acpiprt8 at acpi0: bus 1 (RP01) acpiprt9 at acpi0: bus 2 (RP02) acpiprt10 at acpi0: bus -1 (RP0
Re: Etnernal & infernal browser woes
On Fri, Apr 28, 2017 at 04:32:49PM +0200, Martin Pieuchot wrote: > On 28/04/17(Fri) 16:20, Anders Andersson wrote: > > [...] > > From what I read, it seems as if the problems are mostly from when you > > try websites which are heavy on javascript. > > If javascript was the problem others OSes would suffer as well. > > > Let me butt in as a grumpy > > not-so-old man and point out that there's nothing even remotely > > "secure by default" by even allowing javascript, considering its > > horrible track record. > > So better run javascript on your phone or any other OS, right? > > > Perhaps this is one of the reasons for the disinterest with browser > > performance? > > No. The reason is always the same: somebody has to do the work. It's > not easy, it takes time and we all have other things to do. > I've got to totally disagree that other OS's don't have a big problem with firefox. A while back I bought an old box with 4GB and windows 7 installed. I then took advantage of the free one year upgrade to Windows 10. I have EXACTLY the same problem in Windows as in OpenBSD! Suddenly firefox just crashes. I am right now using 6.1 stable. Firefox has changed in one way for the better. (Thanks to whoever, wherever for that!) It now takes a long period to actually finish crashing and always comes up clean or with a restore. Occasionally the last tab is lost. Which is probably a good thing. Watch top as it very slowly lets firefox crash. Or I should say as firefox crashes itself, not top. :-) Firefox has been reliably crashing for years on many different boxes I have had, so this is nothing new to me. I can't write anything except the most simple javascript, but having "form letter" javascript from 30-35 companies on a website and making all of that interact probably is just not up to the skills of the IT staff (or they would just write the code themselves without any extra junk in it.) As far as YouTube, except for that brief period where they went with Flash, I have had no trouble with watching videos for several years Frankly, trying to get more people to start using OpenBSD is a waste of time. I have tried repeatedly and failed. The correct users of OpenBSD are going to bring themselves to using it. Just like I brought myself. Crash! Chris Bennett
Re: Etnernal & infernal browser woes
On 04/28/17 09:43, trondd wrote: On Fri, April 28, 2017 10:17 am, Fred wrote: I have to agree with David - here I used chrome on a daily basis with a minimum of two chrome windows with at least 4 tabs in each I don't want to get into the conversation, but I thought this was funny. I am a heavy tabs user. I currently have firefox running with 134 tabs open. It's been running since I last updated -current last weekend. That number is actually small because I just went through my tabs and closed a bunch of older or redundent ones. Damn! I thought I was tab happy at 15-20.
Re: Etnernal & infernal browser woes
On 2017-04-28 16:09, Jyri Hovila [iki.fi] wrote: Have you properly configured your user? As far as I know, raising the ulimit and being in the staff class can not possibly be the solution. Ulimit has to be raised unless one wants the browser(s) to constantly crash due to memory exhaustion, and that I havedone. But really: adding a normal user to staff class just to be able to run a browser properly is not in line with the secure by default approach, and should not (in my opinion) affect the performance in any way. The user account I use is, for other reasons, in the wheel group. With chromium or iridium it's not as bad as you have described. Personally I use iridium on a daily basis. They (chromium and iridium) may be slightly faster, but far from a level that could be considered normal. Also, they eat even more memory than Firefox. Browsers are usually optimized by large developer groups to run on Linux, macOS and Windows. Big companies pay a lot of money for that. Browsers are not optimized to run on a wide range of platforms. The work provided by the OpenBSD developer is therefore incredible with respect to making that software runnable on OpenBSD, seriously!!! And I can confirm that website do run very good on OpenBSD.
Re: Etnernal & infernal browser woes
Here are the details, from my everyday setup with no problems in browsing. I use Firefox, Chromium gives me constant core files and looks chopped at interface. I tested many sites, Falsebook and Youtube included, no problems yet. OpenBSD 6.1 (GENERIC.MP) #17: Thu Mar 30 21:37:57 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8029429760 (7657MB) avail mem = 7781404672 (7420MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeebc0 (57 entries) bios0: vendor LENOVO version "9VKT33AUS" date 09/11/2013 bios0: LENOVO 1990RZ2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC TCPA MCFG SLIC MCFG HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) II X2 B26 Processor, 3194.57 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: TSC frequency 3194565970 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) II X2 B26 Processor, 3192.02 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimcfg1 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE2) acpiprt3 at acpi0: bus -1 (PCE3) acpiprt4 at acpi0: bus -1 (PCE4) acpiprt5 at acpi0: bus -1 (PCE5) acpiprt6 at acpi0: bus -1 (PCE6) acpiprt7 at acpi0: bus -1 (PCE7) acpiprt8 at acpi0: bus -1 (PCE9) acpiprt9 at acpi0: bus -1 (PCEA) acpiprt10 at acpi0: bus 2 (P0PC) acpiprt11 at acpi0: bus 3 (PE20) acpiprt12 at acpi0: bus -1 (PE21) acpiprt13 at acpi0: bus -1 (PE22) acpiprt14 at acpi0: bus 4 (PE23) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS "PNP0501" at acpi0 not configured tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e acpibtn0 at acpi0: PWRB cpu0: 3194 MHz: speeds: 3200 2500 1900 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 unknown vendor 0x17aa product 0x9602 rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 4250" rev 0x00 drm0 at radeondrm0 radeondrm0: apic 3 int 18 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 3 int 19, AHCI 1.2 ahci0: port 0: 3.0Gb/s ahci0: port 1: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed naa.50014ee1018094dc sd0: 305245MB, 512 bytes/sector, 625142448 sectors cd0 at scsibus1 targ 1 lun 0: ATAPI 5/cdrom removable ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 3 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling azalia0: codecs: Realtek ALC662 audio0 at azalia0 pcib0 at pci0 dev 20 function 3 "ATI SB700 ISA" rev 0x40 ppb1 at pci0 dev 20 function 4 "ATI SB600 PCI" rev 0x40 pci2 at ppb1 bus 2 ohci2 at pci0 dev 20 function 5 "ATI SB700 USB" rev 0x00: apic 3 int 18, version 1.0, l
Re: Etnernal & infernal browser woes
Whats your hardware? Are you running openbsd 6.1? I had alot of problems with my firefox and chrome a couple of months ago. (OpenBSD 6.0). I couldnt play videos on firefox. Not even youtube. I could play videos on iridium but i had to clear browsing data etc almost every day otherwise the browser was becoming slow. I send a couple emails to misc and some people suggested that the problems were due to my CPU (skylake) I uninstalled openBSD and installed it a couple of weeks ago. Most of the problems are solved although as far as i know OpenBSD still doesnt support skylake. ps. I think openbsd should try to attract desktop users. In the long term it could lead to better hardware support. On 04/28/17 15:18, Jyri Hovila [iki.fi] wrote: > Dear everyone, > > I'm well aware of the bashing potential this message contains, and > kindly ask you not to resort to the usual "offence is the best defence" > strategy. I've been in the scene for a long time (you'll find my first > e-mails to this list almost two decades ago) and I'm well aware of how > operating systems and application software works. I do not need to be > educated about the basics of proper software design, nor the fact that > OpenBSD is developed with different goals in mind than all of the Linux > crap out there. > > With the above disclaimer said, and still knowing the potential for a > war, I must say this: There is not much hope for OpenBSD to ever become > a desktop (or laptop) OS if the nightmarish sluggishness of ALL modern > web browsers can not be solved. Even I, who can easily take long delays > etc. as the cost for having a much more secure system, am about to fry > my poor brain because even the few sites I need to use are just totally > unavailable if I browse them from OpenBSD. > > Everyday problems include (but are not limited to): Waiting tens of > seconds to several minutes for a script intensive site like Facebook > (yes, I actually need to use it) or LinkedIn to load. Having the whole > system slow down to a crawl while the browser is trying to do it's > stuff. Having the browser crash (without any error messages) several > times a day -- after I've first waited 30-60 seconds for it to become > responsive. > > Now I've spent lots and lots of time getting familiar with OpenBSD in > server environments, so I'm pretty well up to date with what I can do > to optimize the OS. I've been following the discussions that were > around six months ago or so, when there was a patch that relieved the > situation so that at least it became possible to finally watch YouTube > videos -- quite an achievement, considering that was in 2016 when > "everyone else" have had their videos running smoothly for at least a > decade. > > I am not blaming anyone here -- I rarely do. I'm not asking anyone to > just fix this issue for me. In fact, I don't even care if it gets fixed > or not; I can always do my browsing on some other platform, even if it > feels insanely stupid. What I am saying is what I already said: Unless > issues like this get solved, OpenBSD will remain pretty much as it is, > which is properly coded, very stable and secure, but (when it comes to > a "normal" user or even an experienced sysadmin) utterly useless when > it comes to doing the stuff everyone does these days -- browsing the > net. Yes, I know many of you are browsing the net with OpenBSD. So am > I. Just to make sure everyone understands what I mean: it is not that > it would be impossible, it is just insanely irritating and slow. > > Now, can anyone provide a relatively clear description of what it is > that make the same browsers (Firefox, Seamonkey, Chrome) that work > fine in Linux, Windows and OS X so ridiculously slow when they are > being run on OpenBSD? > > Peace, please. > > - Jyri >
Re: Etnernal & infernal browser woes
On 04/28/17 09:00, David Coppa wrote: On Fri, Apr 28, 2017 at 2:18 PM, Jyri Hovila [iki.fi] wrote: Dear everyone, With the above disclaimer said, and still knowing the potential for a war, I must say this: There is not much hope for OpenBSD to ever become a desktop (or laptop) OS if the nightmarish sluggishness of ALL modern web browsers can not be solved. Have you properly configured your user? What I usually do is: 1) be sure my user has the "staff" class: # grep dcoppa /etc/master.passwd dcoppa:***:1000:1000:staff:0:0:David Coppa:/home/dcoppa:/bin/ksh 2) I have this at the top of my ~/.profile: ---8<--- # bump limits ulimit -S -d $(ulimit -H -d) ulimit -S -n $(ulimit -H -n) ulimit -S -p $(ulimit -H -p) ulimit -S -s $(ulimit -H -s) ---8<--- With chromium or iridium it's not as bad as you have described. Personally I use iridium on a daily basis. Ciao! David I agree with David. It's manageable. I switched from Firefox to chrome some time ago, along with otter and Iridium--the three browser lifestyle. Firefox causes my wife to snarl all too often, so it isn't the case that FF on Windows is so great. Gone are the days of a 2G web browsing system, mostly. I have a 32G thinkpad and make sure limits are ramped up to absurd limits. Is is slower? Sure, but I'll take that over a faster, diseased system any time. OpenBSD will improve. Windows will not. --STeve Andre'
Re: Etnernal & infernal browser woes
On Fri, April 28, 2017 10:17 am, Fred wrote: > I have to agree with David - here I used chrome on a daily basis with a > minimum of two chrome windows with at least 4 tabs in each I don't want to get into the conversation, but I thought this was funny. I am a heavy tabs user. I currently have firefox running with 134 tabs open. It's been running since I last updated -current last weekend. That number is actually small because I just went through my tabs and closed a bunch of older or redundent ones.
Re: Etnernal & infernal browser woes
"Jyri Hovila [iki.fi]" writes: > Exactly. Which is why I'm asking -- not expecting anyone to give a full > answer. I want to know what people who have been working on this issue > have already found out. I assume there is at least some basic > understanding of why browsers are so incredibly sluggish on OpenBSD. Or > is the clearest picture we have this far simply "because the browsers > have been coded wrong"? Something is wrong on your system. What you say does not correspond to my experience at all. I use Firefox and Chromium from packages all day every day at work and have no problems. I don't use Facebook or LinkedIn but I do use Google Docs, Sheets, Gmail, etc. which are all heavy javascript and they all work fine. At home I run on a 10+ year old MacPro1,1 and browser performance is "acceptable" there also, i.e. similar to what I remember from when the machine ran MacOS. Allan
Re: Etnernal & infernal browser woes
On Fri, 28 Apr 2017, Anders Andersson wrote: > From what I read, it seems as if the problems are mostly from when you > try websites which are heavy on javascript. Let me butt in as a grumpy > not-so-old man and point out that there's nothing even remotely > "secure by default" by even allowing javascript, considering its > horrible track record. > > Perhaps this is one of the reasons for the disinterest with browser > performance? I for one would recommend the following: - Implement a TLS-enabled, cross-platform, secure Gopher server and client - Start pressuring website maintainers and web companies to deliver content and expose services over Gopher - Uninstall all web browsers Seems like wins all around. <3,K.
Re: Etnernal & infernal browser woes
On 28/04/17(Fri) 16:20, Anders Andersson wrote: > [...] > From what I read, it seems as if the problems are mostly from when you > try websites which are heavy on javascript. If javascript was the problem others OSes would suffer as well. > Let me butt in as a grumpy > not-so-old man and point out that there's nothing even remotely > "secure by default" by even allowing javascript, considering its > horrible track record. So better run javascript on your phone or any other OS, right? > Perhaps this is one of the reasons for the disinterest with browser > performance? No. The reason is always the same: somebody has to do the work. It's not easy, it takes time and we all have other things to do.
Re: Etnernal & infernal browser woes
On Fri, Apr 28, 2017 at 4:09 PM, Jyri Hovila [iki.fi] wrote: > >> Have you properly configured your user? > > As far as I know, raising the ulimit and being in the staff class can > not possibly be the solution. Ulimit has to be raised unless one wants > the browser(s) to constantly crash due to memory exhaustion, and that > I havedone. But really: adding a normal user to staff class just to be > able to run a browser properly is not in line with the secure by default > approach, and should not (in my opinion) affect the performance in any > way. >From what I read, it seems as if the problems are mostly from when you try websites which are heavy on javascript. Let me butt in as a grumpy not-so-old man and point out that there's nothing even remotely "secure by default" by even allowing javascript, considering its horrible track record. Perhaps this is one of the reasons for the disinterest with browser performance?
Re: Etnernal & infernal browser woes
On Fri, Apr 28, 2017 at 10:11 AM, Karel Gardas wrote: > On Fri, Apr 28, 2017 at 4:01 PM, Jyri Hovila [iki.fi] > wrote: >>> You ask for peace but your whole post is highly explosive. >> >> No, it is not. >> >> I'm just expressing myself directly -- as us aspergers often do. >> > > Then as a real asperger come with hard evidence supporting your claim > that browsers suck on OpenBSD while fly (or not so suck) on Linux & > Windows. For the same hardware, please. Thanks, -- Raul
Re: Etnernal & infernal browser woes
On 04/28/17 14:00, David Coppa wrote: On Fri, Apr 28, 2017 at 2:18 PM, Jyri Hovila [iki.fi] wrote: Dear everyone, With the above disclaimer said, and still knowing the potential for a war, I must say this: There is not much hope for OpenBSD to ever become a desktop (or laptop) OS if the nightmarish sluggishness of ALL modern web browsers can not be solved. Have you properly configured your user? What I usually do is: 1) be sure my user has the "staff" class: # grep dcoppa /etc/master.passwd dcoppa:***:1000:1000:staff:0:0:David Coppa:/home/dcoppa:/bin/ksh 2) I have this at the top of my ~/.profile: ---8<--- # bump limits ulimit -S -d $(ulimit -H -d) ulimit -S -n $(ulimit -H -n) ulimit -S -p $(ulimit -H -p) ulimit -S -s $(ulimit -H -s) ---8<--- With chromium or iridium it's not as bad as you have described. Personally I use iridium on a daily basis. Ciao! David I have to agree with David - here I used chrome on a daily basis with a minimum of two chrome windows with at least 4 tabs in each - and I do not see the issues you describe, my laptop is coming up for 4 years old, with some info from dmesg shown at [1]. Cheers Fred PS I have been a happy OpenBSD desktop user since July 2001 :~) [1] port:fred ~> dmesg|head -4; dmesg|grep i5-2520 OpenBSD 6.1-current (GENERIC.MP) #67: Mon Apr 17 15:22:46 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17037066240 (16247MB) avail mem = 16516042752 (15750MB) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.23 MHz cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.90 MHz cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.90 MHz cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.90 MHz
Re: Etnernal & infernal browser woes
On Fri, Apr 28, 2017 at 4:01 PM, Jyri Hovila [iki.fi] wrote: >> You ask for peace but your whole post is highly explosive. > > No, it is not. > > I'm just expressing myself directly -- as us aspergers often do. > Then as a real asperger come with hard evidence supporting your claim that browsers suck on OpenBSD while fly (or not so suck) on Linux & Windows.
Re: Etnernal & infernal browser woes
On 28/04/17(Fri) 14:03, Jyri Hovila [iki.fi] wrote: > > If you can answer this question you've already done 50% of the work. > > Exactly. Which is why I'm asking -- not expecting anyone to give a full > answer. I want to know what people who have been working on this issue > have already found out. I assume there is at least some basic > understanding of why browsers are so incredibly sluggish on OpenBSD. Or > is the clearest picture we have this far simply "because the browsers > have been coded wrong"? I know that our libpthread has some suboptimal code which I'm trying to improved. The futex(2) syscall I just committed is the first piece. I also know that the Xorg/Input/Browser communication could be improved.
Re: Etnernal & infernal browser woes
> Have you properly configured your user? As far as I know, raising the ulimit and being in the staff class can not possibly be the solution. Ulimit has to be raised unless one wants the browser(s) to constantly crash due to memory exhaustion, and that I havedone. But really: adding a normal user to staff class just to be able to run a browser properly is not in line with the secure by default approach, and should not (in my opinion) affect the performance in any way. The user account I use is, for other reasons, in the wheel group. > With chromium or iridium it's not as bad as you have described. > Personally I use iridium on a daily basis. They (chromium and iridium) may be slightly faster, but far from a level that could be considered normal. Also, they eat even more memory than Firefox.
Re: Etnernal & infernal browser woes
> If you can answer this question you've already done 50% of the work. Exactly. Which is why I'm asking -- not expecting anyone to give a full answer. I want to know what people who have been working on this issue have already found out. I assume there is at least some basic understanding of why browsers are so incredibly sluggish on OpenBSD. Or is the clearest picture we have this far simply "because the browsers have been coded wrong"? - Jyri
Re: Etnernal & infernal browser woes
> You ask for peace but your whole post is highly explosive. No, it is not. I'm just expressing myself directly -- as us aspergers often do. Should I keep smiling after every sentence and how would that change the actual fact, that using a web browser in OpenBSD is and has for a very long time been virtually impossible? - Jyri
Re: Etnernal & infernal browser woes
On Fri, Apr 28, 2017 at 2:18 PM, Jyri Hovila [iki.fi] wrote: > Dear everyone, > With the above disclaimer said, and still knowing the potential for a > war, I must say this: There is not much hope for OpenBSD to ever become > a desktop (or laptop) OS if the nightmarish sluggishness of ALL modern > web browsers can not be solved. Have you properly configured your user? What I usually do is: 1) be sure my user has the "staff" class: # grep dcoppa /etc/master.passwd dcoppa:***:1000:1000:staff:0:0:David Coppa:/home/dcoppa:/bin/ksh 2) I have this at the top of my ~/.profile: ---8<--- # bump limits ulimit -S -d $(ulimit -H -d) ulimit -S -n $(ulimit -H -n) ulimit -S -p $(ulimit -H -p) ulimit -S -s $(ulimit -H -s) ---8<--- With chromium or iridium it's not as bad as you have described. Personally I use iridium on a daily basis. Ciao! David
Re: Etnernal & infernal browser woes
On 28/04/17(Fri) 12:18, Jyri Hovila [iki.fi] wrote: > [...] > Now, can anyone provide a relatively clear description of what it is > that make the same browsers (Firefox, Seamonkey, Chrome) that work > fine in Linux, Windows and OS X so ridiculously slow when they are > being run on OpenBSD? If you can answer this question you've already done 50% of the work.
Re: Etnernal & infernal browser woes
For testing I would also recommend you to make sure both OSes provide browser with the same amount of RAM (i.e. unlimit your limits in /etc/login.conf) and I would also browse ports email list probably and search for patch limiting amount of RAM which is allocated for firefox javascript engine. I guess this is not the case on Linux so I would recommend to revert this and recompile your own package and then do another comparison.
Re: Etnernal & infernal browser woes
I use OpenBSD because it reliably breaks my code when I have done something wrong. Browsers, meanwhile, seem to do a lot of things wrong (look at what is needed to compile the things, or how people compare browser functionality). I suspect you would be better off getting a $100..$200 chromebook and wiring that up as a peripheral than trying to optimize the OS for browser performance. The hardware skills might also give you insight into other problems, later... That said, if you want to get into the browser implementations and use that to identify OS algorithms which merit work, and then move on to improving that part of the OS - and you can do that without breaking things, and if you can also accomplish something useful using this approach - you have my sincere admiration. Thanks, -- Raul On Fri, Apr 28, 2017 at 8:18 AM, Jyri Hovila [iki.fi] wrote: > Dear everyone, > > I'm well aware of the bashing potential this message contains, and > kindly ask you not to resort to the usual "offence is the best defence" > strategy. I've been in the scene for a long time (you'll find my first > e-mails to this list almost two decades ago) and I'm well aware of how > operating systems and application software works. I do not need to be > educated about the basics of proper software design, nor the fact that > OpenBSD is developed with different goals in mind than all of the Linux > crap out there. > > With the above disclaimer said, and still knowing the potential for a > war, I must say this: There is not much hope for OpenBSD to ever become > a desktop (or laptop) OS if the nightmarish sluggishness of ALL modern > web browsers can not be solved. Even I, who can easily take long delays > etc. as the cost for having a much more secure system, am about to fry > my poor brain because even the few sites I need to use are just totally > unavailable if I browse them from OpenBSD. > > Everyday problems include (but are not limited to): Waiting tens of > seconds to several minutes for a script intensive site like Facebook > (yes, I actually need to use it) or LinkedIn to load. Having the whole > system slow down to a crawl while the browser is trying to do it's > stuff. Having the browser crash (without any error messages) several > times a day -- after I've first waited 30-60 seconds for it to become > responsive. > > Now I've spent lots and lots of time getting familiar with OpenBSD in > server environments, so I'm pretty well up to date with what I can do > to optimize the OS. I've been following the discussions that were > around six months ago or so, when there was a patch that relieved the > situation so that at least it became possible to finally watch YouTube > videos -- quite an achievement, considering that was in 2016 when > "everyone else" have had their videos running smoothly for at least a > decade. > > I am not blaming anyone here -- I rarely do. I'm not asking anyone to > just fix this issue for me. In fact, I don't even care if it gets fixed > or not; I can always do my browsing on some other platform, even if it > feels insanely stupid. What I am saying is what I already said: Unless > issues like this get solved, OpenBSD will remain pretty much as it is, > which is properly coded, very stable and secure, but (when it comes to > a "normal" user or even an experienced sysadmin) utterly useless when > it comes to doing the stuff everyone does these days -- browsing the > net. Yes, I know many of you are browsing the net with OpenBSD. So am > I. Just to make sure everyone understands what I mean: it is not that > it would be impossible, it is just insanely irritating and slow. > > Now, can anyone provide a relatively clear description of what it is > that make the same browsers (Firefox, Seamonkey, Chrome) that work > fine in Linux, Windows and OS X so ridiculously slow when they are > being run on OpenBSD? > > Peace, please. > > - Jyri >
Re: Etnernal & infernal browser woes
On Fri, Apr 28, 2017 at 2:18 PM, Jyri Hovila [iki.fi] wrote: > Now, can anyone provide a relatively clear description of what it is > that make the same browsers (Firefox, Seamonkey, Chrome) that work > fine in Linux, Windows and OS X so ridiculously slow when they are > being run on OpenBSD? > > Peace, please. You ask for peace but your whole post is highly explosive. Honestly I'm still Solaris 11 user and I can assure you that on this OS situation with browsers is even worse than on OpenBSD. In fact I'm really surprised that chromium works on OpenBSD and you may be surprised that I even use that from time to time over ssh tuneled X11 connection to my testing OpenBSD box. So kudos to all the brave hearts who are working on browsers issue for OpenBSD! Back to your topic: if you write "...that work fine in Linux...so ridiculously slow when there are being run on OpenBSD" -- I'm afraid for this you would need to provide some hard real benchmark numbers. To me at least firefox run on Ubuntu 16.04 LTS/14.04 LTS, Solaris 11 and OpenBSD 6.1 more or less sucks in the same way: stupidly high memory consumption, with a ton of tabs open the browser become less and less responsive so the only chance is to exit it and rerun again. So far I blame firefox's javascript compiler since chromium behaves quite differently -- but this is only on OpenBSD/Linux so not comparison with Solaris here... So please provide scientific numbers of let say few page loads/reloads/program run in of your preferred website on Linux and OpenBSD on the exactly same hardware and do that in a verifiable way and post here. Otherwise so far your post is only about psychology and just your feeling...
Etnernal & infernal browser woes
Dear everyone, I'm well aware of the bashing potential this message contains, and kindly ask you not to resort to the usual "offence is the best defence" strategy. I've been in the scene for a long time (you'll find my first e-mails to this list almost two decades ago) and I'm well aware of how operating systems and application software works. I do not need to be educated about the basics of proper software design, nor the fact that OpenBSD is developed with different goals in mind than all of the Linux crap out there. With the above disclaimer said, and still knowing the potential for a war, I must say this: There is not much hope for OpenBSD to ever become a desktop (or laptop) OS if the nightmarish sluggishness of ALL modern web browsers can not be solved. Even I, who can easily take long delays etc. as the cost for having a much more secure system, am about to fry my poor brain because even the few sites I need to use are just totally unavailable if I browse them from OpenBSD. Everyday problems include (but are not limited to): Waiting tens of seconds to several minutes for a script intensive site like Facebook (yes, I actually need to use it) or LinkedIn to load. Having the whole system slow down to a crawl while the browser is trying to do it's stuff. Having the browser crash (without any error messages) several times a day -- after I've first waited 30-60 seconds for it to become responsive. Now I've spent lots and lots of time getting familiar with OpenBSD in server environments, so I'm pretty well up to date with what I can do to optimize the OS. I've been following the discussions that were around six months ago or so, when there was a patch that relieved the situation so that at least it became possible to finally watch YouTube videos -- quite an achievement, considering that was in 2016 when "everyone else" have had their videos running smoothly for at least a decade. I am not blaming anyone here -- I rarely do. I'm not asking anyone to just fix this issue for me. In fact, I don't even care if it gets fixed or not; I can always do my browsing on some other platform, even if it feels insanely stupid. What I am saying is what I already said: Unless issues like this get solved, OpenBSD will remain pretty much as it is, which is properly coded, very stable and secure, but (when it comes to a "normal" user or even an experienced sysadmin) utterly useless when it comes to doing the stuff everyone does these days -- browsing the net. Yes, I know many of you are browsing the net with OpenBSD. So am I. Just to make sure everyone understands what I mean: it is not that it would be impossible, it is just insanely irritating and slow. Now, can anyone provide a relatively clear description of what it is that make the same browsers (Firefox, Seamonkey, Chrome) that work fine in Linux, Windows and OS X so ridiculously slow when they are being run on OpenBSD? Peace, please. - Jyri
