Морам да признам да је моја оцена Transifex‑а из 2022. делимично погрешна, чему је кумовала конфузна почетна страница MC‑а, на којој није било инструкција за регистрацију као сада. Том SaaS‑у, иначе Федорином чеду, је заиста примарни тип налога онај који се плаћа на месечном нивоу, али су били толико „великодушни“ да предвиде и „Open Source налоге“, који се не плаћају... бар не новцем. На страници Privacy се описује које све податке Transifex прикупља о кориснику. Поред података које постави корисник, такође се аутоматски прикупљају и детаљни подаци о типу уређаја, оперативног система, па чак и јединствени идентификациони бројеви уређаја и подаци о апликацијама. Такође се описује са ким се све ти подаци деле: између осталог, и са трећим странама, у које спадају и „партнери за оглашавање“, којима су роба — корисници. И све то само да би се слободни софтверски пројекат превео на неенглески језик! Зашто једноставно vim po/sr.po кад може компликовано?

Веома је интересантан податак да је пројекат Федора, под окриљем ког је настао Transifex, у марту 2015. прешао на сервис Zanata, зато што је Transifex постао власнички 2013. године. И тако је пројекат локализације слободног софтверског пројекта Midnight Commander заробљен у власничком SaaS пројекту који продаје личне податке преводилаца трећим странама и оглашивачима. Зашто Midnight Commander није следио пример Федоре? Тешко је рећи, али је вероватно у питању инерција, и чињеница да је дистрибуција Федора ипак пројекат који окупља далеко више људи. Неко је имао времена да преиспита алате који се користе за локализацију. Услови коришћења сервиса Zanata у вези са приватношћу тренутно (2025-11-18) делују за нијансу боље од Transifex‑а, зато што према наведеном не укључују детаљну идентификацију уређаја који приступа сервису, и не укључују агенције за оглашавање међу „трећим странама“.

Без обзира на стање главног репозиторијума Midnight Commander‑а, мој превод тог програма ће увек моћи да се нађе на овом сајту и репозиторијуму translations.

1. Речено ми је да тај пројекат „већ 20 година“ нема никакве везе са Пројектом ГНУ! Само да није „мање незгоде“: носилац ауторских права је и даље Free Software Foundation. Закон о ауторским правима не познаје „удаљавање од FSF/Сталмана/итд“. 😊 Ал' добро, нека им буде...]]> https://strahinja.org/blog/2025-10/20251024/ https://strahinja.org/blog/2025-10/20251024/ Fri, 24 Oct 2025 07:32:36 +0200 Иако је поступак надоградње OpenBSD‑а веома сведен и аутоматизован, ћудљиви хардвер вам може покварити дан. Пошто је за кориснике OpenBSD‑а, у које спадам, тренутно актуелна надоградња на верзију 7.8, овде у кратким цртама излажем своја запажања у вези са овим поступком на конкретном моделу V15‑ADA Lenovo лаптопа који поседујем. Она могу бити од користи за све који употребљавају OpenBSD на том моделу лаптопа, или који се срећу са сличним симптомима.

Забелешке

• Користим mksh, компајлиран и инсталиран директно из изворног кода (не из портова) као подразумевану љуску и за обичног корисника и за root‑а. То утиче само на кораке 2 и 6 у наставку.

• Lenovo V15‑ADA има баговити уграђени WiFi адаптер, Atheros QCA6174, за који је мало вероватно да ће икад бити написани пристојни драјвери за OpenBSD. Приморан сам да користим USB WiFi адаптер Realtek 802.11 са подржаним чипсетом. Обично под OpenBSD‑ом (изузев после ребутовања након sysupgrade(8)‑а), када је USB WiFi адаптер прикључен, нема конфликта са уграђеним WiFi адаптером, вероватно зато што не постоји драјвер (па ни уређај у оквиру ОС‑а) за уграђени адаптер. Понекад се систем потпуно закочи ако су оба уређаја прикључена, рецимо под старијим нивоима ажурирања Windows‑а 10.

  Стање уграђеног WiFi адаптера после ребутовања у OpenBSD окружење за надоградњу испољава исте симптоме, што води до неупотребљивог система (због неуспешног процеса надоградње). Процес бутовања стаје код поруке:

  softraid0 at root
  scsibus1 at softraid0: 256 targets
  

• Кроз тестирање, уочио сам да је једини начин да се избегне ово кочење система ребутовање у систем који има подршку за уграђени WiFi адаптер (рецимо било који модернији LiveUSB ГНУ‑а са Линуксом) уз претходно уклањање USB WiFi адаптера, што изгледа да коректно иницијализује уграђени WiFi адаптер у оперативно стање, и затим ребутовање назад у OpenBSD, настављајући инсталацију, после чега треба поново прикључити USB WiFi адаптер.

Детаљна упутства

1. НЕ ПОКРЕТАТИ sysupgrade! Ово ће заглавити систем после ребутовања. Уместо овога, покренути sysupgrade -n.

2. Као root:

   # ln -f /bin/ksh /bin/sh	# за сваки случај
   # chsh				# па подесити root-ов shell на било шта осим
   				# mksh-а, нпр. /bin/ksh.
   

3. Ребутовати у ГНУ са Линуксом на LiveUSB‑у, али током ребутовања уклонити USB WiFi адаптер после поруке да је одговарајући интерфејс оборен, пре него што се лаптоп заиста ребутује.

4. Ребутовати назад у OpenBSD.

5. Пошто се заврши процес надоградње, након следећег аутоматског ребутовања, поново прикључити USB WiFi и покренути:

   # sh /etc/netstart
   # fw_update
   # pkg_add -u
   

6. Поново компајлирати mksh/lksh, инсталирати, променити root‑ову љуску на mksh.

О новој адреси сам размишљао већ неко време, из неколико разлога. Адреса contact@ је, ако се добро сећам, већ била подешена у cPanel‑у када сам прешао на постојећи хостинг, па сам по инерцији, уместо да креирам нову, само наставио да користим ту адресу. Међутим, добијао сам чудне погледе када је било потребно да је усмено издиктирам. Оно што ме је коначно одлучило да променим адресу contact@ је преглед чувања („commits“) у tog(1)‑у. Свако чување је представљено једним редом у оваквом формату:

2024-06-30 212c1fe5 contact  [tags/v0.16] Update themes

Овде contact заиста делује прилично чудно, и не преноси информацију о аутору. Разматрајући неколико варијанти нове адресе, одлучио сам се за sr@.

Пошто сам стару адресу користио за git, got и мејлинг листе, један од првих корака био је да креирам нове GPG и SSH кључеве за потписивање чувања у git‑у и ознака („tags“) у got‑у. Затим сам пребацио све филтере за мејлинг листе (ручно, зато што cPanel, бар за сада, не подржава извоз и увоз филтера) на нов налог, одјавио налог contact@ са листа и пријавио нов налог sr@.

Најзад, креирао сам и нов signify(1) кључ, услед чега сам морао да поново генеришем потписе за све архиве на страници /programi/.

Ово је, наравно, само почетак овог процеса. У наредном периоду наставићу да свуда где је то потребно мењам своју стару адресу на нову.]]> https://strahinja.org/blog/2024-05/20240529/ https://strahinja.org/blog/2024-05/20240529/ Wed, 29 May 2024 14:56:50 +0200 Већ извесно време на овом сајту сам поставио приказ репозиторијума неких мојих програма у виду статичких HTML датотека генерисаних програмом stagit. Међутим, он не функционише у директоријумима „радних стабала“ добијених наредбом got checkout. Дакле, не може се просто покренути stagit у директоријуму са којим се директно ради у got‑у.

Прва помисао ми је била да би ваљало направити „stagot“ (што и даље не треба одбацивати), међутим, срећна околност је што got ради са git репозиторијумима. Директоријум репозиторијума, који се добија наредбом got clone, представља „огољени“ (bare) git репозиторијум. Простим копирањем датотека description, owner и url у тај директоријум и усмеравањем stagit‑а на њега добија се исти резултат као и раније:

(cd ~/src/gotdir
 repodir="$(got info | awk '/repository:/{print $2}')"
 cd ~/src/www/stagit
 stagit -l 100 "$repodir")

Разлог због кога би ипак требало размислити о замишљеном програму stagot је зависност од git‑а. Ово је тек приручно решење, а идеално git не би ни требало да буде инсталиран.]]> https://strahinja.org/blog/2024-05/20240518/ https://strahinja.org/blog/2024-05/20240518/ Sat, 18 May 2024 09:54:10 +0200 Недавно је на мејлинг листи misc@ OpenBSD‑а у теми о омиљеним програмима за репликацију система поменут got — Game Of Trees („игра стабала“), што ме је заинтересовало за овај систем за контролу верзија. За њега сам чуо и раније, али сам сада одлучио да га боље проучим и започнем процес преласка са git‑а na got.

На питање „Чему све ово? Зашто просто не користити Git?“ у „често постављаним питањима“ got‑а, тренутно је дат, по мом мишљењу, непотребно одвраћајући одговор:

We don't need to hear your opinion that our project is pointless because Git is superior. Thank you!

тј.

Не треба нам ваше мишљење да је наш пројекат бесмислен зато што је Git бољи, хвала!

Овакав одговор маши поенту. Неко ко не познаје got и заиста је заинтересован за разлог његовог постојања, без намере да га омаловажава, остаје ускраћен за одговор. Такође је, слично пројекту Џемини, употребљена (по мени неискрена, и то непотребно) ограда да got „нема намеру да замени git“, и да је „било ко ко намерава да протури идеју замене git‑а got‑ом у великој заблуди“. Како да не! И зашто да не?

Коришћењем got‑а постају јасне његове предности и оправданост његовог постојања. Got се према git‑у односи отприлике као OpenBSD према било ком мејнстрим систему ГНУ‑а са Линуксом: фокусирање на оно што је битно, без непотребних могућности које се ретко користе или се могу урадити на други начин, већ постојећим програмима, а које уз то само стварају додатне мете за пробијање безбедности. Got је, у ствари, git који поштује основне вредности OpenBSD‑а. Уз све то, got користи исти формат репозиторијума као и git, само што је сваки репозиторијум у њему „го“ („bare“), и радно стабло (work tree) се мора експлицитно направити из репозиторијума. Директоријум радног стабла се не сме преклапати са директоријумом репозиторијума, а got користи уграђене механизме OpenBSD‑а, као што је unveil(2), да ограничи свој приступ и радном стаблу и репозиторијуму само на минимум неопходан за функционисање.

За сада једини ресурс за учење got‑а су његове странице упутства и упоредни преглед got‑а и осталих постојећих система за контролу верзија, као што су CVS, SVN и git. Учећи got из ових докумената, мој први пројекат који сам пребацио на got је програм table, а између осталог, got омогућава далеко елегантније генерисање верзије и датума последњег чувања. Рецимо:

got log |
awk '
/^date: / {
	gsub(/^date: /,"",$0);
	print $2 " " $3 ", " $5
	exit
}' >date.new

наспрам:

LC_ALL=C
export LC_ALL
user=$(unalias ls >/dev/null 2>&1 || true; \
	command ls -ld . | awk '{print $3}')
e_user=$(id -un)
if [ "$e_user" = "$user" ]; then
	git log --format=format:%cd \
		--date=format:"%B %d, %Y" -1 @ >date.new
else
	su "${user}" -c 'env LC_ALL=C git log --format=format:%cd \
		--date=format:"%B %d, %Y" -1 @' >date.new
fi
echo >>date.new

Комплекснији код је последица тога што git, за разлику од got‑а, не дозвољава кориснику root да извршава наредбе у корисничком репозиторијуму без подешавања safe.directory у /root/.gitconfig.]]> https://strahinja.org/blog/2024-04/20240429/ https://strahinja.org/blog/2024-04/20240429/ Mon, 29 Apr 2024 20:16:13 +0200 Мој лични лајтмотив почетка ове године је прелазак са ГНУ‑а са Линуксом на OpenBSD. Са тим у вези, поставља се питање мог става према основним лиценцама ова два оперативна система — ГНУ‑овој ОЈЛ и ISC лиценци.

У данашње време, када се покрене тема лиценци и помене ГНУ‑ова општа јавна лиценца — ГНУ‑ова ОЈЛ (енгл. GNU General Public License — GNU GPL), према мом искуству, нажалост, у великом броју случајева, постало је модерно да се омаловажава тај избор, па чак, сасвим у духу времена, и онај ко се дрзнуо да уопште помене ту лиценцу. Обично се као „аргумент“ истиче како је ГНУ‑ова ОЈЛ „идеолошка“, „политичка“ и „догматска“ лиценца, а како су „мање рестриктивне“ лиценце „слободније“ од ГНУ‑ове ОЈЛ.

Као „аргумент“ у прилог овој тези, наводе се рестрикције које ГНУ‑ова ОЈЛ поставља, пре свега у погледу подлиценцирања (sublicense): (превод СР)

(§2.c:)

Испоручивање под било каквим другим околностима је дозвољено искључиво под условима који су назначени доле. Подлиценцирање није дозвољено. Члан 10 га чини непотребним.

(§10:)

Сваки пут када испоручите обухваћено дело, прималац аутоматски прима лиценцу за покретање, мењање и ширење тог дела према овој лиценци од првобитних давалаца лиценце. Од вас се не тражи наметање поштовања ове лиценце трећим странама. [...]

Ово ефективно значи, да уколико програм користи делове који су објављени под мање рестриктивним лиценцама, њихова лиценца ће, као део веће целине тог програма, аутоматски бити преиначена на ГНУ‑ову ОЈЛ. Рецимо, ISC (Internet Systems Consortium) лиценца, преферирана под OpenBSD‑ом, гласи (превод СР):

Ауторска права <ГОДИНА> <ВЛАСНИК>

Овим се допушта коришћење, измена, и/или¹ расподела овог софтвера у било коју сврху, са или без надокнаде, уз услов да су очувани горње обавештење о ауторским правима и ово обавештење о дозволама. [...]

Простим очувањем ових обавештења услови мање рестриктивне лиценце су испоштовани. Уз додатак, рецимо оваквог обавештења (наравно на енглеском):

Ова датотека је заснована на <МАЊИ_ДЕО>, (c) <ГОДИНА> <ВЛАСНИК>. Овај програм је лиценциран под одредбама ГНУ-ове ОЈЛ [...]

програм као целина, заједно са делом који је био лиценциран под мање рестриктивном лиценцом, може (и мора) бити подлиценциран под ГНУ‑овом ОЈЛ.

Противници ГНУ‑ове ОЈЛ ово називају „вирусом ОЈЛ“ и сматрају негативним. Као аргумент у прилог томе, помињу се одредбе ГНУ‑ове ОЈЛ посебно смишљене да онемогуће злоупотребу софтверских патената („тивоизацију“) и друге начине које су велике корпорације историјски користиле да заобиђу одредбе ГНУ‑ових лиценци.

Такође, (§12:)

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

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

Софтвер треба да је јавно добро човечанства. Ако ово значи отуђивање корпорација или престанак подршке корпорација, нека тако буде. Човечанство као целина је важније од корпорација. Ако је ово политика и идеологија, у истој мери је политика и идеологија и супротстављање овоме. На крају крајева, шта је то толико, само по себи, лоше у политици и идеологији?

Одговор на питање из уводног пасуса је да и даље користим и користићу искључиво ГНУ‑ову општу јавну лиценцу в3 (или било коју следећу верзију) за све своје програме. То што је оперативни систем који сада користим под „лабавијом“ лиценцом на њих уопште не утиче.

1. Занимљиво је да је текст ISC лиценце непрецизан. Чак и после измене из 2007. („и“ → „и/или“), нејасно је да ли је њом дозвољена расподела измењених примерака. Више о овоме на https://www.gnu.org/licenses/license-list.html#ISC.]]> https://strahinja.org/blog/2024-03/20240331/ https://strahinja.org/blog/2024-03/20240331/ Sun, 31 Mar 2024 14:50:14 +0200 Ових дана је тема о којој се прича (дописује) широм IT света тзв. backdoor¹ у пројекту xz (прецизније библиотеци liblzma). Овај случај истиче све мањкавости постојећег начина функционисања слободних софтверских пројеката. Није реч о техничкој грешци, нити о техничком безбедносном пропусту: нападач је убацио backdoor након инфилтрације (у стварном свету) на руководећу позицију пројекта постепеним стицањем поверења maintainer‑а, а затим и заузимања његовог места као новог maintainer‑а. Цела операција је веома добро испланирана: осим самог backdoor‑а, нападач је слао читав низ „добрих“ печева.

Штета која је начињена је огромна: библиотеку liblzma користе дистрибуције које користе systemd и glibc (другим речима: мејнстрим дистрибуције, нпр. Debian, Fedora, Ubuntu...) да би омогућиле рад OpenSSH сервера. Према неким проценама, потребно је проверити око 700 commit‑ова које је послао нападач само пројекту xz (а слао их је, рецимо, и пројекту libarchive).

Сада се долази до веома интересантног закључка: као што некад вируси за Windows и DOS нису функционисали под ГНУ‑ом са Линуксом, просто зато што се програми за те системе нису могли (лако) извршавати, па се за ГНУ са Линуксом прочуло да је „аутоматски безбедан систем“, тако су (за) сада Униксолики системи који не користе systemd и glibc (рецимо: Alpine Linux, OpenBSD, ...) „имуни“ на овај backdoor. Ето веома доброг разлога да се напусте мејнстрим дистрибуције ГНУ‑а са Линуксом, и пређе макар на Alpine Linux, који користи musl libc, или на OpenBSD, што је тренутно и моја препорука. Ако ништа друго, систем контроле изворног кода који се укључује у издања OpenBSD‑а је далеко ригорознији.

Наравно, ништа не може заштитити систем од људског фактора. Рецимо, позната пракса мејнстрим „developer“‑а је да напишу Bash скрипт за инсталацију и корисницима дају инструкцију за инсталирање сличну овој:

$ sudo bash <(curl -L nekisajt.com/install.sh)

Ова епизода са backdoor‑ом у xz‑у показује зашто је штетност оваквих наредби апсолутна: не постоји сајт, нити пројекат, коме се може апсолутно веровати.

1. Део кода који омогућава заобилажење безбедносних механизама.]]> https://strahinja.org/blog/2024-02/20240216/ https://strahinja.org/blog/2024-02/20240216/ Fri, 16 Feb 2024 17:20:28 +0100 Коначно сам одвојио мало времена да на један од рачунара које користим инсталирам OpenBSD ван емулатора („наживо“). Своја запажања сам поставио у одељку „Текстови“ под насловом „OpenBSD забелешке“. Пошто још увек подешавам OpenBSD и тражим решења разних проблема у вези са OpenBSD‑ом које сам приметио, тај текст ћу допуњавати у наредном периоду.]]> https://strahinja.org/blog/2024-01/20240115/ https://strahinja.org/blog/2024-01/20240115/ Mon, 15 Jan 2024 09:40:20 +0100 Док ово пишем, већ пет дана, почевши од 10.1.2024., траје агонија сервиса за хостовање софтверских пројеката Sourcehut. Наиме, од тада нису доступни, или су спорадично доступни, сви придружени сервиси на доменима који се завршавају на sr.ht. Не упуштајући се детаљније у теорије о томе шта је узрок овом нападу (Microsoft са својим Github‑ом има највећи мотив; ово личи на класично Microsoft‑ово минирање конкуренције свим, па и прљавим, средствима), који су на сајту status.sr.ht описали речима:

We deal with ordinary DDoS attacks in the normal course of operations, and we are generally able to mitigate them on our end. However, this is not an ordinary DDoS attack; the attacker posesses considerable resources and is operating at a scale beyond that which we have the means to mitigate ourselves. [ист.СР] In response, before we could do much ourselves to understand or mitigate the problem, our upstream network provider null routed SourceHut entirely, rendering both the internet at large, and SourceHut staff, unable to reach our servers.

тј. (прев. СР):

Током уобичајеног рада, сусрећемо се са обичним DDoS нападима, које обично можемо сами да одбијемо. Међутим, ово није обичан DDoS напад. Нападач поседује значајне ресурсе и дејствује у размерама ван оних које можемо сами да одбијемо. [ист.СР] Стога је, пре него што смо било шта могли сами да учинимо да бисмо разумели или решили проблем, наш провајдер у потпуности null‑рутирао SourceHut, што је онемогућило како цео Интернет, тако и особље SourceHut‑а, да приступе нашим серверима.

ово значи да је врло вероватно да у наредних неколико недеља репозиторијуми и странице мојих програма могу бити недоступни.

Стога сам на страници „Програми“ свим пројектима за које то има смисла додао и архивиране верзије њихових репозиторијума, хостоване на мом сајту, као алтернативе директном приступу репозиторијумима. Наравно, право решење би био VPS, где бих директно понудио git:// приступ, али је он за мене лично баснословно скуп (ако се не изузме Google Cloud или неки сличан сервис, а њих не желим да користим). Такође немам намеру да се враћам на Github.]]> https://strahinja.org/blog/2024-01/20240105/ https://strahinja.org/blog/2024-01/20240105/ Fri, 5 Jan 2024 13:50:05 +0100 Пошто се у последње време бавим писањем уређивача текста за Window Maker/WINGs, написао сам упутство за коришћење функција за програмирање читања и писања Property List (plist) датотека које се у Window Maker‑у користе за датотеке са подешавањима и меније. Ради се о првој текстуалној верзији тог формата коришћеној на NeXTSTEP рачунарима.]]> https://strahinja.org/blog/2023-12/20231222/ https://strahinja.org/blog/2023-12/20231222/ Fri, 22 Dec 2023 12:18:00 +0100 У тачност релације из наслова уверио сам се још једном јуче, при покушају синхронизације датотека Syncthing‑ом. За оне који не знају за њега, ради се о програму за синхронизацију датотека. Принцип је следећи: (рецимо) сликате слику на телефону, покренете Syncthing док сте прикључени на Wi‑Fi, покренете Syncthing на другом уређају, и ако сте подесили да се директоријум (рецимо) /storage/emulated/0/DCIM/New синхронизује са неким директоријумом на циљном уређају, слике се магично појаве на њему. Ако онда на том другом уређају обришете неке неуспеле слике, оне се исто тако магично обришу и на телефону. Слично важи и за било какве датотеке у општем смислу, рецимо документе, PDF датотеке, итд.

Уместо да се у програму SyncTrayzor отвори веб интерфејс Syncthing‑а и да се датотеке „магично“ појаве на одредишном рачунару који користим на послу, а који ради под Windows‑ом 7, дочекао ме је празан прозор SyncTrayzor‑а, са log прозором садржине сличне овој:

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0

runtime.asmstdcall()
        runtime/sys_windows_amd64.s:65 +0x75 fp=0x22fca0 sp=0x22fc80 pc=0x473dd5
rax     0x0
rbx     0x1a27f20
rcx     0x1a87ec0
rdi     0x7fffffdd000
rsi     0x22fea0
rbp     0x22fde0
rsp     0x22fc78
...

итд. Претрагом на Интернету сам сазнао да је проблем у томе што су они који одржавају језик Go, у коме је писан Syncthing, просто одлучили да следе одлуку Мајкрософта да прекине подршку за Windows 7. А корисници? Шта се па они питају? Важан је Мајкрософт... Ако неко нема пара да купи најновији хардвер, који подржава најновију верзију Windows‑а и да плати непримерено високу цену лиценце, у визији big tech компанија он просто нема права да постоји. Све фирме морају давати харач индустрији хардвера, набавком новог, неколико пута годишње, и Мајкрософту и другим „играчима“ плаћањем астрономских цена лиценци.

Мора се истаћи да је оно што би пре десетак‑двадесетак година у овом конкретном случају било сматрано незамисливо аматерским, то да уместо поруке о некомпатибилности нове верзије програма, корисници добијају нефункционалан програм који их „части“ стањем процесорских регистара. Опет: кога брига за кориснике? Они су најмање битни.

Ово је савршен пример зашто је јурњава за најсвежијим верзијама софтвера штетна, зашто је „always online“ принцип лош, а такође и зашто су лоши и штетни програмски језици који зависе од система пакета, (који морају увек бити ажурни) као што је Go, али и данас форсирани Rust, па и Python, JavaScript и слични.]]> https://strahinja.org/blog/2023-12/20231212/ https://strahinja.org/blog/2023-12/20231212/ Tue, 12 Dec 2023 16:32:34 +0100 Менаџер прозора Window Maker користи сопствену библиотеку, WINGs. За разлику од пројекта GNUstep који представља слободну имплементацију Apple‑овог API‑ја Cocoa, који се користио у NeXTSTEP рачунарима, и написан је у језику Objective-C, WINGs је прилично лагана библиотека у језику C, која се ослања на библиотеку Xlib. Иако WINGs има недостатака, он је послужио за прављење апликације за подешавање Window Maker‑а WPrefs и апликације FSViewer. Ипак, апликације које користе WINGs личе на апликације са NeXTSTEP‑а, чија елеганција плени и дан‑данас.

Пре неки дан сам објавио wmgen, костур и генератор за нове апликације које користе WINGs. Он се може наћи на адреси:

https://sr.ht/~strahinja/wmgen/

Тренутни изглед основне верзије апликације генерисане уз помоћ wmgen‑а 0.3 је на слици:

]]> https://strahinja.org/blog/2023-11/20231119/ https://strahinja.org/blog/2023-11/20231119/ Sun, 19 Nov 2023 21:58:54 +0100 Пошто сам недавно креирао локализацију Window Maker‑а на српски, данас сам поставио и упутство за подешавање GTK и Qt окружења тако да подсећа на NeXTSTEP и OPENSTEP. Упутство сам додао у списак текстова.]]> https://strahinja.org/blog/2023-11/20231112/ https://strahinja.org/blog/2023-11/20231112/ Sun, 12 Nov 2023 10:21:29 +0100 Већ неко време у репозиторијуму мојих превода чувам преводе појединачних израза у датотеци dict.tsv. Недавно сам поставио и посебну страницу са преводима генерисану из те датотеке.

Од како сам почео да се бавим локализацијом софтвера на српски, нешто слично сам чувао у датотеци у формату XML, али TSV je свакако много боље решење. Ипак, вероватно ћу ускоро поставити и тај стари речник.]]> https://strahinja.org/blog/2023-11/20231101/ https://strahinja.org/blog/2023-11/20231101/ Wed, 1 Nov 2023 19:51:17 +0100 Када се тражи једноставан менаџер прозора, постоји читав низ примера, као што су dwm, cwm или i3wm. Међутим, ако се постави услов да они буду и „пријатељски према кориснику“, тј. приступачни и почетницима, вероватно би се мало ко сетио Window Maker‑а.

Последњих дана сам радио на преводу Window Maker‑а на српски, и данас је тај превод дошао до тачке да може да се пошаље у виду печа git send-email‑ом.

На слици се види локализација програма за подешавања Window Maker‑а, WPrefs, на српски. Апликација FSViewer није локализована, али ако то буде могуће намеравам да радим и на њеној локализацији.]]>