Ну, практика показывает, что спрятать свои зловещие козни можно даже в открытом коде.
Даже соревнования ежегодные в этой дисциплине проводятся: underhanded.xcott.com/
Собственно, сам объект может создаться только из конструктора.
Единственное место, где может быть конструктор — где-то в недрах queue.getTaskBlocking().
Или этот вызов возвращает полную копию внутреннего объекта Task?
не создаёт экземпляра, а просто объявляет переменную под указатель на этот экземпляр.
Тут компилятор всё делает правильно — выделение памяти под указатель внутри цикла множество раз менее эффективно, чем выделение памяти под указатель один раз, до цикла. Кроме того, такая оптимизация упрощает жизнь для GC — он будет срабатывать на объект-без-ссылок, а не на объект-который-больше-не-понадобится
Угу.
Видимо, именно из-за этого «всё в порядке» по сию пору многие в чуланах хранят крупу и туалетную бумагу.
И выращивают картошку на приусадебных участках потому же — от обилия картошки в магазинах. Ну нормально — девать её было некуда, вот и приходилось закапывать в землю.
Как, в можете проткнуть страницу — и попасть точнёхонько в наперёд заданную ячейку, после чего модифицировать её — не перелистывая страницу.
Кроме того, при больших нагрузках в процессе письма возможно проникновения отпечатка на следующую страницу — и этот отпечаток будет неотличим в плане позиционирования в ячейках от родного.
И в конце концов — произвольное устройство адресации каждой страницы памяти — это суперпрогрессивная технология, позволяющая предотвратить функционирование любых вирусов отныне и впредь.
Гомосексуализм ведёт к снижению популяции вида только в рамках длительных супермоногамных отношений.
Если для кого-то не проблема оплодотворить 10 самок, значит кто-то может остаться не у дел.
Поясняю — через Вас как узел I2P проходят потоки байт. От узлов {A, B, C} к узлам {X, Y, Z}. Траффик зашифрован, что в каком из потоков — узнать нет никакой возможности. Более того, если даже на узле Z стоит сервер, вещающий запрещённую порнуху — Вы этого никогда не узнаете.
То есть один релей M видит все проходящие соединения как идущие от одного релея (A) на одном конце к релею (Z) на другом конце. Если Z ещё сервер, а в пакете от A содержится запрос к нему — это будет приятная неожиданность для него, когда он получит покет, развернёт свой слой шифрования, и увидит там готовый запрос. От хрен-знает-кого, известного только под внутрисетевым определителем.
Суммируя:
Узлы внутри сети известны под идентификаторами, отличными от ip. Получить соответствие ip<->адрес I2P технически невозможно (плюс-минус ошибки в реализации протоколов).
Где сервер, а где просто туннель, разобраться так же невозможно — весь траффик затуннелирован из конца в конец.
Концы соединения изолированны — то есть пакет идёт по цепочке, каждое звено которой знает только про соседей.
Кстати, всем интересующимся ITT рекомендую книгу «Митио Каку. Физика невозможного»
Университетский профессор разбирает подробно распространённые штампы из научной фантастики, и сортирует их на «возможно/нескоро/невозможно». Очень гладко написано, при этом довольно глубоко тема вскрыта. И выводы любопытные часто делаются.
Читайте, не пожалеете.
Каждый отдельный клиент ответственен за проходящий через него фрагмент контента ровно настолько же, насколько ответственен один из пользователей Skype за фрагмент разговора двух террористов, маршрутизирующийся через его скайпоклиент.
Проходящий контент, кстати, и там и там зашифрован, так что никакой возможности отделить «хороший» траффик от «плохого» не существует.
Пассаж про ip и шлюзы не понял — возможно, Вы недопонимаете принцип работы сети I2P?
Но ASP не особо успешен даже не из-за паранойи, ИМО.
Даже соревнования ежегодные в этой дисциплине проводятся: underhanded.xcott.com/
Единственное место, где может быть конструктор — где-то в недрах
queue.getTaskBlocking().Или этот вызов возвращает полную копию внутреннего объекта
Task?Task task;
не создаёт экземпляра, а просто объявляет переменную под указатель на этот экземпляр.
Тут компилятор всё делает правильно — выделение памяти под указатель внутри цикла множество раз менее эффективно, чем выделение памяти под указатель один раз, до цикла. Кроме того, такая оптимизация упрощает жизнь для GC — он будет срабатывать на объект-без-ссылок, а не на объект-который-больше-не-понадобится
Дефицит в словаре вовсе не как «нехватка, недостача» определяется.
Видимо, именно из-за этого «всё в порядке» по сию пору многие в чуланах хранят крупу и туалетную бумагу.
И выращивают картошку на приусадебных участках потому же — от обилия картошки в магазинах. Ну нормально — девать её было некуда, вот и приходилось закапывать в землю.
А 1975 — это просто «неурожай зерновых».
Кроме того, при больших нагрузках в процессе письма возможно проникновения отпечатка на следующую страницу — и этот отпечаток будет неотличим в плане позиционирования в ячейках от родного.
И в конце концов — произвольное устройство адресации каждой страницы памяти — это суперпрогрессивная технология, позволяющая предотвратить функционирование любых вирусов отныне и впредь.
В предсказуемости узора на неисписанных пока страницах кроется серьёзная уязвимость, если вдуматься на минутку.
Если для кого-то не проблема оплодотворить 10 самок, значит кто-то может остаться не у дел.
(Мозаика Пенроуза, если кто не в теме.)
То есть один релей M видит все проходящие соединения как идущие от одного релея (A) на одном конце к релею (Z) на другом конце. Если Z ещё сервер, а в пакете от A содержится запрос к нему — это будет приятная неожиданность для него, когда он получит покет, развернёт свой слой шифрования, и увидит там готовый запрос. От хрен-знает-кого, известного только под внутрисетевым определителем.
Суммируя:
Узлы внутри сети известны под идентификаторами, отличными от ip. Получить соответствие ip<->адрес I2P технически невозможно (плюс-минус ошибки в реализации протоколов).
Где сервер, а где просто туннель, разобраться так же невозможно — весь траффик затуннелирован из конца в конец.
Концы соединения изолированны — то есть пакет идёт по цепочке, каждое звено которой знает только про соседей.
Университетский профессор разбирает подробно распространённые штампы из научной фантастики, и сортирует их на «возможно/нескоро/невозможно». Очень гладко написано, при этом довольно глубоко тема вскрыта. И выводы любопытные часто делаются.
Читайте, не пожалеете.
Проходящий контент, кстати, и там и там зашифрован, так что никакой возможности отделить «хороший» траффик от «плохого» не существует.
Пассаж про ip и шлюзы не понял — возможно, Вы недопонимаете принцип работы сети I2P?