Subscribe: Блогчетање
Preview: Блогчетање


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


Трајање ауторских права у Србији
Ауторска права у Србији пре 21. века Почетком двадесетог века, у Србији је на снази био Аустроугарски Закон о ауторским правима на дела књижевности, уметности и фотографије [1895] од 26. децембра 1895. са изменама од 26. фебруара 1907. који је опште трајање ауторских права на заштићена дела ограничавао на 30 година од смрти аутора. Али, током двадесетог века, ауторска права у Србији (Краљевини Србији, Краљевини Срба, Хрвата и Словенаца, те Краљевини па Федеративној народној, Социјалистичкој федеративној и коначно Савезној републици Југославији) су регулисана са више закона: 27. децембар 1929. — Закон о заштити ауторског права[1929] — ступио на снагу даном објаве са ретроактивним важењем 6. јул 1931. — Закон о изменама и допунама у Закону о заштити ауторског права [1931] — од објаве 4. јун 1946. — Закон о заштити ауторског права [1946] — од објаве, ретроактиван 28. август 1957. — Закон о ауторском праву[1957] — три месеца од објављивања, ретроактиван 24. јул 1968. — Закон о ауторском праву[1968] — двадесет дана од објављивања 14. јул 1978. — Закон о ауторском праву[1978] — три месеца од објављивања 15. мај 1998. — Закон о ауторском и сродним правима[1998] — осам дана од објављивања Но, осим закона из 1946. године, сви они су трајање ауторских права одређивали на 50 година након смрти аутора (тј. 50 година од смрти последњег аутора, ако је у питању више аутора, или 50 година од издавања дела ако је аутор анониман или непознат, односно ако је дело издато од стране правног лица). [1946] је, са друге стране, ауторска права ограничио на животни век аутора, и животни век његове жене у случају његове смрти, те њихову децу до навршених 25 година старости (у нарочитим околностима и на родитеље и унуке): очигледна је намера да ауторска права обезбеде „зараду“ самим ауторима за живота и њиховој деци до завршетка школовања, тј. „осамостаљења“. Да не улазимо у то што би у случају смрти жене аутора, муж остао ускраћен за уживање ауторских права на њеним делима :-) Ипак, у складу са међународним конвенцијама, то се враћа на уобичајени облик већ у [1957], и то „ретроактивно“: закон важи и на она дела чија су ауторска права законом [1946] можда истекла (нпр. аутори без супружника и потомака преминули до доношења закона 1957. пошто је и ранији био ретроактиван). Законом из 1957. први пут [...]

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?