colocation support

хостинг на три буквы, первая — m

я: нужно перезагрузить сервер
они: готово
я: что–то нет ответа. а не могли бы вы подключить kvm?
они: готово, логин, пароль
я: спасибо, kvm работает, но, к сожалению, сервер не мой

первый их сбой, кстати. все остальное — просто замечательно; лучший хостер из всех на моей памяти

хостинг на 6 букв, первая — m

сначала подвисала сетевуха с сообщением TX is hung и они не могли разобраться в проблеме

после перетыкания кабеля стало работать

обнаружив, что соединение half duplex вместо full duplex, предположил, что проблема у них в кабельной системе. ответа жду уже третью неделю

хостинг на 10 букв, первая — m

перевозили без предупреждения ночью сервер в другой датацентр

когда заканчиваются деньги, отключают dns. то, что он у некоторых клиентов в глубинке восстанавливается неделями, их не ебет

хостинг на 9 букв, первая буква — p

пиздец, никому не пожелаю.

служба поддержки способна разобраться с проблемами только в рабочее время по будням. в выходные нет даже дежурного админа.

при установке сервера выдали мне чужие ip адреса.

забыли оформить пропуск на внос сервера.

при расставании выдали не мои салазки.

на площадке сервер перед выносом всегда выключается по питанию.

svn

svn мне напоминает анекдот:

«

– я ж тебе говорил, что это говно, а ты — засахарилось, засахарилось.

»

возьмем, например связывание директории с другим репозиторием через svn:externals

во первых, это делается жутко неочевидным способом.

во вторых, в svnbook нет явного примера, как это сделать.

в третьих, для того, чтобы связать директорию внутри дерева файлов, связывать ее нужно в корне репозитория.

памятка:

$ cat >svn_ext_val.txt
dir_of_repo_one http://svn.my.com/path/to/repo_one
dir/of/repo/two http://svn.my.com/path/to/dir1/dir2/repo_two

svn propset svn:externals . -F svn_ext_val.txt

ЕЩЕ: все оказалось еще интереснее. оказывается, эти проперти нужно закоммитить, а у меня была куча файлов, которые коммитить не хотелось. определенно, разработчики svn какие–то хуеголовые

ЕЩЕЩЕ: они не умеют показать файлы, которые будут обновлены без реального update. это уже даже не пиздец

SD vs BluRay

мне сразу показалось, что победа BluRay над HD DVD была пирровой. размышляя пару дней назад с женой над будущим BluRay пришла в голову идея сделать небольшую табличку.

тип	SD/microSD	DVD	BluRay	HDD
размер	32 × 24 mm 11 x 15 mm	120 x 120 mm		101.6 х 26.1 х 147 mm
емкость*	8GB	4.38 GB	25GB	1000GB
скорость доступа	20 MB/s at 150x	10 MB/s	18 MB/s at 4x	30 MB/s (USB 2.0)
стоимость оборудования, руб.	100	1000	9000	1000
цена носителя за гигабайт	71	7	21	3
цена за 1000 гигабайт**	125 / 72500	220 / 7850	40 / 30200	1 / 4200

* за номинальную емкость SD взята емкость, которая оправдана экономически, то есть лучше по соотношению емкость/стоимость

** включая стоимость оборудования, коим является кардридер, дисковод и коробка для hdd; цифра в числителе дроби — количество накопителей.

мораль всего этого такова:

1. для домашнего консервирования дешевле и удобнее купить внешний жесткий диск;


2. для переноса небольшого количества данных стоит использовать SD/microSD; для большого количества данных — внешний hdd


3. диски BluRay по большому счету нафиг никому не нужны в дальней перспективе — SD очень активно дешевеют, чего за BluRay дисками не наблюдается. и применения им не видно, потому что для переноски данных они не годятся из–за высокой стоимости оборудования, для консервирования — из–за высокой стоимости;


4. DVD — достояние истории. на них по прежнему можно хранить данные, но ощутимо проще (но не дешевле) купить SD на 8–16 GB и забыть про стопки DVD как про страшный сон;


5. не стоит рассматривать SD как панацею — стоимость за гигабайт все еще слишком высока.

opensource

вообще, opensource забавная штука. вот я выкладываю свой код и получаю на него вполне себе feedback. opensource — это как социальные сети для разработчиков.

в большинстве своем opensource, конечно, на редкость уебищно — нет ни нормального интерфейса, ни нормального кода, но некоторые проекты, в которых есть некий заказчик и организатор или упёртый эниузиаст, выходят отличными. например, ничего лучше, чем evolution, для почты еще не придумали. или другой пример, я использую eclipse colorer plugin для подсветки синтаксиса многих файлов. оба — и eclipse и colorer — примеры качественного opensource.

и мне самому было бы тяжело без открытого кода. как бы я тогда поправил баги в DBD::Oracle, если бы не было исходников?

вообще все это я хотел написать после того, как пересоберу colorer под snow leopard. но не тут то было — colorer пересобрался, но при попытке открытия файла падает.


ХАХАХА: мы с создателем colorer нашли проблему и я таки собрал новую версию.

miraculous oracle

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

допустим, в таблице есть поле VARCHAR2. максимальный размер поля такого типа — 4000 байт. теперь начинается fun. допустим, мы создаем поле типа VARCHAR2(100 CHAR). в реальности же будет создано поле размером x00 байт (где x — максимальное количество байт, которое потребуется для представления любого символа из UCS2 в UTF8). так, чтобы 100 любых символов из unicode поместились. хотя, возможно, внутри оно хранится в UCS2 и поэтому выделяется всего 400 байт.

отойдем от технических деталей и попробуем вставить 100 символов. у нас все получится, несмотря на кодировку. то есть вставится и 100 ASCII и 100 Kana.

теперь же попробуем выделить 4000 CHAR для этого поля. и что вы думаете? в такое поле может быть вставлено будет только то количество символов, которое в utf8 помещается в это количество байт. на другие значения будет выдано сообщение об ошибке.

совсем забыл: но это еще не все. для обхождения ограничения в 4000 байт нужно использовать CLOB. но просто так нельзя записать в CLOB более 4000 байт (меньше — можно). для записи нужно отказаться от

prepare ($$sql)
execute (@params)

и начать использовать

prepare ($sql)
foreach my $params (@params) {
    if (sql_type_of ($param) eq 'CLOB') {
        bind_param ($i, $param, {ora_type => 112})
    } else {
        bind_param ($i, $param)
    }
}
execute

там, конечно, условия посложнее, но общее представление показывают

DBD::Oracle bugs

второй критический баг в DBD::Oracle:

https://rt.cpan.org/Ticket/Display.html?id=46661

p.s: первый:

https://rt.cpan.org/Ticket/Display.html?id=44788

еще немного в копилку о базах

как обычно, сегодня одна какашка в сторону oracle и луч поноса в сторону mysql.

oracle, как сурьезный движок баз данных, конечно же не имеет неявных секвенсоров (хотя, может и имеет, но я не знаю способа привязать секвенсор к полю кроме как через триггер). поэтому функция $dbh->last_insert_id вообще не имеет смысла. чтобы достать это самое значение для primary key, сгенерированное из некоего секвенсора, я должен детектить секвенсор и брать из него currval. жутковато, но работает.

ну а поддержку primary_key_info писал мудак. потому как в оракле нужно в качестве схемы скормить имя пользователя, что выливается в специальный код для поддержки оракла. нужно будет отправить им патч.

вообще, oracle постепенно у меня в голове превращается в долбанутую, но вполне работоспособную систему.

теперь к mysql

BEWARE 5.1!

в какой–то момент mysql умудрился потерять администраторские права для рута. и это вылилось в поднятие еще одного mysql и переливание данных, создание заново всех пользователей. вообще как это можно сделать что–то такое, чтобы их потерять?

короче, я не знаю, как там будет дальше с mysql, но если он исчезнет, то я не расстроюсь. ну его нахуй в таком–то виде.