Void and Null

Преди около месец със Станислав написахме една документация по електромера, дето го правим за дипломна работа и я пратихме като публикация със заявка за участие на Compsystech 2009. Тогава разбрахме късно и хванахме някакъв deadline extension, но в крайна сметка заявката беше изпратена в срок. От тогава насам чакахме месец и кусур да изпратят обратно ревю с отговор. Идеята на това ревю е ако има нещо криво, да оправим публикацията да я изпратим отново на опашката. Крайния срок да получим ревюто беше на 30-ти май, а то дойде на 31-ви вечерта.

Това ревю се състои от три независими наблюдения.

Първото наблюдение твърдеше че според него измерването на електрическа енергия не е важно.

Is it really _important_ for everyone to know how much power _exactly_ use their consumer electronic devices?

Ами да, подяволите, важно е! Енергията струва пари, енергията замърсява природата!

Другата му аргументация за Weak Reject рейтинга беше че английският ни е зле. Беше изкарал цели четири правописни грешки от пет страници документ. Излиза по-малко от една грешка на страница. Ако беше матура по български език от преди двадесет години, да сме скъсани. Само че това не е матура, а представяне на техническа документация.

Освен това сме нямали връзки към други документи (references). Имахме посочени два-три datasheets, няколко application notes и една свързана по темата истинска публикация от друг автор.

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

Третият наблюдател ни е сложил най-високата оценка - Neutral (4). За него английският пак е зле. Не е ясно с какво документът допринася за добруването на света и би трябвало да бъде постнат в детската секция, а не в хардуерната. Критиката, която приемам от него е че сме забравили да сметнем грешката на електромера. Това е сериозен пропуск за едно измервателно устройство.

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

Another crash happened while handling crash!

От Google Earth и разбитите им версии за Линукс. Версия 4.2. тръгва един от пет пъти (на напълно случаен принцип), а версия 4.3 и нагоре забива системата до ниво “екрана на снимка и всички прекъсвания - забранени”.

# tc filter help
Command “help” is unknown, try “tc filter help”.

Обичам липсата на документация и когато същата документация представлява един ред:
TODO: translate from Polish

… И когато връзката към полската документация е 404

Всеки мрази проблеми. От всякакво естество. А най-отвратително е когато проблема уж се реши, а се оказва че само е отложен/разсеян/заобиколен/подтиснат…
Проблема е че LAN картата на случайни интервали от време спира да работи и единствения начин да се пусне е рестарт на машината. В dmesg имам:

<br />
NETDEV WATCHDOG: eth0: transmit timed out<br />

LAN картата е Realtek 8139. Текуща версия на ядрото - 2.6.25.6, но проблема съществува във всички 2.6.х
В нета са изписани хиляди мнения по въпроса - никой не може да каже точно какво е. Навсякъде се повтаря ‘грешка в драйвъра на картата’. На места пишат че от 2.6.24 нагоре проблема е оправен - да, ама не. На места пишат че Windows записвал някакви шитни в паметта на картата, които пречат на други операционни системи да активират картата. Глупости, защото във FreeBSD нямам проблеми. Всъщност проблема се появява дори след рестарт от FreeBSD към Линукс.
Ето някои мои наблюдения върху феномена:
1) Грешката се появява само след рестарт от друга операционна система към Линукс.
2) Картата се изключва в абсолютно случаен момент от време - не зависи от мрежовото натоварване, от температурата или от фазата на Венера.
3) Ако се рестартира машината след получаване на грешката, има шанс това пак да се случи. Единствената застраховка - гарантирано че мрежата няма да изчезне - да се мине през пълен shut down. През какъвто и да е рестарт (топъл, студен) или стоп на машината да се мине, има шанс следващия път проблема пак да се появи.

На места намирам препоръка да се изключи tcp segmentation offload (каквото и да значи):

<br />
ethtool -K eth0 tso off<br />

Не върши работа.

Някой казват че проблема е свързан с ACPI и препоръчват в процеса на boot-ване да се добави стринга “noacpi”. Не работи.

Най-тъпото е че Проблема (мисля че си заслужи главната буква) не може да се дебъгне с никакви конвенционални средства. Току изглежда че някаква магическа мантра помага - мрежата не пада… и след Х часа/дни/седмици пак се издъни.

А на всичкото отгоре DNS-a на доставчика ми внезапно спря да прави resolve на ivanatora.info.

Много се дразня когато половината ми contact list от еди-кой-си Instant Messanger почне да ми праща приветливи линкчета, обещаващи порно или други човешки благини в голямо количество… Ама най-много се дразня когато въпросните спамове са написани неграмотно:

Така ли не можа поне името на сайта да си напишеш правилно?
Всъщност интересното е, че HIT.BG имат такъв акаунт. Но имат и акаунт с правилно написано име, който ви отвежда на сайт обещаващ още благини… как да правите пари от интернет докато си стоите вкъщи.
Няма такова нещо като безплатен обяд! Това е за всички вас, които не знам с какъв акъл цъкате на всякакви линкове!
Ако внезапно ви изскочи подчертан син надпис (в повечето пъти), спрете се и пребройте до десет или петнайсет преди да цъкнете отгоре му. Кой ви го праща? Дори и да го познавате, разпитайте го. Защо ви го праща? Какво очаквате да намерите там? Не се дръжте като рибки, а използвайте малко сивото си вещество!