Just posted a new blog post to the Server Check.in blog: Moving functionality to Node.js increased per-server capacity by 100x. Here's a snippet from the post:

One feature that we just finished deploying is a small Node.js application that runs in tandem with Drupal to allow for an incredibly large number of servers and websites to be checked in a fraction of the time that we were checking them using only PHP, cron, and Drupal's Queue API.

If you need to do some potentially slow tasks very often, and they're either network or IO-bound, consider moving those tasks away from Drupal/PHP to a Node.js app. Your server and your overloaded queue will thank you!

Read more.

I didn't go to the biennial HotOS conference, which was held last week in New Mexico.

I am, however, extremely grateful to USENIX and to the sponsors and participants for making the technical session materials freely available to all.

There's a lot of dig through in the conference, and I'll share my thoughts on some of the work once I've had more of a chance to read it.

Meanwhile, Matt Welsh has stirred up a fair bit of discussion with his post-conference blog post: What I wish systems researchers would work on.

Of the 27 papers presented at the workshop, only about 2 or 3 would qualify as bold, unconventional, or truly novel research directions. The rest were basically extended abstracts of conference submissions that are either already in preparation or will be submitted in the next year or so. This is a perennial problem for HotOS, and when I chaired it in 2011 we had the same problem. So I can't fault the program committee on this one -- they have to work with the submissions they get, and often the "best" and most polished submissions represent the most mature (and hence less speculative) work.

Welsh has been involved with the conference for years; moreover, given his well-known move from member of the faculty of Harvard's Computer Science department to lead researcher at Google, he has a fascinating background in both the academic and industrial research arenas.

So his thoughts are worth considering.

And yet, I must say that I find Welsh's criticisms to ring hollow.

It doesn't seem right to critique a topic by whether it is brand new, or whether it "has been a recurring theme" that involves "problems that are 25 years old." In some ways, I think it is a mark of Computer Science's maturity that we've stopped completely changing our entire perspective every 18 months, and are instead returning to deep problems of enduring interest.

For example, the observation by an IBM research team that the last two decades have seen dramatic progress in network I/O performance but a dramatic lack of progress in storage I/O performance seems like a great topic for the operating systems community to be discussing. Why, just last week I was digging into continued research in the network I/O world, while the disk storage world appears to be still stuck in bloated, layered, horrifically complex implementations from gigantic enterprise companies that ladle on the complications while ratcheting up the price: it's not uncommon for an enterprise SAN device to cost 7 or 8 digits, as much as 1000 times the cost of the servers that are trying to process that imprisoned data.

And when Welsh outlines the areas he considers important, he notes that:

A typical Google-scale system involves many interacting jobs running very different software packages each with their own different mechanisms for runtime configuration: whether they be command-line flags, some kind of special-purpose configuration file (often in a totally custom ASCII format of some kind), or a fancy dynamically updated key-value store. and also that: the modes of interaction are vastly more complex and subtle than simply reasoning about state transitions and messages, in the abstract way that distributed systems researchers tend to cast things.

I couldn't agree more with Welsh's points, which makes me wonder how he reacted to the session from the RAMCloud team: Toward Common Patterns for Distributed, Concurrent, Fault-Tolerant Code. The RAMCloud developers ran smack into these problems, and felt that pain:

For example, when a server failure notification is received by a server, several of its segments are affected, and each affected segment replica can be in a different state. Some replicas may have an RPC outstanding to the failed server and must abort the RPC and restart replication elsewhere instead of expecting a response. Other affected replicas may not be consistent with their counterparts; such replicas require contacting the cluster coordinator before starting recreation in order to prevent inconsistencies.

Now, what the RAMCloud team propose is not so new or trendy; again, they look back two decades, to the dawn of object-oriented design, and the "patterns" approaches that proved so successful in the 1990's:

Although the implementations were different in many respects, we eventually noticed a common theme; each of these modules contained a set of rules that could trigger in any order. We gradually developed a pattern for DCFT code based on three layers: rules, tasks, and pools. This particular pattern has worked for a variety of problems in RAMCloud. We believe that this pattern, or something like it, might provide a convenient way of structuring DCFT modules in general.

It's important to look to the future, but it's important to learn from and build on the past. Some old techniques are sound, and we shouldn't jettison them just because they're old (of course, remember you're getting this from a 52-year-old systems programmer who still codes 10 hours a day in C!).

So keep pushing the envelope, but let's not excoriate those who try to help us learn from proven decades-old approaches and bring that wisdom to the problems of modern software.

A Cryptic Crossword Clue Solver ←

Saw this via Twitter.

It is a partial crossword solver, because it only helps solve a particular category of crossword clues - those in which the clue (which is usually a sentence or phrase) contains both a "definition" of the answer as well a hint of some kind that leads to the same answer. This solver tries to compute the answer using both the definition and the hint, and checks whether the results match. Ingenious.

I found it interesting because this is a somewhat difficult problem, and yet the author managed to create a solution (involving NLTK and parsing) that works in many, if not all cases.

Also, long ago, in college days, I had written another kind of partial crossword solver (in BASIC); it was much simpler, using a brute force method - what it did was help solve the kind of crossword clues in which the answer is a permutation of a substring of the characters comprising the clue sentence or phrase. The program would generate and display on the screen, all possible permutations of all possible substrings of the sentence, that were of the same length as the answer. Then you had to view those permutations and guess whether any of them was the right answer, based on the clue.

I wrote the permutation-generation code by hand, but saw recently that the Python itertools module has methods to generate permutations (as well as combinations) from sequences:

http://docs.python.org/2/library/itertools.html

http://en.m.wikipedia.org/wiki/Permutation

http://en.wikipedia.org/wiki/Crossword

- Vasudev Ram
dancingbison.com

Vasudev Ram

I'm newbie for library transition, so sorry to violate to "Please do not upload the package to unstable without approval from the release team" term for transition from libsnmp15 to libsnmp30.

Now you can track it via tracker, thanks to release team to file it.

Montréal-Python would like to invite you all to the next Python Project Night, on Thursday, the 30th of May, 2013 at the offices of Caravan.

Like on previous nights, it’s an informal meetup where people work on different projects and generally mess around with Python code. Everyone is welcome, from the grizzled python hacker to the absolute beginner who just finished their first workshop. We will encourage people to help each other and we will also have dedicated helpers to help people get started.

As per usual, beer and pizza are provided, so just bring your laptop computer.

If you have any projects you would like to work on, please post them on the mailing list: montrealpython@googlegroups.com. If you don’t have any ideas, don’t worry, we will find you a project that needs help.

When: Thursday, May 30th 2013 from 7 PM to 9:30 PM

Where: Caravan, 5334 de Gaspé, office #1204 (Montreal)

Where to sign up: Please sign up on our Eventbright event

We would like to thank for hosting our event!

The UCSF Drupal Web Starter Kit project has been our most successful university project to date. It has empowered UCSF to roll out sites for small departments, offices, and researchers in a matter of minutes.

Just 3 months after launch, 70 sites have gone live.

Here are a few examples of sites leveraging the Drupal Web Starter Kit:

1. Office of the Executive Vice Chancellor & Provost
2. UCSF Depression Center
3. Drupal Web Starter Kit

The problem

UCSF has hundreds of small web properties for offices, researchers and small departments who don’t have the budgets and resources to create custom websites. Historically these groups have been left to their own devices to cobble together sites by whatever means necessary. These sites grow quickly out of date, are hard to maintain and rarely adhere to UCSF brand guidelines. 

UCSF created an initiative to build a Drupal install profile that they could offer to these groups at minimal cost and effort. UCSF turned to Chapter Three to design and build this solution.

The solution

1. A flexible information architecture

   Because this web solution had to work for small departments, offices, and researchers, we needed to find some common ground in how the sites were structured, while still providing enough flexibility for end users to modify the site’s structure to fit their needs. 

   We began by creating menu structure consisting of “Home, About, News, Events, Publications, Services and People”.  We arrived at this list after careful research of the commonalities across sites for the three key audiences. This meant that when a new website was created, the new client would have a primary navigation menu which was already created. They could then add items to the menu as needed, customizing it to fit their specific needs. 

   We also created specific content types for News & Events. Events were structured so that they could show upcoming and past.  Over time it is our goal to extend the project to create structure around more content including Publications and People.

2. Three different palettes 

   We collaborated with UCSF’s brand specialist to ensure that our designs were approved at the highest level to properly represent the look and feel of the University. We delivered three different color palettes of the template so that end users could pick the color scheme they liked most for their site.

3. Robust content display options

   To empower the admins to have more control of the key content regions, we designed a WISYWIG editor with the power to do far more than add text, links and images. All project administrators can add:

   • vertical tabs
   • accordions
   • tool tips

   Additionally, special care was taken to ensure that the back end system could be easily controlled by individuals who self identified as “non-technical” people.

4. Responsive design framework

   The future is device agnostic. As screen sizes multiply by the day, we knew that delivering a fully responsive site was paramount for the long term success of this project. We accounted for this with a fully responsive solution which provides legible content on any device interface. Since this solution was meant for hundreds of groups at UCSF, accounting for the long term viability of the website was fundamental to it’s success.

Thanks to UCSF

We appreciate the opportunity to work with an amazing client like UCSF. The project has been a resounding success for all involved. We look forward to building on this framework long into the future to better equip UCSF's groups with the tools they need to do their jobs. 

 

 

 

Here we go! Portland's Drupalcon is here. Here is a quick update about some of the exciting things that Metal Toad is bringing to the event. Stop by our booth (#207) and come party with us Tuesday and Wednesday. Come watch us record the podcast live and even step up to the mic if you dare. T-shirts, wine, stickers, foosball, Drupal!?!?! Whoa.

• Read more

• Newegg nukes “corporate troll” Alcatel in third patent appeal win this year

  I am loving this. Particularly this:

  At trial in East Texas Cheng took the stand to tell Newegg’s story. Alcatel-Lucent’s corporate representative, at the heart of its massive licensing campaign, couldn’t even name the technology or the patents it was suing Newegg over. “Successful defendants have their litigation managed by people who care,” said Cheng. “For me, it’s easy. I believe in Newegg, I care about Newegg. Alcatel Lucent, meanwhile, they drag out some random VP—who happens to be a decorated Navy veteran, who happens to be handsome and has a beautiful wife and kids—but the guy didn’t know what patents were being asserted. What a joke.” “Shareholders of public companies that engage in patent trolling should ask themselves if they’re really well-served by their management teams,” Cheng added. “Are they properly monetizing their R&D? Surely there are better ways to make money than to just rely on litigating patents. If I was a shareholder, I would take a hard look as to whether their management was competent.”

  (tags: patents ip swpats alcatel bell-labs newegg east-texas litigation lucent)

• Call me maybe: Carly Rae Jepsen and the perils of network partitions

  Kyle “aphyr” Kingsbury expands on his slides demonstrating the real-world failure scenarios that arise during some kinds of partitions (specifically, the TCP-hang, no clear routing failure, network partition scenario). Great set of blog posts clarifying CAP

  (tags: distributed network databases cap nosql redis mongodb postgresql riak crdt aphyr)

• The $12 Gongkai Phone

  Welcome to the Galapagos of Chinese “open” source. I call it “gongkai” (??). Gongkai is the transliteration of “open” as applied to “open source”. I feel it deserves a term of its own, as the phenomenon has grown beyond the so-called “shanzhai” (??) and is becoming a self-sustaining innovation ecosystem of its own. Just as the Galapagos Islands is a unique biological ecosystem evolved in the absence of continental species, gongkai is a unique innovation ecosystem evolved with little western influence, thanks to political, language, and cultural isolation. Of course, just as the Galapagos was seeded by hardy species that found their way to the islands, gongkai was also seeded by hardy ideas that came from the west. These ideas fell on the fertile minds of the Pearl River delta, took root, and are evolving. Significantly, gongkai isn’t a totally lawless free-for-all. It’s a network of ideas, spread peer-to-peer, with certain rules to enforce sharing and to prevent leeching. It’s very different from Western IP concepts, but I’m trying to have an open mind about it.

  (tags: gongkai bunnie-huang china phone mobile hardware devices open-source)

• Stability Patterns and Antipatterns [slides]

  Michael “Release It!” Nygard’s slides from a recent O’Reilly event, discussing large-scale service reliability design patterns

  (tags: michael-nygard design-patterns architecture systems networking reliability soa slides pdf)

DrupalCon Portland is off with a bang! Over 1,270 people have already arrived to pick up their badges and DrupalCon tshirts, and we're expecting as many attendees to arrive tomorrow.

Today alone, over 498 training attendees rolled in, as well as nearly 90 attendees for the CXO event. We're expecting over 3,300 people to attend the conference this week, so don't get stuck in line, get here early and grab your badge before sessions start at 9:00am.

If you haven't registered yet and still want to attend - this is your chance!

SUPERIMPOSED CAPTION: ‘SUBURBAN LOUNGE NEAR ESHER’
Elderly couple, Mr A and Mrs B are staring through french windows at a cat that is sitting in the middle of their lawn motionless and facing away from them. A car is heard drawing up.

The last couple of tutorials have been a bit heavy, so this week’s tutorials are going to balance that out by being a little light. We’re having a look at a couple of different aspects of the Python language.

List Comprehensions
The first is comprehensions:

>>> a_list = [1,2,3,4,5] >>> b_list= [element*2 for element in a_list] >>> b_list [2, 4, 6, 8, 10]

In this example, we have automatically generated a new list b_list from an existing list a_list by using a list comprehension. The structure of the comprehension is, I hope comprehensible. If not, it is a little hard to explain in steps. The comprehension above is equivalent to:

>>> b_list = [] >>> for element in a_list: ... b_list.append(element*2) ... >>> b_list [2, 4, 6, 8, 10]

We could call the variable element anything we liked – it is just another variable:

>>> b_list = [baloney*2 for baloney in a_list] >>> b_list [2, 4, 6, 8, 10] >>>

You can also add conditions. Let’s say you only wanted the even elements in a_list:
>>> b_list = [element for element in a_list if element%2 ==0] #ie remainder is 0 when dividing by two >>> b_list [2, 4] >>>

The condition here is if element%2 ==0, but you can substitute other conditions (as long as they resolve to either True or False). You can have a comprehension which relies on multiple variables (this example is from the Python documentation):

>>> [(x, y) for x in [1,2,3] for y in [3,1,4] if x != y] [(1, 3), (1, 4), (2, 3), (2, 1), (2, 4), (3, 1), (3, 4)]

Unwinding this is a little tricky – for each element in [1,2,3] it runs through each element in [3,1,4] (ie 9 comparisons in all) and appends the tuple if the elements are not equal.

List comprehensions provide an easy shorthand for constructing lists. Moreover, they are often more readable than writing out the for loops explicitly.

Tuples
The second topic is tuples.
The other thing we’re going to look at is tuples (pronounced, variously, “tupp-lls”, “two-pls” and, to some people, “tyou-pls” – my preference is tupp-lls, rhymes with couples). Tuples are a little like lists, except that they are immutable. That is, once they are made they cannot be changed. Tuples are made by putting the elements in round braces:

>>> my_tuple = (1,2,3) >>> my_tuple (1, 2, 3) >>> my_list = [1,2,3] >>> my_list [1, 2, 3]

Elements of the tuple are referenced in the same way as you’d reference a list but, unlike lists, these elements cannot be changed (tuples are “immutable”):

>>>my_tuple[0] 1 >>>my_tuple[0]=2 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'tuple' object does not support item assignment

The TypeError is telling us that you can’t change the elements of a tuple. To make a tuple with a single element is a little difficult because the interpreter could just interpret the parentheses as determining order of operation (think (1+2)*3). Instead, we put a comma after the single element to indicate that we are creating a tuple:

>>> my_tuple = (1) # no comma, so Python just thinks it's a number >>> my_tuple 1 >>> my_tuple[0] # just a number, so has no elements Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object has no attribute '__getitem__' >>> my_tuple= (1,) >>> my_tuple (1,) >>>my_tuple[0] 1

So, if a tuple does what a list can do, only less, why bother with a tuple? Why not use a list? Well, tuples are easier for the Python interpreter to deal with and therefore might end up being faster. Tuples might also indicate that you have an ordered list where the ordering has some meaning (for example, a date tuple might store year, month and day (in that order) in tuple). The fact that you’re using a tuple then flags that each of the entries has a distinct meaning or use and that their order is significant. Another pragmatic reason to use a tuple is when you have data which you know shouldn’t change (like a constant). So, if you accidentally try to change one of the tuple’s entries, you will have an error thrown.

Finally, since tuples are immutable they can be used as keys in dictionaries, unlike lists:

>>> my_dict={} >>> my_tuple=("A Name",23,"A location") >>> my_list= list(my_tuple) >>> my_dict[my_tuple]="Client 1" >>> my_dict[my_list]="Client 2" Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unhashable type: 'list'

Richard Stallman asks and then answers the question "Is it ever a good thing to use a nonfree program?" in the new short essay found at http://www.gnu.org/philosophy/is-it-ever-a-good-thing.html

In the night of May 18, mages, sorcerers, witches, and fairies took from the cauldron the new stable release of Mageia, now in your third version.

Mageia is a community Linux distribution based on Mandriva. This version have several softwares in their recent versions: KDE 4.10.2, GNOME 3.6, XFCE 4.10, Linux 3.8, systemd 195, rpm 4.11, LibreOffice 4.0.3, and more.

This release is dedicated to Eugeni Dodonov, former employer in Mandiva and a great free software developer. In your last work, Dodonov was in Intel developing a better integration between Intel graphics cards and Linux kernel. Dodonov died very young. He was cycling when was hit by a car. This accident happened in Sao Carlo city, Brazil, in 2012.

This release is special for me because the packages that I am the maintainer are available for Mageia users now. I am packing SWI-Prolog and abnTeX2. I intend make packages for scientific softwares and KDE stuff like themes and plasma applets. And, maybe, make a package to Cave Story because it is a beautiful game and everyone must play it! =)

Release notes, download link, tutorials to update from Mageia 2, and more news  are here.

What if, just like Bill Murray in Groundhog Day, you could wake up to a fresh and identical development environment completely free of yesterday's experiments and mistakes? Vagrant lets you do exactly that. more>>

The Los Angeles County Museum of Art has recently launched its Collections Online site, an online image library where art lovers can explore and download high quality images. This is a triumph for the accessibility of fine art in an increasingly digital world. Making this vast collection public benefits not only local art lovers but also the international art community, particularly students.

Fifteen years late, we stumbled across The Legend of 1900.

I suspect that 1900 is the sort of movie that many people despise, and a few people really enjoy.

Count me on the "really enjoy" side. Just knowing that the lead character's name was

Danny Boodman T.D. Lemons Novecento was probably enough to hook me.

Like any good fantasy, the movie is a parable: about war, about immigration, about society, and perhaps most of all, about the longing that drives people to travel. As 1900 says in a crucial monologue:

I think land people waste a lot of time wondering why. Winter comes and you can't wait for summer, summer comes and you never can wait for winter. That's why you never tire of traveling or chasing some place far away, where it's always summer.

I can't tell what sort of reaction you might have to this movie, but if you find yourself on a quiet evening looking for something just a bit unusual to watch, you might give The Legend of 1900 a try.

In his talk on performance problems Rainer Schuppe gave a great introduction to
which kinds of performance problems can be observed in production and how to
best root-cause them.

Simply put performance issues usually arise due to a difference in either data
volumn, concurrency levels or resource usage between the dev, qa and production
environments. The tooling to uncover and explain them is pretty well known:
Staring with looking at logfiles, ARM tools, using aspects, bytecode
instrumentalisation, sampling, watching JMX statistics, and PMI tools.

All of theses tools have their own unique advantages and disadvantages. With
logs you get the most freedom, however you have to know what to log at
development time. In addition logging is i/o heavy, so doing too much can slow
the application down itself. In a common distributed system logs need to be
aggregated somehow. As a simple example of what can go wrong are cascading
exceptions spilled to disk that cause machines to run out of disk space one
after the other. When relying on logging make sure to keep transaction
contexts, in particular transaction ids across machines and services to
correlate outages. In terms of tool support, look at scribe, splunk and flume.

A tool often used for tracking down performance issues in development is the
well known profiler. Usually it creates lots of very detailed data. However it
is most valuable in development - in production profiling a complete server
stack produces way too much load and data to be feasable. In addition there’s
usually no transaction context available for correlation again.

A third way of watching applications do their work is to watch via JMX. This
capability is built in for any Java application, in particular for servlet
containers. Again there is not transaction context. Unless you take care of it
there won’t be any historic data.

When it comes to diagnosing problems, you are essentially left with fixing
either the “it does not work” case or the “it is slow case”.

For the “it is slow case” there are a few incarnations:

• It was always slow, we got used to it.
  


• It gets slow over time.
  


• It gets slower exponentially.
  


• It suddenly gets slow.
  


• There is a spontanous crash.
  

In the case of “it does not work” you are left with the following observations:

• Sudden outages.
  


• Always flaky.
  


• Sporadic error messages.
  


• Silent death.
  


• Increasing error rates.
  


• Misleading error messages.
  

In the end you will always be spinning in a Look at symptoms, Elimnate
non-causes, Identifiy suspects, Confirm and Eliminate comparing to normal. If
not done with that, leather, rinse, repeat. When it comes to causes for errors
and slowness you will usually will run into one of the following causes: In
many cases bad coding practices are a problem, too much load, missing backends,
resource conflicts, memory and resource leakage as well as hardware/networking
issues are causes.

Some symptoms you may observe include foreseeable lock ups (it’s always slow
after four hours, so we just reboot automatically before that), consistent
slowness, sporadic errors (it always happens after a certain request came in),
getting slow and slower (most likely leaking resources), sudden chaos (e.g.
someone pulling the plug or someone removing a hard disk), and high utilisation
of resources.

Linear memory leak

In case of a linear memory leak, the application usually runs into an OOM
eventually, getting ever slower before that due to GC pressure. Reasons could
be linear structures being filled but never emptied. What you observe are
growing heap utilisation and growing GC times. In order to find such leakage
make sure to turn on verbose GC logging, do heapdumps to find leaks. One
challenge though: It may be hard to find the leakage if the problem is not one
large object, but many, many small ones that lead to a death by 1000 cuts
bleeding the application to death.

In development and testing you will do heap comparisons. Keep in mind that
taking a heap dump causes the JVM to stop. You can use common profilers to look
at the heap dump. There are variants that help with automatic leak detection.

A variant is the pig in a python issue where sudden unusually large objects
cause the application to be overloaded.

Resource leaks and conflicts

Another common problem is leaking resources other than memory - not closing
file handles can be one incarnation. Those problems cause a slowness over time,
they may lead to having the heap grow over time - usually that is not the most
visible problem though. If instance tracking does not help here, your last
resort should be doing code audits.

In case of conflicting resource usage you usually face code that was developed
with overly cautious locking and data integrity constraints. The way to go are
threaddumps to uncover threads in block and wait states.

Bad coding practices

When it comes to bad coding practices what is usually seen is code in endless
loops (easy to see in thread dumps), cpu bound computations where no result
caching is done. Also layeritis with too much (de-)serialisation can be a
problem. In addition there is a general “the ORM will save us all” problem that
may lead to massive SQL statements, or to using the wrong data fetch strategy.
When it comes to caching - if caches are too large, access times of course grow
as well. There could be never ending retry loops, ever blocking networking
calls. Also people tend to catch exceptions but not do anything about them
other than adding a little #fixme annotation to the code.

When it comes to locking you might run into dead-/live-lock problems. There
could be chokepoints (resources that all threads need for each processing
chain). In a thread dump you will typically see lots of wait instead of block
time.

In addition there could be internal and external bottlenecks. In particular
keep those in mind when dealing with databases.

The goal should be to find an optimum for your application between too many too
small requests that waste resources getting dispatched, and one huge request
that everyone else is waiting for.

This is a bit of a follow-up to Mike Bell's introductory article on using Codeception to create Drupal test suites. He concludes by stating he "need[s] to figure out a way of creating a Codeception module which allows you to plug in a Drupal testing user (ideally multiple so you can test each role) and then all the you have to do is call a function which executes the above steps to confirm your logged in before testing authenticated behaviour."

"Something along the lines of:

$I->drupalLogin('editor');

So, after skimming through Codeception and Mink documentation, I've tinkered with two potential ways of achieving this... for acceptance testing at least.

A crude toolbox

The first method is to use two custom classes to provide details of (a) a general Drupal site and (b) the specific site to be tested. This idea stemmed from this article which suggests that including literals - such as account credentials, paths and even form labels - in tests is bad practice. What if the login button label changes?

read more

The big week is finally here with DrupalCon Portland kicking off in our own backyard. For those of you not familiar with Portland, we're really big into birds (yes, I'm aware that's very 2010), and chickens in particular. I'm working real hard here to make a clever connection to RedHen, the leading native Drupal CRM, and the only one named after a bird!

Just in time for the conference, RedHen has a new release with plenty of performance improvements and bug fixes. We have a production site about to launch with over 100k contacts, and our test/development environments are running with over a 100k contacts with thousands of engagements each. We still have lots of work to do, but we're confident in RedHen's ability to scale to "enterprise" levels.

Understandably, one of the most requested features since we launched RedHen as been the ability to import contacts. Our initial pass at meeting that critical need also launched last week in the form RedHen Feeds, a Feeds processor for RedHen contacts. So get those contacts out of that spreadsheet and into RedHen! Support for organizational affiliations isn't there yet, but is in the works.

ThinkShout will be helping lead a RedHen sprint on Friday, May 24th, DrupalCon Portland's official sprint day. So if you're at all native CRM curious, come join our team as we hack away on RedHen and related tools. Learn about large datasets, Salesforce integration, managing memberships, email integration, event registrations, and common use cases. Site builders, documentarians, UX specialists, and developers are all welcome.

PS - ThinkShout is co-hosting the Drupal DoGooders Happy Hour, a fundraiser for Aaron Winborn, today, Monday May 20th. So please joint us and start your week off right by giving back to someone who has given so much to the Drupal community!

Tags: Drupal PlanetRedHenconferenceevents

Nearly six years ago, I set up a personal Jabber server using ejabberd.  This setup survived the server migration to Ubuntu 8.04 and 10.04.  This past weekend, I attempted to migrate that to a server running 12.04 and all I could get out of it was an erlang crash dump.

A quick scan for successors turned up prosody. Configuration was as simple as adding a VirtualHost and setting allow_registration to true.

In the past, we have had multiple heated discussions involving systemd. We (the pkg-systemd-maintainers team) would like to better understand why some people dislike systemd.

Therefore, we have created a survey, which you can find at http://survey.zekjur.net/index.php/391182

Please only submit your feedback to the survey and not this thread, we are not particularly interested in yet another systemd discussion at this point.

The deadline for participating in that survey is 7 days from now, that is 2013-05-26 23:59:00 UTC.

Please participate only if you consider yourself an active member of the Debian community (for example participating in the debian-devel mailing list, maintaining packages, etc.).

Of course, we will publish the results after the survey ends.

Thanks!

Best regards,
the Debian systemd maintainers