Re: em(4): enable TCP/UDP checksum offload

2012-11-06 Thread mxb
In my case, it is a CARP backup(master will be upgraded soon) rolling ospf on top of gre on top of ipsec, running npppd, and daily NAT/RDR for about 100 clients. On 6 nov 2012, at 21:31, Stuart Henderson wrote: > For people who are testing checksum-offload-enabling diffs, it would > help if you

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Antoine Jacoutot
On Wed, Nov 07, 2012 at 08:58:55AM +1100, Brett wrote: > Not to disparage the hard work by Antoine and others on Gnome and KDE, but if > upstream are going to entwine their code with non-standard OSs, then why > bother with them? That _is_ precisely the question I asked on GNOME lists. I'm not r

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Vadim Zhukov
07.11.2012 2:06 пользователь "Brett" написал: > > On Tue, 6 Nov 2012 13:38:32 +0100 > Marc Espie wrote: > > > Basically, we have a pattern, mostly observed with kde (and a bit with > > gnome) which is really harmful for us. > > > They occupy a few people in our team FULLTIME wi

Re: dc(1) exp improvements

2012-11-06 Thread Otto Moerbeek
On Tue, Nov 06, 2012 at 04:57:20PM -0430, Andres Perera wrote: > On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek wrote: > > Hi, > > > > And here's a diff to repair ^, whcih now produces correct results for > > things like > > > > (dc)0.1 _1 ^p > > or > > (bc)0.1 ^ -1 > > > > The diff is aga

Re: [cwm] tab completion

2012-11-06 Thread Alexander Polakov
* Alexander Polakov [121107 02:20]: > I think this one is ready for wider testing. > > How to use: hit tab in exec menu to complete the command (start > with / if you want something not in $PATH). When you're ready, > hit tab again. This will open "file menu", which can be used to > complete fi

Re: heads-up: on -current, -static may not be as static as you think

2012-11-06 Thread Pascal Stumpf
On Tue, 6 Nov 2012 21:49:12 +, Stuart Henderson wrote: > On 2012/11/05 13:57, Marc Espie wrote: > > > > This stuff is totally a moving target, it is probably going to change in > > the future. > > > > > > Note that there are very good reasons to prefer pie binaries in MOST cases, > > includi

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Amit Kulkarni
>> Basically, we have a pattern, mostly observed with kde (and a bit with >> gnome) which is really harmful for us. > >> They occupy a few people in our team FULLTIME with respect to gnome, they're >> the reason we still DON'T have a full kde4 in our tree (hopefully to be >> addressed shortly), and

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Brett
On Tue, 6 Nov 2012 13:38:32 +0100 Marc Espie wrote: > Basically, we have a pattern, mostly observed with kde (and a bit with > gnome) which is really harmful for us. > They occupy a few people in our team FULLTIME with respect to gnome, they're > the reason we still DON'T have a full kde4 in our

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Daniel Bolgheroni
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: > > It's also quickly turning Posix and Unix into a travesty: either you have > the linux goodies, or you don't. And if you don't, you can forget anything > modern... This IS the main problem.

[cwm] tab completion

2012-11-06 Thread Alexander Polakov
I think this one is ready for wider testing. How to use: hit tab in exec menu to complete the command (start with / if you want something not in $PATH). When you're ready, hit tab again. This will open "file menu", which can be used to complete file argument. Completion works for other menus as

Re: heads-up: on -current, -static may not be as static as you think

2012-11-06 Thread Stuart Henderson
On 2012/11/05 13:57, Marc Espie wrote: > > This stuff is totally a moving target, it is probably going to change in > the future. > > > Note that there are very good reasons to prefer pie binaries in MOST cases, > including for 'static' binaries... > > So, as far as the chroot way goes, the mo

Re: dc(1) exp improvements

2012-11-06 Thread Andres Perera
On Tue, Nov 6, 2012 at 3:27 PM, Otto Moerbeek wrote: > Hi, > > And here's a diff to repair ^, whcih now produces correct results for > things like > > (dc)0.1 _1 ^p > or > (bc)0.1 ^ -1 > > The diff is against very current, so beware. i've lightly tested it against gnu bc and it works i d

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Kevin Chadwick
On Tue, 6 Nov 2012 21:39:42 +0100 Marc Espie wrote: > I don't have ANY KIND OF SOLUTION. Certainly couldn't for that general problem without likely being the problem. As I've said before I'm not a Gnome fan and far from a Gnome 3 fan however the reason udisks dropped many gnome features like au

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Marc Espie
On Tue, Nov 06, 2012 at 08:42:48PM +0100, TAKRIZ wrote: > I hear you on this, thinking about it I'd like to ask you what would be a > solution to this rather recurrent issue/problem we're facing from the Linux > side of the spectrum? What would be a solution or a framework that could > somehow nega

Re: em(4): enable TCP/UDP checksum offload

2012-11-06 Thread Stuart Henderson
For people who are testing checksum-offload-enabling diffs, it would help if you could say what sort of things have tested. Things like fragments/NFS are far more likely to exercise bugs in the hardware than standard web browsing.

dc(1) exp improvements

2012-11-06 Thread Otto Moerbeek
Hi, And here's a diff to repair ^, whcih now produces correct results for things like (dc)0.1 _1 ^p or (bc)0.1 ^ -1 The diff is against very current, so beware. Please test. I have some regress test updates for dc as well. t9 turns out to be a wrong test (computation of 2.1 ^ 500). Th

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread TAKRIZ
I hear you on this, thinking about it I'd like to ask you what would be a solution to this rather recurrent issue/problem we're facing from the Linux side of the spectrum? What would be a solution or a framework that could somehow negate most of the effects of this particular problem?. I grew up ti

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Jiri B
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: > It could well end up the other way around, with systemd dying. It does > far too much and most of which is pointless in order to gain traction > but also limiting it's scope and so success unless it is forked or > radically changed o

Re: [cwm 1/1] Add a menu to search and call internal functions.

2012-11-06 Thread Kent R. Spillner
Hey, dude- > I too would prefer to use nitems, to be consistent with the rest of the > code. Also reduces the number of gratuitous changes, and of course the > size of the diff. I chose the guard element approach because it leads to the smallest diff, but I can move the definition of name_to_kbf

Re: em(4): enable TCP/UDP checksum offload

2012-11-06 Thread mxb
tested on em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x05: msi, address 00:25:90:27:da:51 em1 at pci6 dev 0 function 0 "Intel PRO/1000 MT (82574L)" rev 0x00: msi, address 00:25:90:27:da:50 hwfeatures=36 on both On 4 nov 2012, at 15:52, Brad Smith wrote: > On Sat, Nov 03, 2012 at 09:49

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Tomas Bodzar
On Tue, Nov 6, 2012 at 1:43 PM, Antoine Jacoutot wrote: > On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: >> Basically, we have a pattern, mostly observed with kde (and a bit with >> gnome) which is really harmful for us. >> >> Those vendors say "we're not in the distribution business,

Re: [cwm 1/1] Add a menu to search and call internal functions.

2012-11-06 Thread Kent R. Spillner
Hey, dude- > Can you please provide a unified cvs diff? The first patches I sent last week were cvs diffs, but I saw quilt was recently added to ports to I switched to using it to manage all of the patches (I have a few other things I'm working on, too, which I haven't sent out for review yet).

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Miod Vallat
> From your point of view everybody > is nice to you ;-) I'm not! Miod

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Lars von den Driesch
Hi Marc On Tue, Nov 6, 2012 at 5:16 PM, Marc Espie wrote: > So, hey, do whatever you want with that. Apart from the proverbial > curmudgeons, > there are LOTS of nice people in the OpenBSD developer community, who are > fairly open to a lot of stuff... I wouldn't be there if that weren't the >

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Lars von den Driesch
On Tue, Nov 6, 2012 at 5:10 PM, Peter Hessler wrote: > On 2012 Nov 06 (Tue) at 16:45:17 +0100 (+0100), Lars von den Driesch wrote: > > This is exactly what happened in Linux-land, and brought us to this > place in the first point. I know :-) And I understand this - but in this situation I be

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Marc Espie
On Tue, Nov 06, 2012 at 04:45:17PM +0100, Lars von den Driesch wrote: > On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie wrote: > > > > > This is a mindset we need to fight, and this has to be a grass-roots > > movement. > > > > I agree with most of your statement, but for a grass-root movement you >

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Peter Hessler
On 2012 Nov 06 (Tue) at 16:45:17 +0100 (+0100), Lars von den Driesch wrote: :If you want people to gain traction you will need to :reduce some standards... This is exactly what happened in Linux-land, and brought us to this place in the first point. -- Math is like love -- a simple idea but

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Lars von den Driesch
On Tue, Nov 6, 2012 at 1:38 PM, Marc Espie wrote: > > This is a mindset we need to fight, and this has to be a grass-roots > movement. > I agree with most of your statement, but for a grass-root movement you will need to attract a lot of people. Otherwise you will move exactly *nothing*. And let

Re: [cwm 1/1] Add a menu to search and call internal functions.

2012-11-06 Thread Okan Demirmen
I haven't caught-up, nor reviewed anything else yet, but comments inline: On Tue 2012.11.06 at 16:11 +0100, Thomas Pfaff wrote: > Can you please provide a unified cvs diff? 'cvs diff -uNp' is best... > [...] > > for (iter = 0; iter < nitems(name_to_kbfunc); iter++) { > > - if (strc

Re: [cwm 1/1] Add a menu to search and call internal functions.

2012-11-06 Thread Thomas Pfaff
Can you please provide a unified cvs diff? I've not tried this patch but I have some comments (see below). > Useful for those times you want to use an unbound function, but even > when the function is bound to something you haven't memorized yet it > can be faster than lookup up the keybinding in

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Stefan Sperling
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: > in some cases, you even have some people, who are PAID by some vendors, > agressively pushing GRATUITOUS, non compatible changes. I won't say names, > but you guys can fill the blanks in. I'll fill in redhat, making upstream support eve

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Christiano F. Haesbaert
Lets be honest, half the problem goes away if Lennart stops "hacking".

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Gregory Edigarov
On 11/06/2012 03:45 PM, Marc Espie wrote: On Tue, Nov 06, 2012 at 01:43:50PM +0100, Antoine Jacoutot wrote: One could answer you that the BSD community is not involved enough with upstream. 99% of the development is done on Linux by developers using Linux -- if you want that to change, some !l

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Marc Espie
On Tue, Nov 06, 2012 at 01:43:50PM +0100, Antoine Jacoutot wrote: > One could answer you that the BSD community is not involved enough with > upstream. 99% of the development is done on Linux by developers using Linux > -- if you want that to change, some !linux people should get involved in > o

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Marc Espie
On Tue, Nov 06, 2012 at 01:15:04PM +, Kevin Chadwick wrote: > > Rather than spending time on these, are trinity and mate etc.. worth > looking at? I'm pretty sure trinity is worth looking at, haven't had nearly enough time to do so, especially since it's yet another build system you need to d

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Arto Jonsson
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: > Basically, we have a pattern, mostly observed with kde (and a bit with > gnome) which is really harmful for us. > > ... Relevant LWN.net article: http://lwn.net/Articles/520892/

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Kevin Chadwick
Apparently branding as a priority by some devs, is a major reason. I can't believe a Gnome dev said he hadn't heard of XFCE to a transmission dev! http://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/ > in some cases, you even have some people, who are PAID by some vendors, > a

Re: upstream vendors and why they can be really harmful

2012-11-06 Thread Antoine Jacoutot
On Tue, Nov 06, 2012 at 01:38:32PM +0100, Marc Espie wrote: > Basically, we have a pattern, mostly observed with kde (and a bit with > gnome) which is really harmful for us. > > Those vendors say "we're not in the distribution business, distribution > problems will be handled by OS vendors. We ca

upstream vendors and why they can be really harmful

2012-11-06 Thread Marc Espie
Basically, we have a pattern, mostly observed with kde (and a bit with gnome) which is really harmful for us. Those vendors say "we're not in the distribution business, distribution problems will be handled by OS vendors. We can break compatibility to advance, and not think about it, this is not

Re: athn@usb: fixup detach panic

2012-11-06 Thread Stefan Sperling
On Tue, Nov 06, 2012 at 11:32:19AM +0100, Mike Belopuhov wrote: > attach fails early in case there's no firmware, but > athn_detach does ieee80211_ifdetach and if_detach > regardless of whether ifnet part got setup correctly > leading to a free of an unallocated memory and a > panic. > > the follo

athn@usb: fixup detach panic

2012-11-06 Thread Mike Belopuhov
attach fails early in case there's no firmware, but athn_detach does ieee80211_ifdetach and if_detach regardless of whether ifnet part got setup correctly leading to a free of an unallocated memory and a panic. the following diff follows an established practice in the other drivers and fixes the p

vge(4): Add flow control support

2012-11-06 Thread Brad Smith
Here is a diff to add flow control support to vge(4). Tested with.. vge0 at pci2 dev 4 function 0 "VIA VT612x" rev 0x11 ciphy0 at vge0 phy 1: CS8201 10/100/1000TX PHY, rev. 1 OK? Index: if_vge.c === RCS file: /home/cvs/src/sys/dev/

jme(4): enable TCP/UDP checksum offload

2012-11-06 Thread Brad Smith
Here is a diff to enable the checksum offload support for jme(4). Tested with.. jme0 at pci4 dev 0 function 0 "JMicron JMC250" rev 0x11 Index: if_jme.c === RCS file: /home/cvs/src/sys/dev/pci/if_jme.c,v retrieving revision 1.28 diff

stge(4): enable TCP/UDP checksum offload

2012-11-06 Thread Brad Smith
Here is a diff to enable the checksum offload support for stge(4). Tested with.. stge0 at pci0 dev 3 function 0 "D-Link DGE-550T" rev 0x07 Index: if_stge.c === RCS file: /home/cvs/src/sys/dev/pci/if_stge.c,v retrieving revision 1.54