помоему иконки совершенно неудачны.
очень мало удачных, по которым легко что-то идентифицировать.
намного лучше было бы сделать их схематичнее (без излишнего натурализма) и в меньшем количестве.
то же пиво одной иконкой (может быть несколькими для светлого, темного, ...), а страны каким-то фильтром.
с бокалами — вообще ужас.
по-моему иконки должны быть такими чтобы можно было бы без труда пройти следующий тест:
один человек смотрит картинку со всеми иконками как в посте, второй выбирает иконку и пытается одним коротким предложением объяснить первому какую выбрать не тыкая пальцем.
имхо хабрахбар не совсем соцсеть, хотя и взял от них много.
тут основа все-таки - централизованная подача контента через хабраленту.
и практически нет акцента на взаимосвязях между участниками.
посмотри Personal Menu, им можно заменить те два пункта меню, которые остались, на кнопки, места освободится еще больше. Да и само меню можно почистить (оставить только то чем пользуешься и вынести все нужное на 1 уровень).
неравномерность тоже выбирается случайным образом, при выборе факторов и формулы, так что по идее это не страшно.
главное чтобы пространство событий было слишком большим для перебора, тогда этим можно пренебречь.
Если пространство событий небольшое (или подмножество пространства которое имеет значительную вероятность, курс +- сегодняшний, счет очень маловероятно будет 1012:2556 и так далее), то автор алгоритма может подобрать такие формулы и факторы, которые повысят шансы нужного выбора. например в приведенном алгоритме поиграться с вариантами выбора валют и драгметалов которые учитывать в формуле.
Другое дело что скорее всего максимальная разница в вероятностях все равно будет мизерной.
как раз это и плохо. берем 100 раз данные статистики достаточно близко к заявленным 16:00, прогоняем через алгоритм и выбираем тот результат который нас больше устраивает.
мысль интересная. Ведь "бросить монетку" онлайн, так чтобы это было достоверно, невозможно. Эта процедура - аналог. Но к выбору случайных факторов нужно подходить осторожно. Это ни в коем случае не должно зависеть от быстроменяющихся случайных факторов (вроде статистики почещения на какое-то время). потому что можно произвести серию "взбрасываний" около нужного времени и выбрать более приемлимый с точки зрения злоумышленника результат (сославшись на небольшой сдвиг во времени сервера, который обрабатывает случайные данные).
Такой метод очень хорошо подошел бы для составления списков участников чего-либо в случайном порядке (там где место в списке может повлиять на результат).
думаю высказывания Столлмана содержат рациональное зерно. Столлман говорит именно об обработке данных и контроле за этим процессом, а не о попадании данных за пределы локального компьютера вообще.
Обработка данных в сети, которые можно обработать локально, действительно не нужна и в какой-то степени опасна. За исключением специфических случаев, когда не хватает мощности собственной вычислительной техники. Но и в этом случае можно арендовать доступ на удаленный вычислительный ресурс и запускать там свое или чужое СПО.
Если вы пересылаете готовый документ, отсылаете почту, IM сообщение, или что-то в этом роде, то вы информацию передаете с помощью интернета, а не обрабатываете. обработка идет на уровне пакетов, протокола, но не вашей информации, которая может быть зашифрована и для промежуточных серверов являтся мусором с информационной точки зрения. И кроме того процесс передачи без изменений несложно верифицировать, в отличии от нетривиальной обработки.
Естественно все это не касается информации которая сама по себе предназначена для распостранения через веб - публикация статей, видео, подкастов, комментариев и прочего, то есть всего того что делать локально просто не имеет смысла. Причем опять таки логичнее произвести всю предварительную обработку локально, в приложении которое для этого преждназначено, и выпустить в мир уже готовый "документ". Например для постинга тех же комментариев - мы пользуемся браузером, набираем готовый текст, в локальном приложении и потом отсылаем его в веб.
интересно, что если обобщить задачу:
есть N вариантов, из них K правильных, ведущий уберает M заведомо неправильных.
(очевидно, что M N(K-1)/K
то есть если, например, правильных вариантов 2, то выгодно менять выбор (выбирать из дверей которые не были выбраны в начале), только если ведущий откроет больше половины дверей.
а при K^2+K > N, сколько бы ведущий дверей не открывал лучше оставаться при своем мнении.
>ИОС не должна знать, что такое процессор, драйвер видеокарты и пр. Она должна быть железонезависима.
хммм. ОС всегда была прослойкой между прикладными программами и железом. чем будет заниматься ОС которая ничего не знает о железе и что будет обеспечивать взаимодействие с этим самым железом?
Открытый подход "базарного" типа к расширению протокола может привести к очень неприятным последствиям.
Как-то имел несчастье работать с p2p протоколом Gnutella. Более непоследовательного подхода я никогда не видел, бинарные вставки в http-like заголовках хэндшейка, бинарный поток сообщений, который мог паковаться и кодироваться на 3-4 уровнях. Несовместимые между собой расширения для метаинформации, причем помещаемые в разные контейнеры для расширений протокола. Расширения расширений для расширений. Метаинформация кодирующаяся, то плейнтекстом, то кусками xml, то просто блобами с кодировкой. И все это плохо документировано, на сайте протокола - вечный draft Gnutella 0.6, не включающий внятного описания расширений придуманных для различных клиентов этой сети. Плюс к нему еще 2 дополнительных протокола для функций, которые уже не лезли в основной.
А начиналось все с довольно простого и логичного Gnutella 0.4
но вряд ли все-таки эти иконки легко узнаваемы.
а если они не рядом?
очень мало удачных, по которым легко что-то идентифицировать.
намного лучше было бы сделать их схематичнее (без излишнего натурализма) и в меньшем количестве.
то же пиво одной иконкой (может быть несколькими для светлого, темного, ...), а страны каким-то фильтром.
с бокалами — вообще ужас.
по-моему иконки должны быть такими чтобы можно было бы без труда пройти следующий тест:
один человек смотрит картинку со всеми иконками как в посте, второй выбирает иконку и пытается одним коротким предложением объяснить первому какую выбрать не тыкая пальцем.
тут основа все-таки - централизованная подача контента через хабраленту.
и практически нет акцента на взаимосвязях между участниками.
когда меня так настойчиво пытаются куда-то затянуть, внутри появляется органическое неприятие.
главное чтобы пространство событий было слишком большим для перебора, тогда этим можно пренебречь.
Если пространство событий небольшое (или подмножество пространства которое имеет значительную вероятность, курс +- сегодняшний, счет очень маловероятно будет 1012:2556 и так далее), то автор алгоритма может подобрать такие формулы и факторы, которые повысят шансы нужного выбора. например в приведенном алгоритме поиграться с вариантами выбора валют и драгметалов которые учитывать в формуле.
Другое дело что скорее всего максимальная разница в вероятностях все равно будет мизерной.
Такой метод очень хорошо подошел бы для составления списков участников чего-либо в случайном порядке (там где место в списке может повлиять на результат).
Обработка данных в сети, которые можно обработать локально, действительно не нужна и в какой-то степени опасна. За исключением специфических случаев, когда не хватает мощности собственной вычислительной техники. Но и в этом случае можно арендовать доступ на удаленный вычислительный ресурс и запускать там свое или чужое СПО.
Если вы пересылаете готовый документ, отсылаете почту, IM сообщение, или что-то в этом роде, то вы информацию передаете с помощью интернета, а не обрабатываете. обработка идет на уровне пакетов, протокола, но не вашей информации, которая может быть зашифрована и для промежуточных серверов являтся мусором с информационной точки зрения. И кроме того процесс передачи без изменений несложно верифицировать, в отличии от нетривиальной обработки.
Естественно все это не касается информации которая сама по себе предназначена для распостранения через веб - публикация статей, видео, подкастов, комментариев и прочего, то есть всего того что делать локально просто не имеет смысла. Причем опять таки логичнее произвести всю предварительную обработку локально, в приложении которое для этого преждназначено, и выпустить в мир уже готовый "документ". Например для постинга тех же комментариев - мы пользуемся браузером, набираем готовый текст, в локальном приложении и потом отсылаем его в веб.
есть N вариантов, из них K правильных, ведущий уберает M заведомо неправильных.
(очевидно, что M N(K-1)/K
то есть если, например, правильных вариантов 2, то выгодно менять выбор (выбирать из дверей которые не были выбраны в начале), только если ведущий откроет больше половины дверей.
а при K^2+K > N, сколько бы ведущий дверей не открывал лучше оставаться при своем мнении.
хммм. ОС всегда была прослойкой между прикладными программами и железом. чем будет заниматься ОС которая ничего не знает о железе и что будет обеспечивать взаимодействие с этим самым железом?
Как-то имел несчастье работать с p2p протоколом Gnutella. Более непоследовательного подхода я никогда не видел, бинарные вставки в http-like заголовках хэндшейка, бинарный поток сообщений, который мог паковаться и кодироваться на 3-4 уровнях. Несовместимые между собой расширения для метаинформации, причем помещаемые в разные контейнеры для расширений протокола. Расширения расширений для расширений. Метаинформация кодирующаяся, то плейнтекстом, то кусками xml, то просто блобами с кодировкой. И все это плохо документировано, на сайте протокола - вечный draft Gnutella 0.6, не включающий внятного описания расширений придуманных для различных клиентов этой сети. Плюс к нему еще 2 дополнительных протокола для функций, которые уже не лезли в основной.
А начиналось все с довольно простого и логичного Gnutella 0.4