Skip to main content

a silhouette of a person's head and shoulders, used as a default avatar

Why I Strive to be a 0.1x Engineer

There has been more discussion recently on the concept of a “10x engineer”. 10x engineers are, (from Quora) “the top tier of engineers that are 10x more productive than the average”

Productivity

I have observed that some people are able to get 10 times more done than me. However, I’d argue that individual productivity is as irrelevant as team efficiency.

Productivity is often defined and thought about in terms of the amount of stuff produced.

“The effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input”

Diseconomies of Scale

The trouble is, software has diseconomies of scale. The more we build, the more expensive it becomes to build and maintain. As software grows, we’ll spend more time and money on:

  • Operational support – keeping it running
  • User support – helping people use the features
  • Developer support – training new people to understand our software
  • Developing new features – As the system grows so will the complexity and the time to build new features on top of it (Even with well-factored code)
  • Understanding dependencies – The complex software and systems upon which we build
  • Building Tools – to scale testing/deployment/software changes
  • Communication – as we try to enable more people to work on it

The more each individual produces, the slower the team around them will operate.

Are we Effective?

Only a small percentage of things I build end up generating enough value to justify their existence – and that’s with a development process that is intended to constantly focus us on the highest value work.

If we build a feature that users are happy with it’s easy to count that as a win. It’s even easier to count it as a win if it makes more money than it cost to build.

Does it look as good when you its compare its cost/benefit to some of the other things that the team could have been working on over the same time period? Everything we choose to work on has an opportunity cost, since by choosing to work on it we are therefore not able to work on something potentially more valuable.

Applying the 0.1x

The times I feel I’ve made most difference to our team’s effectiveness is when I find ways to not build things.

  • Let’s not build that feature.
    Is there existing software that could be used instead?
  • Let’s not add this functionality.
    Does the complexity it will introduce really justify its existence?
  • Let’s not build that product yet.
    Can we first do some small things to test the assumption that it will be valuable?
  • Let’s not build/deploy that development tool.
    Can we adjust our process or practices instead to make it unnecessary?
  • Let’s not adopt this new technology.
    Can we achieve the same thing with a technology that the team is already using and familiar with? “The best tool for the job” is a very dangerous phrase.
  • Let’s not keep maintaining this feature.
    What is blocking us from deleting this code?
  • Let’s not automate this.
    Can we find a way to not need to do it all?

Identifying the Value is Hard

Given the cost of maintaining everything we build, it would literally be better for us to do 10% the work and sit around doing nothing for the rest of our time, if we could figure out the right 10% to work on.

We could even spend 10x as long on minimising the ongoing cost of maintaining that 10%. Figuring out what the most valuable things to work on and what is a waste of time is the hard part.

a silhouette of a person's head and shoulders, used as a default avatar

HOWTO: Configure 389-ds LDAP server on openSUSE Tumbleweed

Recently I’ve been setting up LDAP authentication on CentOS servers to give a shared authentication method to all the compute nodes I use for my day job. I use 389-DS as it’s in my opinion much better to administer and configure than openLDAP (plus, it has very good documentation). As I have a self built NAS at home (with openSUSE Tumbleweed), I thought it’d be nice to use LDAP for all the web applications I run there. This post shows how to set up 389 Directory Server on openSUSE Tumbleweed, including the administration console.

(Obligatory) disclaimer

While this setup worked for me, there’s no guarantee it will work for you. If something breaks, you get to keep all the pieces. With some adjustments (repo names etc) this might also work on openSUSE Leap 42.1, but I haven’t tested it. Use these instructions at your own risk.

Prerequisites

Your machine should have a FQDN, either a proper domain name, or an internal LAN name. It doesn’t really matter as long as it’s a FQDN.

Secondly, you need to tune a couple of kernel parameters to ensure that the setup won’t scream at you for lack of available resources. In particular, you’ll need to raise the ranges of local ports available and the number of maximum file descriptors. You can easily do that by creating a file called /etc/sysctl.d/00-389-ds.confwith the following contents:

# Local ports available
net.ipv4.ip_local_port_range = 1024 65000
# Maximum number of file handles
fs.file-max = 64000

After adding it, issue sysctl -p as root to apply the changes.

Installing 389 Directory Server

Afterwards, we’ll need to add the network:ldap OBS project, as in particular the admin bits of 389 aren’t yet available in Tumbleweed. Bear in mind that adding third-party repository to a Tumbleweed install is unsupported.

zypper ar -f obs://network:ldap Network_Ldap
# Trust the key when prompted
zypper ref

The obs:// scheme automatically adds the “guessed” distribution to your repository (with Leap it might fail though, so beware). Then we install the required packages:

zypper in 389-admin 389-admin-console 389-adminutil 389-console 389-ds 389-ds-console 389-adminutil 389-adminutil-lang

Adjusting the configuration to ensure that it works

So far so good. But if you follow the guides now and use setup-ds-admin.pl, you’ll get strange errors and the administration server will fail to get configured properly. This is because of a missing dependency on the apache2-worker package and because the configuration for the HTTP service used by 389 Directory Server is not properly adjusted for openSUSE: it references Apache 2 modules that the openSUSE package ships builtin or with different names and thus cannot be loaded.

Fixing the dependency problem is easy:

zypper in apache2-worker

Then, we’ll tackle the configuration issue. Open (as root) /etc/dirsrv/admin-serv/httpd.conf, locate and comment out (or delete) the following line:

LoadModule unixd_module         /usr/lib64/apache2/mod_unixd.so

Then change the mod_nss one so that it reads like this:

LoadModule nss_module         /usr/lib64/apache2/mod_nss.so

Save the file and now you’ll be able to run setup-ds-admin.pl without issues. I won’t cover the process here, there are plenty of instructions in the 389 DS documentation.

After installation: fixing 389-console

If you want to use 389-console on a 64 bit system with openJDK you’ll notice that upon running it’ll throw a Java exception saying that some classes (Mozilla NSS Java classes) can’t be found. This is because the script looks in the wrong library directory (/usr/lib as opposed to /usr/lib64). Edit /usr/bin/389-console and find:

java \
    -cp /usr/lib/java/jss4.jar: # rest of line truncated for readability

and change it to:

java \
    -cp /usr/lib64/java/jss4.jar: # rest of line truncated for readability

Voilà!

389-console working

a silhouette of a person's head and shoulders, used as a default avatar

Bit shifting, done by the << and >> operators, allows in C languages to express memory and storage access, which is quite important to read and write exchangeable data.

Bit shifting, done by the << and >> operators, allows in C languages to express memory and storage access, which is quite important to read and write exchangeable data. But:

Question: where is the bit when moved shifted left?

Answere: it depends

Long Answere:

// On LSB/intel a left shift makes the bit moving 
// to the opposite, the right. Omg 
// The shift(<<,>>) operators follow the MSB scheme
// with the highest value left. 
// shift math expresses our written order.
// 10 is more than 01
// x left shift by n == x << n == x * pow(2,n)
#include <stdio.h> // printf
#include <stdint.h> // uint16_t

int main(int argc, char **argv)
{
  uint16_t u16, i, n;
  uint8_t * u8p = (uint8_t*) &u16; // uint16_t as 2 bytes
  // iterate over all bit positions
  for(n = 0; n < 16; ++n)
  {
    // left shift operation
    u16 = 0x01 << n;
    // show the mathematical result
    printf("0x01 << %u:\t%d\n", n, u16);
    // show the bit position
    for(i = 0; i < 16; ++i) printf( "%u", u16 >> i & 0x01);
    // show the bit location in the actual byte
    for(i = 0; i < 2; ++i)
      if(u8p[i]) 
        printf(" byte[%d]", i); 
    printf("\n");
  }
  return 0;
}

Result on a LSB/intel machine:

0x01 << 0:      1 
1000000000000000 byte[0] 
0x01 << 1:      2 
0100000000000000 byte[0] 
0x01 << 2:      4 
0010000000000000 byte[0] 
0x01 << 3:      8 
0001000000000000 byte[0]
...

<< MSB Moves bits to the left, while << LSB is a Lie and moves to the right. For directional shifts I would like to use a separate operator, e.g. <<| and |>>.

the avatar of Aleksa Sarai

Dockerinit and Dead Code

After running into insane amounts of very weird issues with gccgo with Docker, some of which were actual compiler bugs, someone on my team at SUSE asked the very pertinent question "just exactly what is dockerinit, and why are we packaging it?". I've since written a patch to remove it, but I thought I'd take the time to talk about dockerinit and more generally dead code (or more importantly, code that won't die).

the avatar of Bruno Friedmann

A brief 360° overview of my first board turn

You’ve certainly noticed that I didn’t run for a second turn, after my first 2 years. This doesn’t mean the election time and the actual campaign are boring 🙂

If you are an openSUSE Member, we really want to have your vote, so go to Board Election Wiki and make your own opinion.

The ballot should open tomorrow.

board-leaving-tigerfoot

Why not a second turn?

Being a board member (present at almost every conference call, reading the mailing lists and other task) consume free time. It has increased during the last semester too. And we’ve got some new business opportunities here at Ioda-Net Sàrl in 2015, and those need also my attention for the next year(s). I prefer to be a retired Board member, than not being able to handle my responsabilities.
But I’m not against the idea of a "I’ll be back" in a near future. Moreover with a bit more bandwidth in my free time, I will be able to continue my packaging stuff, and other contributions.

What a journey!

With the new campaign running, I found funny to bring back to light my 2013 platform written 2 years ago. And spent 5 minutes on checking the differences with today. I’m inviting you to discover the small interview between me and myself 🙂

1. Which sentences would you say again today?

I’m a "Fucking Green Dreamer" of a world of collaboration, which will one day offer Freedom for everyone.

Clearly still a day by day mantra and leitmotiv. But even if I’m dreaming, I never forget that
Freedom has a price : Freedom will only be what you do for it.

2. Which thing you would not say again, or differently ?

Well, as there’s no joker card, let’s start by this one:
"A Visible Active Board > A Visible Active Project." With the experience and time, and interaction, (the one who said fight, get out please :-)), I would said this is not as easy as it sound first.
I’m pretty sure, I was more quieter since I was on the board, than before. Because it’s too hard to make a clear distinction, when you just want to express something as "a simple contributor": you are on the board, and then whatever you can try to trick the fact: you’re still a board member.

So making the Board visible like a kind of communicant Alien, will certainly not improve that much our project.
It’s written everywhere, almost everybody agree, the board is not the lighthouse in the dark showing you the future.
Anyone, I repeat, anyone in this community is a potential vector of a future for openSUSE.

So in my past platform "Guardians of the past, Managers of the present, Creators of the future." I would replace Creators of the future by kinda "enabler"

3. In the last 2 years, where did openSUSE mostly evolve?

I think we moved from a traditional way of building distribution to some creative alternative, the rolling but tested Tumbleweed, and the hybrid Leap are really good things that happened.
I believe that if we have also some hard time on mailing list, which are exhausting, they also have a positive aspect (yeap:-)). If we fight, then it’s certainly because of our faith in something. Is this one defined? Not sure! But I’m pretty convinced that all members around have a good image of it.

4. What would be an advice to your successor (even if he doesn’t care about it)?

We are a tooling community, we love tools. Beware of one thing, if you get hurt by a tool, you can become the worst asshole you’ve never met. With tools, you can also hurt other people.

My advise, watch your step and keystroke!

truly-green-yours

5. Something more you would like to share?

I’ve invested time and energy during 2014 and beginning of 2015, to run booth, talks, represent openSUSE’s project all around. It was awesome to go to those events and meet people, involved or interested about openSUSE.

Perhaps some of you don’t know, but we have friends all around us, in many communities, and when the magic about working together appears, it just blast my heart.

Thanks for reading and for your support during this period

Truly green yours

a silhouette of a person's head and shoulders, used as a default avatar

Keras for Binary Classification

So I didn’t get around to seriously (besides running a few examples) play with Keras (a powerful library for building fully-differentiable machine learning models aka neural networks) – until now. And I have been a bit surprised about how tricky it actually was for me to get a simple task running, despite (or maybe because of) all the docs available already.

The thing is, many of the “basic examples” gloss over exactly how the inputs and mainly outputs look like, and that’s important. Especially since for me, the archetypal simplest machine learning problem consists of binary classification, but in Keras the canonical task is categorical classification. Only after fumbling around for a few hours, I have realized this fundamental rift.

The examples (besides LSTM sequence classification) silently assume that you want to classify to categories (e.g. to predict words etc.), not do a binary 1/0 classification. The consequences are that if you naively copy the example MLP at first, before learning to think about it, your model will never learn anything and to add insult to injury, always show the accuracy as 1.0.

So, there are a few important things you need to do to perform binary classification:

  • Pass output_dim=1 to your final Dense layer (this is the obvious one).
  • Use sigmoid activation instead of softmax – obviously, softmax on single output will always normalize whatever comes in to 1.0.
  • Pass class_mode='binary' to model.compile() (this fixes the accuracy display, possibly more; you want to pass show_accuracy=True to model.fit()).

Other lessons learned:

  • For some projects, my approach of first cobbling up an example from existing code and then thinking harder about it works great; for others, not so much…
  • In IPython, do not forget to reinitialize model = Sequential() in some of your cells – a lot of confusion ensues otherwise.
  • Keras is pretty awesome and powerful. Conceptually, I think I like NNBlocks‘ usage philosophy more (regarding how you build the model), but sadly that library is still very early in its inception (I have created a bunch of gh issues).

(Edit: After a few hours, I toned down this post a bit. It wasn’t meant at all to be an attack at Keras, though it might be perceived by someone as such. Just as a word of caution to fellow Keras newbies. And it shouldn’t take much to improve the Keras docs.)

a silhouette of a person's head and shoulders, used as a default avatar

High DPI with FLTK

After switchig to a notebook with higher resolution monitor, I noticed, that the FLTK based ICC Examin application looked way too small. Having worked in the last months much with pixel independent resolutions in QML, it was a pain to see the non adapted FLTK GUI. I had the impression, that despite of several years of a very appreciated advancement of monitor technology, some parts of graphics stacks did not move and take advantage. So I became curious on how to solve high DPI support the hard way.

First of all a bit of introduction to my environment, which is openSUSE Linux and KDE-5 with KF5 5.5.3. Xorg use many times a hardcoded default of 96 dpi, which is very unfortune or just a bug? Anyway, KDE follows X11. So the desktop on the high resolution monitor looks initially as bad as any application. All windows, icons and text are way too small to be useable. In KDE’s system settings, I had to set Force Font with DPI and doubled its size from 96 to 192. In the kscreen module I had to set scale 2.0 and then increased the KDE task bars width. Out of the box useability is bad with so many inconsistent manual user intervention. In comparision with the as well tested Unity DE, I had to set a single display scaling factor to 2.0 and everything worked fine and instantly, icons, fonts and window sizes. It would be cool if DE’s and Xorg understand screen resolution. In the tested OS X 10.10 even different screen resolutions of multiple monitors are scaled correctly, so moving a window from a high DPI monitor screen to a traditional low resolution external monitor gives reasonable physical GUI rendering. Apples OS X provides that good behaviour initially, without manual user intervention. It would be interessting how GNOME behaves with regards to display scaling.

Back to FLTK. As FLTK appears to define itself as pixel based, DPI detecion or settings have no effect in FLTK. As a app developer I want to improve user experience and modified first ICC Examin to initially render physically reasonably. First I looked at the FL::screen_dpi() function. It is only a helper for detecting DPI values. FL::screen_dpi() has has in FLTK-1.3.3 hardcoded values of 96DPI under Linux. I noticed XRandR provides correct milimeter based screen dimensions. Together with the XRandR provided screen resolution, it is easy to calculate the DPI values. ICC Examin renderd much better with that XRandR based DPI’s instead of FLTK’s 96DPI. But ICC Examin looked slightly too big. The 192DPI set in KDE are lower than the XRandR detected 227 DPI of my notebooks monitor. KDE provides its forced DPI setting to applications by setting Xft.dpi in XResources. That way all Xft based applications should have the same basic font scaling. KDE and Mozilla apps do use Xft. So add parsing of a Xlib XResources solved that for ICC Examin. The remainder of programing was to programatically scale FLTK’s default font size from 14 pixels with: FL_NORMAL_SIZE = scale(14) . Some more widget sizes, the FtGl font sizes for OpenGL, drawing line widths and graphics scaling where needed. After all those changes, ICC Examin takes now advantage of high resolution rendering inside KDE. Testing under Windows and OS X must follow.

The way to program high DPI support into a FLTK application was basically the same as in QML. However Qt’s QML takes off more tasks by providing a relative font unit, much like CSS em sizes. For FLTK, I would like to see some relative based API’s, in addition to the pixel based API’s. That would be helpful to write more elegant code and integrate with FLTK’s GUI layout program fluid. Computer times point more and more toward W3C technology. FLTK would be helpful to follow.

the avatar of Jigish Gohil

a silhouette of a person's head and shoulders, used as a default avatar

Fosscomm 2015 at Athens

Fosscomm is the annual conference of the Greek Free Software communities. This year the event took place on November 7 & 8 at the Technological Educational Institute(TEI) of Athens. This time around openSUSE had quite the strong presence in the conference with 3 talks and a booth.

openSUSE-el

The Booth itself always had at least 3 persons busy answering questions with old time and some new contributors to the project and local community handling the organization and distribution of the swag in the booth and explaining the merits of our current structure, projects and releases.

Community Booth

Enlightening Lizards

Although i haven’t had time to really contribute to this project in a while, it’s still one i really hold dear/close to heart so made sure to do this presentation again this year but with updated stats to spread the word about this awesome window manager and its foundation libraries and the stellar packaging work done by simon lees.

Enlightening Lizards

Automated Testing With openQA

My second and I believe most important presentation, this year, was about the excellent QA tool actually used to build our distro, “openQA”. As said by it’s motto, “Life is too short for manual testing!”, thus openQA is used to automate testing of the whole distribution (either as a collection or in individual package basis). You can see some test case examples on it’s homepage, you can also fetch the presentation from my github repo (FOSSCOMM_2015 directory) linked in the blog sidebar.

Automated Testing, openQA

Leaping Ahead

Alex Vennos another community member had a presentation about the latest stable release “Leap 42.1”, unfortunately i couldn’t attend it but heard that it was well received even though people showed some confusion about the sudden “Leap” to a version like 42.1 from the previous 13.2

Leaping Ahead

The rest

I spent the rest of the conference at our booth helping people, answering questions and generally socializing and talking with old & new friends.

Congratulations to the people from the TEI of Athens for the organization! :)

Update minor (mostly grammar/typo fixes)

the avatar of Sankar P

2015 Learning Retrospective


  • The year began well. Started working on keeri with an aim to implement a distributed database, thereby learning the distributed systems concepts and leveraging my storage / filesystem experience. 
  • Took the coursera's cloud computing concepts course to understand the fundamentals that will help in implementing keeri
  • As part of the database implementation, needed to implement a SQL parser which will convert given SQL statements into a decision tree. Took a coursera course on compilers. Implemented a decent recursive-descent (note the wordplay) parser that will process SQL queries with parentheses, Logical operators and Relational operators.
  • Having already been tired with the non-core aspects of the "distributed" database, abandoned the project temporarily.
  • Need to learn more about NewSQL technologies. Especially in the areas around how it helps for better tooling (for IDEs and the like) and also for parallelism.
  • Studied a bit of database literature around ARIES, Voltdb etc.
  • Attempted to read part-time parliament but lost interest midway because of reading raft, which is for similar purpose but a lot simpler to read, follow. Did a paper reading session together with Sureshkumar Thangavel for this.
  • Played around with Continous Integration systems (travis, jenkins, etc.) out of interest, which later helped in projects in two different dayjobs.
  • Wasted a lot of time, pretending to be preparing for interviews but did not do anything more than chatting with job change aspirants. But no complaints as time enjoyed is not time wasted.
  • Learnt a little bit in more detail about queueing systems (Amazon SQS, rabbitmq to be specific)
  • Wrote some test / tutorial programs for the Amazon Go SDK
  • Did a few prototypes using Go for the API backend, Angular and React as the web frontends for few project ideas. Bothered about the fatigue induced by the constant reinvention in the frontend JS technologies. The future looks potentially even more heavily fragmented with no sanity in the horizon.
  • Learnt to create docker images. Did some non-trivial dockerization for a legacy product with then employer. Wanted to checkout kubernetes, rocket and potentially provide patches. But lost interest.
  • Wrote a bunch of long blog posts which triggered some nice private discussions. 1    2    3
  • Worked a little bit on ithavi - the book on operating systems in tamil, but shamefully minuscule progress. Should do more next year at least.
  • The year began well but lost steam midway, probably due to the decision to change the dayjob after 10+ years with SUSE/Novell. It led to distraction, lack of interest and some sentimental times leading to lesser productivity towards hobby projects. Hopefully the next year will be better, but with a job in a startup that works fast, I am not sure how much bandwidth I may have.
  • Still not convinced if I should work on any of these system software anymore or if I should focus on some other paradigm that is at its infancy. Ken Thompson and Dennis Ritchie worked on Unix when OSes were not mature. Leslie Lamport worked on distributed systems papers which became valuable after more than two decades. Go is now using a paper on garbage collection by Dijkstra and Lamport written in the 70s. So, I am thinking if I should focus on some problems / technologies whose time has not come yet, to feel that excitement of walking on unchartered territories. There are a few options like quantum cryptography etc. which have good theorists who need programmers. If I could collaborate with such intelligent people and synergistically add some value, it will be satisfying. I briefly discussed with some researchers in India (IIT Madras, TIFR etc.) about doing a PhD or helping as an assistant. But not any progress and nothing sounds too promising if work has to be done from India, thanks to our country's brain drain and the Government of India's focus on doing research on loony vedic technologies instead of on useful things. That is enough rant for the year :)
This is a series of blog posts, that I write every year to document and reflect on the learnings, that I have had outside the dayjob. Previous editions: 2014, 2013