Search Results: "algernon"

29 August 2016

Gergely Nagy: Recruitment mistakes: part 3

It has been a while that I have been contacted by a recruiter, and the last few ones were fairly decent conversations, where they made an effort to research me first, and even if they did not get everything right, they still listened, and we had a productive talk. But four days ago, I had another recruiter reach out to me, from a company I know oh so well: one I ranted about before: Google. Apparently, their recruiters still do carpet-bombing style outreach. My first thought was "what took them so long?" - it has been five years since my last contact with a Google recruiter. I almost started missing them. Almost. To think that Google is now powerful enough to read my mind, is scary. Yet, I believe, this is not the case; rather, it's just another embarrassing mistake.To make my case, let me quote the full e-mail I was sent, with the name of the sender redacted, and my comments - which I'm also sending to the recruiter:
Hi Gergely,
Hi!
How are you? Hope you're well.
Thank you, I'm fine, just back from vacation, and I was thrilled to read your e-mail. Although, I did find it surprising too, and considering past events, I thought it to be spam first.
My name is XXX and I am recruiting for the Google Engineering team. I have just found your details on Github...
I'm happy that you found me through GitHub, but I'm curious why you mailed me at my debian.org address then? That address is not on my GitHub profile, and even though I have some code signed with that address, that's not what I use normally. My GitHub profile also links to a page I created especially for recruiters, which I don't think you have read - but more on that below.
...and your experience with software development combined with your open source contributions is particularly relevant to Google
Which part of my recent contributions are relevant to Google? For the past few months, the vast majority (over 90%) of my open source work has been on keyboard firmware. If Google is developing a keyboard, then this may be relevant, otherwise, I find it doubtful.Some of my past OSS contributions may be more relevant, but that's in the past, and it would take some digging to see those from GitHub. And if you did that kind of digging, you would have found the page on my site for recruiters, and would not have e-mailed me at my Debian address, either.
We are always interested in talking to top engineers with your mix of skills and I was wondering if you are at all open to exploring roles with Google in EMEA.
To make things short, my stance is the same as it was five years ago, when I wrote - and I quote - "So, here's a public request: do not email me ever again about job opportunities within Google. I do not wish to work for Google. Not now, not tomorrow, not ever."This still stands. Please do not ever e-mail me about job opportunities within Google. I do not wish to work for Google, not now, not tomorrow, not five years from now, not ever. This will not change. Many things may change, this however, will not.But even if I ignore this, let me ask you mix of skills are you exactly interested in? Keyboard firmware hacking, mixed with Emacs Lisp, some Clojure, and hacking on Hy (which, if you have explored my GitHub profile, will surely know) from time to time? Or is it my Debian Developer hat that got your interest? If so, why didn't you say so? Not that it would change anything, but I'm curious.Is it my participation in 24pullrequests? Or my participation in GSoC in years past?Nevertheless, my list of conditions I mentioned above, apply. Is Google able to fulfill all my requirements, and the preferences too? Last time I heard, working for Google required one to relocate, which I clearly said on that page, I'm not willing to do.
The teams I recruit for are responsible for Google's planet-scale systems. Just to give you more of an idea, some of the projects we work on that might be of interest to you would include:
  • MapReduce
  • App Engine
  • Mesa
  • Maglev
And how would these be interesting to me, considering my recent OSS work? (Hint: none of them interest me, not a bit. Ok perhaps MapReduce, a little.)
I think you could be a great fit here, where you can develop a great career and at the same time you will be part of the most mission critical team, designing and developing systems which run Google Search, Gmail, YouTube, Google+ and many more as you can imagine.
My career is already developing fine, thank you, I do not need Google to do that. I am already working on things I consider important and interesting, if I wanted to change, I would. But I certainly would not consider a company which I had asked numerous times NOT to contact me about opportunities. If you can't respect this wish, and forget about this in mere five years, why would I trust you to keep any other promises you make now?
Thank you so much for your time and I look forward to hearing from you.
I wish you had spent as much time researching me - or even half that - as I have spent replying to you. I suppose this is not the reply you were expecting, or looking for, but this is the only one I'll ever give to anyone from Google.And here, at the end, if you read this far, I'm asking you, and everyone at Google to never contact me about job opportunities. I will not work for Google. Not now, not tomorrow, not five years from now, not ever. Please do not e-mail me again, and do not reply to this e-mail either. I'm not interested in neither apologies, nor promises that you won't contact me - just simply don't do it.Thank you.

22 April 2016

Gergely Nagy: ErgoDox: Day 0

Today my ErgoDox EZ arrived, I flashed a Dvorak firmware a couple of times, and am typing this on the new keyboard. It's slow and painful, but the possibilities are going to be worth it in the end.That is all. Writing even this much took ages.

27 November 2015

Gergely Nagy: Feeding Emacs

For the past fifteen years, I have been tweaking my ~/.emacs continously, most recently by switching to Spacemacs. With that switch done, I started to migrate a few more things to Emacs, an Atom/RSS reader being one that's been in the queue for years - ever since Google Reader shut down. Since March 2013, I have been a Feedly user, but I wanted to migrate to something better for a long time. I wanted to use Free Software, for one.I saw a mention of Elfeed somewhere a little while ago, and in the past few days, I decided to give it a go. The results are pretty amazing.blah

23 November 2015

Gergely Nagy: Keyboard updates

Last Friday, I compiled a list of keyboards I'm interested in, and received a lot of incredible feedback, thank you all! This allowed me to shorten the list considerably, two basically two pieces. I'm reasonably sure by now which one I want to buy (both), but will spend this week calming down to avoid impulse-buying. My attention was also brought to a few keyboards originally not on my list, and I'll take this opportunity to present my thoughts on those too.The FinalistsErgoDoxErgoDoxPros Cons SummaryThe keyboard looks interesting, primarily due to the thumb keys. From the ErgoDox EZ campaign, I'm looking at $270. That's friendly, and makes ErgoDox a viable option! (Thanks @miffe!)There's also another option, FalbaTech, which ships sooner, I can customize the keyboard to some extent, and Poland is much closer to Hungary than the US. With this option, I'm looking at $205 + shipping, a very low price for what the keyboard has to offer. (Thanks @pkkolos for the suggestion!)Keyboardio M01Keyboardio Model 01Pros Cons SummaryWith shipping cost and whatnot, I'm looking at something in the $370 ballpark, which is on the more expensive side. On the other hand, I get a whole lot of bang for my buck: LEDs, two center bars (tripod mounting sounds really awesome!), hardwood body, and a key layout that is very similar to what I came to love on the TypeMatrix.I also have a thing for wooden stuff. I like the look of it, the feel of it.The VerdictRight now, I'm seriously considering the Model 01, because even if it is about twice the price of the ErgoDox, it also offers a lot more: hardwood body (I love wood), LEDs, palm key. I also prefer the layout of the thumb keys on the Model 01.The Model 01 also comes pre-assembled, looks stunning, while the ErgoDox pales a little in comparsion. I know I could make it look stunning too, but I do not want to build things. I'm not good at it, I don't want to be good at it, I don't want to learn it. I hate putting things together. I'm the kind of guy who needs three tries to put together a set of IKEA shelves, and I'm not exaggerating. I also like the shape of the keys better on the Model 01.Nevertheless, the ErgoDox is still an option, due to the price. I'd love to buy both, if I could. Which means that once I'm ready to replace my keyboard at work, I will likely buy an ErgoDox. But for home, Model 01 it is, unless something even better comes along before my next pay.The Kinesis Advantage was also a strong contender, but I ended up removing it from my preferred options, because it doesn't come with blank keys, and is not a split keyboard. And similar to the ErgoDox, I prefer the Model 01's thumb-key layout. Despite all this, I'm very curious about the key wells, and want to try it someday.Suggested optionsYogitypeYogitypeSuggested by Andred Carter, a very interesting keyboard with a unique design.Pros Cons SummaryI like the idea of the keyboard, and if it wouldn't need a special inlay, but used a small screen or something to show the keys, I'd like it even more. Nevertheless, I'm looking for a mechanical keyboard right now, which I can also use for coding.But I will definitely keep the Yogitype in mind for later!Matias Ergo ProMatias Ergo ProPros Cons SummaryThis keyboard hardly meets any of my desired properties, and doesn't have anything standing out in comparison with the others. I had a quick look at this when compiling my original list, but was quickly discarded. Nevertheless, people asked me why, so I'm including my reasoning here:While it is a split keyboard, with a fairly simple design, it doesn't come in the layout I'd prefer, nor with blank keys. It lacks the thumb key area that ErgoDox and the Model 01 have, and which I developed an affection for.Microsoft Sculpt Ergonomic KeyboardMicrosoft SculptPros Cons SummaryThis keyboard does not buy me much over my current TypeMatrix 2030. If I'd be looking for the cheapest possible among ergonomic keyboards, this would be my choice. But only because of the price.Truly Ergonomic KeyboardTruly Ergonomic KeyboardPros Cons SummaryTwo important factors for me are physical layout and splittability. This keyboard fails both. While it is a portable device, that's not a priority for me at this time.

20 November 2015

Gergely Nagy: Looking for a keyboard

Even though I spend more time staring at the screen than typing, there are times when I - after lots and lots of prior brain work - sit down and start typing, a lot. A couple of years ago, I started to feel pain in my wrists, and there were multiple occasions when I had to completely stop writing for longer periods of time. These were situations I obviously did not want repeated, so I started to look for remedies. First, I bought a new keyboard, a TypeMatrix 2300, which while not ergonomic, was a huge relief for my hands and wrists. I also started to learn Dvorak, but that's still something that is kind-of in progress: my left hand can write Dvorak reasonably fast, but my right one seems to be Qwerty-wired, even after a month of typing Dvorak almost exclusively.This keyboard served me well for the past five year or so. But recently, I started to look for a replacement, partly triggered by a Clojure/conj talk I watched. I got as far as assembling a list of keyboards I'm interested in, but I have a hard time choosing. This blog post here serves two purposes then: first to make a clear pros/cons list for myself, second, to solicit feedback from others who may have more experience with any of the options below.Update: There is a [follow up post], with a few more keyboards explored, and a semi-final verdict. Thanks everyone for the feedback and help, much appreciated!Lets start with the current keyboard!TypeMatrix 2030TypeMatrix 2030Pros Cons SummaryAll in all, this is a keyboard I absolutely love, and am very happy with. Yet, I feel I'm ready to try something different. With my skins aging, and the aforementioned Clojure/conj talk, the desire to switch has been growing for a while now.Desired propertiesThere are a few desired properties of the keyboard I want next. The perfect keyboard need not have all of these, but the more the merrier. I plan to buy one keyboard for a start, but may end up buying another to bring to work (like I did with the TypeMatrix, except my employer at the time bought the second one for me). At work, I will continue using the TypeMatrix, most likely, but I'm not sure yet.Anyhow, there are a number of things I do with my computer that require a keyboard: I am looking for a keyboard that helps me do these things. A keyboard that will stay with me not for five years or a decade, but pretty much forever.The optionsUltimate Hacking KeyboardUltimate Hacking KeyboardPros Cons SummaryThe keyboard looks nice, has a lot of appealing features. It is programmable, so much so that by the looks of it, I could emulate the hardware dvorak switch my TypeMatrix has. However, I'm very unhappy with the addons, so there's that too.All in all, this would cost me about $304 (base keyboard, modules, palm rest and shipping). Not too bad, certainly a strong contender, despite the shortcomings.ErgoDoxErgoDoxPros Cons SummaryThe keyboard looks interesting, primarily due to the thumb keys. From the ErgoDox EZ campaign, I'm looking at $270. That's friendly, and makes ErgoDox a viable option! (Thanks @miffe!)Kinesis AdvantageKinesis AdvantagePros Cons SummaryThe key wells look interesting, but it's not a split keyboard, nor is it open source. The cost come out about $325 plus shipping and VAT and so on, so I'm probably looking at something closer to $400. Nah. I'm pretty sure I can rule this out.Kinesis FreeStyle2Kinesis FreeStyle2Pros Cons SummaryWhile a split keyboard, at a reasonably low cost ($149 + shipping + VAT), it lacks too many things to be considered a worthy contender.MaltronMaltronPros Cons SummaryWithout shipping, I'm looking at 450. That's a very steep price. I love the wells, and the thumb keys, but it's not split, and customisability is a big question here.AtreusAtreusPros Cons SummaryWhile not a split keyboard, it does look very interesting, and the price is much lower than the rest: $149 + shipping ($50 or so). It is similar - in spirit - to my existing TypeMatrix. It wouldn't take much to get used to, and is half the price of the alternatives. A strong option, for sure.Keyboardio M01Keyboardio Model 01Pros Cons SummaryWith shipping cost and whatnot, I'm looking at something in the $370 ballpark, which is on the more expensive side. On the other hand, I get a whole lot of bang for my buck: LEDs, two center bars (tripod mounting sounds really awesome!), hardwood body, and a key layout that is very similar to what I came to love on the TypeMatrix.I also have a thing for wooden stuff. I like the look of it, the feel of it.The Preference ListAfter writing this all up, I think I prefer the Model 01, but the UHK and ErgoDox come close too!The UHK is cheaper, but not by a large margin. It lacks the thumb keys and the palm key the M01 has. It also looks rather dull (sorry). They'd both ship about the same time, but, the M01 is already funded, while the UHK is not (mind you, there's a pretty darn high chance it will be).The ErgoDox has thumb keys, split keyboard, and is open source. Compared to the UHK, we have the thumb keys, and less distraction, for a better price. But the case is not so nice. Compared to the Model 01: no leds, or center bar, and an inferior case. But, much better price, which is an important factor too.Then, there's the Atreus. While it's a DIY kit, it is much more affordable than the rest, and I could have it far sooner. Yet... it doesn't feel like a big enough switch from my current keyboard. I might as well continue using the TypeMatrix then, right?The rest, I ruled out earlier, while I was reviewing them anyway.So, the big question is: should I invest close to $400 into a keyboard that looks stunning, and will likely grow old with me? Or should I give up some of the features, and settle for one of the $300 ones, that'll also grow old with me. Or is there an option I did not consider, that may match my needs and preferences better?If you, my dear reader, got this far, and have a suggestion, please either tweet at me, or write an email, or reach me over any other medium I am reachable at (including IRC, hanging out as algernon on FreeNode and OFTC).Thank you in advance, to all of you who contact me, and help me choose a keyboard!

6 October 2015

Gergely Nagy: What dh-exec is, and what it isn't for

Strange as it may be, it turns out I never wrote about dh-exec yet, even though it is close to being four years old. Gosh, time flies so fast when you're having fun! Since its first introduction, there's been a reasonable uptake in dh-exec use: as of this writing, 129 packages build-depend on dh-exec. One might think this would be a cause for celebration, that the package is put to great use. But it's not.You see, a significant number of those 129 packages are doing it wrong, and need not build-depend on dh-exec at all.The purpose of dh-exec is to allow one to do things stock debhelper can't do, such as renaming files during the dh_install phase, or applying architecture or build profile based filtering, or doing environment variable substitution. There are many legit uses for all of these features, but there are some which can be easily solved without using dh-exec. So first, I'll talk a bit about the don'ts.What not to use dh-exec forOne of the most abused part of dh-exec is its variable substitution feature, and it is often used without need, to install multiarch-related files. While that is one intended use-case, there are few situations currently in the archive that stock debhelper can't handle. Let me explain the situation!Lets assume we have an upstream package, where the build system is something as common as autotools or CMake, for which debhelper can automatically set the appropriate flags and paths. Furthermore, lets assume that the upstream build system would install the following files:
/usr/lib/x86_64-linux-gnu/libalala.so.1.2.3
/usr/lib/x86_64-linux-gnu/libalala.so.1
/usr/lib/x86_64-linux-gnu/libalala.so
/usr/lib/x86_64-linux-gnu/libalala.a
/usr/lib/x86_64-linux-gnu/pkgconfig/libalala.pc
/usr/include/lalala/lalala.h
We want to include the first two in the libalala1 package, the rest in libalala-dev, so what do we do? We use stock debhelper, of course! That is all you need. In this case, there is absolutely no need for dh-exec. While using dh-exec without need is not much of an issue, because it only increases the space required for the build and build times by a tiny bit, I would still strongly recommend not introducing dh-exec needlessly. Why? Because of simplicity and aesthetics.So, if you find yourself doing any of these, or similar, that's a sign you are doing things wrong:
usr/lib/$ DEB_HOST_MULTIARCH 
usr/lib/$ DEB_HOST_MULTIARCH /*.so.* /usr/lib/$ DEB_HOST_MULTIARCH /
usr/lib/$ DEB_HOST_MULTIARCH /pkgconfig/*.pc /usr/lib/$ DEB_HOST_MULTIARCH /pkgconfig
usr/lib/$ DEB_HOST_MULTIARCH /package/*.so /usr/lib/$ DEB_HOST_MULTIARCH /package
Unless there are other directories under usr/lib that are not the multiarch triplet, using stock debhelper and wildcards is not only more succinct, simpler and more elegant, but also lighter on resources required.When dh-exec becomes usefulChanging installation pathsOnce you want to change where things get installed, then dh-exec becomes useful:
usr/lib/*.so.* /usr/lib/$ DEB_HOST_MULTIARCH 
usr/lib/$ DEB_HOST_MULTIARCH /package/* /usr/lib/$ DEB_HOST_MULTIARCH /package-plugins/
some/dir/*.so.* /usr/lib/$ DEB_HOST_MULTIARCH 
This usually happens when upstream's build system can't easily be taught about multiarch paths. For most autotools and CMake-based packages, this is not the case.Variable substitutionConsider this case:
#!/usr/bin/dh-exec
/usr/share/octave/packages/mpi-$ DEB_VERSION_UPSTREAM /hello2dimmat.m /usr/share/doc/octave-mpi/examples/hello2dimmat.m
/usr/share/octave/packages/mpi-$ DEB_VERSION_UPSTREAM /hellocell.m /usr/share/doc/octave-mpi/examples/hellocell.m
Here, the build supplies $ DEB_VERSION_UPSTREAM , and using dh-exec allows one to have a generic debian/links file, that does not need updating whenever the upstream version changes. We can't use wildcards here, because dh_link does not expand them.Renaming filesIn case one needs to rename files during the dh_install phase, dh-exec can be put to use for great results:
ssh-agent-filter.bash-completion => usr/share/bash-completion/completions/ssh-agent-filter
FilteringSometimes one would wish to conditionally install something based on the architecture, or the build profile. In this case, dh-exec is the tool to turn to:
<!stage1 !stage2> ../../libdde-linux26/Makeconf* usr/share/libdde_linux26
usr/lib/gvfs/gvfsd-afc                                          [!hurd-any]
usr/lib/gvfs/gvfsd-gphoto2                                      [linux-any]

13 April 2015

Mehdi Dogguy: DPL campaign 2015

This year's DPL campaign is over and voting period is also almost over. Many did not vote yet and they really should consider doing so. This is meant as a reminder for them. If you didn't have time to dig into debian-vote's archives and read questions/answers, here is the list with links to candidates' replies:
Compared to past years, we had a comparable number of questions. All questions did not start big threads as it used to be the case sometimes in the past :-) The good side of this is that we are trolling DPL candidates less than we used to do :-P

Now, if you still didn't vote, it is really time to do so. The voting period ends on Tuesday, April 14th, 23:59:59 UTC, 2015. You have only a few hours left!

14 March 2015

Bits from Debian: apt install dpl-candidate: Gergely Nagy

0. Who are you and what's your history with Debian Project? I'm a little mouse behind a keyboard, going by the nickname "algernon". I used to be a lot of things: a flaming youth, an application manager, package maintainer, upstream, ftp-assistant, a student, a mentor, a hacker. In the end, however, I am but a simple, albeit sometimes crazy person. I did a number of things within Debian - mostly small and marginal things, mind you. With a little break, I've been here for over a decade, and am planning to stay for at least another. 1. What's your most proud moment as Debian Developer? At last year's LinuxTag, I was wandering around a stand where they sold Raspberry Pis (with cases and other accessories). I had a nice chat with one of the staffers there, inquired about the price (including the case, of course), and a few other things. He asked a few things back: what I'll be using it for, and so on. After it turned out that I'm a Debian Developer, and syslog-ng hacker, he went to the back, and emerged a few minutes later with a boxed up Pi, and gave it to me as a gift, for working on Debian. This was an incredibly touching moment, in many, many ways. 2. In your opinion what is the strongest part of Debian Project? That's hard to say, to be honest. There are a good number of things Debian is incredibly strong at, and it would be hard to arbitrarily pick one. Quality, responsibility, safety, predictability are all areas we are very good at. But those are the qualities of the OS. As a project, we are remarkably well organised, given the volunteer & distributed nature of the project. 3. And what is the weakest part of Debian Project? While we can resolve and work with technical issues in a reasonable manner, the project as a whole is rather lacking in all other areas. To grow beyond being the creators of the Universal OS, we, as a project, need to pursue goals beyond the OS. Being part of GSoC and Outreachy are great steps forward. But we still have a lot of internal issues that need to be resolved. Areas such as innovation, team work, where we're in dire need of improvement. 4. How do you intend to resolve the weakest part? As explained in my platform, my primary goal is to remove roadblocks. The DPL can do very little alone, his time and powers are better spent on enabling those who have the required skills and desires, to pursue those. 5. DPL term lasts for one year - what would you challenge during that term and what have you learned from previous DPL's? The most valuable thing I learned from past DPLs is that the expectations are sky-high, yet, a significant portion of what the DPL does is very different than what I imagined in past years. I'd like to challenge the status quo of the DPL being a nearly full-time job. 6. What motivates you to work in Debian and run for DPL? I'm in it for the fame and glory, of course! And because my Tamagotchi told me to. But on a more serious tone, my main motivation to work on Debian is because contributing makes me happy. It satisfies my hunger for doing useful work. Debian is - in my opinion - the perfect platform to give back to the wider Free Software community. Similarly, my motivation to run for DPL is to allow Debian to be a stronger member of that greater

12 March 2015

Gergely Nagy: Lost in a maze, looking for cheese

ApologyAs a twisted turn of fate, I need to start my platform with an apology. Last year, I withdrew my nomination, because my life turned upside down, and the effects of that are still felt today, and will continue to have a considerable footprint for the rest of my life. But this is not what I want to apologise for! I want to apologise because my nomination, my platform, and my plans are rather uncommon - or so I believe. Unlike past Project Leaders, if elected, I will not have as much time to travel, as some of them. Nor will I have the resources to do all the things one may expect from a Project Leader. But - as you'll read later - I consider this both the biggest weakness and the greatest strength of my platform.Furthermore, I will not be available from the second half of the voting period until after the new Project Leader's term starts: I'll be getting married, and will enjoy a nice honeymoon, and as such, my email will remain unread from the 9th of April until we're back on the 21st of April.On the mouse behind the keyboardMy name is Gergely Nagy, or algernon, for those of you who may know me by my online presence. I used to be a lot of things: a flaming youth, an application manager, package maintainer, upstream, ftp-assistant, a student, a mentor, a hacker. In the end, however, I am but a simple, albeit sometimes crazy person. I imagine, a lot of people reading this will not know me, and that is actually not only fine, but in my case, desirable.The Role of the Project LeaderThe role of the Project Leader, what people perceive about the role, and what is actually done by one single person changed dramatically over time. In some ways for the better, some ways for the worse. It should be sufficiently clear by now that if we combine all the things past Project Leaders have done, and what people expect the Project Leader to do, then not even all the time in the world would be enough to accomplish everything. On the other hand, we should not cut the responsibilities back to constitution-granted ones only.There has been some discussion about this very topic on debian-project@, back in February, with excellent observations by both past Project Leaders and the current one. I encourage my dear readers to stop reading this platform now, and read at least Lucas's mail. I'll be right here when you get back.Back? Good.You may notice that unlike in previous years, I do not have a Grand Vision, not in the same sense at least. No matter what I envision, however noble that vision may be, it is not the Project Leader's job to save the world, so to say. While I still believe that we have serious problems with motivation, inspiration and innovation within the project, the Project Leader is the wrong person to try and solve these issues with.Apart from the constitutionally required responsibilities, the primary purpose of the Project Leader in my opinion, is to be an enabler: the Project Leader is not a front runner to lead the herd to victory, but a gentle shepherd to make them happy.HappyThere are many ways to make people happy. One such way is to enable them to pursue their passion - and not just enable them, but encourage and fuel that passion, too! -, to remove barriers, to empower them, or in a lot of cases, to include them in the first place. My vision is a project that is greater than just an amazing distribution. More than a role model for technical excellence. I want to do away with territorial pissings (with which I don't mean to imply that this would be the general atmosphere within the project - far from it!), and would rather see a warm, welcoming culture within the project - the kind of "I'm home!" feeling I had at the DebConfs I had the privilege to attend -, on public and private media alike.That is the vision I have, but I can't do it. At best, I can hope to enable people much better at the these things to do what needs to be done. I wish to take the burden of administration, bureaucracy off their shoulders, so they can focus on what they do best. I feel that this is the most important part of being a Project Leader: to enable the project to grow. And this is why I feel that most of you not knowing my name is an advantage here: When you look at a beautiful flower, you admire the flower itself, rarely the gardener.In the endI wish to be the Project Leader no one remembers. I'd rather see people remember all the great things the Project - as a whole - accomplished, for there are many. My purpose is to let You pursue your passion, which in turn enables even more people to pursue their happiness, and allows the greater Free Software community to bask in the warm glow of accomplished dreams.

Bits from Debian: Debian Project Leader elections 2015

It's that time of year again for the Debian Project: the elections of its Project Leader! Starting on April 1st, and during the following two weeks, the Debian Developers will vote to choose the person who will guide the project for one year. The results will be published on April 15th and the term for new the project leader will start on April 17th, 2015. Lucas Nussbaum who has held the office for the last two years won't be seeking reelection this year and Debian Developers will have to choose between three candidates: Gergely Nagy and Neil McGovern previously ran for DPL in past years; it's the first run for Mehdi Dogguy. The campaigning period started today and will last until March 31st. The candidates are expected to engage in debates and discussions on the debian-vote mailing list where they'll reply to questions from users and contributors.

2 March 2015

Gergely Nagy: Distributed Version Control from another angle

I've been using distributed version control systems for a good while, started with TLA back in 2001, when it was still a bunch of shell scripts and was simply called "Arch". I jumped the Git bandwagon quite early too, sometime around May 2005, I believe, though it was only something to test and play with on the side: I didn't migrate my projects over yet. There are many reasons why I preferred these over the systems I used in the past (RCS and CVS; never considered Subversion an option), most of those reasons have been discussed at length over the years, and there's no reason to do so again.The reason for this post, is because I read a blog post about why Git and the other DVCSes fall short. There are a number of things in that article that I find... well, lets just say misinformed. I'll try to explain why.But here's the rub
I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. But for the rest of us, I am going to assert that this is not the use case you need to optimize for when choosing a VCS.
I'm neither a field tech, nor do I work on a space station or a submarine. Yet, having the full history available locally has been crucial for my work for at least the past six years. Initially, I worked offline primarily, because my internet connection was incredibly limited (slow, expensive and unreliable), yet, I had a habit of committing small changes often. I needed a full clone to work effectively, and conveniently. Throw-away branches and all that - I needed them local, I didn't have the resources to push them online every time I wanted a merge.But now that I have fast and reliable internet, why do I need the full history on my own computer? I do, because I do much more research than I do development. The vast majority of my work between 2010 and 2012 involved reading histories, cherry picking and so on. About six hours a day, I was reading the past. Having the full history locally is a terrific aid when your job involves digging through it.Between 2013 and 2014, the amount of history reading dropped significantly, but I still worked with long-lived branches a lot, branches where history matters, where having easy and fast access to them is indispensable. I still had to find changes based on content (not commit message, branch, date or anything - content) on a daily basis. Hitting the network for each and every search would have wasted not only tremendous bandwidth and processing power on the server, but also a significant amount of time.If you do more maintenance and research, or follow a good number of branches (or forks), with the intent to merge and cherry-pick actively from them, having all the histories available locally is a huge improvement. I'm happy to pay the price of "wasting" disk space to have this available. I couldn't work otherwise. Without full, local history, the things I did for syslog-ng would not have been possible. No maintenance, none of the features I implemented, none of the fixes I found. Why? Because I rely on the project's history to aid me in learning the whys, not just the hows.Thank you, but - perhaps unlike others - I like to learn from the past, and prefer doing it efficiently.Say goodbye to blobs (or your sanity (and sometimes both))
You know what kind of external binary asset management system works really well? Subversion. Turns out it works tolerably for source control, too. Maybe you should take a look at it.
Sure, some systems are better at managing binary assets. Git - and usually DVCSes - are terrible at it. There's nothing stopping anyone from using two systems: one for source, another for data. Mind you, I am extremely happy with git-annex. I disagree with Subversion being tolerable for source control. I'd turn this assertion around instead: You know what kind of system works really well for source code? Git. Turns out it works tolerably as an external binary assest management system, too. Maybe you should take a look at it.But then, I rarely need to work with blobs, so I'm likely not the best person to disagree here.Say goodbye to sane version synchronizationOkay, so this part of the article is ill-titled, I believe. Large repositories and version synchronisation are two different, not necessarily related topic. Granted DVCSes may not be the best fit for large repositories, but neither are centralised version control systems, based on my past experience. I had the misfortune of working with a roughly 3-4Gb (checked out) project, with extensive history, managed with a centralised version control system, without local history. It was terrible (and blame was so slow and expensive that we were told never to use it, because it crashed the server). While the system allowed us to have a reasonable overview over the whole project, but it utterly failed at allowing us to work at the component level. How do I see which version of component X we had in project release A? Or the version of component Y we had two weeks ago? Or what if we have component M, made up from components J and K, and belonging to component Z? Good luck managing that in a single repository.With TLA, we had configs, which were a bit cumbersome to use, but captured most of the essential parts of managing component bundling and hierarchical versioning far better than any other solution I've seen so far. I've yet to find an acceptable solution, but I'm convinced it will not have anything to do with centralised systems. You can't capture the delicate relations there.Say what again, I dare you, I double dare you
All of the above might be almost tolerable if DVCSes were easier to use than traditional SCMs, but they aren t.
I'm sorry, but have you tried managing a decently sized project, with a large history, built from multiple components with a traditional SCM? Because that is a colossal pain in the backside.Does Git's UI suck? Yes. But so did CVS's and Subversion's. If you rely on the command-line tools, you're going to feel the pain. That is why you use the IDE integration you surely have, which makes the most common tasks a breeze. That may sound like a git-apology, but remember, we did the same with every other version control system, because smart people prefer integration, and want the computer to work for them.
And yet, when someone dares to say that Git is harder than other SCMs, they inevitably get yelled at, in what I can only assume is a combination of Stockholm syndrome and groupthink run amok by overdosing on five-hour energy buckets.
If you feel the need to understand the innards of Git - then yes, it is harder than traditional SCMs. It is distributed, and different than what you're used to. If you do not have prior knowledge though, the difference in learning the internal working of Git and - say - Subversion all that different. And if you do not care how it works down below (and I dare say, a lot of developers should not, and do not care), then there is nothing to learn, apart from your IDE integration, which ain't different from a traditional SCM's.Mind you, I found it both interesting, and beneficial to learn Git's inner workings. Not only because it allowed me to make better use of my VCS, but because it taught me a bunch of things I could make use of elsewhere. I learned nothing from traditional SCMs.Do you hear the people sing, singing the song of angry men
There is one last major argument that I hear all the time about why DVCSes are superior, which is that they somehow enable more democratic code development.
The reason Git and other tools make code contribution easier is not GitHub pull requests (although, for drive-by contributions those are pretty useful too). The reason they make contribution easier is because you have your own copy of the full history. You can create your own branches easily, you can work with it as if you were the owner. For one-off contributions, that is no real advantage, I'll give you that. It takes more effort to fork & do a PR on GitHub, than to send a patch, I'll also agree with that.But once you start working with a project for more than a few patches, when you want to work with its history too, once you have long-lived branches, the local copy quickly becomes a great asset. Once you want to submit more than a few changes, you won't have to repeat a all steps. And not only that: since you have the full history, merging upstream changes (or just cherry picking from them), rebasing your work, and many other tasks become simpler.That is what it buys you, that is why it makes contribution easier. GitHub pull requests are an icing over the cake at best (and there are a good number of cases where the icing is completely unnecessary, because it doesn't go well with the cake).In closingIn closing, I'd like to highlight that different projects have different requirements. For example, I understand why Facebook, Google and a number of others use a single, huge repository. I happen to hate that setup, and would find working in such an environment horrible. But luckily, I don't work for those companies, and they don't listen to me, either, so everyone's happy. That does not mean I would go out and tell them they're wrong to use such a centralised, single-repository setup. For their use, in their situation, for their requirements, that may be the better option. For mine, not so much.In the end, what we need to realise is that there is no single tool that will fit all needs. There are tasks where Git is a terrible choice, but that does not make it terrible for all cases. Similarly, there are cases where Subversion is superior (I assume - I didn't have the misfortune of meeting with such a case).Instead of bashing the DVCS world, and assuming the Big Company use cases are all that matter, and that everyone uses the tools the same way, accept that some use it to achieve things you didn't think of, jobs you didn't consider.

15 September 2014

Gergely Nagy: Looking ahead

A little more than a year ago, I started working as a syslog-ng OSE developer full-time. That was a tremendously important milestone in my career, as one of the goals I wanted to achieve in life - to work on free software for a living - became a reality. Rocket boots were fired up, and we accomplised quite a lot in the past year, and I'm very, very proud of the work we did - we, the whole community. I enjoyed every bit of it, but as it turns out, some of the other desires I wish to pursue, and new challenges I am looking for, will lead me in a different direction. At the end of August, I handed in my resignation, and the past friday was my last work day at BalaBit.There are a few questions that will likely be asked, and I'll try my best to answer them beforehand. Questions such as: What will happen to syslog-ng?, Who will be the new maintainer?, How does this affect your Debian work?, and so on, and so forth.syslog-ngWhat will happen to syslog-ng?After careful consideration, with the syslog-ng team at BalaBit, we decided that they will take over OSE-related responsibilities as well. They will do releases, they will engage the people on GitHub and the mailing list, they will take care of the @sngOSE twitter account.During the past few months, we've been working on pushing the team closer to the community: we moved issues to GitHub, the team submitted pull requests, and in general, we moved closer to each other in every possible way.While they may not have the open source maintainer experience I had, they are all capable folk, and will quickly learn on the job. The team taking over also has the advantage of having more manpower, and better collaboration between the premium edition and OSE.Who will be the syslog-ng maintainer?There will be no single bottle neck. This has both good and bad implications, but I believe the good ones outweigh the disadvantages.What about the roadmap? When will 3.6.1 happen?The roadmap is already laid out for 3.6, but it is the team's judgement when it will be released. The latest 3.6.0beta2 was released together with the team, too. I expect there will be delays (I planned 3.6.1 to be released on September 27th), but not much; a few weeks, perhaps.What will your involvement in syslog-ng development be?With changing jobs, my involvement will drastically decrease. I will remain a syslog-ng user, and I will continue packaging it for Debian and Ubuntu, and will keep my unofficial repository running. I do not see myself contributing much, perhaps bug reports, opinions and an occasional idea.Nevertheless, my expertise is still considerable, and I will help the team and the community in whatever way I can - but I will be severely time constrained.DebianWhile BalaBit were very free software friendly, and allowed me to work on Debian tasks from time to time, my other activities took up an increasingly big chunk of my paid time, and I had to cut back a little. At the new job, things will be a bit different: while I won't have as much time to do Debian work on the job, I will have a lot more free time, in which I hope to do more for Debian.I will - as promised above - continue maintaining syslog-ng, and all other packages I currently maintain. Apart from those, I wish to make myself more useful within the Clojure and Hy teams.MiscellaneousWhere to are you moving?This is something I will answer in due time. For now, I will have two weeks off, which I wish to spend my way, picking up projects I neglected for far too long.

30 August 2014

Gergely Nagy: Happy

For the past decade or so, I wasn't exactly happy. I struggled with low self esteem, likely bordered on depression at times. I disappointed friends, family and most of all, myself. There were times I not only disliked the person I was, but hated it. This wasn't healthy, nor forward-looking, I knew that all along, and that made the situation even worse. I tried to maintain a more enthusiastic mask, pretended that nothing's wrong. Being fully aware that there actually is nothing terribly wrong, while still feeling worthless, just added insult to injury.In the past few years, things started to improve. I had a job, things to care about, things to feel passionate about, people around me who knew nothing about the shadows on my heart, yet still smiled, still supported me. But years of self loathing does not disappear overnight.Then one day, some six months ago, my world turned upside down. Years of disappointment, hate and loathing - poof, gone. Today, I'm happy. This is something I have not been able to tell myself in all honesty in this century yet (except maybe for very brief periods of time, when I was happy for someone else).[Engaged]A little over six months ago, I met someone, someone I could open up to. I still remember the first hour, where we talked about our own shortcomings and bad habits. At the end of the day, when She ordered me a crazy-pancake (a pancake with half a dozen random fillings), I felt happy. She is everything I could ever wish for, and more. She isn't just the woman I love, with whom I'll say the words in a couple of months. She's much more than a partner, a friend a soul-mate combined in one person. She is my inspiration, my role model and my Guardian Angel too.I no longer feel worthless, nor inadequate. I am disappointed with myself no more. I do not hate, I do not loathe, and past mistakes, past feelings seem so far away! I can share everything with Her, She does not judge, nor condemn: she supports and helps. With Her, I am happy. With Her, I am who I wanted myself to be. With Her, I am complete.Thank You.

23 April 2014

Gergely Nagy: GSoC2014: syslog-ng accepted projects

The Google Summer of Code 2014 programme reached another milestone recently: the accepted proposals were published, and over a thousand students were selected by nearly two hundred mentoring organisations, among them the syslog-ng project. We will be working with four students this year (twice we worked with last year), with more mentors, on a wider selection of projects. It was a tough decision to select the proposals, we received some very strong work this year.We would like to express our gratitude to both Debian, for giving us an extra slot (so we could accept four students instead of three), and Google and Carol Smith in particular, for allowing it, and putting up with our fumbling during the process.The accepted projects and students are: Good luck to all students, we're looking forward to working with you throughout the summer! Happy hacking!

1 April 2014

Gergely Nagy: Motif on Wayland

Earlier this year, on the fourth of February, Matthew Garrett posted an interesting tweet. The idea of porting Motif to Wayland sounded quite insane, which is right up my alley, so I've been pondering and preparing since. The result of that preparation is a fundraiser campaign, which, if successful, I'll dive deeper into the porting effort, to deliver a library that brings the Motif we used to love back in the days to a modern platform.The aim of the project is to create a library, available under the GNU Lesser General Public License (version 2.1 or later, the same license original Motif is under), ported to Wayland, with full API compatibility if at all possible. In the end, we want the result to feel like Motif, to look like Motif, so that any program that can be compiled against Motif, will also work with the ported library. I will start fresh, using modern tools and modern methodologies (including, but not limited to autotools and test-driven development, on GitHub) to develop the new library, instead of changing the existing code base. Whether the goal is fully achievable remains to be seen, but the API - and the look of the widgets, of course - will feel like Motif, even if in a Wayland context, and we will do our best to either make the API 100% compatible with Motif, or provide a compatibility library.Since I have a day job, in order to be able to spend enough time on the library, I will need funding that more or less matches my salary. The more raised, the more time will be allocated to the porting project. Would we exceed the funding goal, there are a few stretch goal ideas that can be added later (such as porting the Motif Window Manager, and turning it into a Wayland compositor, with a few modern bells and whistles).For further information, such as perks, updates and all, please see the campaign, or the project website!

25 February 2014

Gergely Nagy: GSoC2014: syslog-ng ACCEPTED

We are happy to announce that we were accepted to be a mentoring organisation for Google Summer of Code Google Summer of Code 2014 programme! This year, we applied as the syslog-ng project, independently from the company behind, and we put a lot of effort not just into the proposals, but on the organisation image as well, with a brand-new website, among other things. I would like to thank both openSUSE for their past help (in 2012, and in 2013, we participated on GSOC under the umbrella of the openSUSE) and for vouching for us this year, and Debian too, for supporting our application with their vouch as well.This year, we have - as per usual - an interesting list of projects to choose from, with varied difficulties, touching a wide range of syslog-ng components. I am confident that any student interested in logging, or systems infrastracture in general, would find something interesting on our idea page. But if not, we are certainly open to accepting student proposals too.Unlike in previous years, we have a much better infrastracture (in the form of The Incubator), more documentation, more mentors, and projects that are described in more detail, where we, as mentors, have a better idea of what we'd like to see. This is a very interesting opportunity for us too, not just for students, as for the first time in our history within the Google Summer of Code programme, we are on our own, without an umbrella organisation, and we have to prove our worth. And we certainly will do that. What our students built last year is the bare minimum this year: we're upping the goals, for we want to build even more awesome features.Of course, building amazing things is just a side-effect, because the real purpose of the programme is to teach, and to get people involved in the free software community as a whole. Our mentors are all contributors to various free software projects, and we'd like our students to become such contributors too, to let them see that while the tasks may be challenging, the rewards are well worth it. Seeing your code used in production is a terrific feeling. Talking with the community, with the potential users is incredibly useful, and rewarding too. We'd like our students to be involved throughly and deeply, we will let them see the beauty the Free Software world has to offer.They will also learn a ton about the internals of syslog-ng, a software used on millions on devices, from embedded devices to room-size cluster monsters. We'll touch multi threading, in-software communication, scalability, performance and data structure topics. We'll fight with ancient, legacy systems, and win! The road ahead is challenging, but full of adventure.If you are a student, contact us, either on IRC, on Twitter, or the mailing list, we are happy to answer any questions you may have. If you are a user of syslog-ng, we would welcome feedback on our ideas, and new proposals too!

14 February 2014

Gergely Nagy: I love Free Software

I love Free Software! I love Free Software, and the people behind it. Even though I have been a free software user and developer for more than a decade now, there's still more to be amazed at, still more to contribute, and still more to learn. I love the Free Software community, because it never ceases to amaze me. It's not just about the technical side, but the social, human side of it, too!During the past year, I came to another milestone in my career: as of july first, I am a Free Software developer, and enjoying every moment of it. This is a feat that could not have been done without there being demand for what I do, without the free software community as a whole. For that, I owe you all a big thank you, you make it possible for me to make my dream come true. I can only hope that through my work, and through my example, I can contribute back enough.To this day, I take delight in contributing to free software, be it a Lisp on Python (or projects built in it), any of my own projects, syslog-ng, Google Summer of Code mentoring, Debian work - any and all of that are great fun. Even processing NEW is (I really should do that more often)! It's an endless source of not only entertainment and knowledge, but inspiration too.Whenever I read something as amazing as Russ Allbery's mail on the Debian technical committee impasse, I realize just how amazing people we have in our community, and how much we all can learn from them, and how much we owe them. This is yet another reason why I feel that contributing to Free Software is a passion many can share, because it teaches us good values too, atop of being technically excellent.I love Free Software, because without it, I would be lost. Thank you.

29 December 2013

Gergely Nagy: Introducing the syslog-ng Incubator

When syslog-ng 3.5.1 was released, the existence of the syslog-ng Incubator project was already announced, but I did not go into detail as to why it exists, what is in there, how to build it, or how to use it. The documentation that exists on it is almost non-existent, and what does exist, is usually in the form of a commit message and some example files. But there's nothing on how the things in the Incubator can be used, and what problems they solve.With this post, I will try to ease the situation a little, and provide some insight on how I use some of the things in there, like the Riemann destination.About the IncubatorThe idea for the Incubator existed for a long time, the first incarnation of it was called syslog-ng module collection, and had a different scope: it was a playing field not only for new modules, but updates to existing ones too. The idea was to try out new, possibly experimental features separately from syslog-ng. That didn't work well: it was a nightmare to maintain, and even harder to use. So it never got anywhere, as the developments made there were quickly merged into syslog-ng itself anyway.Then, two years later, I had a need for a new destination, but there was no open development branch to base it against, and forking and maintaining a whole syslog-ng branch for the purpose of a single module sounded like an overkill. So the Incubator was born, from the ashes of the failed module collection.The purpose of the Incubator is to be a place of experimental modules, and an easier way to enter the world syslog-ng development. It's something with far less requirements than syslog-ng (I do not care all that much about portability when it comes to the Incubator, especially not to horrible abominations like HP-UX or AIX), less rules, and more freedom. It's meant to be more developer friendly than syslog-ng proper.It also serves as an example of developing modules completely external to syslog-ng, and parts of it will be used in future posts of mine, to demonstrate the development of new modules.Compiling & InstallationThe first thing we need to do, is to compile whatever we need from the Incubator, unless we happen to have pre-built binaries available (which are going to appear in your usual third-party syslog-ng repositories over the next few weeks). For this, at a minimum, one will need syslog-ng 3.5+ and ivykis installed, along with autotools (autoconf, automake and libtool), pkg-config, bison, and depending on which modules one needs, riemann-c-client and libmongo-client too. Most of these are available packaged in better distributions, but only in recent versions, so one may need to compile those too. They follow a very similar scheme, though.If everything is installed at the standard locations, getting the Incubator to compile is as simple as this:
$ git clone https://github.com/balabit/syslog-ng-incubator.git
$ cd syslog-ng-incubator
$ autoreconf -i
$ ./configure && make && sudo make install
If anything happens to be installed in a non-standard location, one will need to adjust PKG_CONFIG_PATH to help the configure script locate the needed libraries.Once installed (the configure script will figure out where syslog-ng modules are, and modules will be put there), syslog-ng will automatically recognise the new modules. One can make sure that this is the case by running the following command after installation:
$ syslog-ng --module-registry
The PluginsNow that we're over the hard part of compiling and installing the Incubator, lets see what is inside! I will start with the easier things, and move on to the more complicated features as we progress. That is, we'll start with some template functions, have a glance at the trigger source, then explore the rss destination, and finish off with the riemann destination.Template functionsThe Incubator gives us three new template functions, some less useful than the others, and one that's a huge, ugly hack for a problem that I ended up solving in a very different way - without the hack.These functions are the $(or) template function, which takes any number of arguments, and returns the first one that is not empty. The main use case here is that if you have, say, similarly named fields, but some messages have one, the others another, and you want to normalize it, $(or) is one way to do it:
$(or $ HOST  $ HOSTNAME  $ HOST_NAME  "<unknown>")
Another function is $(//), which does the same thing as the built-in $(/) template function: divide its arguments. Except this one works with floating-point numbers only, while the built-in one is for integers exclusively. Using it is simple, too:
$(// $ some_number  3.4)
The last template function provided by the Incubator is $(state), which can be used to maintain global state, that does not depend on log messages. You can set values in here, like counters, from within a template function. It is possible to count the total amount downloaded data when processing a HTTP server log, for example. But it's slow, and there are better ways to do the same thing, syslog-ng really isn't the best tool for this kind of job. If anyone happens to find a use-case for it, please let me know. As for using it, it has two modes: set (with two arguments) and get (with one):
$(state some-variable $ VALUE )
$(state some-variable)
Trigger sourceThe trigger source has many in common with the built-in mark feature: at given intervals, it sends a message. This is mostly a debugging aid, when you want to generate messages without an external tool. It only has two options: trigger-freq() and trigger-message(), which default to 10 and "Trigger source is trigger happy.", respectively. It also accepts a number of common source options such as program-override(), host-override() and tags().To use it, one just needs to set it up like any other source, and bind it to a destination with a log statement:
source s_trigger  
 trigger(
  program-override("trigger")
  tags("trigger-happy")
  trigger-freq(5)
  trigger-message("Beep.")
 );
 ;
Without a program-override() option, messages will be attributed to syslog-ng, which is likely not what you want, even while debugging. Internal messages are usually routed somewhere else.RSS destinationThe RSS destination is an interesting beast. It offers an Atom feed of the last hundred messages routed to the destination. I could very well imagine this being useful in a situation where one already has monitoring set up to listen on various RSS sources - this would be just another. It also works well with most RSS feed readers. The length of the feed is not configurable at this time, and the number of options is limited to port(), title(), entry-title() and entry-description().The first one specifies which port the destination should listen on (it serves one client at a time!); title() can be used to set the title of the feed itself, while entry-title() and entry-description() can be used with templates to fill in the per-message Atom entries.Once we have a suitable path we want to route to the RSS destination (such as critical error messages only), we can set it up like this:
destination d_rss  
 rss(
  port(8192)
  feed-title("Critical errors in the system")
  entry-title("Error from $ PROGRAM  @ $ HOST_FROM  at $ ISODATE ")
  entry-description("$ MESSAGE ")
 );
 ;
Riemann destinationBeing the original motivator for the Incubator, I left this last. This module is the interface between your logs and the Riemann monitoring system. With this, you can take all the legacy applications that are hard to monitor, but provide log files, use syslog-ng's extraordinary log processing power, and send clear and concise events over to Riemann.One can use it to monitor logins, downloads, uploads, exceptions - pretty much anything. Just extract some metric, or state, send it over to Riemann, and that will do the heavy lifting. What exactly can be done, will be worth a separate blog post, so for now, I will give just a very tiny example:
destination d_riemann  
 riemann(
  ttl("120")
  description("syslog-ng internal errors")
  metric(int("$ SEQNUM "))
 );
 ;
Hook it up to a path that collects syslog-ng internal messages, keeps only error messages, and routes it toward this destination:
log  
  source   internal();  ;
  filter   level(err..emerg);  ;
  destination(d_riemann);
 ;
The destination itself has the following options: Closing thoughtsThe Incubator contains one more tool, one which can be used to visualise logs in strange ways. But that's not strictly related to syslog-ng, isn't a module, either, so I will not describe it here right now. The above was quite a lot already, I believe.As a closing thought, I would just like to say that while the Incubator is home for experimental modules, some of them are used in production. Don't be afraid to use them, especially when packages start to arrive to your favourite GNU/Linux distribution!

24 December 2013

Gergely Nagy: Some free software are really free

I read a post titled "Free software is NOT Free", and that triggered a few thoughts, which I would like to share here. While the post has some good thoughts, there are points in it which I disagree with strongly. You see, I've been writing free software almost half my life, most of the things I contributed to various projects, and the vast majority of my own projects, were made because it made me feel good. Because I scratched an itch, and sharing filled me with a sense of accomplishment.I always had bills to pay, and I have a day job to get that kind of thing sorted, yet, I do not believe that the quality of my free software work suffers because of that. Do I have less time? Yes, I do. But slower pace does not mean lesser quality - more often than not, I found that slower pace leads to better considerations, more care given to each change, because fixing it later, fast, is much more costly, so you make sure that your improvements will stand the trial of time.But I digress. I want to share a different view on the topic, based on my own experiences.When I first got into free software, I was young, bright-eyed, full of hopes and illusions of grandieur. I did my part of small contributions here and there, and every bit of "Thanks!", every bit of feedback - be it criticism or rejection - contributed to my development. This part of the free software culture is still important to me, and remains a major factor behind my desire to work on free software. Later on, there came another revelation: people actually use the stuff I write! That's an awesome feeling too, but with it, comes a burden too: supporting users, and trying to cater to every need that arises. To combat this, to not drown, you need to learn to say "No". It is hard, but as maintainer of a project, it's your task to keep it maintainable, and you need to know your limits. Would it be better if you could fulfil every wish? If you could do everything you ever dreamed of? You may think the answer is yes, but you're wrong. The answer is "No".Not everything needs to be done, not every wish needs to come true. As always, there's a balance. Limiting the amount of time that can be spent on a project helps keep that balance. And when balance is found, the project becomes more mature, maintenance stops being a chore you do not want to do, but have to, and instead becomes something you actually enjoy. We are human beings, we dream and wish for a lot, and we have a hard time realising our limits. That makes us feel sad, sometimes even inadequate. Having less time puts us into a different position, where were are forced to reevaluate how we spend the little free time we have. In the long run, I believe that is good for free software.But there's an even better way to approach the problem! You want to work on your projects, right? Yet, you also want to pay your bills. And you are a fan of free (as in freedom) software. When I found myself in a position like that, when I was looking for work, I was looking at companies which are friendly towards free software, and even have a few on their portfolio. Working for such a company allows me to be happy with myself, by not betraying my own beliefs, and on the side, still spend time on my own things.When I spend my day working on free software, I feel energised, and during lunch break, I can look through my plans for my own projects (some of which are related to my work too, which makes it even easier to spend time on them), plan ahead, and go home with a head full of ideas. No exhaustion after a daunting day of hacking proprietary software, with a sinking heart. No feeling guilty of not taking good care of your projects, because you do take care! You just do it on your own terms.So this is my suggestion to independent free software hackers: find a free software friendly company, that allows - or even encourages - you to work on your own things too. That way, you can pay your bills, and work on your hobbies, and best of all: keep them as hobbies, so it does not become a burden. When a hobby becomes your job, that often leaves a sour taste behind, when you can't fulfil every need, or fix every issue.Get a free software day-job, and keep your hobby as such, and everyone benefits. You get to keep your sanity, and users will receive better care, because the developers do what they love, and not what they have to.You give up some of your freedoms, yes, by not being independent. But being independent is not always the right choice. For some people, it may well be, for some, not so much. My experience over the past 15 years or so, is that independence brings a lot more headache than I'm willing to deal with. I'd rather work for a free software friendly company, where, after three years, I get paid to write and contribute to free software, and take care of my personal projects on the side, than try do all of it on my own.None of the software I wrote is worth a full salary, and none of them requires me to work full time on them, either. I could, mind you, I have enough ideas lined up to keep me busy for years. But do I want to? Do I want to burn myself out?No. The day job satisfies my hunger for contributing to a widely used piece of software, and my hobby projects satisfy my exploratory needs. I'm happy this way, and I'm very happy that thanks to the work and dedication of some amazing people, we got this far, that one can have a day job and independent projects too, that are all free software, without having to depend on fairly unreliable sources, such as donations (mind you, donations are a nice extra).There are, of course, different situations, and different people. What works for one, may not work for the other. This is what worked for me, and I felt the need to share it, lest anyone thinks that the world's darker than it really is.

8 October 2013

Gergely Nagy: Onto the margin of a summer of code

Just as last year, BalaBit applied to become a mentoring organisation for this year's Google Summer of Code, but like the year before, were not accepted. Instead, the openSUSE project was kind enough to give us two slots of their own, similarly to the year before - we are very thankful for this, and this year, both of the projects we took were closed successfully! So much so, that one of them was already merged into syslog-ng 3.5.0beta2, and the other one is being prepared for getting merged into the Incubator. I also helped out a little with Clojure & Leiningen packaging, although my contributions there were minimal at best.On the whole, I really liked this year's programme, our students accomplished a lot, and the whole summer was a great experience in itself, I learned a lot about mentoring, and about working with other people, people who are very new to the codebase they're working on. I would like to summarise what I learned and observed this year, in the hopes that others may find them useful too.This year, we set fairly ambitious goals for our students: they had to write a Redis and a MySQL destination, both of which presented interesting challenges to the students. None of them had prior experience with the syslog-ng source code, and their programming knowledge was mostly in C#, not plain old C which syslog-ng is written in. They also had to dabble a bit in the bowels of our overly complex configure.ac and a few Makefiles. Wasn't an easy task.In the beginning, we tasked the students to write proof of concept code, to get familiar with the libraries they will need to use - no syslog-ng involved at this point. This sounded like a good idea on paper, but without clear goals and milestones, a lot of time was spent on this task, and the students ran into a few dead-ends which could have been avoided, if we, the mentors, were more careful. This resulted in a reasonably poor first term, frustration and caused many a sleepless nights. We had to change our approach if we wanted to see the projects succeed.So we sat down with the students, and took one big leap: in person, we explained some of the internals of syslog-ng, did code reviews with them, and so on. But the best thing we did was what my colleague (and the main mentor), Viktor Tusa, came up with: we wrote a test script, that started syslog-ng, configured it, and ran tests against it. Students had to make their code pass the test by the next in-person meeting. This helped tremendously, and increased the speed they worked at by an order of magnitude at least. We kept developing the test script further, and so did the projects improve.ConclusionsThere are a couple of conclusions I arrived at as the programme concluded, things we (or other mentors, as I plan to participate as a student next year) will need to improve upon in the coming years.

Next.