My Time in the USA: About Tipping

I’m afraid I don’t have a suitable photo for this post!

Coming from Italy to the US for the first time, it’s important to note a few very different customs. One of these is the already noted bigger portions, that can cause you to overeat if you don’t remember to ask for a box when you’re stuffed. Another big one is tipping. While it’s not unheard of in Italy as well, tipping is not as regular, or regulated, as here. For what I know, tips (mancie) are not declared at all, even if they are supposed to, since they are only possible on cash transaction, as there are no lines in the receipts where you can add tips. Even though Wikipedia says that this requires a citation (maybe I should just take a picture of my next receipt when I go back to Italy).

The reason for this is that the service, i.e., the wage for the waiting staff, is usually included on the bill (usually, explicitly — some rare times it’s included in the price of the food itself, but that’s been rare until a few hours ago). The same is true, as far as I know, in England for the most part, while in France it seems like they are happy to get some.

Anyway, I have to say that up to now, my experience with tipping staff is actually quite positive. It’s not like it changes much of how I go around — even in Italy I tend to always go to the same place, but I guess it helps the fact that I tip well enough that the waitresses remember me, and they almost never bring me the menu nowadays, unless I ask for it (they know already what I’m getting).

A quick check of my past receipts shows that my average tipping is around 22%, with the exception being the breakfasts I get in the morning, which is well over that (but simply because it would be less than eight dollars), at around 50%. This actually paid off, since I didn’t have to know about the local diner’s “Breakfast Club” — the waiter brought me the card after seeing me one morning after the other, already stamped twice; and the one time I forgot my card at the office, he stamped it twice the next visit. Also, once I actually used the fidelity card, which got me free pancakes, they poured in the coffee with it (which is not supposed to be included).

I guess that for most of the waiting staff, having to survive on tips is far from easy. On the other hand, it feels like the waiting staff here is more caring about the single customer’s experience (since their living depends on it) rather than the frenetic “serve as many customers as possible in the shortest time as possible” that most of the Italian restaurants (as in, in Italy) focus on. Even in places I like, and where I know the owner since forever, don’t have the same friendly service.

Googling around, it seems like there is a lot of angst and grief around the concept of tipping – I was looking around to see how much to tip a cap driver since today I went to Santa Monica to see The Oatmeal – and I can from one point understand why, on the other hand it’s also an easy to use them as a way to make sure that you’re offered a decent service. Like the cab driver who brought me back, and who insisted for me to get cash on the ATMs, which meant I had to walk three blocks over, and pay another $3 in fees, and got less than 10% tip (if he accepted the credit card, he would have gotten 20% — yes that means waiting and paying the extra fee, but it’s still more than he got).

I guess one of the reasons why I’m not having much problem, as a customer, with tipping, is that Free Software works the same way. We’re for the most part not paid, or paid (as related to opensource) a minimum wage, and all we do is compensated for the most part in tips … which are actually rarely enough to cover our side of the expenses — I can actually write quite a bit on the subject as recently I found out how much it costed me, in power alone, to run Yamato and the tinderbox at my house.

So in all of this, I can actually say that it’s one of the things that I have really no problem whatsoever with, during my stay here.

For A Parallel World: ebuild writing tip: faster optional builds

Today lurking on #gentoo-hardened I came to look at an ebuild written particularly badly, that exasperated one very bad construct for what concerns parallel builds (which are a very good thing with modern multi-core multi-thread CPUs):

src_compile() {
  if use foo; then
     emake foo || die
  fi

  if use bar; then
    emake bar || die
  fi

  if use doc; then
    emake doc || die
  fi
}

This situation wastes a lot of processing power: the three targets with all their dependencies will be taken into consideration serially, not in parallel; if you requested 12 jobs, but each of foo and bar only have three object files as dependencies, they should have been built at the same time, not in two different invocations.

I admit I made this mistake before, and even so recently, mostly related to documentation building, so how does one solve this problem? Well there are many options, my favourite being something along these lines:

src_compile() {
  emake 
    $(use foo && echo foo) 
    $(use bar && echo bar) 
    $(use doc && echo doc) 
    || die "emake failed"
}

Of course this has one problem in the fact that I don’t have a general target so it should rather be something more like this:

src_compile() {
  local maketargets=""

  if use bar ; then
    maketargets="${maketargets} bar"
  else
    maketargets="${maketargets} foo"
  fi

  emake ${maketargets} 
    $(use doc && echo doc) 
    || die "emake failed"
}

This will make sure that all the targets will be considered at once, and will leave make to take care of dependency resolution.

I tried this approach out in the latest revision of the Drizzle ebuild that I proxy-maintain for Pavel; the result is quite impressive because doxygen, instead of taking its dear time after the build completed, runs for about half of the build process (using up only one slot of the twelve jobs I allocate for builds on Yamato).

Obviously, this won’t make any difference if the package is broken with respect to parallel build (using emake -j1) and won’t make a difference when you’re not building in parallel, but why not doing it right, while we’re at it?

Some tips for both students and mentors for SoC (but not limited to)

While I wrote my rant about last year’s SoC I started to think of some advises for both students and mentors of Google Summer of Code.

I have to say first off that I didn’t partecipate actively as a mentor in 2006 (I was backup), and I didn’t partecipate last year at all, so you have to take these suggestions as an outsider’s suggestion, but, I think, a quite experienced outsider, by now.

  • Work in advance. Don’t wait till your application is accepted. Plan ahead, if you intend to partecipate, start working already! Find an interesting idea, and start fleshing out details. How are you going to work on it? Can you already prepare a few use case diagrams? Can you design an interface already? This is an investment, even if you don’t get accepted, the goal of SoC is to put you into a real-world environment, and doing this work is the first step. Think of it like trying to sell an idea to your superior, or a new company you want to work for. Also, it should give you quite an edge, showing you care about the experience more than the money (which in turn should mean you might actually continue working on the thing afterward).
  • Ask around! An important task for any developer, not limited to Free Software developers, is to be able to ask the right questions. If you’re a free software developer, you most likely have to ask one day to people who worked on similar issues than your own, colleagues and similar, so that you don’t have to re-implement the wheel every time. Searching documentation is cool, but it’s not always going to cut it as you might not find any reference to what you want to know. If you need information, you have to ask not only your mentor, but whoever has the information you need. Your mentor is supposed to know more about the project which you’re working on than you, but if that is not the case you has to find someone to give you the information. Trying to work without knowing the conventions and similar is not going to produce good results.
  • If you’re working on a testable project (a library, or a non-interactive tool), write testcases: doing so will make sure that your mentor can tell your work is proceeding correctly. And will give you a way to make sure you don’t end up breaking what you wrote a week before. In addition, I’d suggest you to write one test each time you do find an error in the behaviour, even if that means you end up with hundreds of tests!
  • Profile your code. Profiling is an important task for making sure of the quality of the code; while in most universities you’re done with writing a working solution, or a working not over-complex solutions, in real world you have to write code that doesn’t suck. And that means it has to run in a timely fashion and not abusing memory. Try looking around in my blog about memory usage and cowstats for instance. You need to learn how to use tools like that, smem, valgrind, and so on. This is the best time!

Mentors should look at these points above, and see what they can do to facilitate their students. Be around to answer their questions, point them to the right person to ask if you can’t answer them. Make sure you know how the testsuites work in the language of choice of your student, this way you can judge if he’s doing them right or if he’s just testing the behaviour that is known to work; also, try to figure out patterns that are not yet tested for, and ask the student to test those.

Up to now the suggestions refer to any organisation and project involved in Summer of Code, not just Gentoo. So feel free to link this post (or quote it, please still reference my blog though) to your students.

As it might be that not all the developers writing up as mentors will have time to do all of the above, I’m at least going to help by trying to stay around for the students. This means that if you have any question, especially related to C or Linux programming (ELF files, memory usage, compiled code analysis – both static and dynamic), feel free to contact me. In the worst case I’ll have to answer you “ask me again tomorrow, I’m busy” or “sorry this I don’t know, it’s not my area of expertise”. It’s worth a try :)

(Joshua, Alec, whoever, feel free to link this blog in the SoC page).

Using the Trash transparently in more partitions

I think this is something that can be useful to people to know.
With new trash support, that should be used by Gnome, KDE and XFCE transparently, one can have a trash directory for every partition, so the “Move to trash” action does not take eons to move big files around…
Also if someone can think that this is something that is just for lusers or similar, I think a trash can be helpful, always, as everybody can be not-so-present with the mind sometimes.

So well, what has one to do to be able to use the Trash effectively outside his home, in a partition where he can’t give the user the full write control (like / or /var) ?

Quite simple actually:

sudo mkdir /.Trash
sudo chmod 1777 /.Trash

repeat that for every partition where you want trash support enabled, and there you are :)

Ok the real reason I blogged this was to avoid forgetting this again :P