Funny bugfixes in Nortel 6.2.4 ERS software release

There are few nice bugs in Nortel 6.2.4 ERS release (release notes). There are update surprises:

  • After Upgrading from 6.1.1 to 6.2.1, QoS configurations were lost (wi00838747)
  • Some links get disabled after upgrade from 5.1.x to 6.x (wi00731564)
  • Stack upgrade failure from 6.1.4.011s to 6.2.1.003s with a large config file (wi00882592)
  • After upgrading from 5.1.4 to 6.2.1 EDM routing/IGMP/SNOOPING table expanded indefinitely causing high CPU utilization (wi00886347)

Weird issues, which can be explained by lack of objects interoperability:

  • Unable to add static route under certain conditions, adding the route required a reboot (wi00937754)
  • With autosave enabled on 5632FD, if the power is recycled the fiber connectivity to 470-48T switch is lost (wi00941175)
  • Autonegotiation could not be disabled (wi00824799)
  • Ping or Telnet to any DNS hostname would sometimes cause loss of connectivity to the management VLAN requiring a reboot of the stack (wi00933202)

Very weird bugs, which cause many wtf-like questions on the source code:

  1. Using show running-configuration with 744 VLANs configured, spiked the CPU utilization to 100% for about 12-15 minutes (wi00907462)
  2. Switch does not learn MAC of format xx:59:xx:xx:xx:xx (wi00870510)
  3. Cannot give an IP address to the switch with the last octet as “0” (wi00872983)

I can explain the third bug by an error of checking network address in classless notation. I suppose, the code was checking an IP address in a classful way, i.e. if IP ends by zero, it’s a network address, hence can not be assigned.

How could they create bugs 1 and 2? They should’ve had hard coded numbers 744 and 0x59 (dec89). Why? what was the purpose? What was the algorithm? Can you guess an algorithm by knowing the information above?

How to Remove Juniper Netscreen Tunnel Interface

1. Delete all routes for all VR’s

set route 10.0.0.0/24 interface tunnel.1 preference 20
set route 10.0.0.0/24 interface tunnel.1 preference 20

2. Delete all policy entries

set policy id 1 name "Policy Name" from "Trust" to "Untrust"  "Local" "Remote" "HTTPS" permit
set policy id 1
set service "Remote-services"
exit
set policy id 2 from "Untrust" to "Trust"  "Remote" "Local" "ANY" permit
set policy id 2
set dst-address "Trust-networks"
exit

3. Delete all policy elements

set address "Untrust" "Network Name" 10.63.194.0 255.255.255.0

4. Delete all interface bindings. Via web interface you should edit AutoKey IKE entry by removing interface binding first (advanced settings), only after delete the AutoKey IKE

set vpn "PH2_Policy" id 0x1b9 bind interface tunnel.1

5. Delete AutoIKE entry

set vpn "PH2_Policy" gateway "PH1_Policy" no-replay tunnel idletime 0 sec-level standard
set vpn "PH2_Policy" monitor source-interface ethernet0/1 optimized rekey
set interface tunnel.1 ip unnumbered interface ethernet0/1

6. Delete the tunnel Interface

set interface "tunnel.1" zone "Untrust"

О мате

Я, наконец–то, понял, чем плох мат. До этого как–то не удавалось сформулировать.  Вот типичные аргументы адептов русского мата в изложении всеми любимого Артемия Лебедева: “Мат — это не латынь и не суахили. Мат — это и есть русский язык. Ничто так не способствует развитию родной культуры как родная речь. Употребление мата на письме, в устной речи — это развитие русской культуры” Артемий напирает на то, что матерные слова — это не какие–то особенные, грязные слова, которые стоят особняком от всего остального русского языка, а такие же полноправные члены лексикона. Ок, тут он прав. Но есть еще кое–какой аспект, который он и другие матоложцы упускают из рассмотрения.

Мат — это суррогатный контекстный язык. Точнее, он потенциально может стать таким. Нет ничего плохого в том, чтобы назвать хуй хуем. Однако, в отличие от других корней, матерные корни обладают свойством джокера — они вполне могут заменять любые другие. Набросать — нахуячить, нарисовать — нахуячить, наготовить — нахуячить. Благодаря этому свойству, матерные слова могут заменять любые отсутствующие в лексиконе или подзабытые слова. Необязательно вспоминать слово “претензиозный”, можно сказать “нехуевый”. Или “пиздатый”. Или “ебанись какой”. Особенно ярко проявляются дегенеративные свойства мата в устной речи: там под удар попадают не только отсутствующие в лексиконе понятия и слова, но и те, которые чуть задержались в отдаленных уголках мозга, и вместо “передай мне эээ…надфиль” можно услышать “передай мне ту хуйню”. С одной стороны, мы пользуемся родной речью и всеми возможностями, которые она предлагает, а с другой — манкируем ее богатствами, заменяя их сублимированным сухпайком из контекстно–зависимых универсальных корней. Второй аргумент, который часто приходится слышать — мат содержит в себе необходимую эмоциональную окраску, которой не достигнуть, пользуясь эвфемизмами. Но это же естественно! Эвфемизм — это всего лишь матерное слово лишенное привычного облика. Теряя свою обсценность, ореол “запретности”, оно не приобретает ничего и предстает пред нами во всей своей беспомощности. Ошибочно принимая эту самую “запретность” за эмоциональную окраску, люди называют друг друга уебками, жалуются, что соседи пиздят картошку и так далее. Весьма сомнительно, что выражение “Словом можно убить” было сказано о таких примитивных ругательствах. Контекстность, “джокерность” мата мешает ему разить точно в цель, ведь адресат всегда может понять его так, как захочет — это же слово с десятью тысячами смыслов! Лишая потребности правильно, точно выражать свои мысли, мат кастрирует речь, не давая лексикону пополняться. Если вы сейчас думаете, читая: “это все хуйня”, то задумайтесь, а почему вы не подумали что–то вроде: “нелепые потуги вывести мои привычки в качестве злокачественной зависимости”?  Ну, и в заключение — анальный табель: 1. Первая степень — человек разумный. Когда уместно, назовет хуй хуем, пиздец — пидецом, а когда не уместно — воспользуется эвфемизмом или подходящим словесным оборотом. 2. Вторая степень — человек посылающий на хуй. Не любит эвфемизмы, ругается только с употреблением мата. 3. Третья степень — человек–хуйня. Часто использует матные корни в обыденной речи. 4. Четвертая степень — человек, бля. Непроизвольно матерится, ептый. Не может, бля, не материться. Нахуй. Постскриптум: есть еще ханжи, это тоже болезненное отклонение.

Я всегда ругался матом столько, соклько хотел, в любом обществе и при любых обстоятельствах. Я называл всех, кому это не нравилось, ханжами. До того момента, как кто-то написал этот текст на Лепре. Меня очень сложно убедить в чем-то расходищимся с моим собственным мнением, но эта цитата сделала невозможное. Впредь я буду стараться употреблять меньше мата, стыдиться выскочившему мату и проявлять другие призныка высокообразованного мальчика.

Animated favicon

Tiamat.name has a favicon now. Happy Firefox users see . Opera, Konqueror, Chrome users see only the first frame from the gif: . IE users should see


    

DokuWiki and Syntax

I have tried Dokuwiki for a personal wiki. It’s ugly. It forces me to edit pages as a plain text files, using it’s own wiki syntax format. It also stores articles in a format of wiki text. Every time somebody wants to view a page, Dokuwiki parses wiki-formatted file and produces HTML. Every time. That’s how article looks in a wiki format.

====== HiPath 4000 Backup destinations: ======
  - MO/CF
  - Server
    - NFS
    - FTP

====== HiPath 4000 HDD Layout ======

^Name	^Purpose	^Contents^
|:PDS:	|program disk	|RMX|
|:DBD:	|Debug disk	||
|:AMD:	|Administration and maintenance disk	||
|:CGD:	|Call change disk	|tarification files|
|:TMD:	|Traffic metering disk	||
|:PAS: 	|Miscellaneous usage	|REGEN file|

Looks ugly. That is a how your data is seen by both editor and application. Both editor and dokuwiki have to be able to understand wiki syntax in order to see the formatted data. Both are negatively affected. Editor has to learn a new syntax for writing an article, Dokuwiki has to translate article to HTML every time user requests it (many times).

The third victim is data itself. It gets transformed to an ugly format, compatible with the only software which is wiki engine you use. In other words, if you let a wiki engine take care about your information, the information would most likely stay in there forever. If you want to extract a document from a wiki engine, you have to render a page, using the engine.

Why do we need to have wiki-formatted intermediate presentation? The official answer is to help users who lacks HTML+CSS knowledge to develop a document structure. It probably worked in 2000, when there was no technology for creating interactive applications in a browser. Nowadays things changed. We have Google docs, which allows a document to be edited in WYSIWYG mode, and, moreover, to be stored and exported in any format. Some might say WYSIWYG editors corrupt formatting when used in a wrong way. It applies to documents where we need a style. In a Wiki we do not aim to create a document with style. We do aim to develop a document with structure. Style has to be generated by a wiki engine.

Hence, the best approach for wiki architecture is: editing documents in WYSIWYG, storing documents in a structured format without styles, presenting them as-is.

It is very important not to let WYSIWYG editor to define styles. It’s a common user mistake to apply styles to an articles. Styles has to applied by an application. An editor should define the structure of the document only: Headings, paragraphs, tables, code, bold, italic, etc. Editor needs no colours, no browser compatibility nothing extra.

Let the approaches be compared:

Stage Wiki-approach Correct approach Best approach
Editing Using ugly wiki format, which is neither a
document, nor a pure data
Using WYSIWYG editor, which allows editing
structure, but not styles.
Using WYSIWYG editor, which allows editing
structure, but not styles.
Storing Using ugly wiki format, which is neither a
document, nor a pure data
Using a structured document format, like (X)HTML,
XML, OD>
(X)HTML with no styles
Presenting Parsing wiki format, restructuring it to a
document (HTML+CSS)
Presenting a stored document as is+ applying some
predefined styles to it.
(X)HTML + CSS style
Engines MediaWiki, DocuWiki, pmWiki Almost there: WordPress, MoinMoin, Sharepoint wiki module… ???

Currently there is no Wiki engine in the market who does the job right.

3 Things Web Can Not Do in 2011

There is no way to share files between end-users without a server. You have to share a file somewhere on a server. Even torrents require a tracker. I want to have an opportunity to let someone download a file I have. in a current situation I have to either share it somewhere, either email it, or my PC a server. Every way is too complicated.

There is no standard on RSS feed entries formatting and rendering. It’s somehow HTML and CSS, but since there are many kinds of feed aggregators, they all render HTML-in-XML differently. Also, there is no way to apply proper JS to RSS entry, because there is no proper DOM support and no specification for a RSS reader opportunities as well as rendering rules.

There is no way to download several files by a single click. You have to either click every file’s URL, either download a single archive with multiple files inside. URL does not support including several files in a single hyperlink. This architecture lays in an architecture of a very first designs of web.

If you know any desired feature, web does not yet support, feel free to share your thoughts.

Perl error “isvstring is only available with the XS version of Scalar::Util” fix

I faced the subj error after updating Perl package. It appears, Scalar::Util package is shipped with C-compiled modules which are not properly updated by yum. The workaround is manual package reinstalling:

wget http://search.cpan.org/CPAN/authors/id/G/GB/GBARR/Scalar-List-Utils-1.23.tar.gz && \
tar zxvf Scalar-List-Utils-1.23.tar.gz && \
cd Scalar-List-Utils-1.23 && \
perl Makefile.PL && \
make test install && \

Stand Alone

Stand alone блог – отличный шанс почувствовать свою независимость в сети на миг, а потом потерять весь интерес к блоггингу.

Еще это отличный шанс быть, у всех на виду, но при этом оставаться совершенно невидимым. Как в Московской толпе – все смотрят мимо тебя. Так же и этот блог, с четырьмя стами хитов в месяц, из которых 95% спамботы. Блог есть, но есго никто не видит, хоть он и близко. Зато можно кричать. Можно ворваться в кишащий хаос вбеа и заорать во весь голос, переходящий в ультразвук, а потом затухающий хрипотой. И никто даже не обернется. Никто не зматит.

Here I stand among the crowd of web. Alone.

Smooth Transition

Слишком часто встречается явление, когда один человек начинает всречаться с другим, не расставаясь с предыдущим. И плавно переходит из рук в руки. Это есть проекция капиталистического взляда на вещи, когда хочешь больше, но не хочешь терять того, что есть. Через риск, ложь переводишь себе на баланс более качественный, лучший объект. Прямая монетизация отношений. Это не работает в долгосрочной перспективе. В долгосрочной перспективе работает честность.

T1 logo in JS+PNG

Initially, my logo was 105K GIF. Now it’s transparent PNG+JS. As easy as:

            //
            var color = 0;
            var interval = 60;  /* time msec, after which color changes */
            var clrInc = 4;     /* HSV degree increment */
            function chcolor(){
                var t1_logo = document.getElementById("t1_tl"); /* div_to_animate */
                color < 360 ? color = color + clrInc : color = 0;
                t1_logo.style.backgroundColor = "hsl("+color+", 100%, 50%)";
            }

            function stchcol(){
                var logoChCol = setInterval(chcolor, interval);
            }
            window.onload = stchcol;
            //-->

and

Main page

Benefits are smaller page size, smaller prcessor load. Eventuall, animation in JS consumes lees resources than a GIF rendering. 35% losad with GIF animation vs 15% load with JS animation. At least, in Fedora 16 with nouveau.

The idea was given to me by fiskus, but it was quite a long ago, so I feel I had the same idea at the moment he suggested it to me. Nevertheless, he desrves a credit.