Но почему? Если человек на естественном (очень гибком и прощающем) языке пишет с ошибками, то мы его ругаем, зовем неграмотным. Если же программист пишет на очень строгом языке с ошибками, о многих из которых его предупреждают любые современные редактор и компилятор, — мы ругаем язык?.. И ведь ему за это часто платят, в отличие от двоечника Пети
А в чем проблема-то? Мы же не говорим, что русский плохой, потому что в нем можно построить грамматически корректные фразы, которые при этом не несут смысла, "не работают". И уж тем более не бежим создавать новый просто из-за того, что люди страдают с выражением своих мыслей на существующем
После си переходить на раст больно. Язык содержит в себе гору клевых идей, но синтаксис явно разрабатывался в первую очередь для чтения компилятором, а уже потом человеком. И вечное желание сделать его максимально не С-подобным не помогает(
Да ладно, по крайней мере тут нет ни политической, ни корпоративной составляющих. Написанный плохо, но живым человеком пост — куда уж ближе к оригинальному хабахабру?)
Я тоже, когда мне нечего делать, пишу компаниям во вконтаклях. А когда не отвечают, начинаю угрожать девочкам из техподдержки высшими инстанциями. Про меня даже пишут в газеты
Не могу сказать, что прямо гуру, но если уж автор интересуется мнением, то, надеюсь, не обидится на пару простых замечаний и предложений в образовательных целях)
По поводу алгоритма
Если отбросить все детали реализации (а там есть над чем работать) и оставить только сам алгоритм, то при распараллеливании стоит задуматься в первую очередь над КПД потоков:
Во-первых, в исходном алгоритме рабочий за раз обрабатывает самостоятельно лишь одну ветвь под-дерева, все остальные отправляя в блокирующую структуру. Каждый вызов add и take блокирует все остальные аналогичные вызовы, тем самым образуется "бутылочное горлышко"
Во-вторых, первый поток почему-то отличается от остальных и прекращает свою жизнь на первом же встретившимся листе, что не имеет практического смысла
Общий алгоритм на основе блокирующей очереди можно скорректировать, например, так. Пусть мы хотим обойти дерево с помощью N потоков, изначально работает лишь один, а другие не были созданы заранее. Он:
Создает счетчик T = N-1;
Если у рассматриваемого узла есть M потомков (он папка):
Если M < N, то шаг пропускается. Иначе, делит потомков на N частей, для N-1 из них:
Если T > 0, то присваивает T = T-1 и создает новый поток (который будет работать по тому же алгоритму с шага 2), передает ему для обработки рассматриваемую часть;
Если T == 0, то добавляет всю часть одной задачей в очередь;
Если K >= N, то берет оставшующуюся N-ую часть из разделения на шаге 3;
Иначе берет задачу из очереди;
Иначе (если файл) — обрабатывает его и возвращается на предыдущий уровень рекурсии;
Рекурсивно повторяет алгоритм для каждого файла из новой задачи с шага 2.
Такой алгоритм уменьшает нагрузку на очередь и не тратит процессорное время до того момента, как у программы появились данные для обработки. Сами операции с очередью теперь работают с множеством данных, тем самым уменьшая необходимое количество обращений к ней. При этом часть работы производится в неблокирующей форме, не оказываясь в очереди вообще (и таких будет значительное число, сильно сказывающееся на производительности)
Стоит лишь заметить, что операции с T должны быть синхронизированы между потоками. В отличие от синхронизации на очереди, это ограничение легко обойти, храня локальную копию значения, и выполняя синхронизацию на шаге 2.1 только когда она > 0
По поводу реализации
Помимо сказанного другими выше, в коде не отслеживается конец задачи. Решение тривиально: нужно лишь проверять перед взятием новой задачи, сколько потоков в настоящий момент уже ждут у нее. Если значение равно N-1, значит, работы больше не светит, программу можно сворачивать
В такой простой задаче не нужно использовать пулы потоков, если не предполагается его передача функции "извне". Мы либо контролируем полностью процесс распараллеливания, либо полагаемся на внешние интерфейсы для многопоточности, смешивать два подхода не имеет смысла
Не стоит просто игнорировать исключения в потоках — если добавил try, то сделай обработку в catch, иначе просто пробрось его наверх. И проверяй неявные исключения — listFiles() иногда возвращает null, в следующей строчке может получиться NullPointerException
И напоследок — очень советую использовать встроенные в джаву функции работы с потоками, не ограничивая себя одним интерфейсом блокирующей очереди
Потому что из текущего описания мне понятно в какой момент дергать рубильник
И в какой же? Ну вот дернул я рубильник по предложению, когда Алиса ответила своему заказчику на картинку с зонтом (потому что "как в примере"), своровал какое-то сообщение. На следующий день оказалось, что это просто левый человек зонт заказал, а Алиса не агент (и таких миллионы). Или еще хуже — она агент и сбежала от такой явной атаки за границу. И кого я кому я навредил в итоге?
Не просто так привел пример со скрытым каналом ведь: никто не будет "дергать рубильник" на каждую электронную подпись просто потому, что в ней может что-то быть, верно?
Если посылки запихнуть в стегу, то будет не видно по вашей логике.
В третий (с учетом одного в самом посте) раз говорю — так делать нельзя. Для этого придется хранить метод стеганографии в тайне, что, как мы уже выяснили. Тут нет нигде моей логики, протокол разрабатывался как раз для избавления от таких требований
я вижу базу вашего алгоритма именно в этом
Каждый художник видит как хочет, конечно, но в моем описании нет требования хранить в секрете что-либо, кроме частей Алисы и Боба, поэтому претензии не ко мне. Сам протокол открыт, части закрыты, все равно определить, происходит диалог или аутентификация, нельзя
Алгоритм открыт, неизвестны лишь части Алисы и Боба. Не знаю, что в моей фразе могло навести на эту мысль. Невозможность определения проведения протокола не означает, что он секретен, лишь что был правильно выполнен. Скрытый канал Эль Гамаля тоже нельзя просто так отличить от обычной подписи, например, но мы его не записываем в категорию "не криптографии"
Я понимаю, что можно взять миллион вариантов для M, но не вижу смысла тратить место, если PKI решает все это проще
Использование PKI легко определить даже на глаз, она решает задачу явной аутентификации, а не скрытой
просто в первом же сообщении отправляйте секретные данные
Для этого как раз потребуется держать общий ключ и, что важнее, алгоритм в секрете. Я думал, тут речь о криптографии)
Вот никак не вижу усиления от того, что стеганка используется как часть секрета
Усиление заключается в двух факторах. Первый — Алиса контролирует выбор формы передачи секрета. В какой-нибудь схеме Шамира у нее не оставалось бы контроля над тем, что присылает Боб — это всегда была бы просто его число, хоть головой об стену бейся
Второй — если Боб стал злоумышленником (противник соблазнил женщинами и деньгами), то он может атаковать часть Алисы после проведения аутентификации, имея на руках как свою часть в явном виде, так и восстановленный секрет. Именно поэтому я сделал акцент на невозможности восстановления по Em как Ex, так и самого секрета M, который содержится в отображении части Боба и не несет никакой информации о части Алисы
кто угодно, знающий ответную реплику, может выдавать себя за А
Это, конечно же, неверно. Я даже расписал, почему. Во-первых, любая последовательность Em и соответствующий отпечатоп h(M) Боба одноразовые, поэтому знание M противнику ничего не даст — набор данных уже был использован. Во-вторых, никто не мешает ему провести потом повторные раунды аутентификации, так как единственной Ex Алисы сопоставлено бесконечное множество его частей. В-третьих, само построение протокола скрывает шаги аутентификации, поэтому у третьей стороны в общем случае нет способа понять, для кого и когда дергать рубильник. А даже если каким-то образом и поняли — в общем случае нет возможности определить, какая часть диалога содержит передаваемый Бобом контейнер (от текста до ссылки на ютуб), а какая — извлеченную из него информацию Алисой (ответную "реплику", которой может быть и не текст вовсе)
И тут мы получаем самую обычную PKI с сертификатами и подписями, которую можно использовать для любого алгоритма взаимной аутентификации.
Так и есть, это все являлось попыткой сделать систему с открытым ключом для стеганографии, а протокол должен явно намекать на классический: "взял рандом, зашифровал открытым, передал владельцу закрытого, получил и сравнил".
в плане какой недостаток он нивелирует
В классических системах с открытым ключом передаваться между сторонами будет около-случайный набор байт, который сам по себе содержит информацию о связи двух лиц, а именно — они хотят что-то скрыть от посторонних, а сама форма данных может даже раскрывать сампротокол. Я стараюсь решить именно эту задачу, не давая наблюдателю абсолютно никакой информации об обмене информации
Чтобы избежать части вопросов по надежности, составил зачем-то на ночь глядя такую диаграмку с возможностями проведения атак контр-агентами в разных условиях информационного голода на разных шагах и описаниями результата. Так как уже поздно, то мог что-то забыть, но идею постарался передать
Но почему? Если человек на естественном (очень гибком и прощающем) языке пишет с ошибками, то мы его ругаем, зовем неграмотным. Если же программист пишет на очень строгом языке с ошибками, о многих из которых его предупреждают любые современные редактор и компилятор, — мы ругаем язык?.. И ведь ему за это часто платят, в отличие от двоечника Пети
А в чем проблема-то? Мы же не говорим, что русский плохой, потому что в нем можно построить грамматически корректные фразы, которые при этом не несут смысла, "не работают". И уж тем более не бежим создавать новый просто из-за того, что люди страдают с выражением своих мыслей на существующем
Тогда ладно, а то вдруг я не знаю чего, аж интересно стало)
После си переходить на раст больно. Язык содержит в себе гору клевых идей, но синтаксис явно разрабатывался в первую очередь для чтения компилятором, а уже потом человеком. И вечное желание сделать его максимально не С-подобным не помогает(
Ну один юнион — одна переменная с одним адресом, просто разными интерпретациями содержимого
Теперь мне даже интересно, как по мнению автора в плюсах можно создать две переменные, имеющие один адрес, без насилия над компилятором
Ну у меня выборка не прям большая, а сам я даже не бакалавр, поэтому кто знает. СГУ им. Чернышевского
Всегда ужасает этот факт. Кто и почему решил, что юзерам по умолчанию нужен запуск текстовых файлов по двойному клику, а не их просмотр?
Да ладно, по крайней мере тут нет ни политической, ни корпоративной составляющих. Написанный плохо, но живым человеком пост — куда уж ближе к оригинальному хабахабру?)
Из всех моих бывших сокурсников только один человек получает зп выше медианной в таблице, но зато аж в 3 раза. И здесь выборка всех обманула)
Я тоже, когда мне нечего делать, пишу компаниям во вконтаклях. А когда не отвечают, начинаю угрожать девочкам из техподдержки высшими инстанциями. Про меня даже пишут в газеты
P.S. Для таких вопросов на официальных сайтах обычно есть целые отдельные разделы
Не могу сказать, что прямо гуру, но если уж автор интересуется мнением, то, надеюсь, не обидится на пару простых замечаний и предложений в образовательных целях)
Если отбросить все детали реализации (а там есть над чем работать) и оставить только сам алгоритм, то при распараллеливании стоит задуматься в первую очередь над КПД потоков:
Общий алгоритм на основе блокирующей очереди можно скорректировать, например, так. Пусть мы хотим обойти дерево с помощью N потоков, изначально работает лишь один, а другие не были созданы заранее. Он:
Такой алгоритм уменьшает нагрузку на очередь и не тратит процессорное время до того момента, как у программы появились данные для обработки. Сами операции с очередью теперь работают с множеством данных, тем самым уменьшая необходимое количество обращений к ней. При этом часть работы производится в неблокирующей форме, не оказываясь в очереди вообще (и таких будет значительное число, сильно сказывающееся на производительности)
Стоит лишь заметить, что операции с T должны быть синхронизированы между потоками. В отличие от синхронизации на очереди, это ограничение легко обойти, храня локальную копию значения, и выполняя синхронизацию на шаге 2.1 только когда она > 0
Помимо сказанного другими выше, в коде не отслеживается конец задачи. Решение тривиально: нужно лишь проверять перед взятием новой задачи, сколько потоков в настоящий момент уже ждут у нее. Если значение равно N-1, значит, работы больше не светит, программу можно сворачивать
В такой простой задаче не нужно использовать пулы потоков, если не предполагается его передача функции "извне". Мы либо контролируем полностью процесс распараллеливания, либо полагаемся на внешние интерфейсы для многопоточности, смешивать два подхода не имеет смысла
Не стоит просто игнорировать исключения в потоках — если добавил try, то сделай обработку в catch, иначе просто пробрось его наверх. И проверяй неявные исключения — listFiles() иногда возвращает null, в следующей строчке может получиться NullPointerException
И напоследок — очень советую использовать встроенные в джаву функции работы с потоками, не ограничивая себя одним интерфейсом блокирующей очереди
Это обычные кодовые фразы, существует и работает (в газетах в частности). Минусы все еще никуда не исчезли)
И тут кликбейт: нашел кучу причин, почему интернет должен упасть, но так и не понял, почему он до сих пор онлайн
Первые совета три серьезно думал, что это просто очередной набор советов для вебдевов
И в какой же? Ну вот дернул я рубильник по предложению, когда Алиса ответила своему заказчику на картинку с зонтом (потому что "как в примере"), своровал какое-то сообщение. На следующий день оказалось, что это просто левый человек зонт заказал, а Алиса не агент (и таких миллионы). Или еще хуже — она агент и сбежала от такой явной атаки за границу. И кого я кому я навредил в итоге?
Не просто так привел пример со скрытым каналом ведь: никто не будет "дергать рубильник" на каждую электронную подпись просто потому, что в ней может что-то быть, верно?
В третий (с учетом одного в самом посте) раз говорю — так делать нельзя. Для этого придется хранить метод стеганографии в тайне, что, как мы уже выяснили. Тут нет нигде моей логики, протокол разрабатывался как раз для избавления от таких требований
Каждый художник видит как хочет, конечно, но в моем описании нет требования хранить в секрете что-либо, кроме частей Алисы и Боба, поэтому претензии не ко мне. Сам протокол открыт, части закрыты, все равно определить, происходит диалог или аутентификация, нельзя
Алгоритм открыт, неизвестны лишь части Алисы и Боба. Не знаю, что в моей фразе могло навести на эту мысль. Невозможность определения проведения протокола не означает, что он секретен, лишь что был правильно выполнен. Скрытый канал Эль Гамаля тоже нельзя просто так отличить от обычной подписи, например, но мы его не записываем в категорию "не криптографии"
Использование PKI легко определить даже на глаз, она решает задачу явной аутентификации, а не скрытой
Для этого как раз потребуется держать общий ключ и, что важнее, алгоритм в секрете. Я думал, тут речь о криптографии)
Усиление заключается в двух факторах. Первый — Алиса контролирует выбор формы передачи секрета. В какой-нибудь схеме Шамира у нее не оставалось бы контроля над тем, что присылает Боб — это всегда была бы просто его число, хоть головой об стену бейся
Второй — если Боб стал злоумышленником (противник соблазнил женщинами и деньгами), то он может атаковать часть Алисы после проведения аутентификации, имея на руках как свою часть в явном виде, так и восстановленный секрет. Именно поэтому я сделал акцент на невозможности восстановления по Em как Ex, так и самого секрета M, который содержится в отображении части Боба и не несет никакой информации о части Алисы
Это, конечно же, неверно. Я даже расписал, почему. Во-первых, любая последовательность Em и соответствующий отпечатоп h(M) Боба одноразовые, поэтому знание M противнику ничего не даст — набор данных уже был использован. Во-вторых, никто не мешает ему провести потом повторные раунды аутентификации, так как единственной Ex Алисы сопоставлено бесконечное множество его частей. В-третьих, само построение протокола скрывает шаги аутентификации, поэтому у третьей стороны в общем случае нет способа понять, для кого и когда дергать рубильник. А даже если каким-то образом и поняли — в общем случае нет возможности определить, какая часть диалога содержит передаваемый Бобом контейнер (от текста до ссылки на ютуб), а какая — извлеченную из него информацию Алисой (ответную "реплику", которой может быть и не текст вовсе)
Так и есть, это все являлось попыткой сделать систему с открытым ключом для стеганографии, а протокол должен явно намекать на классический: "взял рандом, зашифровал открытым, передал владельцу закрытого, получил и сравнил".
В классических системах с открытым ключом передаваться между сторонами будет около-случайный набор байт, который сам по себе содержит информацию о связи двух лиц, а именно — они хотят что-то скрыть от посторонних, а сама форма данных может даже раскрывать сампротокол. Я стараюсь решить именно эту задачу, не давая наблюдателю абсолютно никакой информации об обмене информации
Чтобы избежать части вопросов по надежности, составил зачем-то на ночь глядя такую диаграмку с возможностями проведения атак контр-агентами в разных условиях информационного голода на разных шагах и описаниями результата. Так как уже поздно, то мог что-то забыть, но идею постарался передать