Пункт 2 специфичен только для второго питона, в третьем отказались от классического стиля наследования классов. Т.е. в третьем питоне можно не наследоваться явно от object
Если быть точным, то интерпретатор CPython предсоздаёт объекты для чисел от -5 до 256 включительно. Вот небольшой кусок Objects/longobject.c исходников Python 3.2.5:
#define NSMALLPOSINTS 257
...
#define NSMALLNEGINTS 5
...
/* Small integers are preallocated in this array so that they
can be shared.
The integers that are preallocated are those in the range
-NSMALLNEGINTS (inclusive) to NSMALLPOSINTS (not inclusive).
*/
static PyLongObject small_ints[NSMALLNEGINTS + NSMALLPOSINTS];
Это лишь всего одна небольшая оптимизация конкретной реализации языка Python. Например, PyPy поступает по-другому.
Кстати, раз объекты предсоздаются, мы можем использовать модуль ctypes чтобы поменять значения в них.
Не так давно перечитал спецификацию Питона и по некоторым местам, которые показались мне неочевидными или интересными сделал тест. После каждого ответа выводится верный ответ и ссылка на нужный пункт спецификации.
Если значение маленькое, то проблем быть не должно.
Эти три числа задают, соответственно, минимальный, дефолтный, и максимальный размер буфера, в котором накапливаются данные для одного TCP-соединения, которые нужно отправить или принять. Поэтому ядро не сможет послать за раз больше, чем максимальный размер буфера(чем последнее число).
Если у вас Линукс, то этого можно добиться, подкрутив настройки протокола TCP командами:
sysctl net.ipv4.tcp_rmem="<желаемое количество байт в пакете> <желаемое количество байт в пакете> <желаемое количество байт в пакете>
и
sysctl net.ipv4.tcp_wmem="<желаемое количество байт в пакете> <желаемое количество байт в пакете> <желаемое количество байт в пакете>"
Да, одно и тоже число следует повторить три раза. Первая команда влияет на входящие данные, а вторая — на исходящие. Осторожно: если поставить мало, то TCP будет работать очень медленно, как будто на том конце кто-то неспешно набирают ответ вручную.
Так как в архивах на сайте очень много файлов, подскажу где искать: dl/webadmin-_seraph.tar.gz, dl/resident-_seraph.tar.gz и dl/libshared-_seraph.tar.gz. Это реализация веб-интерфейса роутера и его взаимодействия с основной системой. Люблю их периодически перечитывать в качестве примера того, как не надо писать код.
Понравившиеся комментарии:
Осторожно, мат
json_t *bred =json_object(); //Ключ здесь вообще не нужен, но меня не слушают
json_object_set(test_json,"ports_end",json_object_get(test_json,"ports_begin")); //нет, это не состязание в извращенности, просто не хочется плодить кучу объектов
outbuf=malloc(st.st_size); //это конечно допущение, но думаю в конфиг бинари мы не будем пихать (UPD 3.02.2012 Я сильно заблуждался (T_T))
#ifdef BCM47XX // это очень, блеать, костыльно!!! но, к сожалению, и на завод уйдет так же =(
char* DSCPCheck; // большая хрень...поясню при необходимости см. qoscls.html
char* DSCPMark; // ещё одна большая хрень...поясню при необходимости см. qoscls.html
//TODO там в коде поставь, я потом и сам там подрулю в случае чего
// на девайсе почему-то не матчит. сука! if(!fnmatch("*( |\t)ppp[0-9]:*", buf, FNM_EXTMATCH)){
res->name, res->desc);*/ /* ВНЕЗАПНО! Найдено! */
const char *bablo; // Деньги
// сделаем немного через ..опу, чтоб не вводить дополнительные поля
Если нет USB-UART, но есть Arduino, то можно воспользоваться им. На ардуину накатываем пустую прошивку, соединяем TX, RX и GND ардуины с ножками платы, и запускаем штатный serial monitor одноимённой программы Arduino.
Нужно помнить, что D-Link DIR-620 выпускается в двух модификациях совсем непохожих друг на друга по аппаратной и программной начинке. Например в моём DIR-620 это выглядит так:
фото
Исходники прошивки и утилиты для её сборки есть в открытом доступе на сайте dlink. Часть исходников явно написана русскими программистами(в комментариях встречается русский мат)
Более того, дверки могут быть и в toolchain'e, используемом при сборке, и в разделяемых библиотеках, и даже в железе. Если выкрутить уровень паранойи почти на максимум, то возможно видеонаблюдение в помещении, использование высокочувствительных микрофонов для изучение звука нажатых клавиш, сбор электромагнитных волн, испускаемых оборудованием, использование паяльника не по назначению и.т.д.
В самостоятельной реализации tls есть проблема: протокол настолько обширен, что реализовать его самому и не допустить ошибок — практически невыполнимая задача. Особенно, если вспомнить про существование атак, основанных на задержках по времени. Если спуститься на уровень ниже и реализовывать toolchain, библиотеки, ОС и железо, то может не хватить и всей жизни.
Немного углубимся: протокол ssh позволяет иметь внутри одного TCP-соединения несколько логических. Тогда схема будет выглядеть так:
А) На Сервере SSH-клиент говорит SSH-серверу: «если к тебе придёт подключение, то отправь его в этот логический канал, а я его расшифрую и передам данные на свой порт 4445».
… дальше по аналогии…
Кстати, у стандартного линуксового ssh клиента есть замечательные горячие клавиши. Если вы нажмёте после подключения <enter>~#, то вам покажут список логических каналов, а если вы нажмёте <enter>~C, то вам покажут командную строку, в которой вы сможете создавать каналы динамически(введите help для информации о синтаксисе). А если вы нажмёте <enter>~?, то вам покажут что ещё можно нажать; самое полезное, это, конечно, <enter>~., завершающее текущее ssh-соединение.
В моём случае вероятность этого не очень высока, т.к. я использую zsh, не использую утилиту sudo и не использую пароль для аутентификации. А вообще да, такой сценарий возможен. Но повторюсь: я доверяю своему собеседнику.
Да, можно было бы сделать фильтрацию спецсимволов, красивые окошки, удобный, интуитивно-понятный пользовательский интерфейс, придумать ники и ставить timestamp'ы перед каждой фразой. Но это бы потребовало написания кода, что привело бы к проблемам «а вдруг у вас там баги и уязвимости?» или даже «а вдруг вас заставили внести туда баги и уязвимости?». Тем более, таких продуктов и сервисов уже существует довольно много. В них периодически находят уязвимости, и с ними происходит, например, внезапное закрытие. Я писал об этом в статье. Основная идея статьи — не писать код. Я специально не использовал даже перенаправление ввода вывода и пайпы.
Решение не позиционируется как универсальное решение, которое подойдёт всем. Если данные таковы, что их секретная передача таким способом — параноидальная несущественная проблема, то лучше использовать способы попроще(например GnuPG). Решение для тех, для кого передача данных является параноидальной существенной проблемой.
Потому что IM — это обычно тысячи строк кода. В них дополнительно могут быть уязвимости и ошибки. В посте я приводил в пример Cryptocat, который использует OTR.
Имеет смысл регулярно обновлять ПО и запускать эмулятор терминала из под отдельного пользователя, а лучше даже из-под отдельной виртуальной машины.
Тут ещё есть другая, социальная опасность. Если один собеседник пытается хакнуть другого, то с таким же успехом он может посадить около себя, например, полицейского, нарушив тем самым конфиденциальность данных.
Спасибо за ссылку. Нашёл описание метода, но не нашёл конкретных инструкций, как им воспользоваться.
По поводу велосипедостроения не согласен. Скорее наоборот — мы пользуется стандартными протоколами и открытыми, хорошо себя зарекомендовавшими программами и библиотеками.
Это лишь всего одна небольшая оптимизация конкретной реализации языка Python. Например, PyPy поступает по-другому.
Кстати, раз объекты предсоздаются, мы можем использовать модуль ctypes чтобы поменять значения в них.
Для третьего питона:
Для второго:
Эти три числа задают, соответственно, минимальный, дефолтный, и максимальный размер буфера, в котором накапливаются данные для одного TCP-соединения, которые нужно отправить или принять. Поэтому ядро не сможет послать за раз больше, чем максимальный размер буфера(чем последнее число).
и
Да, одно и тоже число следует повторить три раза. Первая команда влияет на входящие данные, а вторая — на исходящие.
Осторожно: если поставить мало, то TCP будет работать очень медленно, как будто на том конце кто-то неспешно набирают ответ вручную.
и последующим запуском:
?
Понравившиеся комментарии:
Нужно помнить, что D-Link DIR-620 выпускается в двух модификациях совсем непохожих друг на друга по аппаратной и программной начинке. Например в моём DIR-620 это выглядит так:
Исходники прошивки и утилиты для её сборки есть в открытом доступе на сайте dlink. Часть исходников явно написана русскими программистами(в комментариях встречается русский мат)
В самостоятельной реализации tls есть проблема: протокол настолько обширен, что реализовать его самому и не допустить ошибок — практически невыполнимая задача. Особенно, если вспомнить про существование атак, основанных на задержках по времени. Если спуститься на уровень ниже и реализовывать toolchain, библиотеки, ОС и железо, то может не хватить и всей жизни.
А) На Сервере SSH-клиент говорит SSH-серверу: «если к тебе придёт подключение, то отправь его в этот логический канал, а я его расшифрую и передам данные на свой порт 4445».
… дальше по аналогии…
Кстати, у стандартного линуксового ssh клиента есть замечательные горячие клавиши. Если вы нажмёте после подключения <enter>~#, то вам покажут список логических каналов, а если вы нажмёте <enter>~C, то вам покажут командную строку, в которой вы сможете создавать каналы динамически(введите help для информации о синтаксисе). А если вы нажмёте <enter>~?, то вам покажут что ещё можно нажать; самое полезное, это, конечно, <enter>~., завершающее текущее ssh-соединение.
Да, можно было бы сделать фильтрацию спецсимволов, красивые окошки, удобный, интуитивно-понятный пользовательский интерфейс, придумать ники и ставить timestamp'ы перед каждой фразой. Но это бы потребовало написания кода, что привело бы к проблемам «а вдруг у вас там баги и уязвимости?» или даже «а вдруг вас заставили внести туда баги и уязвимости?». Тем более, таких продуктов и сервисов уже существует довольно много. В них периодически находят уязвимости, и с ними происходит, например, внезапное закрытие. Я писал об этом в статье. Основная идея статьи — не писать код. Я специально не использовал даже перенаправление ввода вывода и пайпы.
Решение не позиционируется как универсальное решение, которое подойдёт всем. Если данные таковы, что их секретная передача таким способом — параноидальная несущественная проблема, то лучше использовать способы попроще(например GnuPG). Решение для тех, для кого передача данных является параноидальной существенной проблемой.
Имеет смысл регулярно обновлять ПО и запускать эмулятор терминала из под отдельного пользователя, а лучше даже из-под отдельной виртуальной машины.
Тут ещё есть другая, социальная опасность. Если один собеседник пытается хакнуть другого, то с таким же успехом он может посадить около себя, например, полицейского, нарушив тем самым конфиденциальность данных.
По поводу велосипедостроения не согласен. Скорее наоборот — мы пользуется стандартными протоколами и открытыми, хорошо себя зарекомендовавшими программами и библиотеками.