Когда мне понадобится этот контроль, когда я буду готов тратить на него время или платить — я поставлю свои сервисы. Пока мне этот контроль не нужен — я вполне спокойно пользуюсь SaaS.
По аналогии с ПО — пока мне не нужен контроль над работой приложения, меня устраивает закрытое ПО. Когда я разрабатываю ПО сам, я пользуюсь только OpenSource, ибо, кроме лицензионных вопросов, у меня полный контроль над работой библиотек.
Во-первых, от Столлмана действительно такого «не ждали». Хотя это вполне вписывается в концепцию, которую кратко можно обозвать как «be free»…
Вот только, с моей точки зрения, абсолютной свободы нет. Есть только во-первых, свобода относительная, во-вторых, свобода как выбор. Так вот облака — это выбор, возможность выбора между привязанностью к своему компьютеру и привязанностью к своему сервису. Я не представляю, чтобы я делал после потери данных с жёсткого диска, если бы моя почта хранилась на нём. Я не знаю что посоветовать человеку, который вместо хранения кода проекта в ClearCase / SVN / SourceForge хранит его локально (пусть даже и с версионностью).
Облака нам дают такой выбор. Он может не нравится, потому что привязывает нас к определённым компаниям. Он может не нравится, потому что даёт «плохим дядям» доступ к нашим данным. Но он имеет право нравится за то, что мы об этом сервисе больше не беспокоимся. За то, что это работает лучше, чем если бы мы это делали самостоятельно. И, часто — дешевле.
Ещё один вопрос, это то, как эти сервисы привязывают нас к себе. В случае GMail ничто не мешает скопировать почту к себе на компьютер. У меня на телефоне доступны 25 последних сообщений, на ноуте — переписка за 3 месяца. Если очень захочется — я могу скачать всю почту по IMAP к себе и использовать GMail лишь как почтовый ящик (но делать этого не буду).
Готов ли я доверять Гуглу? А почему нет? Чего я боюсь в жизни? Тайное рано или поздно станет явным. Стоимость такой утечки дороже для провайдера данных (в плане репутации), чем для меня. И пока так будет — я готов доверять.
Мне кажется, очень мало раскрыто по использованию данного шаблона. А ведь это один из самых популярных в EJB-технологии. По сути все EJB сделаны в той или иной мере на основе данного подхода.
1) Proxy также (и, наверно, в основном) используются для оборачивания основного объекта некоторой оболочкой, контролирующей его работу. Например, оборачиванием каждого вызова в проверку и открытие транзакции, включение профайлинга и т.д., проверку наличия security credentials и прав доступа на объект. При этом метод исходного объекта, обычно, вызывается «без купюр» — то есть не происходит модификации аргументов вызова или результатов (кроме уже их оборачивания в прокси).
Кстати, использование proxy == null / getProxy() является примером т.н. LazyProxy, являющимся ещё одним шаблоном проектирования. Самый известный (с моей точки зрения) пример использования — Lazy-инициализация бинов в Hibernate.
2) Создание Proxy в простейшем случае делается с помощью классов Proxy / InvokationHandler, которые позволяют создать прокси для любого набора интерфейсов. Однако часто приходится оборачивать не интерфейсы (EJB 2.x — это были бы Remote/Local интерфейсы), а классы (EJB 3.x). В этом случае используются фреймворки вроде CGLIB / ASM / Javaassist для реализации шаблона Proxy через наследование, т.е. через создание дочернего класса и оборачивания всех super-вызовов нужным кодом.
Это всё, конечно, в случае необходимости оборачивания Proxy в runtime, когда класс на момент компиляции не знает, что придётся оборачивать. И хотя при этом страдает производительность, данный подход имеет плюсы и в случае статической компиляции — если мы добавим новый метод в исходный объект, в «динамических» прокси нам менять ничего не нужно, а вот «статические» придётся дописывать.
3) Proxy бывают и нелокальные, например, предназначенные для вызова методов объекта в удалённой JVM. Обычно реализуются через Proxy / InvokationHandler, так как у объекта есть RemoteInterface.
Удалённое администрирование машин в офисе. На IT happens была история, что администратору пришлось даже вносить похожую программу в список исключений антивируса.
«после определенного количества шагов делает невозможным декриптование»
Если всё делать руками, то дешифрование возможно. Нужно только помнить, что исходный кодовой вектор нужно искать на каждой итерации. Разумеется, если вы попытаетесь одним шагом исправить ошибку, вызванную двумя и более операциями — скорее всего ничего не выйдет.
«О каких «итерациях» в современных функциях шифрования вы говорите?»
Я имел ввиду повторное применение операции шифрования к тексту. (Я надеюсь, вы не имеете ввиду итерации в смысле DES/AES, которые тоже однозначны)
«Главная проблема с предыдущими схемами была в том, что каждая операция добавляет некоторый «шум» в криптотекст»
Что за чушь?! Все операции в RSA выполняются над числами, меньшими N, поэтому операция mod ничего не меняет (кроме того, что позволяет числам остаться внутри заданной области).
Что это ещё за «шум», который мешает нам расшифровывать? Любая современная функция шифрования — однозначна и обратима на 100%, а значит никакого шума ни в одной современной функции шифрования нет. Если бы подобный шум был бы — однозначное шифрование было бы невозможно даже бы на первой итерации.
Мне понятно, в каких случаях может произойти плохое поведение. Мне интересны цифры показывающие прирост из-за использования LOH хоть в каких-нибудь сценариях.
В Java сценарий такой:
— объект создаётся в gen eden
— после первой сборки мусора он перемещается в gen surv
— после заполнения предыдущего поколения в нём проходит GC и выжившие объекты переносятся в permanent generation
При этом нет ограничений на перемещение объектов внутри PG. Однако это происходит редко, так как после заполненности кешей фиг туда что попадёт относительно крупное.
От OOM ничего не спасёт, как на Java, так и в .NET. Отличие в том, что Java сама себя ограничивает объёмом памяти «сверху», но это ограничение можно и снять (установить его заведомо большим с вылезанием в «своп»). Тогда Java будет запрашивать память у системы до тех пор, пока не достигнет системного предела (или установленного из командной строки).
На моём опыте приложения могут улезать в своп только по одной причине — когда они не активны. Если они работают, то свопа быть не должно — выигрыша в производительности это не даёт, а управление хранением данных и синхронизацией лучше отдать какой-нибудь embedded СУБД, той же Derby.
А раз свопа быть не должно, устанавливаем максимальный допустимый размер всей кучи (всех поколений) в 80% от оперативки и радуемся.
Хотелось бы увидеть хабратопик про то, почему я как программист на Java, глубоко несчастен из-за отсутствия LOH.
Почему бы не помещать всё в Small Object Heap? Или, как он называется, generational gc? Есть где-нибудь сравнение производительности с включенным и отключенным LOH? (в статье на msdn ничего нет, кроме каких-то странных рассуждений про сборку мусора «из расчёта 2 тика на байт»)
По аналогии с ПО — пока мне не нужен контроль над работой приложения, меня устраивает закрытое ПО. Когда я разрабатываю ПО сам, я пользуюсь только OpenSource, ибо, кроме лицензионных вопросов, у меня полный контроль над работой библиотек.
Вот только, с моей точки зрения, абсолютной свободы нет. Есть только во-первых, свобода относительная, во-вторых, свобода как выбор. Так вот облака — это выбор, возможность выбора между привязанностью к своему компьютеру и привязанностью к своему сервису. Я не представляю, чтобы я делал после потери данных с жёсткого диска, если бы моя почта хранилась на нём. Я не знаю что посоветовать человеку, который вместо хранения кода проекта в ClearCase / SVN / SourceForge хранит его локально (пусть даже и с версионностью).
Облака нам дают такой выбор. Он может не нравится, потому что привязывает нас к определённым компаниям. Он может не нравится, потому что даёт «плохим дядям» доступ к нашим данным. Но он имеет право нравится за то, что мы об этом сервисе больше не беспокоимся. За то, что это работает лучше, чем если бы мы это делали самостоятельно. И, часто — дешевле.
Ещё один вопрос, это то, как эти сервисы привязывают нас к себе. В случае GMail ничто не мешает скопировать почту к себе на компьютер. У меня на телефоне доступны 25 последних сообщений, на ноуте — переписка за 3 месяца. Если очень захочется — я могу скачать всю почту по IMAP к себе и использовать GMail лишь как почтовый ящик (но делать этого не буду).
Готов ли я доверять Гуглу? А почему нет? Чего я боюсь в жизни? Тайное рано или поздно станет явным. Стоимость такой утечки дороже для провайдера данных (в плане репутации), чем для меня. И пока так будет — я готов доверять.
@Magic
@Hack
@WTF
@ThisHadBetterNotBe
public void filter(@ThisHadBetterNotBe("ArrayList will kill perfomance here") Collection<?> objects);1) Proxy также (и, наверно, в основном) используются для оборачивания основного объекта некоторой оболочкой, контролирующей его работу. Например, оборачиванием каждого вызова в проверку и открытие транзакции, включение профайлинга и т.д., проверку наличия security credentials и прав доступа на объект. При этом метод исходного объекта, обычно, вызывается «без купюр» — то есть не происходит модификации аргументов вызова или результатов (кроме уже их оборачивания в прокси).
Кстати, использование proxy == null / getProxy() является примером т.н. LazyProxy, являющимся ещё одним шаблоном проектирования. Самый известный (с моей точки зрения) пример использования — Lazy-инициализация бинов в Hibernate.
2) Создание Proxy в простейшем случае делается с помощью классов Proxy / InvokationHandler, которые позволяют создать прокси для любого набора интерфейсов. Однако часто приходится оборачивать не интерфейсы (EJB 2.x — это были бы Remote/Local интерфейсы), а классы (EJB 3.x). В этом случае используются фреймворки вроде CGLIB / ASM / Javaassist для реализации шаблона Proxy через наследование, т.е. через создание дочернего класса и оборачивания всех super-вызовов нужным кодом.
Это всё, конечно, в случае необходимости оборачивания Proxy в runtime, когда класс на момент компиляции не знает, что придётся оборачивать. И хотя при этом страдает производительность, данный подход имеет плюсы и в случае статической компиляции — если мы добавим новый метод в исходный объект, в «динамических» прокси нам менять ничего не нужно, а вот «статические» придётся дописывать.
3) Proxy бывают и нелокальные, например, предназначенные для вызова методов объекта в удалённой JVM. Обычно реализуются через Proxy / InvokationHandler, так как у объекта есть RemoteInterface.
Да и про сам поиск, думаю, тоже читатели найдутся. В США раньше время отслеживали розовый цвет пересылаемых фотографий в электронной почте.
Удалённое администрирование машин в офисе. На IT happens была история, что администратору пришлось даже вносить похожую программу в список исключений антивируса.
ru.wikipedia.org/wiki/Золотой_щит
Если всё делать руками, то дешифрование возможно. Нужно только помнить, что исходный кодовой вектор нужно искать на каждой итерации. Разумеется, если вы попытаетесь одним шагом исправить ошибку, вызванную двумя и более операциями — скорее всего ничего не выйдет.
«О каких «итерациях» в современных функциях шифрования вы говорите?»
Я имел ввиду повторное применение операции шифрования к тексту. (Я надеюсь, вы не имеете ввиду итерации в смысле DES/AES, которые тоже однозначны)
Что за чушь?! Все операции в RSA выполняются над числами, меньшими N, поэтому операция mod ничего не меняет (кроме того, что позволяет числам остаться внутри заданной области).
Что это ещё за «шум», который мешает нам расшифровывать? Любая современная функция шифрования — однозначна и обратима на 100%, а значит никакого шума ни в одной современной функции шифрования нет. Если бы подобный шум был бы — однозначное шифрование было бы невозможно даже бы на первой итерации.
Пришёл, вставил флешку-батарейку, обновил содержимое, пошёл дальше. Висит, кушать не просит.
про то, что в комплекте нет девушки-машинистки, тоже не указано.
Большие объекты в Java помещаются в tenured space не сразу, а на второй проход GC по ним, кажется.
В Java сценарий такой:
— объект создаётся в gen eden
— после первой сборки мусора он перемещается в gen surv
— после заполнения предыдущего поколения в нём проходит GC и выжившие объекты переносятся в permanent generation
При этом нет ограничений на перемещение объектов внутри PG. Однако это происходит редко, так как после заполненности кешей фиг туда что попадёт относительно крупное.
От OOM ничего не спасёт, как на Java, так и в .NET. Отличие в том, что Java сама себя ограничивает объёмом памяти «сверху», но это ограничение можно и снять (установить его заведомо большим с вылезанием в «своп»). Тогда Java будет запрашивать память у системы до тех пор, пока не достигнет системного предела (или установленного из командной строки).
На моём опыте приложения могут улезать в своп только по одной причине — когда они не активны. Если они работают, то свопа быть не должно — выигрыша в производительности это не даёт, а управление хранением данных и синхронизацией лучше отдать какой-нибудь embedded СУБД, той же Derby.
А раз свопа быть не должно, устанавливаем максимальный допустимый размер всей кучи (всех поколений) в 80% от оперативки и радуемся.
В Java нет, а в .NET есть. Стало интересно, feature это или bug? Пытаюсь перевести в Java-термины, и пока не понимаю, какая вообще выгода от LOH?
Если память не экономит, а наоборот, препятствует сбору, то должна быть выгода в производительности. Но какая? Хотя бы в попугаях.
Почему бы не помещать всё в Small Object Heap? Или, как он называется, generational gc? Есть где-нибудь сравнение производительности с включенным и отключенным LOH? (в статье на msdn ничего нет, кроме каких-то странных рассуждений про сборку мусора «из расчёта 2 тика на байт»)