Reini Urban will give a talk at YAPC::Europe 2012 described as
address-sanitizer (aka ASan) is a memory error detector for C/C++, superior to valgrind. It comes with clang.
It finds:
* Use after free
* Out-of-bounds accesses to
** heap
** stack
** globals
* Use after return
It is very fast. The average slowdown of the instrumented program is ~2x, it's ~10-20x faster than valgrind. DEBUGGING builds should just use it.
The tool works on x86 Linux and Mac.
How it works, what errors it finds, some tools.
I rarely rant on this board, and I try not to rant whenever I can stop myself. With that in mind I am going to try to phrase this rant as a question and see if people agree with me or not. Note that for the remainder of this post I am going to be speaking in broad generalities and I know that there will be notable exceptions. Ok here goes.
This started while responding to a post from awncorp, but it really isn’t the same topic. I want to know, is the focus on “user-friendly” or “ease of use” or “one-click” hurting users in the end? Not even from a teaching standpoint, but actually in their day-to-day computing? My assertion is that some things in computing are inherently difficult, and that they should be, and people might to well to embrace that.
At $work, our flagship application was recently audited for potential security issues. One of the items which raised a red flag was the fact that we weren't dealing with the threat of CSRF (Cross Site Request Forgery). The solution which we decided to implement was to add a CSRF token to all POST requests. This token should only be known to the app and the end user. Passing it along with a POST request gives some measure of assurance that a POST by the user is intentional and so can help to reduce the risk of CSRF.
I had to remove the perl frontend for mosh, being replaced by a C++ script.
perl IO::Pty on cygwin and various platforms did not work good enough.
mosh was one of the most prominent users of perl.
Accidently some tweet from today says: ": But for some things, #Perl just isn't the optimal choice. (yet) :-) -Larry Wall in 199702221943.LAA20388@wall.org #iFollowBack"
This is not a fork, it's a sanctioned pre-release of 1.3 with a bad version number. It was decided for the next major mosh release 1.3 to use the C++ wrapper by Peter. The new c++ wrapper is also used in the android mosh opkg version.
mosh is awsome, 1.3 will be even more awsome.
PS: If you don't know that: I am the cygwin maintainer of perl, and toddr the IO::Pty maintainer sits next to me. It's not my personal decision to remove perl, but I just
had to do that also for my port.
Matt S Trout will give a talk at YAPC::Europe 2012 described as
A tale of systems introspection, service inference and parallel computing - how we used the Tak systems automation framework to help track a customer's infrastructure.
Just noticed from my CPAN feed that Moo 1.000000 is released. Yay. Also wishing mst to reach 1.000000 in recovery soon.
(I remember about a year ago when only my dists were the ones mainly using Moo. It's nice to see the list has grown. Not far behind Mouse and Moose, really.
On my laptop I use perlbrew to keep my system perl separate from my development perl. But I also develop various Perl projects with different dependencies, and would like to keep those dependencies separate if possible. Using a separate perlbrew perl for each project as well would be overkill in terms of diskspace, CPU energy and time so I thought local::lib might be useful.
If I install dependencies for a particular project using "cpanm -l extlib $MODULE" in the top level directory, the function below will automatically setup local::lib for that location when I change into that directory, and unset it when I change out. I use a test for the existence of a "extlib" directory and a Makefile.PL file because that is what I consistently have.
The talk & tutorial evaluations have now been sent out to all the speakers from YAPC::NA 2012 in Madison. If you were a speaker and haven't received your evaluation, please check your spam folder first. If you still can't find it, email me and I'll resend you a copy. However, please note that I will be offline for a week from this Friday, so you may have to wait until i return to get your feedback.
Many thanks to all the attendees who submitted 566 individual talk evaluations. Having read through them all in order to ensure no unpleasantness appeared, I was quite impressed with some of the great comments. And not one had to be doctored either.
I am now working on the main survey results and hope to have those online by the end of the week.
The cygwin perl packages are using self-written bash scripts to automate the build and release process. They support also self-compiled variants with different features (debugging, non-threaded, different cflags, Policy.sh, ...) and those perl's can be used in parallel to the officially supported one.
It should also be noted that perl in cygwin does not package every single perl module out there, it rather leaves the installation and dependency game to CPAN or cpanm.
Official cygwin packages depending on certain perl modules can just use a cygport three-liner to create this package and install it into vendor_perl. cpan installation go into site_perl.
debian and fedora e.g. package every single module into their own package format.
Do you know the most famous camel in the Perl world? The camel's name is "Meeltje". The camel already went to many conferences like FOSDEM and other Perl workshops. Meeltje was also mentioned in the 152nd edition of FLOSS Weekly.
We are happy to have such a famous guest in Frankfurt...
I love local::lib. You should be using local::lib.
The only thing that bugs me is when I want to run something that has to be under a privileged user (for example listening on ports under 1024), the privileged user is unaware of whatever was installed under local::lib. This includes both modules and scripts it installs. The "scripts" are usually actual applications that are installed via CPAN.
So I have to either reinstall these under the privileged user (which creates a problem because now I have two copies of the same thing) or run it under the privileged user while including the libraries of my private user.
Tricky, annoying.
I'm open to any and all advices...
UPDATE: within 30 seconds daxim has already provided with a solution: sudo -E. Thank you! :)
Apparently the admins of blogs.perl.org managed to close the JavaScript related security issue, which also disabled this solutions. I leave the article here for now but we cannot see the number of visitors this way. I hope a better solution will be implemented soon.
How to set up visitor analyzis on blogs.perl.org
On Saturday I posted a question How many people read your blog?
and included a GetClicky (affiliate) counter in the post. It showed me, about 150 people visited that page.
That was actually quite impressive. It was on a week-end when myothersites usually drop to 30-40% of their regular week-day traffic.
I think I'll experiment a bit with posts on blogs.perl.org but I'd like to get back to the subject in case you too would like to know how many people read your writings.
This week has been an exciting week for the small but dedicated group of scientists in the Perl community. This is because this week we saw the roll-out of two science related Perl sites:
The Quantified Onion a Google Group for two-way communication about Perl and Science
As gizmo_mathboy has already announced his group, I though I should make my site official too!
I wish we could say we had a big roll-out plan, but not so. We had discussed these things, decided we liked both ideas, and should keep them both, and somehow, this week, they both went live.
Leon Timmermans will give a talk at YAPC::Europe 2012 described as
Some things seem easy but turn out to be hard; signals are one of those things. My shortest summary of signals would be «signals are like threads without locking».
In this talk, I'll explain the origin and development of signals, and how perl deals with them, and how you can (or sometimes can't) write signal safe programs.
I've seen lots of bad module abstracts in CPAN uploads. So today I thought let's make a module to evaluate that (dzil plugin coming "soon"). A proof of concept: CPAN::Critic::Module::Abstract. It's modelled after Perl::Critic, with policies/profiles/themes/severity and all that (albeit simpler and not everything is configurable yet). Sample output:
Naveed Massjouni has recently released a new version of his Dancer::Plugin::Email. If you're using Dancer and emails, you probably found this plugin very useful.
The interface stayed pretty much the same (ironcamel++), but the configuration has changed, so you need to update it. Naveed has set up a development version not to break your production code, but you should advise it and update your configurations because it becomes stable.
I switched perl and all its dependencies on cygwin from 5.10 to 5.14 today.
Thanks to all involved maintainers and authors!
This was my announcement mail:
perl has now been updated from 5.10.1-5 to 5.14.2-3.
Most of the dependant official cygwin perl packages containing XS code
have also been updated.
All other packages containing or referencing perl code should just
work, except ming and postgresql.
See below for updating your self-compiled XS modules.
I've got practical and conceptual problems with perl 5.16,
so 5.14 it will be stable for the time being, at least until 5.16.1
will come out.
But it looks like only 5.18 will have inherent security problems with binary
names in 5.16 fixed. I consider using 5.16 too risky. (not only on windows).
No CVE's yet.