Блогчетање

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

Sun, 27 Sep 2026

TL/DR:

  • Each container had around 7.4MiB of host memory overhead for Docker shim and proxy services.
  • Binding only IPv4 port got that down to 6.2MiB per container by running half the proxies.
  • Configuring Docker with userland-proxy: false avoids the proxy altogether and gets overhead down to 4.3MiB
  • Memory usage between Ubuntu and Alpine was mostly the same other than a few exceptions.
  • Rust (1MiB) beats Go (1.5MiB), with Python in the middle (9.4/10.9MiB), followed by TypeScript (~15MiB) and C# last (18.5MiB).
  • Measuring after 200 requests and 15s of settling afterwards, keeps the order but TypeScript and C# fall further behind: Rust (1MiB), Go (3/5MiB), Python (9.7-11MiB), TypeScript (20/26MiB) and finally C# (30/31MiB).
  • dockerd at ~70MiB and containerd at ~50MiB were relatively stable between runs.
  • Ubuntu surprisingly beat Alpine variants in Go (2.9MiB vs 4.9MiB) and Python (9.7MiB vs 11.1MiB) while losing in TypeScript (26.2MiB vs 20.1MiB).

Scope

I was looking to understand overhead of using Docker to run simple network services (basic "Hello World" API service) in different language runtimes and using different base OSes (Alpine Linux and Ubuntu 26.04), and any simple systemic options to optimize that a bit.

The five languages I wanted to compare were Go, Rust, TypeScript, Python and C#.

Methodology

The benchmark was really simple: a basic API handler returning "Hello World" string using whatever the Claude Code/Codex thought made sense as the simplest web framework for the language: Tokio for Rust, ThreadingHTTPServer for Python, node:http for TypeScript, net/http for GoLang and WebApplication for C#. This is not representative of production loads and is mostly to understand the overhead before you start adding actual business logic inside.

Early on, Claude Code mentioned 2 proxy processes for each container: one to bind to IPv4 port, and another to bind to IPv6 port. This made me check: in the idle state (containers stopped and then restarted), baseline memory usage was around 7.4MiB when both IPv4 and IPv6 were proxied, and 6.2MiB with just IPv4 (down by about 1.2MiBper container). From there on, I focused on running with only IPv4 assuming you can always choose which one you prefer for your internal docker communication.

For every run of the benchmarks, I'd stop the docker services (docker compose stop), restart them and only then run the benchmark script with sudo to collect PSS data as RSS was double-counting. Claude Code and OpenAI Codex both contributed to the benchmark scripts which are pushed to [email protected]:dsegan/docker-memory-overhead.git.

To gather idle data, I did sudo scripts/report.sh report --requests 0 --settle 15 --samples 1, and for warm data I did sudo scripts/report.sh report --requests 200 --settle 15 --samples 5.

Idle Results for both IPv4 and IPv6 being served

servicecurrentWSanon filekernelswappeak taskshost taxestimateendpoint
csharp-alpine18.118.18.4 7.91.60.018.5 227.425.5ok
csharp-ubuntu18.518.58.9 7.91.80.019.3 227.425.9ok
go-alpine1.61.61.1 0.00.50.04.9 57.38.9ok
go-ubuntu1.61.61.2 0.00.50.04.7 57.69.2ok
python-alpine10.910.910.4 0.00.50.013.5 17.418.3ok
python-ubuntu9.49.48.8 0.00.60.010.1 17.717.1ok
rust-alpine0.80.80.2 0.00.60.05.2 97.48.1ok
rust-ubuntu1.01.00.4 0.00.60.05.2 97.48.4ok
typescript-alpine13.013.011.9 0.01.10.016.7 77.320.3ok
typescript-ubuntu17.617.616.4 0.01.20.021.8 77.425.1ok
Sum92.592.567.7 15.89.00.0119.9 8874.3166.810/10 ok

Idle Results with just IPv4

servicecurrentWSanon filekernelswappeak taskshost taxestimateendpoint
csharp-alpine21.318.58.4 10.91.60.021.6 226.024.5ok
csharp-ubuntu21.918.78.8 11.31.80.022.5 236.325.0ok
go-alpine3.71.51.0 2.20.50.05.4 56.47.9ok
go-ubuntu1.71.61.1 0.10.50.04.7 56.07.6ok
python-alpine12.310.910.4 1.30.50.014.7 16.317.2ok
python-ubuntu10.69.48.8 1.10.60.011.7 16.415.8ok
rust-alpine0.80.80.2 0.00.60.05.5 96.27.0ok
rust-ubuntu1.11.00.4 0.10.60.05.4 96.17.1ok
typescript-alpine14.713.111.9 1.61.20.017.8 76.319.4ok
typescript-ubuntu19.217.716.4 1.51.20.023.2 76.323.9ok
Total107.393.267.4 30.19.10.0132.5 8962.3155.410/10 ok

Warm results with both IPv4 and IPv6

servicecurrentWSanon filekernelswappeak taskshost taxestimateendpoint
csharp-alpine50.530.111.1 37.31.90.050.9 247.737.8ok
csharp-ubuntu48.731.511.6 35.11.90.049.2 237.839.2ok
go-alpine4.94.92.1 2.30.50.06.1 67.712.7ok
go-ubuntu4.92.92.1 2.30.50.06.2 57.810.7ok
python-alpine17.711.110.4 6.60.60.020.0 17.818.9ok
python-ubuntu13.99.78.9 4.30.70.015.6 17.817.5ok
rust-alpine1.30.90.2 0.50.60.05.1 97.78.6ok
rust-ubuntu1.51.10.4 0.40.60.05.2 97.78.8ok
typescript-alpine44.920.114.1 29.41.40.047.1 77.928.0ok
typescript-ubuntu58.926.220.2 37.21.50.059.6 78.034.3ok
Total247.2138.581.1 155.410.20.0265.0 9277.9216.510/10 ok

Warm results with just IPv4

servicecurrentWSanon filekernelswappeak taskshost taxestimateendpoint
csharp-alpine38.125.711.1 24.81.80.043.3 246.532.2ok
csharp-ubuntu39.025.312.3 24.51.90.045.0 246.331.6ok
go-alpine2.72.22.0 0.50.50.14.9 56.58.7ok
go-ubuntu3.72.62.1 1.20.50.05.5 56.38.8ok
python-alpine12.110.810.4 1.20.40.019.0 16.317.1ok
python-ubuntu10.89.38.9 1.60.40.014.1 16.415.6ok
rust-alpine1.30.80.2 0.50.60.05.2 96.27.0ok
rust-ubuntu1.51.00.4 0.40.60.04.9 96.37.3ok
typescript-alpine19.815.914.4 4.21.20.040.5 76.422.4ok
typescript-ubuntu26.221.620.1 4.81.30.051.8 76.428.0ok
Total155.2115.281.9 63.79.20.1234.2 9263.6178.710/10 ok

userland-proxy: false

servicecurrentWSanon filekernelswappeak taskshost taxestimateendpoint
csharp-alpine47.133.99.2 35.81.70.049.1 234.438.3ok
csharp-ubuntu50.638.413.6 35.21.80.051.3 224.342.7ok
go-alpine4.83.62.1 2.30.50.06.2 54.37.9ok
go-ubuntu5.13.82.3 2.30.50.06.1 54.58.3ok
python-alpine17.312.410.4 6.30.50.019.8 14.316.7ok
python-ubuntu15.410.98.9 5.90.60.017.3 14.215.1ok
rust-alpine1.31.10.2 0.50.60.05.1 94.55.6ok
rust-ubuntu1.51.30.4 0.40.60.05.4 94.35.6ok
typescript-alpine44.119.314.4 28.41.20.046.3 74.523.8ok
typescript-ubuntu51.925.520.3 30.31.30.052.6 74.329.8ok
Total239.1150.281.8 147.49.30.0259.2 8943.6193.810/10 ok

Options & Alternatives

If getting the overhead down is the goal, there are tools which you can leverage which may or may not be suitable:

  • Drop the userland-proxy from Docker Daemon.
  • Avoid languages which aggressively use up your memory: Rust and Go are clear winners, with a surprising show from Python staying mostly stable, and bad results from NodeJS and C#.
  • Podman is daemonless and might avoid the overhead altogether.
  • LXD/Incus might be worth exploring, but they provide system containers vs application containers.
  • Systemd units with sandboxing (but without filesystem isolation) between services should get the overhead down to zero.
  • Snaps to add filesystem isolation to a feature-set similar to systemd units — but not designed for this type of use-case.
  • ...

Conclusions

Docker is not well suited to running on low-memory platforms as always-running daemons take around 100MiB of memory, on top of 4-6-8MiB of additional memory per container: a system with 20 containers will use up 220MiB of RAM just to orchestrate containers, and that's without any service actually operating. With 20 Rust or Go services you might just about fit into 256MiB of RAM, but you'll be looking OOMs in the face. If you are using anything else, 512MiB is going to be low as well.

Finally, take the above results with a (big) grain of salt: benchmark code has been built by LLMs, and it is not representative of any production loads.

[21:48] | [razvoj] | # | G | | TB

Sat, 29 Aug 2026

Judge Dread? Or welcome to my first LLM-related post.

As LLMs and especially coding agents became part of our daily workflows, we started relying more on actual judgement of models we use — judgement, to me, is any decision they default to based on their training and pre-processing without humans actually directing them with prompts or skills.

It might be a simple decision about using tabs or spaces, or a more complex one about how to structure your tests and test fixtures, but you can already get a lot done by offloading decision-making as well.

While this is fast improving, I wanted to test my understanding by asking them to do an extremely common test by Simon Willison of generating a vector image of a pelican riding a bicycle, but with a twist: instead of asking for an SVG, ask for a conceptually different vector format PostScript (really, a programming language), which is closer to the plotting/printing model from 80s, with instructions like moveto, Y-axis actually going upwards, for loops, matrix transformations etc — enough difference in semantic interpretation and less training data to throw a frontier model off :)

My expectation was that they would be a generation or two behind compared to what Simon is getting with SVGs.

I'll let you be the judge if my foresight was right or not.

Prompt: Generate a native PostScript image of a pelican riding a bicycle.

Some quick notes

  • I tried converting PostScript files with ImageMagick first, but after seeing it miss a few things during conversion, decided to use GhostScript loader from within Inkscape instead and export a PNG out.
  • Gemini 3.7 Flash had a broken first version which it was able to fix with the Ghostscript error message passed back (I think it was wrong parameters for ellipse command).
  • Opus 5 took around 4 iterations of rendering to a raster image and reviewing (also hitting a PS syntax error), but managed to improve with each cycle. I did not check the costs, but it was probably expensive :)
  • My first few attempts were with a slightly different prompt of "Make an PS or EPS (PostScript) of a pelican riding a bicycle" ("an" typo included — I probably went for EPS first and never corrected the language). This resulted in greyscale images in ChatGPT confirming that this might be worth looking into. I did not approach it scientifically at all, but switching to "Generate" to match Simon's version always produced a colorized version.
  • All of the text in this post was hand-typed, including the em-dashes.
[21:19] | [llm] | # | G | | TB

Sat, 21 Jan 2017

Ауторска права у Србији пре 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. први пут се раздвајају морална и имовинска права аутора, док је важна промена у закону из 1998. године то што престаје да постоји правно лице као носилац ауторских права.

Важно је приметити и да су неки од горњих закона били и „ретроактивни“ — осим што су продужавали рокове и опсег заштите за дела чија заштита још није истекла (ја чак и то сматрам ретроактивним, али у правном речнику се изгледа тај израз другачије користи), такође су продужавали рокове и проширивали опсег заштите за дела којима би по ранијем закону заштита истекла, а по новом није.

Ауторска права у Србији у овом веку

Нови век доноси са собом и ново време. Живи се све брже, и ауторска дела имају све краћи рок „трајања“, а рок заштите ауторских дела је... све дужи.

Тако први закон о ауторским и сродним правима новог века у Србији (тј. Србији и Црној Гори), Закон о ауторским и сродним правима[2004] продужава трајање заштите на 70 година (од смрти аутора или од издавања ако је аутор непознат или правно лице). Новији, последњи Закон о ауторским и сродним правима[2009] не доноси значајне измене у погледу трајања основних ауторских права. Оба су ступила на снагу осам дана од објављивања у Службеном гласнику СЦГ, односно Србије.

Занимљиво, у изменама закона[2011] се враћа појам „колективног дела“ код којих ауторска права трају 70 година од објављивања (где су колективна дела она настала „спајањем већег броја прилога у једну целину“ одређена у [2009], а дати примери су енциклопедије, антологије, рачунарски програми, базе података).

Трајање ауторских права по законима

ЗаконАуторЗаштитни рокРетроактиван?
1929.познат50 год од смртида
непознат или правно лице50 год од објављивања
1946.није одређенодо смрти или смрти/преудаје супружника („жене“), односно до навршене 25. године ауторове децеда
1957.познат50 год од смртида
непознат или правно лице50 год од објављивања
1968.познат50 год од смртине
непознат или правно лице50 год од објављивања
1978.познат50 год од смртине
непознат или правно лице50 год од објављивања
1998.познат50 год од смртине
непознат50 год од објављивања
2004.познат70 год од смртине
непознат70 год од објављивања
2009.познат70 год од смртине
непознат70 год од објављивања
2011.колектив70 год од објављивањане

Шта више није заштићено?

Да бисмо утврдили шта од ауторских дела издатих у Србији више не подлеже заштити ауторских (имовинских) права, морамо узети неколико ствари у обзир:

  • Неки од закона су ретроактивни (важе и на дела чија су права можда истекла пре њиховог доношења)
  • Законски рок почиње да тече од 1. јануара наредне године од године у којој је ауторско дело издато
  • У случају познатих појединачних аутора, смрт оног који је најкасније умро одређује почетак тока заштитног рока, док у случају дела чији су „аутори“ правна лица или непознати (анонимни или под псеудонимом без познатог грађанског имена аутора)
  • Сваки закон је важио до дана који претходни дану ступања на снагу наредног закона
ЗаконОбјављенСтупио на снагуВажио доТрајање заштитеИстекла заштита
[1895]26. дец 1895.26. дец 1895.26. дец 1929.3031. дец 1898.
[1929]27. дец 1929.27. дец 1929.03. јун 1946.5031. дец 1895.
[1946]04. јун 1946.04. јун 1946.27. нов 1957.027. нов 1957.
[1957]28. авг 1957.28. нов 1957.12. авг 1968.5031. дец 1917.
[1968]24. јул 1968.13. авг 1968.13. окт 1978.5031. дец 1927.
[1978]14. јул 1978.14. окт 1978.22. мај 1998.5031. дец 1947.
[1998]15. мај 1998.23. мај 1998.31. дец 2004.5031. дец 1953.
[2004]24. дец 2004.01. јан 2005.18. дец 2009.7031. дец 1938.
[2009]11. дец 2009.19. дец 2009....7031. дец 1946.
[2011]26. дец 2011.03. јан 2012....7031. дец 1946.

Напомена: за дела објављена 1954. године, могуће је да су њихова права такође „истекла“. Пошто је [2004] почео да важи тек од 1. јануара 2005. то би сва дела чији је рок од 50 година почео да тече 1. јануара 1955. истекао до 31. децембра 2004. 23:59:59.9999... Но, пошто не знам какав је правни третман у овом граничном случају, ограничио сам се на оно што је сигурно истекло.

Најзначајнији су „масни“ датуми, те тако имовинска права више нису заштићена:

  • Свим делима чији су сви аутори преминули до 31. децембра 1953. године
  • Свим делима непознатих аутора (непотписаних или под псеудонимима за које се не знају грађанска имена) објављених до 31. децембра 1953. године
  • Свим делима објављених до 31. децембра 1947. године чији је носилац ауторских права правно лице

Значајно је приметити да, од продужења трајања заштите на 70 година [2004] ниједно ауторско дело није остало без заштите: почетком 2017. године, по актуелном закону, тек би дела објављена 1946. године постала слободна за употребу, односно, мораћемо сачекати још две године (до 2019.) да би се напокон нека нова дела нашла у „јавном власништву“, и то би се односило само на „колективна дела“ која изменама из [2011] уживају заштиту само од дана објаве, а не од смрти последњег аутора. За остала дела, мораћемо сачекати још додатних 5 година (почетак 2024.), па ће коначно и дела објављена 1954. године бити слободна за употребу.

Додатна појашењења

Ваљда је од почетка јасно да нисам правник, те да се овде записано мора узети са резервом. Шта год да радите што се тиче ауторских права, пре свега се обратите својој савести, а потом и неком правнику.

Пошто ме превасходно занима употребљивост давно објављених књижевних дела, нисам се дотицао оних врста ауторских дела на које у одређеним законима важе другачији рокови заштите (по правилу краћи, а ту нарочито спадају фотографије у старијим законима, односно базе података у новијим). На тај начин сам поједноставио анализу, али за сваку врсту грађе се, помоћу горње табеле и употребом истог обрачуна уз другачији рок може добити жељени резултат.

Повремено чак и текст поједностављујем тако што кажем само „од дана издавања“, а то може, у зависности од актуелног закона, значити разне ствари (нпр. „од дана издавања ако је издато за живота аутора, а иначе од дана његове смрти“; или, „од дана када је последњи наставак објављен“...). Ако сте у дилеми, не верујте ничему што пишем: нити сам правник, нити ћу прихватити одговорност за било какво туђе деловање на основу мог мишљења.

Библиографија

  • [1895] Gesetz, betreffend das Urheberrecht an Werken der bildenden Künste und der Photographie, 26. децембар 1895.
  • [1929] Закон о заштити ауторског права, Службене новине Краљевине Југославије, Година XI — 1929. број 304—CXXIX, 27. децембар, 1929.
  • [1931] Закон о изменама и допунама у Закону о заштити ауторског права од 26 децембра 1929 године, Службене новине Краљевине Југославије, Година XIII — 1931 — број 150, 6. јул 1931.
  • [1946] Закон о заштити ауторског права, Службени лист Федеративне Народне Републике Југославије, број 45, 4. јун 1946.
  • [1957] Закон о ауторском праву, Службени лист ФНРЈ, број 36, година XIII, 28. август 1957.
  • [1968] Закон о ауторском праву, Службени лист СФРЈ, број 30, година XXIV, 24. јул 1968.
  • [1978] Закон о ауторском праву, Службени лист СФРЈ, број 19/78 са допунама у 24/86 и 21/90, 14. јул 1978.
  • [1998] Закон о ауторском и сродним правима, Службени лист СРЈ, 24/98, 15. мај 1998.
  • [2004] Закон о ауторском и сродним правима, Службени лист СЦГ, 61/04, 24. децембар 2004.
  • [2009] Закон о ауторском и сродним правима, Службени гласник РС, 104/09, 11. децембар 2009.
  • [2011] Закон о изменама и допунама Закона о ауторском и сродним правима, Службени гласник РС, 99/11, 26. децембар 2011.
[10:32] | [os] | # | G | | TB

Tue, 17 Dec 2013

(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 :)

[15:29] | [zivot] | # | G | | TB

Wed, 23 Nov 2011

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.

[18:21] | [razno] | # | G | | TB

Sat, 08 Oct 2011

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!

[22:22] | [gnome] | # | G | | TB
Contact
Danilo Segan

This is blog (web log) of Danilo Šegan (or Данило Шеган).

Archives
2026-Sep
2026-Aug
2017-Jan
2013-Dec
2011-Nov
2011-Oct
2011-Aug
2011-Jul
2011-Jun
2011-May
2010-Oct
2010-Aug
2010-Jul
2010-Apr
2010-Mar
2010-Feb
2010-Jan
2009-Dec
2009-Oct
2009-Aug
2009-Jun
2008-Oct
2008-Aug
2008-Jul
2008-Jun
2008-May
2008-Apr
2008-Mar
2008-Feb
2007-Dec
2007-Oct
2007-Aug
2007-Jul
2007-May
2007-Apr
2007-Feb
2007-Jan
2006-Nov
2006-Oct
2006-Aug
2006-Jul
2006-Apr
2006-Mar
2006-Feb
2006-Jan
2005-Sep
2005-Jun
2005-May
2005-Apr
2005-Mar
2005-Feb
2004-Dec
2004-Nov
2004-Oct
2004-Sep
2004-Aug
2004-Jul
2004-May
2004-Apr
2004-Mar
2004-Feb
2004-Jan
2003-Dec
2003-Nov
2003-Oct
2003-Sep
1983-Mar

< September 2026
MoTuWeThFrSaSu
  1 2 3 4 5 6
7 8 910111213
14151617181920
21222324252627
282930    
Categories

Links
Kvota.net
Prevod.org
My study page
Srpski.org
GNOME
Friends' Blogs
alex (en)
bc (en)
Bojan Živanović (sr)
Carlos (en)
Goran (sr)
imp (sr)
lilit (sr)
Oskuro (en)
Zombie (sr/en)
Feeds
RSS