О неразрывной связи двух российских бед: http://nilsky-nikolay.livejournal.com/637717.html
"По сравнению с 1901 годом, когда было лишь 1 200 км дорог хоть с каким-то покрытием, в 1938 году в США было закончено 448 000 км шоссе и улиц, в большинстве своем сделанные из бетона, а к 1941 году было построено уже 960 000 км дорог.
Протяженность автомобильных дорог с твердым покрытием в СССР к концу 1940 г. достигла 143,4 тыс. км, стала почти в 4 раза больше, чем в 1913 г."
Тут проскакивало, дескать инопланетяне могут быть опасными по причине, что исчерпав полезные ископаемые у себя они шляются по космосу в виде высокотехнологичных кочевников и копают чужие планеты. Мда. Мне представляется, вот чего может достичь цивилизация, так это возможность не добывать блядские полезные ископаемые. Ведь это каменный век. Фрейдийский комплекс охотника-собирателя. Нахуя полезные ископаемые, если любая частица материи содержит неизмеримое количество энергии? И нахрена полезные ископаемые, если любой элемент может превратиться в другой элемент? Не, инопланетяне, высокоразвитые инопланетяне, они есть, и о нас они знают. Только делать им с нами нечего. Делиться технологиями? Нахуя делиться с технологиями с корыстными, тупыми и агрессивными обезьянами? Учить человечество уму-разуму? Бесполезно. Тут помогут только миллионы лет эволюции.
Силовики предлагают запретить ПО, скрывающее пользователя в Сети
Общественный совет при ФСБ России считает необходимым совершенствование правового регулирования деятельности юридических и физических лиц, распространяющих информацию в интернете. В связи с этим советом были сформированы предложения к законодателям о необходимости запретить использование анонимайзеров — программ, маскирующих информационные данные и IP-адрес пользователей.
Дело в том, что, если по решению суда будет заблокирован доступ интернет-пользователей к определенному сайту, последние при помощи анонимайзеров смогут посещать страницы заблокированного сайта. Например, при помощи данных программ пользователи в Китае и Белоруссии весьма благополучно заходят на те сайты, к которым местные власти блокируют доступ.
Инициатива силовиков подразумевает запрет программного обеспечения или браузеров со встроенным анонимайзером (таких как браузер Tor). Кроме этого, к маскирующим инструментам относятся веб-серверы — автономные сайты, при помощи которых пользователи могут без установления специальных программ переходить с измененным IP-адресом на блокируемый сайт.
Подобные поправки будут внесены в федеральный закон «Об информации, информационных технологиях и о защите информации».
копаюсь в солярковом говне которое должно пулять выхлоп zfs_send() через TCP, сервер соответсно - принимает и срет в локальный датасет через zfs_receive(). сервер умеет несколько клиентов. дизайн сервера, если в двух словах,- многопоточный ад. в процессе рефракторинга пришла мысль - что если все на SCTP переделать нахуй? в плюсах reliability и поддержка multihoming из коробки, число необходимых сокетов сократица до двух на сессию - одно для данных, другое - для контрольной инфы, минусов никаких не вижу. Какие подводные камни есть у SCTP ? SCTP vs TCP тред гоу
"Дорогой премьер-министр, вы не представляете как я вам сегодня благодарен. Вы даже не знаете, какое благое дело сделали для страны сегодня. Сегодня я впервые видел как фанат Фенербахче помог подняться с земли галатасарайцу после приказа полиции "убивать".
Сегодня турки и курды делились водой и хлебом. Сегодня женщины, которых вы называете проститутками, вышли из публичных домов, чтобы промыть раны пострадавших и напоить их лимонной водой.
Сегодня нелюбимые вами трансвеститы спасали людей в своих комнатах дешевых отелей тарлабашы. Адвокаты и врачи раздавали свои телефоны для оказания помощи. Сегодня эснафы (магазины, кофейни все что на первых этажах) отключили пароли на вайфай, а отельеры пускали утомленных или избитых. Сегодня наши глаза полны слез не от вашего перечного газа, а от гордости за нашу Турцию."
http://juick.com/2381278
"Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?
Программист: ну представь, что ты писатель и поддерживаешь проект "Война и мир". У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь "шёл дождь", сохраняешь, вылетает сообщение об ошибке "Наташа Ростова умерла, продолжение невозможно". Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение "Поручик Ржевский умер." Выясняется, что он в следующей главе облокачивается о столб, которого уже нет..."
Резюмирая полгода молчания про SOM:
При портировании SOMObjects Toolkit на Borland C++ Free узнал заодно кучу интересных вещей о C как таковом (большинство примеров для него). Во–первых, есть такая очень весёлая проблема с разным манглингом в разных компиляторах. Символы в DLL можно импортировать двумя способами: через __declspec(dllexport) и __declspec(dllimport), а можно через .def файлы. Если через __declspec, то при экспорте компилятор сам выбирает имя, а это не всегда подходит. Разные компиляторы делают разный манглинг, и вообще, у SOM есть свои требования к именованию в таблице экспорта. Так что только .def. .def файл, похоже, под каждый компилятор нужно писать свой, потому что .def файл сопоставляет имя в таблице экспорта DLL с именем, как его манглит компилятор, когда читает заголовочный файл. Вот Borland, например, добавляет _ в начало cdecl функций и переменных, но никак не уродует stdcall функции, а GNU, я так понял, норовит добавить @размерстека. А VisualAge, под который было всё заточено, добавляет _ в начало и @размерстека в конец. Эта проблема худо–бедно решалась coff2omf, implib и тому подобными утилитами, которые все имена из одного уродства превращают в другое по одному алгоритму. Варьируя командную строку, обычно можно добиться результата. С SOM такое не прокатывает, потому что stdcall там перемешан с cdecl и переменными, и алгоритм должен быть для них разный. Запарился, в конечном итоге просто написал .def файлы руками, во всём SOM 3.0 около 1000 вызовов, не так уж много. Делая это, как не вспомнить импорт/экспорт в Delphi. function такая–то с соглашением таким–то, external оттуда–то с name таким–то. И не надо думать, какой манглинг получится в этом компиляторе для такого–то соглашения. Чётко и конкретно. Правда, нет импорта/экспорта переменных.
В somplatf.h по дефолту делается __declspec(dllexport) для Microsoft C. Как там происходит в MS, не знаю, но если в Borland я оставляю этот __declspec, то этот символ начинает торчать из DLL с тем манглингом, который мне не подходит наряду с нужным манглингом. Так что для Borland я дефайн поменял на пустой. Но если это так, то, может быть, и __declspec(dllimport) не нужен, ведь есть .lib, скомпилированный из .def? Ответ неверный. Для обычных функций генерится код вызова call туда–то, а для импортируемых функций — call dword ptr [там–то], плюс, генерятся трамплины, и, если подключить .lib, но в хедерах не использовать __declspec(dllimport), то компилятор создаёт неправильные вызовы, и всё крашится.
Ещё один источник радости — выбор рантайма в DLL. Так как программы на SOM в любом случае используют som.dll, то не будет лишним использовать и cc3250mt.dll. Всё компилится, даже что–то работает, но какие–то программы крашатся. Позже выясняется, что программы, выводящие на экран через somPrintf, работают, а через fprintf — нет. При отладке выясняется, что stdout не тот, который нужен. У cc3250mt.dll свой stdout, и только через него нужно делать fprintf, а, если не использовать /tWR, то stdout получается в .exe'шнике и не канает. Крашится, то есть. Реализация fprintf отнимает от адреса параметра FILE * адрес начала _streams и делит на sizeof(FILE). Если _streams в cc3250mt.dll, а stdout в .exe, получается дробное отрицательное число, и ничем хорошим это не кончается. По идее, у того, кто bcc32 сразу и компилит, и линкует, такого не происходит, но в нашем случае система сборки разделяет компилятор и компоновщик, поэтому может получаться такое рассогласование. В целом, с Borland вроде бы разобрался. Непроверенными остаются только нюансы с .dll, которые в примерах SOM используются только в DSOM, но DSOM службу я не поднимал. Я вижу, что всё компилится, я вижу, что импорты и экспорты без подчёркиваний, но для проверки надо поднять службу DSOM.
С .def файлами вообще весело. Я не знаю, это фишка Borland или в чём дело, мне .def для компиляции .dll и .def для создании библиотеки импорта (.lib) приходится генерить разные, хотя было бы логично, если в пределах одного компилятора как экспортировали, так и импортируем. То есть, в .def для .dll я пишу dAnimalClassData=_dAnimalClassData, а в .def для .lib — _dAnimalClassData=dAnimalClassData. Не знаю, можь это с переменными только такая петрушка.
Пока что завален рефератами. Из 6 рефератов в год удалось отвертеться от 4х и защитить 1. Надо защитить ещё один, плюс на работе проект важный. Летом, как освобожусь, надо продолжить. Есть желание сделать такой пакет Borland+SOM, чтобы студентоте в качестве Borland C++ подходил, работал без шаманства, в отличие от оф. версии. Оф. версия требует прописывания путей в bcc32.cfg и ilink32.cfg, плюс, не находит их, если путь к .exe'шнику bcc32 или ilink32 содержат в себе пробел. Всё это можно разрулить.
Ну а как бонус, там боеспособный SOM и демки к нему. Впечатляет, как мало весят .exe'шники и .dll'ки. Обычно, если используется ООП, всё быстро разбухает, несмотря на рантайм в отдельных .dll, а тут классы конструируются в рантайме, а в .exe'шниках и .dll'ках только метаинформация со ссылками только на переопределённые методы.
Самый тупой способ генерировать случайные числа от нуля до нужной верхней границы (не включая), если у тебя есть [псевдо]случайные (устраивающего тебя качества) биты — взять остаток от деления на верхнюю границу. Проблема в том, что это не даст равномерного распределения. Так, например, если брать по 3 бита (минимально необходимое число), а нужно сгенерировать число в [0, 5), то очевидно результат будет вдвое чаще попадать в [0, 3), чем в [3, 5). Так что этот способ настолько тупой, что даже неправильный =).
Следующий — брать по 3 бита, пока не попадёт в нужный диапазон. Очень честный способ. Обеспечивает равномерность. Но выкидывает достаточно дорогие [псевдо]случайные биты. В принципе вероятность с первого раза попасть, куда надо, может быть около ½. Поэтому способ тоже тупой. Так, кстати, делает Питон (вот почему тут такой тег), можете посмотреть: http://hg.python.org/cpython/file/3.3/Lib/random.py функция _randbelow
Ок, хорошо, а кто скажет, как это делать нормально, чтобы распределение было равномерным, но чтобы при этом не выкидывать случайные биты?
