Re: Etnernal & infernal browser woes

2017-04-28 Thread Edgar Pettijohn



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.



What's the purpose of the VXLAN IP Address?

2017-04-28 Thread rizz2pro .
Hi,

Can anyone tell me what the purpose of the hostname.vxlan files
needing to have an IP address?

If I start my bridge without an IP on my vxlan interface, it doesn't
work. However, If I put an IP on the vxlan interface, bring up the
bridge and then "ifconfig vxlan1 delete" to remove the IP from the
vxlan interface, everything continues to work.

Thanks for any insight in advance, have a good weekend.



Re: OpenLDAP and filesystem permission

2017-04-28 Thread Marcus MERIGHI
hello, 

ros...@ghweb.de (Markus Rosjat), 2017.04.27 (Thu) 12:59 (CEST):
> I basically want to know if its okay to set permission on a file or
> directory for a LDAP user even if there is no local user on this machine.
> 
> Hope someone understand what I mean, background is setting up a mailserver
> with usermanagement over LDAP. The naive way for me would be creating a
> local user with the same name like the one in the LDAP db. So I can set the
> permissions on the Maildirs for the local user.
> This leaves me with maintaining LDAP and Local user but if I could just use
> only the LDAP user this would be nice ( it works at least in my test env)
> but is this considerd secure or should I stick with the LDAP+local User
> approach?

have you seen ypldap(8), might help with your ldap<->local problem by
going yp(8).

Marcus

> regards
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> K??nigsbr??cker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte pr??fen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
> you print it, think about your responsibility and commitment to the
> ENVIRONMENT
> 
> 
> !DSPAM:5901cf1b9705213319748!
> 



Re: Etnernal & infernal browser woes

2017-04-28 Thread David Lowe

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: iwm0 problems

2017-04-28 Thread Stefan Sperling
On Fri, Apr 28, 2017 at 06:56:08PM +0300, G wrote:
> I should add that video on 6.1 works fine when im connected to ethernet
> So i guess the problem is with the iwm driver

It could be a driver bug but based on the information I have so far there
is nothing I can do but wait and see if somebody else reports the same
problem with an 3165 device. I have no such device to check myself.

Wifi is complicated. I am getting about 1 or 2 problem reports like yours
per week. Most of them turn out to not be driver bugs but general problems
with people's wifi setups.
The most recent one was that Lenovo had mistakenly wired up one of the WAN
antennas for 3g devices to the WLAN device in an x230 laptop they sold, and
that caused a bad signal and poor performance (I did not figure that out,
but gladly the person who reported the problem eventually found out).

Based on such experiences I have become careful about jumping to conclusions
about what must be a wifi driver bug. I certainly will not spend time
debugging a driver unless I get some very solid clues that point towards
a driver bug.

As far as I can tell from your report, your machine needs a BIOS update
or has broken ACPI or has some other hardware issue. Who knows.



Re: iwm0 problems

2017-04-28 Thread G
I should add that video on 6.1 works fine when im connected to ethernet
So i guess the problem is with the iwm driver


On 04/28/17 18:52, G wrote:
> No dmesg didnt have any messages on OpenBSD 6.0 back then. But wifi was
> really slow and couldnt download with more than 500kbit/sec
> Now with wifi i get 4.81Mbps download 0.58Mbps upload 240 ms ping
> and with ethernet i get 10.79Mbps download 0.80Mpbs upload 115 ms ping
> 
> 
> 
> On 04/28/17 18:36, Stefan Sperling wrote:
>> On Fri, Apr 28, 2017 at 03:56:04PM +0300, G wrote:
>>> Hello.
>>> When i connect my laptop using wifi (iwm0) my browser freeze for a
>>> couple of seconds from time to time.
>>> Also when i start play videos the video freeze after a couple of seconds.
>>>
>>> My dmesg gives me
>>>
>>> device timeout
>>> iwm0: fatal firmware error
>>> iwm0: device timeout
>>> iwm0: device timeout
>>
>>> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x99, 
>>> msi
>>
>> Support for AC 3165 chips was already present in 6.0.
>> Does the same problem happen in OpenBSD 6.0?
>>
>> Given that video also has issues there may be an underlying problem that
>> prevents the iwm driver from working properly. As far as I know 3165 chips
>> are working in general. I do not have such a chip test with, though.
>>
> 



Re: iwm0 problems

2017-04-28 Thread G
No dmesg didnt have any messages on OpenBSD 6.0 back then. But wifi was
really slow and couldnt download with more than 500kbit/sec
Now with wifi i get 4.81Mbps download 0.58Mbps upload 240 ms ping
and with ethernet i get 10.79Mbps download 0.80Mpbs upload 115 ms ping



On 04/28/17 18:36, Stefan Sperling wrote:
> On Fri, Apr 28, 2017 at 03:56:04PM +0300, G wrote:
>> Hello.
>> When i connect my laptop using wifi (iwm0) my browser freeze for a
>> couple of seconds from time to time.
>> Also when i start play videos the video freeze after a couple of seconds.
>>
>> My dmesg gives me
>>
>> device timeout
>> iwm0: fatal firmware error
>> iwm0: device timeout
>> iwm0: device timeout
> 
>> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x99, 
>> msi
> 
> Support for AC 3165 chips was already present in 6.0.
> Does the same problem happen in OpenBSD 6.0?
> 
> Given that video also has issues there may be an underlying problem that
> prevents the iwm driver from working properly. As far as I know 3165 chips
> are working in general. I do not have such a chip test with, though.
> 



Re: iwm0 problems

2017-04-28 Thread Stefan Sperling
On Fri, Apr 28, 2017 at 03:56:04PM +0300, G wrote:
> Hello.
> When i connect my laptop using wifi (iwm0) my browser freeze for a
> couple of seconds from time to time.
> Also when i start play videos the video freeze after a couple of seconds.
> 
> My dmesg gives me
> 
> device timeout
> iwm0: fatal firmware error
> iwm0: device timeout
> iwm0: device timeout

> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x99, msi

Support for AC 3165 chips was already present in 6.0.
Does the same problem happen in OpenBSD 6.0?

Given that video also has issues there may be an underlying problem that
prevents the iwm driver from working properly. As far as I know 3165 chips
are working in general. I do not have such a chip test with, though.



Re: Etnernal & infernal browser woes

2017-04-28 Thread Mihai Popescu
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

2017-04-28 Thread G
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

2017-04-28 Thread STeve Andre'



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

2017-04-28 Thread trondd
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

2017-04-28 Thread Allan Streib
"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

2017-04-28 Thread Kamil Cholewiński
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

2017-04-28 Thread Martin Pieuchot
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

2017-04-28 Thread Anders Andersson
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

2017-04-28 Thread Raul Miller
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

2017-04-28 Thread Fred

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

2017-04-28 Thread Karel Gardas
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

2017-04-28 Thread Martin Pieuchot
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

2017-04-28 Thread Jyri Hovila [iki.fi]

> 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

2017-04-28 Thread Jyri Hovila [iki.fi]
> 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

2017-04-28 Thread Jyri Hovila [iki.fi]
> 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

2017-04-28 Thread David Coppa
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

2017-04-28 Thread Martin Pieuchot
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.



iwm0 problems

2017-04-28 Thread G
Hello.
When i connect my laptop using wifi (iwm0) my browser freeze for a
couple of seconds from time to time.
Also when i start play videos the video freeze after a couple of seconds.

My dmesg gives me

device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
wsmouse1 detached
ums0 detached
uhidev0 detached
uhidev0 at uhub0 port 3 configuration 1 interface 0 "vendor 0x USB
OPTICAL MOUSE" rev 1.10/1.00 addr 5
uhidev0: iclass 3/1, 1 report id
ums0 at uhidev0 reportid 1: 3 buttons, Z dir
wsmouse1 at ums0 mux 0
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: device timeout
iwm0: device timeout
iwm0: fatal firmware error
iwm0: devi

Re: Etnernal & infernal browser woes

2017-04-28 Thread Karel Gardas
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

2017-04-28 Thread Raul Miller
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

2017-04-28 Thread Karel Gardas
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

2017-04-28 Thread Jyri Hovila [iki.fi]
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: relayd splice timeout

2017-04-28 Thread Markus Rosjat


 Ursprüngliche Nachricht 
Von: Hiltjo Posthuma  
Datum: 28.04.17  11:34  (GMT+01:00) 
An: Markus Rosjat  
Cc: misc@openbsd.org 
Betreff: Re: relayd splice timeout 

On Thu, Apr 27, 2017 at 07:11:56PM +0200, Markus Rosjat wrote:
> Hi there,
> 
> I was playing arround wit relayd just to get a feeling for it. So I started
> with relaying a ssh connection to a machine behind my gateway.
> 
> But it seems there is some kind of config value I miss because after like  8
> minutes the open ssh connection gets suddenly closed. Running relayd in
> foreground shows a splice timeout.
> 
> So question is, can I and if so where can I adjust the timeout value.
> 
> SSH might be a bad example for relayd use but its the easiest starting point
> thought. Better to discover stuff befor a setup gets more complicated.
> 
> Regards
> 
> -- 
> Markus Rosjat    fon: +49 351 8107223    mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> print it, think about your responsibility and commitment to the ENVIRONMENT
> 

Hey,

Have you tried "session timeout"?

They can be used for relays and redirections.

See the RELAYS and REDIRECTIONS section in relayd.conf(5).

-- 
Kind regards,
Hiltjo


Hi,
I'll will give it a try and check if it makes a difference. 
Thanks for the hint

Re: relayd splice timeout

2017-04-28 Thread Hiltjo Posthuma
On Thu, Apr 27, 2017 at 07:11:56PM +0200, Markus Rosjat wrote:
> Hi there,
> 
> I was playing arround wit relayd just to get a feeling for it. So I started
> with relaying a ssh connection to a machine behind my gateway.
> 
> But it seems there is some kind of config value I miss because after like  8
> minutes the open ssh connection gets suddenly closed. Running relayd in
> foreground shows a splice timeout.
> 
> So question is, can I and if so where can I adjust the timeout value.
> 
> SSH might be a bad example for relayd use but its the easiest starting point
> thought. Better to discover stuff befor a setup gets more complicated.
> 
> Regards
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> print it, think about your responsibility and commitment to the ENVIRONMENT
> 

Hey,

Have you tried "session timeout"?

They can be used for relays and redirections.

See the RELAYS and REDIRECTIONS section in relayd.conf(5).

-- 
Kind regards,
Hiltjo



Re: Need some pointers regarding ELF

2017-04-28 Thread Peter J. Philipp
One quick note.  The sources here are against 6.1 not -current, in order to
compile against -current I'M sure it'll have to be put up to speed.

Regards,
-peter