Contributed by pitrh on from the puffyistic-surströmming dept.
Back in February when Þórður Björnson (thib@) exclaimed 'roadtrip!' to me suggesting I fetch his bunch of lab machines at Slackathon2011 to host them at our Oslo datacenter; it sounded like a good idea. After 8 tedious hours behind the wheel I was not so sure, but at least I'd get to hear the devs. etc. speak about their work while I was there. What with loading the gear, work calls and dinner preparations I missed a few of the presentations, but this is a summary of that which I remember from those I heard:
Nick Marriott (nicm@) spoke about TMUX, with a short history including that it was born out of a desire to modify screen; but since the code was very untidy & (then) unmaintained, it was easier to start from scratch. Screen's GPL license was also a contributory factor. More recently OSX's iterm app may soon incorporate tmux functionality. nicm@ stresses that he's always open to new suggestions especially if accompanied by diffs, but that bloat due to features like serial line I/O is not going to happen.Thanks to Pete for the writeup, and to the Slackathon organizers for making slackathon happen, from the Undeadly editors team!
Henning Brauer (henning@) fought with magicpoint to bring us a trip through 10 years of pf's very busy history. Q&A was of course punctuated by the usual "whats the best hardware/cpu/bus/nic/kernel/shell/editor for pf'ing ?" The devs. consensus being buy some new 'proper' server brand h/w and you're very unlikely to ever experience problems. In short, don't worry, some big names in networking/security with even bigger budgets still choose to use the code and are pleased with the results. If you do experience performance issues then you can test alternatives yourself and subsequently enlighten others. Other gems included the immortal debate on first-match ruleset processing, although it's not possible to change pf to that style of processing (arguably beneficial to performance), a global knob could be provided as an alternative to adding 'quick' to every line. The biggest hurdle is what would you name the opposite of 'quick'? since it's clearly not 'slow'.
Anders Magnusson (ragge@) gave a very interesting walk through PCC compiler creation/updating. He stresses that he's not really interested in inter-o/s politics or licenses. On the other hand, he likes code to be clean, simple, bug-free, fast and extensible. Back in april PCC v1 was released, and he now has a few more issues to address before v1.1 is released. Several optimisations have been implemented since he last compared the execution times of complied binaries between PCC & GCC, however PCC probably complies code around 20-30 times faster than GCC. A quick demo proved cross compiling is as easy as specifying --target=whatever-else . When discussing gcc compatability ragge@ mentioned that this is one of the more troublesome areas, and that infact OpenBSD is the worst offender of his supported platforms (including Net/FreeBSD & Linux) for using gcc specifics (cue horrified look on some devs. faces). Apparently there are only two (make and apache ?) in-tree areas that now stand before a fully PCC compilable source tree.
Daniel Stenberg of cURL fame illustrated to us that the headache of interfacing with OpenSSL (famous for poor api & documentation) was matched only by the ocean of obscure alternatives. I personally have to thank him for his creation since it's the only command line app I know which can do FTP uploads via a HTTP proxy (e.g. squid), making corporate security compliance possible in some arenas. And of course the permissive license. Daniel discussed the lack of standard SSL APIs, and the (bad) effects it has had on app security, but unfortunately lack of time/funding prevents him from crusading that cause.
Lastly Jonathan Gray (jsg@) summed up recent significant changes in OpenBSD. See the project's Daily page for details, but highlights for network admins include the npppd/PIPEX completion for user connectivity aggregation, and NAT[64]+ pf functionality (editor's note:unfortunately NAT64 did not make it into the upcoming OpenBSD 5.0 release). Note of course that even the utterance of the dreaded IPvSH*T was enough to start certain other devs. rambling about the all new IPv0 recently observed in the wild.
Shortly afterwards the tenth anniversary celebrations of pf began in the traditional style in the Bishop's Arms.
Obviously great thanks goes to Janne Johansson (jj@) and his team for putting the event on, including Maria's 'cafe' and Simon's stew, but definitely not the aircon guy…
(Comments are closed)
By Paul Irofti (bulibuta) on gopher://sdf.lonestar.org/1/users/bulibuta
When did he say that? I highly doubt he said that, I was there and don't remember him saying that. This looks like guess work and makes this article look bad.
I actually remember him saying that at one test, run some time ago, pcc did better than gcc at some tests and worse at others. And he said that in a very humble way when asked by the audience.
Comments
By David T. Harris (knightblader) on http://www.cs.ucf.edu/~da465415/
>
> When did he say that? I highly doubt he said that, I was there and don't remember him saying that. This looks like guess work and makes this article look bad.
>
> I actually remember him saying that at one test, run some time ago, pcc did better than gcc at some tests and worse at others. And he said that in a very humble way when asked by the audience.
Has anyone done any benchmarks comparing PCC to GCC?
By wim wauters (unisoftdesign) on www.unisoftdesign.co.uk
>
> When did he say that? I highly doubt he said that, I was there and don't remember him saying that. This looks like guess work and makes this article look bad.
>
To me, that looks a statement about compiling the (core/kernel?) OpenBSD source code. Yes, it would be better to add some info to that statement, but it should come as no surprise to anyone that OpenBSD's internal compiler is very good at compiling OpenBSD :-)
Keep the articles coming, though!
By Lennie (Lennie) on