Subscribe: Блогчетање
Added By: Feedage Forager Feedage Grade B rated
Language: Serbian
account  accounts  email  emails  files  git clone  git  google  intltool  time  да  донеси ком  донеси  ком  је 
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!

Хм, хм, Пејпал све ближи?

Од 7. септембра ће почети да важи нови уговор са корисником у којем се помиње и Србија и то у зони „Европа 2“ (као и Босна, Хрватска,...).

Па, свратићемо на Пејпал.ком 7. септембра, а ако ни то не упали, увек се можемо поуздати и у наше снаге. ;)

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?

Однеси ми Донеси.ком


Био једном један Донеси.ком. Ценио сам га толико да сам једном ресторану из којег често наручујем, када су ми рекли да могу и директно телефоном да наручим, напоменуо да ипак желим да идем преко Донеси.ком — у њему сам видео вредност коју нема директно наручивање телефоном, а то је остављање утисака.


Већ друга ситуација где је обрисан коментар који је негативан за ресторан. Уредно су ми се јавили са „образложењем“, али не делује баш претерано уверљиво („пошто ресторан није наплатио, не можете да оставите утисак“).

(У првој ситуацији је моја девојка наручила из ресторана који је у том тренутку спонзорисао Донеси.ком, а негативан утисак је нетрагом нестао. Не знам да ли то има везе, али можда вреди поменути.)


Зато, нема више Донеси.ком — од сада само старо добро телефонско наручивање.