Subscribe: Блогчетање
http://danilo.segan.org/blog/rss.en.xml
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
account gmail  account  accounts  big  email  emails  files  git clone  git  gmail  google  intltool  people  person  ppa  time  wrong 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Блогчетање

Блогчетање



Данилово блогче



 



You don't have to pick your battles. You just need to accept losing.

(Oh yes, I know about the positive stance of "you should not accept losing", but if you believe in that, you haven't engaged in enough battles yet :)




Routing git clone over "dumb" HTTP?

Doing 'git clone' over either of git:// or http:// backed by git-http-backend results in big memory usage for big repositories (mostly in 'compressing objects' phase). This means that you can usually kill any git server hosting big repos by doing concurrent 'git clone' runs of those repos at the same time.

Instead of doing that, I'd like to keep benefits of the git-http-backend for all users except those using 'git clone'. Anyone has any ideas on how to do that?

OTOH, maybe I am looking for the wrong solution. git supposedly does mmap() of the pack files, and the only thing I need to do is ensure packs are suitably small so they could me "swapped-out" (which equals to being discarded from memory with mmaped files). Or, since git does a mmap() of uncompressed temporary file, maybe I can get git to store uncompressed data instead, allowing it to mmap them directly?

I wouldn't be surprised if I am entirely on the wrong track here. If anybody has ideas on what to do to run a git server with big repositories without needing gazilions of memory, please direct me in the comments section below.




intltool 0.50 released

So, with a few patches already in lp:intltool, I've had some time today to go through all the existing patches attached to bugs and see if I can get them into landable state.

The result is an intltool 0.50.0 release, which has a few reasonably sized changes.

The biggest changes are:

  • #580526: Finally, support for gsettings gschema.xml files is merged in, which should enable maintainers to get a slightly simpler build setup (i.e. no need to use NOMERGE rule anymore, and you can have intltool directly extract translations from .gschema.xml files).
  • #790574: Let xgettext extract Scheme strings out, and add support for intltool-update -m to find files with marked strings.
  • #806006: Improve handling of quotes in intltool-update -m so you get less (no?) warnings about mismatched quotes, and Python processing doesn't get messed up with docstrings and similar.
  • #520986: one for the translators—messages are extracted in the order they appear in original files now, thus allowing translators to infer more of the context from the ordering.

There are a few other bug fixes, but listed above are those with the highest risk factor. Please test and file bugs!




Google: fixing bugs is dumping people?

Story of dotted emails

Around 3-6 months ago, I've started getting email from Facebook for a certain other person on my dsegan account on gmail (only forwarded to my other email, and barely used). Knowing Facebook requires email verification, I was surprised to see that, but since it stopped in a day or two, I've ignored it, attributing it to probable lax policy on Facebook account creation (eg. they could be letting people use their accounts for some time even before they confirm the email or something like that).

Not long after, I've seen more emails sent to a person named with a first name starting on "D" as well and having the identical last name, and directed to d.segan account on gmail. Note the dot in the middle.

This still happens from time to time, and here is what I suspect:

  • Google seems to have allowed at one point in the past accounts with dots in the name to be registered as separate accounts
  • In the meantime, they have disallowed that and made them all aliases to the same account (eg. dsegand.segands.egan…). Old accounts have been left as they were.
  • Sometime in the last 6 months, they've decided to fix this inconsistency.
  • I had registered an account earlier than that other person

It seems as if Google has just decided to delete those accounts created later: meaning, a bunch of people lost email accounts they have used for some time. I've heard reports of other cases like this (I know of at least one other person who started getting emails sent to the same gmail address with a dot in a different place).

If I am not wrong in my analysis, here's a few questions to ponder:

  • Why would Google put sanitizing the system and avoiding bug workarounds ahead of actual people? Did they at least try to let them know of the fact what they are doing?
  • Do they care about privacy? I've already gotten some emails which could be considered confidential and some which are very much private.
  • Are there any better reasons for distributed identities (which emails are, but Google is quickly becoming a monopolist) than realizing that otherwise, you don't have control of your identity at all?
  • Did any of the people who got crapped on like this get another email account at gmail? (masochists :)

And if I am wrong, wtf is going on?




Evolution 3.0 in Ubuntu 11.04

With the great GNOME 3 PPA for Ubuntu, you get most of the GNOME3 desktop.

If you want Evolution as well, I've reused Debian packages and modified it only slightly (to match GNOME 3 dev package names) and built it in my own PPA which depends on the GNOME 3 PPA:

evolution3 ppa



Launchpad meet-up in Prague

Launchpad team is together in Prague, and we are meeting tonight at around 19h at Jama Steakhouse (V Jámě 7).

Anyone interested in meeting up with a bunch of Ubuntu/Launchpad/free software people is welcome to join us. You can probably pick us up from the crowd by the t-shirts. :)