Contributed by merdely on from the its-like-a-half-birthday dept.
Norbert Copones writes:
This news may be late...
OpenBSD turns 4.2-beta:
CVSROOT: /cvs Module name: src Changes by: deraadt at cvs openbsd org 2007/07/25 14:07:28 Modified files: etc/root : root.mail share/mk : sys.mk share/tmac/mdoc: doc-common sys/conf : newvers.sh sys/sys : param.h sys/arch/macppc/stand/tbxidata: bsd.tbxi Log message: crank to 4.2-beta
This news is indeed a bit late. I wanted to wait until full snapshots sets were available for more architectures (mainly i386, since that's what I use). Be sure to check for, download and test 4.2-beta snapshots for your architecture from your favorite mirror.
(Comments are closed)
By Anonymous Coward (212.85.74.34) on
I know I'm gonna test that shiny new sis driver for the soekris :)
Comments
By Anonymous Coward (24.37.242.64) on
>
> I know I'm gonna test that shiny new sis driver for the soekris :)
Same here, and on my WRAP boxes too.
By Jim Razmus II (jim) on http://www.bonetruck.org/
>
> I know I'm gonna test that shiny new sis driver for the soekris :)
Been running it since it was committed. Don't forget all the other network performance improvements too! Great stuff!
By Anonymous Coward (198.175.14.5) on
>
> I know I'm gonna test that shiny new sis driver for the soekris :)
new SIS driver? what are you smoking?
Comments
By Darren Tucker (dtucker) on
>
> new SIS driver? what are you smoking?
It's not a new driver. The interrupt hold-off feature that was already present is now enabled by default, so the chip will wait a small amount of time (1ms) before sending an interrupt when it receives a packet.
This means that if more packets arrive in that 1ms, they can be handled by the same interrupt, so the CPU usage for interrupts goes down (quite significantly, for boxes with lots of traffic and not much CPU like a busy Soekris). The tradeoff is that the average latency goes up, by up to 1 millisecond depending on your traffic patterns.
Comments
By Anonymous Coward (74.244.134.44) on
Is there some way to enable this under 4.1, or disable it under 4.2? I'd like to experiment with it on my -stable box, but i expect i'll want to keep it off. My WRAP routes traffic for a small dsl network, so even at saturation, load averages are around 12%.
Comments
By Darren Tucker (dtucker) on
> Is there some way to enable this under 4.1, or disable it under 4.2?
Edit sys/dev/pci/if_sisreg.h, change the NS_IHR_DELAY define, and build a new kernel.
By sthen (85.158.44.149) on
>
> Is there some way to enable this under 4.1, or disable it under 4.2? I'd like to experiment with it on my -stable box, but i expect i'll want to keep it off. My WRAP routes traffic for a small dsl network, so even at saturation, load averages are around 12%.
With higher packet load, setting IHR should make noticably more difference under 4.2 than it did in 4.1 (randomness used once per interrupt, instead of once per packet).
I bet you can peg the cpu at 100% long before you fill the DSL pipe if your WRAP has to pass small packets.
By Anonymous Coward (198.175.14.193) on
> It's not a new driver. The interrupt hold-off feature that was already present is now enabled by default, so the chip will wait a small amount of time (1ms) before sending an interrupt when it receives a packet.
>
There have been patches available for years. It took some time to discover that the interval had to be set so large to be effective on the soekris.
> This means that if more packets arrive in that 1ms, they can be handled by the same interrupt, so the CPU usage for interrupts goes down (quite significantly, for boxes with lots of traffic and not much CPU like a busy Soekris). The tradeoff is that the average latency goes up, by up to 1 millisecond depending on your traffic patterns.
It is an unfortunate trade-off. It would be nice if the system could just automatically turn the value up and down based on CPU load or whatever.
Comments
By Darrin Chandler (dwc) on http://www.stilyagin.com/darrin/
I think it's a fine trade-off. The code remains simpler than putting in something to tweak values. And at least for my soekris usage (fw/AP for adsl), adding ~1ms latency will not cause any irritation or problem at all. I think this fits well as a sensible setting for the vast majority of uses.
Comments
By Anonymous Coward (198.175.14.193) on
>
> I think it's a fine trade-off. The code remains simpler than putting in something to tweak values. And at least for my soekris usage (fw/AP for adsl), adding ~1ms latency will not cause any irritation or problem at all. I think this fits well as a sensible setting for the vast majority of uses.
While it might be fine at the end of an interleaved ADSL connection, it's not generally desirable.
By jirib (195.212.29.163) on
Comments
By Pierre-Yves Ritschard (pyr) on http://spootnik.org
in the meantime: http://www.openbsd.org/plus.html
Comments
By Anonymous Coward (90.199.221.143) on
>
> in the meantime: http://www.openbsd.org/plus.html
Reading through plus.html, I found this:
"Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."
What does this mean and is this a retrograde step in security? It appears to make these more predictable again.
Comments
By Amir S Mesry (66.23.227.241) starkiller@web-illusions.net on
> >
> > in the meantime: http://www.openbsd.org/plus.html
>
> Reading through plus.html, I found this:
>
> "Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."
>
> What does this mean and is this a retrograde step in security? It appears to make these more predictable again.
I wonder myself, that doesn't sound good, but I haven't read that RFC yet, but monotonic, that word doesn't sound good.
Comments
By Janne Johansson (82.182.176.20) jj@inet6.se on
> > >
> > > in the meantime: http://www.openbsd.org/plus.html
> >
> > Reading through plus.html, I found this:
> >
> > "Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."
> >
> > What does this mean and is this a retrograde step in security? It appears to make these more predictable again.
>
> I wonder myself, that doesn't sound good, but I haven't read that RFC yet, but monotonic, that word doesn't sound good.
I think this magic point slide says this was a change they had wanted to do:
http://www.openbsd.org/papers/asiabsdcon07-network_randomness/mgp00042.html
IIRC, the Basel EuroBSDCon randomness talk also pointed to the RFC 1948 as being the better solution. Also, monotonically means it increases, but not with a fixed amount, so a continously random increment is still a monotonically increasing function.
By Anonymous Coward (206.248.190.11) on
>
> What does this mean and is this a retrograde step in security? It appears to make these more predictable again.
No, it means that they are still random for different hosts, but monotonic from the same host/port combo. So if bad guy tries to connect to get an ISN, it won't help him guess the ISNs of any other connections, as those are all random. But within each host/port tuple the ISNs are monotonic. So if http_load makes thousands of connections to do a load test, each time it reconnects from the same port, it will have a higher ISN and not get stuck waiting for the old connection to be torn down.
By sthen (85.158.44.149) on
faster networks, new device support, new X(7) version, softraid(4), hw.cpuspeed and apmd(8) speed control for MP, new timecounter code on many arch, lots of work on package tools, lots of work on audio, 4-byte ASN support for bgpd(8), new sudo(8) version (please merge /etc/sudoers changes), many other improvements and fixes.
N.B. xbase is now required by many packages/ports since expat has moved there.
Comments
By Gerardo Santana (201.147.183.57) gerardo.santana gmail on
N.B. xbase is now required by many packages/ports since expat has moved there.
I thought for a moment that was crazy. But according to this, expat is part of the base system and the expat you're talking about is another copy.
In summary, I don't understand why many ports would depend on xbase for expat. What ports are they?
Comments
By Devin Smith (drs) on
>
> In summary, I don't understand why many ports would depend on xbase for expat. What ports are they?
>
Subversion or a dependency, at least, requires expat to build. There are probably many others. Building ports without X installed is not really supported anyways.
By sthen (85.158.44.149) on
Not yet, it's not linked into the build (see src/lib/Makefile) because it hasn't been audited. Discussed here: http://marc.info/?l=openbsd-misc&m=118166402911244&w=2.
> In summary, I don't understand why many ports would depend on xbase for expat. What ports are they?
gettext is common, and requires expat.
By sthen (85.158.44.149) on
>
> faster networks, new device support, new X(7) version, softraid(4), hw.cpuspeed and apmd(8) speed control for MP, new timecounter code on many arch, lots of work on package tools, lots of work on audio, 4-byte ASN support for bgpd(8), new sudo(8) version (please merge /etc/sudoers changes), many other improvements and fixes.
>
> N.B. xbase is now required by many packages/ports since expat has moved there.
oh, and how could I have forgotten these?
ifconfig fxp0 10.20.30.40/24 (no more need for 'netmask a.b.c.d')
ifconfig vlan5 vlandev bge1 (stating the vlan tag separately is now is optional)
By Anonymous Coward (63.224.82.202) on
I see the 'make regress' option, but how do I set up my own regression test set? Does anyone have any advice as to where to start?
Comments
By rene (202.63.60.49) on
>
> I see the 'make regress' option, but how do I set up my own regression test set? Does anyone have any advice as to where to start?
man bsd.regress.mk
By Mike Swanson (24.22.214.92) on
Specifically I forced a DPI before with:
DisplaySize 423 318
in the Monitor section
Comments
By Matthieu Herrb (213.41.176.184) on
>
> Specifically I forced a DPI before with:
> DisplaySize 423 318
> in the Monitor section
You'll need to provide more details. Starting with the /var/log/Xorg.0.log file.
Xorg now pays more attention to the DPI computed from the geometry reported by the monitors via DDC/EDID. In the past the resolutions reported by the X server were often completely wrong, leading to wrong choices of font sizes in the applications (either by the programmers or by the users by local customizations). Now that the reported values are more accurated, strange things happen. But the right thing to do is to fix the application configuration to use the proper font size, not to force the X server to report wrong values.
Depending on the toolkit you're using (Gtk+, Qt, Xaw/Motif,...) the ways to configure the default font size are different. But this is another kind of nuisance.
By Anonymous Coward (64.233.230.46) on
Comments
By Gordon Willem Kklok (68.148.17.121) gwk@gwk.ca on
No and 4.2 will not ship with it, it bloats the kernel binary too greatly. Chris Kuethe and I are working on a more elegant solution I would expect it will be available sometime after the 4.2 release.
gwk
By Lawrence Teo (lteo) lteo.openbsd1 ! calyptix.com on http://www.calyptix.com/
I noticed a lot of FFS2-related check-ins and that it is enabled in the GENERIC kernel -- will it be ready for production use in 4.2?
This misc@ post about FFS2 by Otto dated May 20 says there were "some issues" in both kernel and userland; have those issues been resolved?
Comments
By Otto Moerbeek (otto) on http://www.drijf.net
> I noticed a lot of FFS2-related check-ins and that it is enabled in the GENERIC kernel -- will it be ready for production use in 4.2?
>
All know bugs have been fixed, and userland utilities have been modified to handle FFS2 where appropriate.
I'd say FFS2 is ready for serious testing. Only with a lot of testing by a lot op people in different setups I can tell if it's ready for production.
Note that large disk support is not completely done yet.
-Otto