Оно што је мени занимљиво сада је да напоменем које су то разлике између сегментирања и страничења, бар на Интеловим процесорима, пошто о њима једино понешто и знам.

На првом месту, сегментирање је обавезно на Интеловим процесорима — оно се не може искључити, већ се једино може привидно заобићи тако што се направе сегменти за код, податке, стек исте величине, и са истим положајем.

Страничење, са друге стране, обезбеђује виртуелни адресни простор, и то је основни разлог зашто се оно чешће користи од сегментирања. Па, можда вас занима чему служи виртуелни адресни простор?

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

Ваља поменути и да странице на Интел процесорима новијим од Пентијума могу бити и 4МБ, чиме се обезбеђује знатно већи адресни простор, а у ограниченом пољу примена и већа брзина.

Сегментирање, са друге стране, је одличан механизам у који је уложено много више труда и напора при стварању Интел процесора. Једина, условно речено, „мана“ у односу на страничење је што не користи блокове утврђене величине, и самим тим је проналажење одговарајућег сегмента операција која се обавља у два корака (1. погледај где се налази тражени сегмент; 2. припреми тај сегмент за употребу — код страничења се положај странице имплицира њеном адресом [мада у пракси, и то захтева једно гледање у табелу], и она се може одмах „довући“).

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

Оно што говори о супериорности сегмената у односу на странице је то што је могуће сегменте додељивати на произвољан начин, и то било као „глобалне“ (уписане у глобалну табелу описника, тј. GDT) или „локалне“ (за појединачни процес, дефинисан помоћу TSS-а, а ово се уписује у засебну табелу за сваки од таквих процеса: LDT).

И где је овде предност сегмената у односу на странице? Као прво, раздвајањем сваког дела оперативног система, корисничке спреге, и корисничких програма у засебне сегменте аутоматски повећава безбедност — нпр. драјвер (гонич :) не може да приступи осталим услугама језгра, или меморији других драјвера и програма (иначе, садашњи оперативни системи то решавају тако што користе друге могућности Интел процесора за заштиту, као што је „ниво рада“, где се нулти ниво резервише за језгро; ово, наравно, не чува друге програме до самог језгра). Ово је хардверски безуслован начин да се обезбеди заштита меморије.

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

Са практичне стране, сегментирањем се може постићи исто што и страничењем, док обрнуто није случај. Када се користе заједно, може се рећи да је страничење „испод“ сегментирања, тј. сегменти су одређени у односу на виртуелни адресни простор постављен страничењем.

На несрећу, већина језгара је одлучила да поједностави што је више могуће основну спрегу са процесором, па тако имамо случај где нпр. у Линукс језгру није могуће омогућити процесу директан приступ У/И портовима већим од одређеног броја, зато што њихова битмапа није стала у једну меморијску страницу (тј. 4КБ, односно У/И портови преко 0x8000) заједно са TSS-ом (ово је било тачно бар до 2.2 серије, али сумњам да је ишта измењено од тада). На тај начин, софтвер намеће ограничења ради једноставности израде, иако хардвер нуди много више.

Жеља ми је да једног дана нађем више времена да о овоме размислим, и покушам можда да направим и прототип језгра које ће увелико користити сегментирање. Е па, зато и сва ова писанија — не желим да заборавим на све ово у потпуности :)

And this has apparently been released only a couple of hours back, which means that there's no way Google could have indexed it :)

For those who have missed most of it, the first announcement (I know of) is on libc-alpha mailing list. If you want to track development, visit glibc-bsd project page at Savannah.

KDE has a solution for this, but it is based on XML parser built-in Qt. Yuck, a dependency of tens of megabytes just to be able to translate documentation in an efficient manner.

Fortunately, this has long been a recognized problem for translators in Gnome, and there were several attempts to solve it. That includes doc-i18n-tool included in intltool, but not build by default. It was developed in C using libxml2 parser. That means that it makes use of widespread and great parser which Gnome is based around (libxml2), but it also means that it uses obscure language such as C for text processing, which makes it basically a nightmare to create a working prototype.

So, I've took a different approach: I used libxml2 via Python, and that made it possible to create a tiny program which does the job suitably for Gnome Summary. I have also performed some tests with Bug Buddy manual, so I think it is at least sometimes possible to use this for general DocBook documents.

Grab it at kvota.net/hacks/xml2po, where you can find program and example summary, README on how to produce a translation out of it, and Serbian translation (btw, anyone volunteers to do Serbian translations in the future? they will be featured on developer.gnome.org and gnomedesktop.org, so it's a good way to get noticed :).

There are whole lot of quirks and missing features (check the TODO as well), so there's lot to do to make it really usable. In any case, I'd recommend it to Serbian documentation translators for now, so it would be easier to track document changes.

Whoever wants to track development may try my anon CVS:

cvs -z4 -d:pserver:anonymous@cvs.kvota.net:/cvs/i18n co xml2po

intltool bug: by yours truly

Let me not forget: I had the (not so) rare privilege of finally introducing a bug in some core Gnome component. Yes, ladies and gentlemen, I've introduced a bug in intltool which makes it bork for many modules and programs (and not "rarely" as I first though). So, step right on, and get yourself a new intltool 0.29 release, which features a bug made just for you. I was nice enough to even provide a fix for that, so you might want to check out latest intltool from CVS, or look at the simple patch bug #131885 (close to the bottom, inside a message, not attached).

I've been hacking sporadically on intltool, so Kenneth added me to new intltool list hosted at freedesktop.org.

So, if your modules don't build anymore, close your eyes, and think of me :)

I have tried compiling it in the past, but never actually made it perform well. I have used built-in GC (Garbage Collector), but it made it crash on my pretty ancient system (GCC 2.95.3, GNU libc 2.2.3). If I don't use GC at all (--with-gc=none), it borks with mysterious error message of "NullReference where Object as expected" (or something like that) for a bit more complicated code (like 20+ lines of C#, meaning, I'm not even able to recompile Mono from CVS after that, because it requires a working Mono installation; bah, bootstrapping sucks). Since newer GCC's seem not to show up this (nobody else complained), it's most likely a GCC bug.

Luckily, there's an option for another GC, one of Hans Boehm, and that's what made it work, provided I compile it with "--enable-threads=pthreads". For the record, I've used gc 6.3alpha4 version from January 1st, 2004 — I don't mind occasional bugs, as long as it doesn't bork it completely.

So, if you Mono segfaults in "GC_mark_show", that may be the culprit.

Mono from CVS is now being compiled, which leaves me with some time to actually update database for "common Serbian computer dictionary". Hope to put it online tonight, and redirect all requests from prevod.org/recnik to new dictionary.

alert: cannot start: unable to open mutex

Google was not of any help there, but strace helps to find out that it tries to access file lock/sendmutex, so all you need to do is to recreate it, and set the owner to qmails:qmail.

On the matter of why this happened at all, I have a fairly simple explanation: I have been HUP-ing and KILL-ing qmail-send quite agressively, while doing some testing.

Unfortunately, I may have missed some mail during these ten minutes, so if I don't respond to you in the near future, perhaps that's what happened: please resend it.

Гномов управник дисковима треба да замени magicdev, који је досад обављао слични посао, само за мање врста уређаја (углавном само за ЦД-е).

Ипак, за ову новину је потребно доста најновијег софтвера, као што је слој за апстракцију хардвера (HAL), и једноставнији систем за међупроцесну комуникацију (DBUS). Уз то, HAL тренутно може да користи само могућности Линукс језгра серије 2.6.

Ево напокон и озбиљног разлога да освежим свој систем ;-)

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

Хех, надам се да је Горану овај допис био бар једнако забаван како је био мени, јер сам саставио баш леп одговор (што ме подсети да ће га и он примити, па можда му се и свиди мој разговор са Латиницом).

Такође, данас је наступио и велики помак у подршци Наутилуса (програм за управљање датотекама у Гному) за српски језик: напокон је примењена допуна која омогућава испис израза са бројем у зависности од самог броја (нпр. „21 цвет“, „4 цвета“ и „377 цветова“, уместо „21 цветова“, „4 цветова“ итд.). Пре примене сам је морао допунити, и то се налази забележено у Бубаждаји под бројем #106702.

Дејв Кемп је „одобрио“ убацивање измена у код, иако није детаљно прегледао допуну.

У сваком случају, сада Наутилус више не изгледа смешно када се приказује број фајлова у директоријуму.

That's excellent stuff for testers, developers and others who like to be on the edge of Gnome development. The stuff I appreciate is that it's written in Python, which means nice code :)

Yet, there is one feature I missed dearly, so I set out to make it: JHBuild did all of it's building in the same directory where the source code was check out, and this interfered with my work habbits. First of all, my CVS checkout of Gnome apps is on a separate partition that doesn't have too much room to spare. Also, I like to keep my primary CVS checkout tree clean, because I do commits all over the place, and if build system changes something, or I hack something to make it work, I may later commit accidentally something I didn't mean to.

So, better separate it out. I've attached a patch to do that along with a RFE (Request For Enhancement you unenlightened folks) in Bugzilla as bug #131296.

Go ahead and post your comments and suggestions either here or in Bugzilla (you'll need to register an account for Bugzilla).

I switched to using SuExec on a new machine, and it seems to refuse to execute scripts which have +rw set for the group, eventually spitting out the error message in the form of "Premature end of script headers".

Yeah, as I already said here when transferring my blog, this was pretty non-obvious to find out, especially so since most people tend to look for Pyblosxom problem, instead of SuExec.

Though, Data might be having entirely different problem, but since there are some security consious comments there, I guess SuExec is used as well :)

Ипак, у последње време појављује се све више „дневника на вебу“ (у енглеском језику опет исти израз), односно, људи бележе своје догодовштине и животне путешествије на вебу у облику дневника, без икаквог осврта на оно што се догађа на вебу. То можете приметити тако што у уносима готово да нема веза ка другим страницама, а још мање има расправе о рачунарству. Ја сам и даље привржен „старом“ значењу речи „блог“, а и нисам претерано заинтересован за животне приче 50 разних људи из Србије.

Оно за шта јесам заинтересован, и за чију сам „блогчад“ недавно сазнао, су расправе са рачунарском тематиком. Ово значи да и bc и imp заслужују моју пажњу (imp има и најбољи скуп веза ка другим људима, тако да је већ и корисно :), донекле и Радионица (мада се претежно бави неким Виндоуз проблемима, али у потпуности испуњава горњи критеријум „блогчета“). Такође, ту је и лилит, а колику пажњу заслужује њено блогче биће јасно тек када почне озбиљније да га попуњава. У сваком случају, нисам претерано заинтересован за то шта је Ђелиђ рекао ;)

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

Наравно, Зомбијев план о добијању великог броја блогчета (и то не према мом схватању истог, чини ми се) ће учинити да настане и већи број занимљивијих и корисник (према мом схватању :), из чисто статистичких разлога, ако ништа друго. Једино ме брине што 50 није довољно „велики број“ да бих могао да се поуздам у ово.

I guess it was holiday season, after all ;)

I'll try to summarize what has been going on.

First of all, as someone noted on Planet GNOME, Ximian is slowly taking over Novell ;). Novell hired Rob Love (a Linux kernel hacker) to work on desktop integration issues, but this is already old news.

Real news is that Rob is doing very well, which means there's stuff like Gnome Volume Manager. It's good stuff, and he has promised to put it into CVS soon.

The other big stuff around desktop-devel-list is discussion of proposed modules for Gnome 2.6. Since module selection time is (I think, check the release map at yourself, I'm lazy now ;) January 12th, it got pretty heated up. As it seems, most of the proposed modules are not going in (monkey-bubble, g-s-t, gnome-network), some are already in (gnome-keyring, gswitchit), and others are still debatable (rhythmbox, evolution, gal, gtkhtml and evolution-data-server). I'd like Evolution to be in the desktop, but I'd prefer Totem over Rhythmbox (alas, Totem was not even proposed this time, even though it was accepted in 2.4 timeframe, but withdrawn at maintainer's request later on). Actually, what I'd like even more is to see evolution-data-server, and simple addressbook and calendar application. Though, I don't see those simple apps anywhere ;)

Still in the Gnome news, GVADEC (Gnome Users And Developers European Conference) is on schedule for June 28-30, 2003 in Kristiansand, Norway, and there's a call for papers, as well. Call for papers seems modified (I first noticed it with a deadline for abstracts of February 1st, not 16th as it is now), which probably reflects issues Miguel raised in this mail: not enough abstracts submitted, because CFP indicates that they want research papers. That's fine for the D in GUADEC, but it wouldn't really work for the U. I think it will be tragic if it stays that way.

For the rest of the stuff, turn to Planet GNOME, puppet of Jeff's, on a new fancy address.

At the same time, I notice a couple of folks I know started blogging more actively: Jordi Mallach of Debian, and Catalan translator in Gnome, Carlos Perelló Marín (once a Spanish translator, creator of current translation status pages, and most recently, author of a nice Locale and Culture configuration applet).

The new Carlos' applet is good stuff — I hope this will mean no more explaining to folks what is LC_ALL, LANG, LANGUAGE, what priorities do they take, what's LC_MESSAGES, etc. Yeah, I surely hope this will help folks choose their own language in a more natural and easier way.

This is a Dell Inspiron 1100, which is widely available for below $700 at Dell's online store to... US residents. Still, it's possible to use eBay to find someone who's willing to ship it overseas, and that's how I got mine.

This one is a Celeron 2.3GHz, with 256MB memory and 20GB hard drive, and a combo DVD and CD writer. Of course, modem, network, sound and graphics is integrated into Intel i810 board. Network card requires either the latest Linux kernel in the series 2.4 (2.4.23), or getting yourself a separate driver (search for bcm4400). BIOS is riddled with bugs which makes i810 driver in XFree86 4.3 suck (BIOS limits video memory to 1MB, and doesn't accept the request from the driver to change it — reportedly fixed in CVS, which will become 4.4 soon), but there's a simple tool to allow it to be used even with 4.3.

I didn't get modem working, though I didn't even try very hard (I've got a PCMCIA card).

As always, this machine came with Windows preinstalled (XP Home). It took up entire hard drive, and wouldn't let it go. Since I wanted to keep it until I try out Serbian translation of Windows XP, but didn't want it to take over more than 2GB, I had to dump it, and reinstall it later.

Now, I was not too much surprised that my ancient Slackware 8.0 install (which doesn't autodetect anything) didn't detect a thing, though most of it was painless to get working. But, when XP started in 640x480 mode with 16-bit colors, and complained how I should enlarge my resolution (same problem as with X: cannot use more than 1MB of video memory), without a clue about the network card, modem or audio, I started to wonder where is that usability I was often convinced there is (like in discussions on EliteSecurity web forums a couple of months back). Yes, of course, all the drivers were available on a CD. But that usable is any other system too: if vendor provides the drivers, it's not a problem to put them onto a CD, web, or anywhere else. Dell could have also put all the drivers for the Linux kernel and for the XFree86 on a CD (they're all available, except maybe for the modem — Inspirons 1100 apparently come with 3 distinct modem chipsets, and I got the one that has the slightest chances of working).

Ok, point I tried to make earlier got confirmed — installing basic hardware is not easy, and doesn't belong into everyday's work on any system.

As a sidepoint, late in the last year I got a digital camera to play with, and it installed seamlessly as USB storage (once I modprobed all the USB stuff, of course, since this is ancient system ;), and I used Nautilus to view my images. Great, I loved playing with that, but it had to go back ;). Now, I'm seriously considering getting a good digital camera (this one was HP PhotoSmart 850, which is not bad, but is a bit slow on responding).