Изтичането на лични данни от НАП

Поддържането на информационната сигурност е доста отговорна и трудна задача. Дори да давате най-доброто от себе си, ако сте в такава роля, не сте застрахован от изтичане на данни от организацията, в която работите. Но в случая с изтичането на данни от НАП за мен има доста притеснителни неща, които ще се опитам да обобщя в настоящата бележка.

Процеси за разработка и внедряване на продуктов софтуер. Наивно е да се мисли, че има абсолютно сигурни софтуерни приложения. По-скоро има приложения, които още не са разбити. При разработката на приложения е важно да се отдели внимание как се ограничават щетите, ако приложението бъде пробито, както и на регулярните процеси, които гарантират че състоянието му отговаря на текущите разбирания за сигурност (нови възможности за пробиви се появяват ежедневно). От това, което излезе като коментари от казуса с НАП, оставам с впечатление, че: 

• Използвана е уязвимост в приложение, чрез което са достъпни данни от други приложения (недобре обмислен дизайн); 
• Използваната уязвимост е известна от 2012 година (липса на регулярни процеси за одитиране на софтуера). 

В този контекст дежурните оправдания, че заплатите на IT хората в администрацията са ниски спрямо тези на сектора и поради тази причина, хората, които са наети, толкова си могат, леко увисват. Двете точки по-горе са основно управленски проблем, не технически. Решението му е да имаш адекватни процеси.

От техническа гледна точка има доста автоматизирани решения, които помагат за прилагането на такива процеси – анализиране на слаби места в IT инфраструктура, анализиране на софтуерен код спрямо известни атаки, penetration тестове. По отношение на процесите са важни следните неща:

• Ясно разписани критерии за одобряване/внедряване на софтуер, които са еднакви както за вътрешни, така и за външни разработчици (включително за out of the box решения), с които всички разработчици са запознати 
• Контролна функция в организацията, която проверява изпълнението на дефинираните критерии на регулярна база.
• Одитираща функция в организацията, която се грижи критериите да са актуални. 

В резултат на пробива, НАП помолиха Информационно обслужване да им направят одитиране на информационните системи, но в контекста на тук написаното, това е по-скоро реактивно действие, което не решава основния проблем с процесите. НАП е обществена институция и най-малко дължи обяснение какво е научила от пробива и до какви промени в процесите за внедряване на софтуер ще доведе инцидентът.

Процеси за работа с лични данни. НАП има законово основание да събира лични данни без изрично съгласие на хората, което не означава, че нейните служители не трябва да спазват някакви базови правила въведени от GDPR за обработване на лични данни. От това, което се появи в медийното пространство, оставам с впечатление, че изтеклите данни са някакви моментни експортирания от базата данни, които са съхранявани на вътрешни файлови сървъри. Аз бих очаквал, когато служител на НАП анализира данни от информационната система във връзка с конкретна задача, да прави минимум следното: 

• Да ограничи анализа само до данните, до които има нужда. Честно казано експорт на данни за над 1 милион души, не ми се струва добра практика. Ако анализът предполага обобщаване на такъв обем от данни, най-вероятно могат да се ползват BI инструменти в самата информационна система, вместо да се наливат в инструменти извън нея. 
• Ако се налага експортиране на данни от информационната система, да ограничи достъпа до тях само до хората, които са ангажирани със задачата. Фактът, че странично приложение е имало достъп до тях, води до допускането, че и голяма част от служителите на НАП също са имали достъп до тях.
• Да използва експортираните данни само за нуждите на анализа и да ги премахне след приключване на задачата. В медиите се появи информация, че част от данните са за периоди от преди повече от 10 години. За моите разбирания, това е повече от оперативния интерес на НАП, така че е вероятно съответните експорти са направени доста отдавна. 

Както и в предишната точка, всичко се свежда до съществуването на адекватни процеси, тяхното прилагане и навременно актуализиране.

Политическа отговорност. С оглед на казаното дотук ми се струва, че най-малкото ръководителят на НАП трябва да си подаде оставката. Не знам дали има министър, който е натоварен със стратегията за информационни технологии в правителството, но ако има такъв, е добре да си намери друга работа, по-възможност извън IT сектора. Изказванията на различни политически лица по казуса и техния опит да отклонят вниманието считам меко казано за неуместни, но спокойно мога да отлича министъра на финансите в категорията цинизъм и неадекватност. Дали трябва да носи политическа отговорност за това? Не мога да преценя.

GDPR. Това изтичане на информация е своеволен тест до колко GDPR работи в България. За момента имам смесени чувства по отношение на НАП, тъй като им отнема повече време отколкото е нормално. Само за сравнение, алтернативни форми на проверка за изтекли данни се появиха почти веднага след теча. Интересно ми е как ще се справи Комисията за защита на личните данни с казуса. Ако НАП е причината да изтекат данни, то в целия скандал има още няколко организации, които помогнаха за достигането на бедствено положение и очаквам Комисията да вземе отношение по това.

Българските медии са далеч от цветущо положение, но се опитвам да си представя какво IQ трябва да имат журналистите, за да изтъпанчат в национален ефир линк за сваляне на данните и съответната парола. Въпреки всякакви етични кодекси, в търсене на сензацията, медиите са тези, които направиха данните общо достъпни и са отговорни за тяхното масово разпространение в разрез на разпоредбите по GDPR. Много се надявам Комисията за защита на личните данни да глоби провинилите се медии подобаващо.

На хората, които по една или друга причина са свалили данните, мога да им обърна внимание, че е добре да ги премахнат. Не защото тези данни се ползват със законова защита и който ги съхранява без да е оторизиран подлежи на някакво санкциониране. А защото в тези данни има записи за техни приятели. Едва ли някой от тях иска данните им да се съхраняват от трети лица без тяхно съгласие и най-малко трябва да им се уважи това желание.

Електронно банкиране с Firefox 34+

След upgrade на Firefox започнах да имам проблем с електроннота банкиране при ПИБ. Оказа се, че от Firefox версия 34 нататък, са премахнали window.crypto.signText функцията в резултат, на което не могат да се подписват платежни нареждания. Детайли за мотивите около премахването могат да се прочетат тук, а решение на проблемът е, чрез инсталиране на signTextJS плъгина от тук.

Проблеми със сигурността на Microinvest Warehouse Open

Във Microinvest Warehouse Open има проблем със сигурността, който на няколко пъти съм повдигал. За мое съжаление, хората от Microinvest го неглижират. С настоящия си постинг бих искал да дам публичност на проблема, така че от една страна хората, които ползват продукта да преценят до колко той отговаря на техните разбирания за сигурност, а от друга да стимулирам хората от Microinvest да го отстранят.

Microinvest Warehouse Open, както и повечето складово счетоводни програми, принадлежат към класа програми, предоставящи интерфейс върху някаква база данни. С други думи казано съхранението, манипулирането и управлението на данните се извършва от някаква СУБД (в случая на Warehouse Open това е MySQL), а приложният софтуер ни предоставя по-удобен начин да се случва това (не ни се налага да пишем директно сложни SQL команди). Когато се налага да  се реализират някакви правила за достъп и промяна на данните сме изправени пред следната дилема – дали да ползваме функционалностите предоставени от СУБД или да направим нещо върху нея (ако е възможно), което да е реализирано в приложния софтуер.

Всяка себе уважаваща се СУБД предлага доста гъвкавост при управление на достъпа до данните. В повечето случаи не е трудно да се ограничи достъпа на потребителя до конкретна база данни, таблица, колони или редове в таблица, както и операциите, които може да прави върху дадени данни (да ги изтрива, променя по специфичен начин и т.н.). Имайки това в предвид, някак си съвсем естествено идва потребителите на приложния софтуер, да са потребители на СУБД. Разбира се, това може да наложи да се направят множество специфични изгледи на таблици или използването на stored procedures. Съответно, това усложнява структурата на базата данни и може би коства повече усилия да се реализира.

Другата възможност е сигурността да е реализирано в самия приложен софтуер. Най-често това става, като се съхранява таблица с потребители, информация за правата им за достъп и хешове на паролите им. Съответно, когато някой потребител се идентифицира в приложението, то проверява предоставената информация от съответната таблица. Ако всичко е успешно, то променя интерфейса си, съгласно зададените права за достъп. Предимството на този подход е че не се налага да се прави по сложна структура на базата данни и съответно времето за програмиране на приложението би било по-малко. Разбира се, това става на цената на редица недостатъци. За да може приложението да се закачи да СУБД, то трябва да използва потребител от СУБД. Този потребител, в термините на СУБД, трябва да има достъп за четене/промяна (поне) до данните, които управлява приложението. В частност и до таблицата с потребители на приложението. Основните рисковете, които крие тази реализация, са три:

• Данните за идентифициране пред СУБД трябва да се пазят в тайна. Разбиването на паролата на този единствен потребител, компрометира най-малко данните на използваното приложение. В същото време тази информация трябва да съхранява някъде, така че когато някой потребител иска да влезе в приложението, то да може да се закачи до СУБД.
• Ефективно всеки потребител на приложението има повече права, от колкото биха му били нужни за да си върши работата. Това от своя страна означава, че много по-лесно може да се използват грешки на самото приложение (sql injections, грешки в модела/интерфейса направата за достъп и т.н.).
• При злонамерени опити за прихващане на комуникациите между приложението и СУБД, чисто статистически най-вероятно е да има успех при потребителите, които най-често ползват приложението. Обикновено тези потребители (от бизнес гледна точка) не би трябвало да имат значителни права за работа върху данните. Така че компрометирането на техните account-и, не би трябвало да нанесе сериозни щети, ако управлението на сигурността на данните на приложението се извършва от СУБД. Когато самото приложение има грижата да управлява правата за достъп, то рискът от компрометиране на системата е значително по-висок.

Подходът за реализиране на системата за сигурност в приложния софтуер се ползва най-често в web базираните приложения. Като цяло крайният потребител има достъп единствено до интерфейса на приложението, така че възможностите му да прочете файла, в който приложението съхранява информацията за достъп до СУБД или да предприеме атаки върху комуникацията между СУБД и приложението са значително ограничени. Съответно негативните ефекти от реализирането на този подход са силно смекчени.

За съжаление това не е така при stand-alone приложенията. Ако чрез инструментите на операционната система би могло да се ограничат възможностите за атака (от компютъра на който работи приложението) на комуникацията между приложния софтуер и СУБД, то не е толкова лесно да се ограничи достъпа до файла, който съхранява информацията за достъп до СУБД. Като цяло затвореният софтуер разчита на security through obscurity подхода. Информацията се пази криптирана и се разчита, че само приложението знае алгоритъма и ключа който се използва за декриптирането и. Разбира се, този подход не работи при приложенията с отворен код, тъй като всеки би могъл до види използвания алгоритъм и ключ. За мое най-голямо учудване Microinvest Warehouse Open използва именно този подход.

Лесно може да видите информацията касаеща връзката до СУБД чрез:

cat ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep Db

Криптираната парола за достъп до MySQL се съхранява във value полето на DbPassword реда. Бърз поглед върху изходния код на Warehouse Open ни дава информация за използвания алгоритъм и ключ. Имайки тази информация, лесно може да видим паролата чрез тази команда:

cat  ~/.config/Microinvest/Warehouse\ Open/WarehouseOpen.exe.config |grep DbPassword | cut -f4 -d'"' | openssl enc -des-cbc -a -d -K 4d6963726f696e76 -iv 1234567890abcdef; echo

Мисля, че не е необходимо да обяснявам какви биха могли да бъдат последствията, ако паролата за достъп стане известна на злонамерен човек. Ако при инсталирането на Warehouse Open е използван административен потребител на MySQL, то рискът се пренася и върху другите приложения, които използват същия MySQL сървър.

Като цяло докато този проблем не бъде разрешен, не може да се разчита на правата за достъп на Warehouse Open. Съвсем тривиално е всеки да се сдобие с каквито права за достъп иска. Разбира се, това не добавя кой знае какъв допълнителен риск, ако всичко (приложен софтуер и СУБД) се върти на една машина, до която злонамерения потребител има физически достъп. В такава ситуация, макар и една идея по-трудно, могат да се случат доста неприятни неща. За съжаление, този проблем компрометира ситуации, в които машината, на която е разположена СУБД е добре физически и мрежово защитена.

След upgrade до Karmic

Преди два месеца, когато излезе Kubuntu 9.10, се сблъсках с два сериозни проблема след upgrade-ването.

Първият е свързан с графичната среда. На единия от лаптопите, които ползвам, X сървъра вървеше с огромни шрифтове. Грубо казано на екрана се събираха три реда, което правеше компютъра неизползваем. В крайна сметка се оказа, че това е „хардуерен“ проблем, който е описан във wiki-то на ubuntu. Странно защо не се е проявявал в предните версии, но трябваше да се намери някакво решение. В моя случай в секцията monitor на xorg.conf (в новите версии X сървъра работи добре и без него, така че не се учудвайте, ако липсва; трябва да направите някакъв криво ляво) добавих

DisplaySize 330 210

което е размера на екрана в милиметри, а в секцията device, която описва видеокартата

Option "Monitor-LVDS1" "Monitor0"

където Monitor0 е идентификатора от секцията monitor.

Вторият проблем бе по-сериозен, тъй като засегна всички компютри, на които работя. Не можех да използвам електронния си подпис. Явно проблемът бе свързан с начина, по който е компилиран opensc пакета, тъй като

apt-get install libpcsclite-dev

ме върна отново в бизнеса.

Коледна админска мъдрост

Принципно на празници не е хубаво да се работи. Все нещо не става като хората. Когато се съберат повечко почивни дни, както става около Коледа и Нова година, освен яденето и спането, другите неща хич не ми вървят. Въпреки натрупаният опит в такива ситуации тази Коледа реших да пипана едно рутерче Linksys WRT54GL с OpenWRT на него. Ужким настройката трябваше да е дребна. Подкарване на OpenVPN сървър (какво да се прави, като обикалям познатите им пипам техниката). Принципно всичко стана точно, създадох CA на една машина в локалната мрежа, генерирах ключовете за рутера и клиентите, ужким направих и конфигурационните файлове, пипнах iptables-а даже и OpenVPN се стартираше без проблем. Регистрирах стартиращия скрипт да се зарежда, но след рестартиране на рутера нямаше и следа от стартиран OpenVPN. Когато файловата ти система е няколко мегабайта, някак си очевидно няма log файлове. Моето предположение беше, че нещо съм прецакал автоматичното стартиране и започнах да преглеждам как е организиран процеса на зареждане в OpenWRT. От файл на файл, попаднах на едни binary файл и рутерът умря. Вече не щеше да зарежда и достъп до него имаше само във fail safe режим. При монтирането на rootfs даваше някакви странни грешки и повечето команди не работеха. Нямах си никаква идея какво стана, а вече ме чакаха на следващата маса и просто положението беше меко казано напрегнато.

Та от цялата история поне за мен останаха два нови извода:

• Не се бъзикай с рутери по празниците, тъй като не е нужно да си гений да ги прецакаш.
• Когато се ровиш из файлове из embedded устройства ползвай cat вместо vi.

Във вторият извод се криеше и разковничето на моята глупост. Не съм навлизал много в детайлите, но се оказа че OpenWRT по много интересен начин разхвърля 4-те MB flash, с които разполага. Има някакъв 2 MB jffs дял, в който се записват конфигурациите, а останалите неща свързани със системата се монтират в режим само за четене. Всъщност, когато се модифицира файл от системните глупости, то се създава някакво изображение в jffs дялът. Та използвайки vi вместо cat, само заемам допълнително място, защото отварям файловете и за запис. А когато съм се натресъл на големият binary файл съм препълнил jffs дялът. Това само по себе си не е някаква болка, стига въпросният файл да не е busybox (разбира се, аз бях отворил линк към него). В резултат на което съм създал нефункциониращ busybox и системата не е искала да отлепи. Форматирайки jffs дялът нещата си дойдоха на мястото, но трябваше да конфигурирам нещата от нула. Добре че не бяха чак толкова много настройките, а и предвидливо ги бях запазил.

Иначе проблемът с OpenVPN се коренеше в това, че трябва да се указва пълния път до сертификатите и ключовете. Като го направих, работите тръгнаха. Сигурно някой път като не ме мързи, трябва да напиша някакво howto как става целият номер с OpenVPN и OpenWRT.

Debian, postgresql и сортирането на кирилицата

Тези дни се натъкнах на някакъв много странен проблем, а именно че сортировката в postgresql не работеше коректно. След обстойно проучване (абе имаше доста късмет в началото) се оказа, че причината е доста глупава, но изискваше пресъздаване на цялата инстанция.

Всъщност да почна в хронологичен ред. Инсталиране на нова машина с операционната система е debian etch, конфигурирана стандартно с български локал. Не знам защо стандартно на българския локал се слага cp1251 кодова таблица, но така или иначе това може да се промени на по-късен етап. Това успокоение ми изигра лоша шега, защото, когато по-късно сложих utf8 и разкарах cp1251, postgresql сървърът не пожела да тръгне. Стана ми странно, но за да има мир го оставих. По-късно като разгледах скриптовете за създаване на клъстер видях, че се взима локала и кодировката на конзолата и те се използват за задаване на стандартните стойности на разни параметри. До тук всичко добре, но се оказа, че ако в този клъстер създадете база с utf8 кодиране, то сортировката на кирилицата не е коректна. Като осъзнаете истината с доста наляти данни в базата, то процедурата не е много приятна, тъй като трябва да се dump-не цялата база и после да се налее отново.

Цялата тази процедура аз я извърших по следния начин. Като потребител postgres dump-нах базата посредством

pg_dumpall > db.out

След това като root спрях сървъра, премахнах клъстера, създадох го наново и стартирах сървъра

/etc/init.d/postgres stop
pg_dropcluster 8.1 main
pg_createcluster 8.1 main --locale en_US.utf8 –encoding utf8
/etc/init.d/postgres start

Като там някъде горе пропуснах и пипането на конфигурацията по новия клъстър. Накрая базата я налях през postgres потребителя.

psql -f db.out postgres

Разбира се човек може да правя всякакви вариации на този подход. Например не е нужно да изтрива наличиня клъстър, а може да се направи нов. Ако е настроил конзолата да бъде на utf8, то последните параметри при създаването на клъстъра може да ги пропусне.

Печат с qt4 под линукс

Едно от хубавите неща на свободния софтуер е, че с него може да се постигне всичко за крайно време. Вярно, че някой път това отнема по-малко от час, а друг път се точи с дни, но при наличие на желание няма невъзможни неща. Най-забавната случка, която съм имал, бе свързана с подкарването на една ISDN връзка под linux. След няколко часа борене, решихме да погледнем изходния код на драйвера на картата, за да разберем защо не стават нещата (имаше някакво съобщение за грешка) и веднага разбрахме, че не сме включили правилния кабел, където трябва. Ако правехме това нещо под windows едва ли щяхме да разберем за тази дребна грешка.

За съжаление борбата ми с печатането от qt4 програма под linux не беше толкова кратка (май съм отделил към 40 часа) и честно казано е малко спорно до колко краят е успешен. В тази връзка се сблъсках и с един от основните проблеми сред решенията с отворен код, който е свързан с това, че за да се свърши конкретна работа се ползват каскадно доста наброй приложения. Те от своя страна се развиват и начините на комуникации се изменят. При тези промени се чупи връзката между тях и в цялата тази ситуация не е ясно кой е виновен - извикващият или извикваният? Поради тази причина си мисля да споделя натрупаният опит, който макар и след 6 месеца да не е вече актуален, може да е от полза на някой.

Всичко започна със следния казус – едно и също приложение веднъж реализирано на qt3 и веднъж на qt4 печата в qt3 варианта си, а в qt4 варианта си не иска (всъщност на един от принтери печатът даваше грешка, а на друг просто част от текста беше отрязан). Разбира се, в такава ситуация веднага идва на ум, че проблемът е в qt4 библиотеката, която в конкретния случай бе 4.2.1. Всъщност проблемите се оказаха няколко, като част от тях са решени в qt 4.4.0, но имаше и такива в cups (поне във версия 1.2.7).

Може би сега е моментът да кажа как е организиран печата под linux. Като че ли в повечето случаи хората използват cups, който прави какви ли не работи. Qt4 библиотеката не прави изключение и, ако е компилирана (стандартно е) с такава опция, също го използва. Тук идва и първия нюанс. До преди 4.4 версията qt4 печата използва lpr командата като през тръба предава към нея това, което генерира като печат. Всичко хубаво, но е много вероятно тази команда да не ви е инсталирана. Особено ако правите минимални инсталации и bsd style командите на cups са пропуснати. От версия 4.4 нагоре работата вече е друга, тъй като печата става директно през cups библиотеката, като печата се съхранява във временен файл.

Интересно е в какъв формат се генерира това, което ще се отпечати? Отговорът е в native формат, което за windows и mac може би е ясно какво означава, но за linux e postscript при cups < 1.0.2 и pdf за по-високите версии. Всъщност точно тази иновация чупи печата по няколко линии. От една страна повечето програми ползват postcript към cups и съответно има разни неизчистени проблеми с използването на pdf (например landscape печат при pdf формат). От друга страна в qt3 се ползва postscript и тези нововъдения в qt4 променят доста логиката и не са тествани достатъчно. Например в qt 4.2.1 (оправено е в 4.4.0) при използване на pdf формат не се зареждат коректно данните за принтерите, което прецаква печата в ранна фаза. Принципно човек може явно да укаже дали да ползва pdf или postscript формат при печат, но с това се натриса на следващия проблем, който се наблюдава при печат на landscape неща. Ако се печата в pdf формат към cups трябва да се предаде параметър landscape, но ако се печата в postscript той трябва да се пропусне. Пичовете от Trolltech са съобразили това нещо, но за съжаление го правят на база версия на cups и пропускат факта, че програмата само може да си е избрала формата за печат. Единствения начин да се спасите от този проблем (освен да чакате коригирана версия или сами да пачвате библиотеката) е вие да укажете каква външна програма да се ползва. В този случай qt4 не слага допълнителни опции към командата освен името на принтера. Лошото е, че ако се налага и вие не може да слагате и за целта трябва да минавате през външни скриптове. Което прави работата съвсем куца. Явно, докато KDE4 не влезе в масова употреба, проблемите с печата няма да се изчистят. Принципно, ако не ви се налага на печатите landscape, qt 4.4 ще свърши работа. Отделен е въпросът дали върви във всяка дистрибуция (в debian etch го няма и правенето на пакети за него беше едно голямо изживяване най-малкото, защото засмука 4G от диска и трябваше ударно да трия неща, за да не се окаже, че съм батисал няколко часа), макар че тези, които ще предлагат kde 4.1 ще го мъкнат. Ако сте в останалите случаи, то временно ще ви се налага да правите хватки като описаните по-горе, което в код се изразяват на нещо от сорта:

void print()
{
 QPrinter* printer = new QPrinter();
 QPrintDialog printDialog(printer, this);
 if (printDialog.exec() == QDialog::Accepted)
 {
#if defined (Q_OS_UNIX) && ! defined (Q_WS_MAC)
  if (printer->outputFileName().isEmpty())
  {
   printer->setOutputFormat(QPrinter::PostScriptFormat);
   printer->setPrintProgram("/usr/bin/lpr");
  }
#endif
 …
 }
}

Бе ТаКа и продължава и да бъде - част 3

В тази последна част ще споделя опита си с ADSL Helpdesk. Вече от близо четири години имам взимане даване с ADSL услугата на БТК и след като се подкарат настройките не се срещат проблеми. Вярно, че от време на време модемът изисква рестартирано, но какво да се прави, такъв е животът. Покрай подкарването се е налагало да моля за някакви донастройки (пускам IPSec тунели между отделни места, а освен това се налага да правя отдалечена администрация от време на време, което изисква необходимост от forward на пакети към машина стояща зад модема) на модема, но поне навремето нещата вървяха добре.

За съжаление последните няколко дни Суперлюбо си беше взел почивка за един от ADSL-ите. Беше странно, че така са се скапали нещата и хората, които го ползват, звъннали да helpdesk-а да се оплачат и да се види какво може да се направи. Тъй като те не са технически грамотни, нещата са малко изтървани и от БТК се мъчат да прехвърлят проблема към устройството, за което е закачен модема. Като чуват, че става въпрос и за компютри под linux, добиват вида на дявол бягащ от тамян. Работата се закучва и като се подкарва втори ден без интернет и съответно липса на свързаност с останалите места на тази фирма, искам не искам трябва да се заема.

Запътвам се към мястото на модема – промишлена зона в покрайнините на София. Както може да се очаква машините от локалната мрежа стигат до модема, а той от своя страна и хабер си няма какво да прави с пакетите и връща destination unreachable. Рестартирането на модема не помага. Тръгвам да звъня на helpdesk-а. Честно да ви кажа, това е голям мазохизъм. БТК така са си разчели персонала, че трябва да чакате средно около 20 минути, докато се свържете с оператор. Глупаци! Поне това се смята лесно. Няма никаква трудност да се оцени цикличността в натоварването, колко време отива за комуникация и прочие, така че да смъкнат това време значително. По останали доставчици, но които съм звънял не ми се е налагало да чакам толкова. Даже на *88 не съм чакал повече от 5 минути, при положение, че там маймуните са много повече. Това, че някои от операторите са калъфи, е друга тема. В крайна сметка по дефиниция на системата те са хора, които всячески се мъчат да филтрират достъпа от страна на потребителите до хората, които могат да свършат работа, като в рамките на нивото си на компетентност се мъчат да разрешат проблемите, ако могат. Ако не могат, ще предадат на когото трябва. Иначе са учтиви, спор няма.

Свързвам се с някакъв Нейчо. Обяснявам му, че имам проблем и как модемът на Layer 3 не вижда отсрещното устройство на БТК. Той пък ми заявява, че имат големи проблеми upgrade-вали нещо и било нормално точно в момента да нямам интернет. Опитите да му обясня, че това е проблем вече втори ден, който по никакъв начин не би трябвало да е свързан с техните глобални проблеми са неуспешни. От целия диалог разбирам, че наличието на проблем е някаква новост за него, а заявката за минаване на модема от IP extended (което по обяснението му трябва да е накакъв bridge режим) в NAT била вече изпълнена. Wtf? Модемът винаги е работил в NAT режим, а конфигурацията му по другия начин според официалните писания на БТК е невъзможна и трябва доста да поплачеш на някой, че да се навият да ти я изпълнят. Поне такива ми бяха спомените. Така и не може да ми отговори има ли проблем на Layer 2 между двете устройства, а опитите да му обясня каква представляват WAN връзките се оказват неуспешни. Проблемът ми е записан и щяло да се работи по него. Тъй като на мен такива не ми минават веднага питам колко време трябва да им дам за да са оправили проблема. Според него до час и половина са щели да се справят с глобалния проблем, след това трябвало да рестартирам модема и работата трябвало да тръгне. Ако не тръгнела да звъня отново.

Ясно е, че няма какво да правя час и половина там и се изнасям. В крайна сметка и отдалечено мога да проверя имали свързаност, а освен това съм инструктирал охраната как да рестартира модема при необходимост. Два часа по-късно модемът е рестартиран и аз пускам traceroute до съответния ip адрес. Не минават много hop-ове и се появява едно циклене в мрежата на БТК, които еднозначно определят крайния резултат. Ясно, звъним отново на helpdesk-а и отново 20 минути слушам музичка в слушалката. Обажда ми се Валентин. Обяснявам му на него ситуацията. Той от своя страна ме пита как свети модема. Като разбира, че не съм до него иска да ме отсвири. Модемът трябвало да се активира, което можело да стане само на място. На въпросът ми защо се налага активиране на модем който работи успешно повече от две години (всъщност три и половина), той ми отговаря, че поради разни форсмажорни обстоятелства модемът бил влязъл в някакъв защитен режим и трябвало да се активира. Малко съм нанервен от цялата тази ситуация и „стимулиращо“ му обяснявам, че неговите колеги не се отнасят сериозно към проблема ми и ако не е това случаят ще се оплача лично от него, че гледа да ме отсвири. Той пък се засяга от това и го класифицира като лична нападка. Потвърждава ми, че сигнала до модема бил много хубав, но те дистанционно не можели да направят нищо. Аз понеже паса трева, му „повярвам“. Достатъчно му вдигнах кръвното на младежа и вече късно вечерта се вдигам отново към местоположението на модема. Явно това е единствения начин да се кача на следващо ниво в играта на helpdesk-а.

Отново съм на мястото. Модемът отново и хабер си няма какво да прави с пакетите. Преди да тръгна да слушам поредната порция музика по телефона, решавам да се поборя още малко. Включвам модема директно към лаптопа си и специално гледам да boot-на с windows. Това разбира се, с нищо не променя картинката, но след два рестарта на модема има напредък. Модемът явно успя да установи някаква връзка и поне DNS resolvе-а връща винаги страничката за активация. Явно Валентин е бил прав, модемът има нужда от активация. Пиша потребител и парола и процесът стартира. За мое съжаление някъде по средата дава грешка и не може да бъде завършен. Няколко опита, все същата история. Лошо. Пак ще трябва да се звъни.

Следва поредното 20 минутно музикално изпълнение, но този път съм подготвен. Позагубил съм форма на FreeCell, но на Spider пасианса се представям добре. Този път се обажда Калоян. Обяснявам му как имам проблеми с модема, как негови колеги са ми казали, че трябва да се активира, как е възникнало проблем и какво правим оттук насетне. Той предположи, че сървърът бил претоварен и затова не станало, да пробвам от ново. Пробваме. Следващата хипотеза е свързана с това, че модемът има нужда от reset-ване към заводски настройки. Хващам първия кламер и изпълнявам инструкциите. Вече и страничката за активация не се зареждаше. След няколко reset-вания и рестартирания положението не се оправя. От лаптопа виждам модема, но неговия DNS resolve не работи, а traceroute докъдето и да е връща destination unreachable. Чакам инструкции от младежа. Така или иначе съм си загубил доста време, мога да правя всякакви глупости докато си обходи списъка с мерки, че най-накрая да стигне случая до който трябва. Следващите мерки бяха леко смешни. Може би проблемът бил в това, че получавам настройките по DHCP и ако мога да забия настройките IP настройките. Няма смисъл да му обяснявам защо това няма да сработи. В крайна сметка е по-бързо и лесно да следвам инструкциите, а резултатът ще е един и същ, следващо ниво в процеса на диагностика.

Най-накрая изчерпихме списъка и разбрах, че проблемът ми щял да бъде предаден на по-висока инстанция. Щял да бъде оправен до утре сутринта (действието се развива някъде преди 22 часа в петък), рестартирам тогава модема и после трябвало да успея да го активирам. Супер. Обяснявам обаче, че не спя с този модем и ако не взема аз да се замъкна специално и отново за това, то няма кой да го направи, пък от друга страна да седя на някакво забутано място не ми е представата за приятно изкарване на почивните дни. Човека подходи с разбиране и каза, че ще предаде на колегите си да направят и активация. Специално питам дали е възможно, след като Валентин ми е обяснил, че не може. Според Калоян в повечето случаи нямало проблем. Разбираме се, ако няма развитие да звъня утре сутрин отново.

На следващия ден хората от фирмата потвърждават, че интернета работил. Можело значи да стават нещата, само желание липсва. Като се тегли чертата излиза, че съм батисал близо 5 часа. Два в телефонни разговори, от които един да чакам за оператор. И още около два в транспортиране от и до мястото.

Проектите ми в OpenFMI

В края на февруари регистрирах още един проект с име FreeGIVE в OpenFMI, с което проектите там, в които участвам, станаха три. За момента активността около него ще бъде в svn хранилището (май това е основната причина да го регистрирам), където съм сложил нещата, които до момента съм направил по един иконометричен пакет за R. Принципно цялата идея може да се развие в много посоки (за момента ще ги пазя в тайна), но засега ще се концентрира основно върху този пакет, като се надявам в неговата разработка да се включат и други хора (те си знаят кои са). Може би е уместно да се попита защо няма компилирани пакети за windows или кога този пакет ще се включи към официалните пакети за R. Отговорите са свързани най-вече с появяване на документация по отделните функции, нещо, за което не съм се напънал много. Все пак хората, които искат да го ползват и без документация (не знам какви джедаи трябва да бъдат, за да успеят) могат да го дръпнат от хранилището. Ако са под linux доста лесно ще го добавят към останалите пакети. Ако са под windows ще им трябват неща като perl, latex и още доста глупости.

Интересно е какво става с останалите два проекта? Като че ли този, покрай който има най-много движение е RDsuite, макар и спрямо началната версия да няма кой знае какви видими промени. За следващата версия, която най-вероятно ще излезе есента (да не се заричам много) са планирани три важни и видими нововъведения. Така или иначе, който се интересува от този проект, може да дойде да ме види на априлската конференция на „Линукс за българи” или както се казва вече.

Последният проект е свързан с една програмка за генериране на затворени и балансирани тестове, като взима въпросите от някакво предварително дефинирано множество. Като че ли там развитията хич не се очертават, защото за момента ми върши работа, макар и варианта, който ползвам е с леки корекции покрай един бъг. Все пак, ако ми се освободи време, може да се напъна да я поукрася, да оправя директорийната структура, както и да взема да пусна пакети по отделните дистрибуции. Отделен е въпросът дали си заслужават всички тези усилия.

Излезе KDE 4.0

KDE 4.0 е вече факт. Сигурно ще трябва да се наложи да се изчакат няколко дни докато се появят пакетите за повечето дистрибуции. След дълго чакане, една нова страница в развитието на проекта е отворено. Като цяло в KDE4 има доста нововъведения (така и не написах постинг по въпроса), макар и повечето от тях да не са видими, а освен това благинките, които предлага (ще) са достъпни и за Mac и Windows потребителите. Разбира се, като за първа версия едва ли трябва да се очаква много от него. За момента са завършени kdelibs, които едва ли ще претърпят големи изменения в следващите версии, както и основните приложения са портнати криволяво към новите идеи заложени в kde. Тъй като всичко това е направено доста ударно, то е логично да се очаква, че ще има доста недоглеждания и грешки. Но дори и да ги нямаше, то пак KDE 4.0 нямаше да е много функционално. Просто повечето от приложенията за KDE тепърва ще започнат да се портват към новите библиотеки и дотогава няма да ги има налични за новата среда. Вярно, че има библиотеки за съвместимост с KDE3, но като човек, имаш опит с преминаване от Qt3 към Qt4, знам, че работите не са тривиални. Още повече, че при механичното портване, няма да има възможност за използване на новите концепции на средата. Така, че трябва да се почака, докато доста приложения бъдат пренаписани. Предполагам, че при излизането на KDE 4.1(някъде около 28 юли) критичната маса ще е мината, а заедно с това доста полезни програми, които нямат добри аналози, ще са достъпни за Windows и за Mac. Звучи хубаво, нали?

Какво ми липсва в OpenOffice.org?

Преди 2 години написах кратко сравнение между OpenOffice.org и MS Office. В настоящия си постинг ще се помъча да актуализирам впечатленията си като направя един коментар какво ми липсва в OpenOffice.org. За сравнение ще използвам OpenOffice.org 2.3 спрямо MS Office 2002.

От гледна точка на текстообработка Writer-ът трябва да дръпне много в колективната работа. Лично на мен често ми се налага да работя с няколко хора върху един и същ документ (документация, доклад и т.н). Всеки пише някаква част от него, някой ги събира механично, след което започва процесът с ревизиите.

Най-тривиалното нещо, което прави всеки, е като прочете файла да има забележки върху съдържанието. И двата продукти поддържат такава функционалност, но тя работи по различен начин. В Writer-а бележките се вмъкват към текста. В зависимост дали сте дали те да се визуализират или не, то е възможно да се появи едно жълто квадратче, което да индикира, че има бележка и евентуално ако минете върху него с мишката да се визуализира. За съжаление, ако не знаете, че е там, може спокойно да го пропуснете в процеса на четене на теста. Разбира се, има навигация по бележките и можете да ги обхождате една по една. Само че за мен това е малко неудобство, защото за да разбереш забележката, то трябва да си наясно с контекста, в който е поставено, което изисква четене на теста. В този момент навигацията пречи.

Как е реализирана тази функционалност в Word? Отстрани в полето се появява кутийка със забележката, което от своя страна прави лесно едновременното четене на документа и следене на забележките. Отделен е въпросът, че навигацията е изнесена в toolbar, така че ако искате бързо да видите следващата бележка, то не трябва да минавате през меню и диалогов прозорец, с който пък да си закривате текста. Хубавото при Word е, че бележката, освен да бъде вмъкната някъде в текста, може да бъде отнесена към конкретна дума, изречение, параграф (при конвертиране на файлът в OOo тези бележки не се визуализират). Това е удобно, тъй като веднага става ясно какво е искано да се каже с коментара. Отделен е въпросът, че могат да се слагат бележки, към бележки и така се получава цяла дискусия. Разбира се в последното може да се реализира и в Writer-а, но е реализирано чрез добавяне на нов текст към вече написана бележка, като се слага разделител за автор.

Другата основна функционалност, която е недомислена в Writer-а е режимът за следене на промените в документът. В момента функционалността е реализирана на ниво Word 97, т.е. нововъведения текст се оцветява, а изтритият се зачерква. Всичко много хубаво, но така документът става нечетлив. В такива ситуации може да се изключи визуализирането на промените и да се даде индикация, че има промени на някой ред, но пък тогава не става ясно какви са направените промени. Как е реализирана тази функционалност в Word? Нововъведения текст се оцветява, а изтритият и се показва в една кутийка отстрани в полето и се показва мястото, от което е изтрито. Това решение предлага от една страна добра четимост на редактирания текст, от друга страна и добра история на промените, така че те лесно да бъдат приемани и отхвърляни. Не знам какъв е проблемът това да се реализира в Writer-а, още повече че преди две години като гледах feature request-ите това фигурираше. Определено липсата на тази функционалност ще откаже от миграция към OOo хората, които правят редакции на документи.

Една дребна функционалност, която ми липсва е свързване със задаването на езика, на който пиша. Това е важно, ако искате да работи проверката на правописа и някои други благинки. Някак си е нормално, когато използвам BG Layout програмата да приема, че пиша на български, а когато използвам EN Layout на английски. Word го прави, но Writer-ът не. Предполагам е трудно да се реализира тази функционалност при *nix системите, но поне за Windows да го направят. Лично на мен ми се налага в документи да имам текст на повече от един език и е досадна тази ръчна смяна. Да не говорим от интерфейсна гледна точка колко по-лесно е направено в Word (при copy-paste по някой път се налага да се укаже език ръчно). С двойно кликване при Word срещу навигация в менюта и диалогов прозорец в Writer.

По отношение на Calc-а видимо работите като че ли не са се подобрили много. От моя гледна точка единственият видим напредък е подобряване на процеса на създаване на диаграми. Но като се има предвид колко зле беше Calc-а преди две години, то този напредък не трябва да е учудва някой. Диаграмите от Calc-а вече стават за нещо, макар и да трябва още някои неща да се пипнат (например, ако решите да работите с две Y оси, пък после се откажете от втората, става леко мазало). За сметка на това продължава да няма Solver функционалност еквивалентна на тази в Excel (положителното е, че се появяват разни по-елементарни работи, така че сигурно е въпрос на време), което спъва използването на Calc-а за по сериозни сметки.

Да оставим по-сериозните сметки на страна, но в Calc-а имам затруднения и да работя бързо с данни. Получавам един файл с данни и искам на бързо да ги сложа в моделчето, което съм си направил. Ако е стандартен Copy-Paste няма проблем, но в данните има агрегация по някоя от размерностите и на мен ми трябват стойностите от агрегацията (например имате данните по дни, като във всеки стълб става въпрос за отделен ден и след последния ден на месеца имате стълб за месец и на вас Ви трябват само данните по месеци), то в Excel-а маркирам само клетките, които ми трябват и ги копирам. За съжаление в Calc-а Copy-Paste не работи с прекъснати области. Тази липса би отказала голям процент от хората, които работят с данни, да го ползват.

Липсата на критична маса потребители за Calc-а дава отражение върху съпътстващия софтуер. Например за системата R, която е софтуер под GPL, има изградена възможност да се използва под Excel, но липсва такава за Calc. Ако един проект, който малко или много се движи от фенове на свободния софтуер, не е положил усилия да се свърже с най-големия свободен офис пакет, то може ли да очакваме за системи като Matlab, Stata, Mathematica и т.н да могат да работят през него скоро? Дали всякакви комерсиални продукти за финансовите сметки, които са развити на базата на Excel ще видят своите еквиваленти в Calc? Според мен в близките две години едва ли това ще се случи, защото няма да е достигната критичната маса от потребители, при която фирмите, които поддържат Excel базирани решения, да ги port-нат и към Calc.

Все пак положителното, че в развитието на OOo са се ангажирали фирми като IBM и Google. Спор няма, че в последните две години OOo дръпна доста, макар и промените да не са видими, и не бих се учудил, ако като инфраструктура пакетът е по-добре структуриран от MS Office и се надявам покрай IBM и Google да се наложи по-бързо сред корпоративните потребители, което да даде сериозен тласък в развитието на съпътстващия софтуер.

Като за финал да кажа, няколко неща, които ми харесват в OOo пък не знам как/дали могат да станат в MS Office. Доста ми харесва подхода в OOo за embedded документите, където се вграждат само необходимите данни, а не цялата информация от файла източник, както е в MS Office (или поне не знам откъде се настройва). Едно друго нещо, което според мен е доста ценно е възможността за вграждане на SVN хранилище в самият документ и така да се поддържа доста добър Version control на документа, което е в пъти по-добро текущите track changes реализации.

Иначе по отношение на организация на документи в рамките на някаква организация OOo е доста добре интегриран в O3Spaces, така че ако някой вижда бъдещето в Google Office или му харесват решения в контекста на MS SharePoint, то той има как да прави аналогични неща използвайки OOo. За съжаление не са безплатни.

Като цяло съм оптимист за бъдещето на OpenOffice и макар да ми е невъзможно за момента да го ползвам в работата си, то се надявам това да се промени. А дотогава ще му се радвам като домашен потребител. Разбира се, всички тези кусури, които му намирам, по никакъв начин не са свързани с ODF формата, за който Йовко е написал един чудесен постинг. Само да предупредя, че ако искате да ползвате ODF през MS Office, използвайки на plugin-а на Sun, то в повечето случаи ще гризнете дръвцето.

Резултат от сътрудничеството между ДА и Microsoft

Бого е пуснал петиция относно поредната идея на Ники Василев. Историята е дълга, доста се е изписало в мрежата относно проблема, но аз мога да ви направя кратка демонстрация за резултата от използването на Microsoft продукти в държавната администрация. Просто хвърлете поглед на файла относно внасянето на държавния бюджет за 2008 в парламента (няма да коментирам редакционните умения на Бойка Владова, която седи като автор на документа). Ако все пак някой се е напънал да го оправи (лично аз се съмнявам, че ще стане), ето Ви и снимка (цъкнете за по-голяма) на екрана след отварянето му.

Извод: Пращайте PDF-и за да не си личи колко сте неграмотни ;-)

Анкетите в Blogspot

През тази седмица е активна още една анкета в блога ми. Като гледам май ще е последната, тъй като цяло успях да се ориентирам относно функционалността за гласуване в Blogspot.

Някои неща доста ми харесват. Поддържат се голям брой възможни отговори. Аз тествах с 12, предполагам, че и с 20 и нагоре няма да има проблем. Има възможност за избор на повече от един отговор и като се смятат процентите, то човекът гласувал с няколко отговора е броен като един гласувал, а не като в някои други анкети за n-наброй гласували. Човек има възможност да си промени гласа, докато е активна анкетата. Според мен това е доста ценна възможност, особено ако на база някакви дебати мнението му е еволюирало или пък, ако първоначално не е интерпретирал правилно въпроса, какъвто май е случаят в последната анкета (интересно ми е хората, които смятат, че в малките населени места средната брутна месечна учителска заплата трябва да е около 800 лева, което нетно прави около 640 лева през 2008г., колко смятат, че трябва да е в големите градове, както и не смятат ли, че ако заетите в образованието в някоя малка община (да речем Кнежа) взимат между 2 и 3 пъти повече от средната заплата за общината, то това няма ли да взриви трудовия пазар).

По отношение на недостатъците, това което не ми харесва е, че няма някакво специално управление на анкетите и те седят в страничната лента, докато не бъдат изтрити. Като се изтрият (още не съм пробвал), най-вероятно ще се загубят резултатите или поне възможността за тяхното визуализиране. От друга страна, ако се пазят анкетите в страничната лента, то тя ще стане доста претрупана. Сигурно е доста по-добре анкетите да бъдат свързани по някакъв начин с постингите, а в страничната лента да се появяват само активните към момента анкети. Доколкото тази функционалност е в тестов период се надявам хората от Google да измислят нещо по въпроса.

Разчистване

През уикенда започнах да провеждам разчистване на нещата, които седят на твърдия диск на компютъра ми. Свободното пространство падна под санитарния минимум за записване на DVD, а освен това си ме е страх при толкова малко свободно място да тръгна да си upgrade-вам Fedora-та (като гледам как съм се замотал май направо ще скоча на новата версия). Дискът ми не е от най-големите и като цяло се оказа запълнен с pdf-и (преди да ги разкарам, трябва да седна да ги индексирам, което е времеемко), няколко image-и на Debian и Darwin (покрай RD Suite ги държа за да компилирам пакети, на Debian има два броя, едната ми е чисто инсталиран Debian върху, който компилирам, а на другия инсталирам, пък Darwin-а не можах да го подкарам през емулаторите; като остане време трябва да се разправя и с него) и снимки (за мой ужас се оказаха на 16G). Ясно беше, че видим резултат може да се постигне само с тяхното записване и веднага разбрах защо не съм записвал снимки през последната една година. От едно екскурзионно от предходната година част от хората, които участваха, са ми пратили снимките с много гадно наименование. Това че windows-а ги сваля от фотоапарата, слагайки доста интервали в името (мразя да има интервали в имената на файловете), е бял кахър. Сериозният проблем е, че windows-ът като е слагал някаква индексация на снимките ги е разбъркал и така, ако тръгнат да се гледат една по една, подредени на база име на файл (май повечето програми само това използвай като критерий за подредба), идват в разбъркан хронологичен ред. Единственият начин да се подредят е като се ползва датата на заснемане от EXIF информацията на файла. Когато става въпрос за 500-600 снимки, преименуването на ръка е голяма ракиена идея. Още навремето ми беше ясно, че трябва да се ползва някаква програма или скрипт, но тогава ме мързеше да я/го напиша. Сега, когато проблемът беше неотложен, продължаваше да ме мързи, но реших да се поразтърся и да видя дали някой не е решил да направи нещо подобно. Попаднах на KRename и с две итерации реших проблема. Доста ценна програмка изглежда.

Не на OOXML

Явно покрай еуфорията около Мишел през миналата седмица, някак си не видях отразена една новина из българското блог пространство относно неуспеха Microsoft да прокара положително за себе си решение в INCITS V1 относно това дали ANSI да подкрепи бързо приемане на OOXML формата. Явно петък 13 не е бил чак толкова лош ден. Повече информация за какво е цялата борба може да получите при Йовко. Ако искате да подкрепите петицията може да го направите тук.

Данъчни неволи

Този постинг е нещо като продължение на предишния подобен, но този път акцентът пада по-скоро върху това как се правят промените в данъчното законодателство с всичките му последствия.

В общи линии става въпрос за Декларация №6 по чл.42 ЗДДФЛ, която се подава от работодателите. Декларацията изглежда по следния начин.
Бас ловя, че някой програмист я е мислил. По-смотан дизайн на декларация не съм виждал. Принципно работодателят декларира какви данъци е начислил върху изплатени възнаграждения, като самите възнаграждения се класифицират в четири групи:

• аванс по трудов договор
• изплатено възнаграждение през месеца (заплати, но без изплатените аванси)
• начислени, но неизплатени възнаграждения
• възнаграждения по договор за работа без да са възниквали трудови правоотношения (граждански договори и т.н.)

Принципно тази декларация се подава всеки месец и за някои работодатели е възможно да са начислили данъци и в четирите групи възнаграждения. Поради тази причина колоните са четири. Само че от тук започва и гъвкавостта на декларацията. Първо няма значение коя колона за кой тип възнаграждение ще се ползва. Просто това може да се укаже с кода за вид на плащането. Нещо повече, всяка една колона може да се отнася за различен период. Това ог своя страна означава, че ако примерно имате само един вид плащане (заплати в края на месеца и не давате аванс) в посочения формуляр можете да декларирате начислените данъци за четири месеца. Лично на мен това ми се вижда страшно глупаво. Таз гъвкавост може само да обърка хората при попълване на декларацията, а не да ги улесни.

Тъй като декларацията се предава по електронен път, то основните проблеми покрай нея тепърва започват. Едва на 25 януари 2007 година е утвърден спецификацията на входните файлове с данни от изпълнителния директор на НАП. Макар и доста късно, все пак е положително, че е почти месец преди евентуалното първо предаване на тази декларация. Фирмите, които разработват такъв софтуер имат тренинг (все пак не за първи път ги изненадват с промени в законодателството) и би трябвало да се справят. Разбира се, НАП предоставят безплатен софтуер за хората, така че фирмите да не се чувстват задължени да си купуват софтуерен продукт за да попълват декларацията.

Наближава краят на февруари, но НАП още не са издали софтуер. За да не те глобят, отиваш в офиса на НАП и подаваш хартиен екземпляр. Те не могат да ти го приемат, защото нещата се подават по електронен път, но удрят нещо като входящ номер, че да е видно че си ходил.

Софтуерът излиза на 13 март. По-добре късно отколкото никога. Написан е за Windows. Явно НАП са решили да станат по-модерни, но многоплатформената поддръжка липсва. Така или иначе софтуерът им е тромав, поне да бяха седнали да го напишат на Java. Пускам го и се сблъсквам с феноменални интерфейсни решения (цъкнете за оригинален размер).
Това програмата да има менюта и табове едновременно е някаква невероятно революционна „идея“. Обикновено човек се спира или само на менюта или само на табове. Но разбира се, защо да не хвърлим потребителя на черешата. Винаги е хубаво нещата да могат да стават по няколко начина, така че ако пишем после документация, да се чудим как да ги опишем.

Вторият момент е начина на навигация из записите. Този тип навигация беше доста модерен по едно време. Май от Borland да го бяха въвели, но като цяло е доста неудобен. Трябва да се обхождат всички записи от една страна, а от друга страна не е много ясно дали разглеждаш запис, дали редактираш или правиш нещо друго. Да знам, че се свиква, но това не го прави добро решение. Разбира се, висотите в този вид интерфейс съм ги виждал в програми писани от Информационно обслужване, където като вземеш да редактираш някой въведен запис, вместо да го промениш и възможно да го запишеш като нов такъв.

Третият ключов момент, който открих е как се държи програмата при различни резолюции. Принципно програмата в режим под 1024x768 е неизползваема, но забавното е че се прави проверка дали прозореца се събира на екрана. Ако прозорецът не се събира (доста е висок за 800x600), той се мащабира, но не се появява скролер и част от полетата се крият, но навигационния панел остава. В резултат на което програмата е неизползваема. Но какво да се прави, по-добре това, отколкото нищо.

Разбира се, сагата не свършва дотук. След като се е появила програмата, в края на март се прави опит да се подадат декларации попълнени през нея. Има малко тънкости относно генерирането на файловете, които биха озорили счетоводител с недобри компютърни познания, но такъв е живота. Отиваш в офиса на НАП и изненада. Не могат да ти приемат дискетата. Само клиентския софтуер бил готов, сървърната част още не била написана. Смях голям. То да беше някаква сложна система, а то някакви елементарни записи. Някой студент като се хване за 3 дни ще напише всичко както си му е реда. Забавното в случая е, че до миналият месец в НАП още нямаха софтуера, с който трябва да се обработват дискетите и хаосът е пълен.

Мисля, че този пример показва на какво ниво е професионализма в администрацията, по отношение на планиране и изпълнение на разни проекти. Едни дребни неща не могат да се направят като хората, пък камо ли сериозни неща като електронно правителство. Ако се намеси и конфиденциалност на лична информация, нещата стават трагични.

Windows реклама

Днес докато четях една статия в linux.com попаднах на следната реклама:

Тези от Microsoft явно са станали доста безидейни. Но пък поне е забавно къде са я сложили.

Първи стъпки с Debian

Покрай необходимостта да се направят пакети на RD Suite за Debian и поради липсата на желаещи да направят това, реших да се наема с една такава задача. В резултат на което взех, че след толкова години работа с Linux, най-накрая стигнах и до тази дистрибуция. Тъй като нямам излишна машина, на която да правя такива експерименти, си пуснах едно qemu на което да инсталирам. Въпреки виртуализацията и мрежовата инсталация, всичко стана сравнително бързо. Първите ми впечатления са доста положителни. Харесва ми как са организирани нещата и че не се натрапва мнението на хората поддържащи дистрибуцията как да изглеждат отделните неща (който ползва KDE под Fedora ще ме разбере какво имам предвид).
Надявам се скоро да се появи и така желаният пакет. След диагоналното преглеждане на документацията на пакетната система направих основните файлове, но останаха още няколко неща да се настроят, пък времето все не стига.

Малоумието на ГДБОП

Днес се случи прецедент в българското интернет пространство, който навява мисли как свободата в България отива към нивата в Китай и Северна Корея. По искане на ГДБОП, БТК е отказала достъп на своите потребители до определен IP адрес. Няма да коментирам това, че БТК анонсира нещо, за което после е приложен филтър, или че нарушава договорните отношения със свои клиенти. Най-много да я осъдят и да плати някакви неустойки. Плашещото в случая е действието на ГДБОП, които меко казано си превишават правомощията. Като че ли досега свикнахме ГДБОП да изземва функциите на съда и да казва, кое е законно и кое не, да задържа хора, ей така за спорта и да види до колко ще им издържат нервите, както и да прецаква бизнеса, на неудобни за някой хора.

Новият елемент, към който не трябва да има никаква търпимост, е опитът им да се наложи цензура в интернет пространството. Предполагам, че законът им дава право да се правят на малоумни, но пък едва ли ги задължава. Разбира се, разни клоуни като Явор Колев, вместо да се гръмнат (обикновено клоуните в цирковете така правят), без да се замислят колко могат да сринат авторитета на институциите, за които работят, биха могли да наредят на всички български интернет доставчици на база закона на авторското право да филтрират трафика не само към arenabg.com, но и към google, youtube, vbox7 и всякакви там други страници дето предлагат достъп до страници със съмнения относно редовността на авторските права. Доколко тези „съмнения“ не са добре дефинирани цензурата би могла да се пренесе към всичко и да се филтрират медии, блогове, корпоративни сайтове и каквото там се сетите. Честно казано на мен изобщо не ми пука за торентите (от работа нямам време да си прочета разни книги, които съм си накупил, да си пиша в блога, пък камо ли да дърпам и да гледам филми), но цялата тази възможност за цензура е доста плашеща. Разбира се, доставчиците, ако искат да не им пострада бизнеса, щат не щат трябва да се съобразят с тази „заповед“ на клоуните. От друга страна нямат задължение да не филтрират да речем заявки от идващи правителствената мрежа, така че за нея да не бъде достъпно българското интернет пространство.

Малоумието на ГДБОП не се изчерпва с налагането на цензура в интернет пространството. Просто целият подход към решаване на проблема с нарушаване на авторските права от торент мрежите е обречен на неуспех и накрая клоуните от ГДБОП ще трябва да признаят невъзможността да се справят с проблема и да подвият опашките. От сървъри на съдържание, нещата преминаха към торент тракери, в последствие през тунели те бяха фиктивно „изнесени“ в чужбина, а сега може да се слеят с някой от чуждестранните торент тракери и да се върнат отново в първоначалния вариант. Докато ГДБОП не забрани достъпа до интернет (в крайна сметка филтрирането на IP адреси и DNS имена е доста неефективно) и не окошари всички интернет доставчици, защото съдействат за разпространението (макар и неволно) на пиратско съдържание, българските потребители спокойно могат да ползват чужди тракери. Разбира се, проблемът е дали ще има достатъчно български seeder-и, но в тази ниша могат да се вмъкнат бившите вече торент тракери. Тоест те да качват торенти на тракери в чужбина и да seed-ват яко. Както може да се сетите, няма как да бъдат хванати, тъй като могат да бъдат приложени серия от мерки, за затрудняване на проследяването им.

Все пак трябва да се каже, че ГДБОП не са виновни за положението, в което се намират. Депутатите са виновни за това, че приемат закони, които позволяват правоохранителните органи да малтретират гражданите на България. Ако дадеш 1000 лева, на правилните клоуни, то можеш да съсипеш достатъчно живота на някой обикновен човек. Ще преседи достатъчно време в ареста, ще му изтарашат офиса, ще му конфискуват някои работи и спокойно ще го фалират. Нека после да съди държавата. Финансово големите имат възможности за защита, но не така седи въпроса с обикновените хора. За мен възможността за такъв полицейски произвол не е приемлива. Предполагам и за вас.

ДДС неволи

Навремето, когато стана задължително да се подават дневниците по ДДС на магнитен носител, целият счетоводен бизнес се движеше под ДОС и някак си логично от Главна данъчна дирекция предоставиха софтуер, който работеше под ДОС. Първите версии на този софтуер бяха набързо написани и да не бяха много удобни. Тогава се изхитрих да правя дневници по ДДС на Excel. Схемата беше много проста. Въвеждаха се дневниците в електронна таблица (бях направил специален template), експортираха се в csv файл, прекарваха се през една ДОС-овска програма (защо не го направих на Excel-ския Basic не ми е ясно), която бях писал, и накрая се пръкваха файловете готови за данъчните. Който се е занимавал да прави програма за генериране на такива файлове, предполагам знае, че проверките в данъчната служба са малко особени и дори да е генерирал файл по спецификацията, която се публикува в някакво приложение има не малка вероятност генерираните файлове да бъдат върнати. Та последния етап от цялата процедура включваше импортиране на генерираните от мен файлове в програмата на данъчните, и записване на файловете на дискета през нея.

Въпреки, че така описана цялата процедура изглежда доста сложно, всичко ставаше за нула време при добра концентрация. Печелеха се следните неща. Първо дневниците можеха да се печатат на какъвто искаш принтер, а не само на широк матричен и лесно се пропускаха всички празни колони. Второ данните се въвеждаха доста по-бързо, заради автоматичното попълване на имена от страна на Excel-а, както и използването на формули за смятане на разни ставки. А и не на последно място около 40% от фактурите се издаваха от една програма, която ги експортираше в csv.

Тази процедура се използва и досега, нищо че през това време програмата на данъчните е поправена от гледна точка на бързо въвеждане на данни, спря да се използва програмата, която експортваше издадените фактури в csv файл и се появиха доста програми за Windows, които трябва да са по приветливи (като съм гледал програмата на Микроинвест, съм оставал с впечатление, че е правена за счетоводители от 0 до 3 годишна възраст. Толкова е шарена.) Обаче с последните промени на закона за ДДС и коренното променяне на формата на файловете се оказа, че трябва да се правят промени. Негативите от програмата на данъчните си остава необходимостта от матричен принтер. Windows-ки програми не искам да ползвам. От една страна фирмите, които ги разработват изкара версии преди няколко дни, а от друга страна мигрирам всичко под Linux и не ми се разправя с някакви емулации.

Тъй като бях затрил изходния код на програма, която бях писал и се налагаше да почна от чисто, то реших като правя новите неща направо използвайки QT, така че да ги вкарам после лесно в RDSuite. Тъй като не обичам половинчати работи се наложи да направя plugin за кодовата таблица MIK, дето се е ползвала едно време под ДОС. Направих си и всички структури, които съдържат дневниците и генерират в последствие файловете за дискетата. Набързо налях в тях данни от csv файловете, които генерирам през електронната таблица и реших да тествам дали всичко е наред. Критерият беше дали програмата на данъчните ще поеме моите файлове.

Както може да се очаква нещата не минаха гладко. Непрекъснато се сблъсквах с това съобщение.


Пооправих няколко неща, които бях сбъркал, но резултата беше същия. Явно пропусках нещо съществено и щом програмата на компютъра не ще да ги поеме нещата, то в данъчната служба едва ли ще е нещо по-различно. Мислех си, че е бъг в системата и изтеглих по-нова версия, но без резултат. В момент на отчаяние реших да пробвам да въведа някакви данни в програмата на данъчните, да ги запиша на дискета и после да ги импортирам от там в програмата на данъчните. За мое учудване съобщението за грешка остана. И тогава разбрах, че просто импортирането от дискета не работи и напразно съм се взирал в последния един час, къде е проблемът. Импортирах файловете от директория на диска (виж картинката отдолу) и нещата заспаха.


Разбира се, програмата, която писах за целта се мисля да я развия в някакво по-сериозно приложение с интерфейс и прочие, което ще бъде част от RDSuite и да може да си се ползва от всеки под Linux. Въпреки че не знам до колко това има смисъл, като гледам как RDSuite се сваля основно от Windows потребители.

И най-накрая само да отбележа, че DosBox е доста добър емулатор и фирмите, които правят счетоводен и складов софтуер, могат доста лесно да стъпят в Linux сегмента, като извадят от архивите старите си ДОС-овски програми, колкото да видят колко е голям пазара и ако отговаря на очакванията им да почнат на пишат native Linux приложения.