sebres
–2

А теперь подумайте еще раз про то, что вы спросили… 70% от чего? (мы еще помним, что TTT монополист, правда?)
Для математиков: 70% от трафика != 70% от новостей...


И потом:


  • сколько тех 70% просто потому, что если чел не пришел вовсе, то он и дальше не стал кликать
  • сколько по вышеупомянутой причине (ака точка входа — чел смотрит новости начиная с агрегатора и уходит к "конкуренту" издателя)
  • сколько упало по причине снижения рейтинга (честно-честно просто таким образом работает наш "секретный" алгоритм, который учитывает ленту новостей...)
  • сколько из тех 70% правда (сколько раздули и т. п.)

Это на вскидку, а если подумать то таких сколько...

sebres
0
Аналогия...

Ну вы тут немного передергиваете (либо еще не совсем поняли, либо нарочно путаете теплое с мягким): в качестве контр-примера...


Другая аналогия: Телекомпания ТТТ — монополист. Размещая чужой контент в блоке новостей она лишает людей его изготовивших заработка. При этом она не хочет никому ничего отчислять и в случае обращения просто забывает про издателя от слова совсем (т.е. не размещая чужой контент, но и не упоминая его вовсе), при этом снова тем самым лишая людей заработка (а мы помним что ТТТ — монополист).
Вопрос: Как долго ТТТ сможет размещать чужой контент, когда все те люди его создающие пойдут по миру?
Другой вопрос: как при этом затронут интерес другой группы — потребителя (не лишает ли их монополист ТТТ тем самым возможности узнать про новость, чтобы прочитать/посмотреть ее где-нибудь у издателя), а в долгосрочной перспективе и новостей совсем?


Повторюсь, я вовсе не за "копирастию" (по крайней мере в текущем ее виде), но вот так однозначно делить на белых и пушистых (типа "аргументы издателей выглядят слабоватыми") я бы не стал.


Размещает новости целиком и без ссылки на источник?

А вот это уже хороший вопрос ибо где та граница, когда ссылка остается еще интересна. Если новость сама по себе — новость и выжимки google практически достаточно, то на ту ссыль нажмут единицы.

sebres
0

А там вовсе не про рекламу в прямом смысле — google используется потребителем как агрегатор новостей, и он действительно фактически монополист, т.е. избирательно "выбросив" кого-либо из выборки, он тем самым практически "исключает" издателя для огромной аудитории.
Т.е. понять можно обе стороны:


  • google понятно по какой причине (похожая на вашу позиция)
  • издателей же, по причине, что google размещает таки "чужие новости" и имеет с того (агрегации новостей) определенный профит, а люди создававшие эти новости как бы идут лесом (ибо потребитель далеко не всегда по ссылкам ходит).

Нисколько не поддерживая закон в том виде как оно есть, я все же могу понять аргументы обеих сторон. Т.е. проблема действительно есть, другое дело, что возможно решать ее нужно было не обязательно в суде и уж точно не таким "дурацким" законом (имхо).

sebres
+2
Axel Springer не оставалось ничего другого, как разрешить Google ссылаться на тексты бесплатно.

Оно еще вовсе не закончилось — т.е. этот спор вышел на новый (юридический) уровень.
И как бы там не только Шпрингер, там еще с десяток-другой всяческих контор подвизались...


Т.е. если коротко, то:


  • Издатели утверждают, что google — фактически монополист, и поэтому обязан размещать (но и посему платить в соответствии с новым положением от 2013 в Leistungsschutzrecht).
  • В google настаивают на — либо бесплатно, либо не размещаем вовсе.

Как мне видится — это еще очень на долго...


Статья про это на немецком от марта 2016 — weiter auf Deutsch (и с выключенным адблокером).

sebres
0
Максимальная размерность… RAW = 4000 байт

Небольшая поправка:
Лимит для RAW = 2000 байт (если MAX_STRING_SIZE = STANDARD)

sebres
+1

А это художественное произведение и есть...

sebres
+3
Гению откажет… Искать и удерживать.

Ну вот не откажет, а через год-два "гения" собьет машиной, или он с Эвереста скувыркнётся, тем самым не "удержится". Как вам такая альтернатива?.. Оцените риски?


Тут как-бы стоит не про гениальность соискателя поговорить… Дело вот в чем: написать jvm-ный байт-код (а то и в с десяток других, включая питоний или нативный, ака asm например) смогут возможно многие, и из моего окружения в том числе, но при этом:


  • они сделают это без лишнего литья воды вокруг (я про собственный загрузчик и ко, что как минимум не имеет никакого прикладного значения в рамках поставленной задачи, т. е. не комильфо оно тут — вы же не будете писать ОС с дровами и шлюзами, если вас просят прочитать из channel)
  • постараются сначала или в процессе выяснить уровень "мальчика" Тима, чтобы разговор шел хотя бы на одном языке, тем самым...
  • не выставят человека полным нубом (ну или если хотите не покажут ему своего к нему "отношения")
  • будут вести разговор в продуктивном ключе (т. е. найдут возможность "блеснуть" так, чтобы собеседующий это хотя бы понял и проникся уровнем "гениальности")
  • покажут уровень "взрослости" собеседуемого (потому что, шутки-шутками, но вот-это сильно тянет на "я вчера сбежал с детского сада", уровня "кулхацкер" в абсолюте)
  • ну или как минимум уточнят рамочные условия, тем самым покажут ему что "из пушки по воробьям" для них знакомое словосочетание, а фирма не получит такого "все-на-свете-оптимизирующего" в ущерб читабельности, совместимости, безопасности (и еще с десяток ...-сти) того-самого "кода".

А так, да… как красивая история для бложика — возможно (т.е. написано-то и правда красиво, + понты, эго… все дела)…
Но как "реальная" история из жизни, — упаси боже от таких гениев-коллег.

sebres
+5
systemd-escape

может просто не надо писать баш-скрипты в systemd?
Т.е. я про то, почему это должно быть непременно частью something.service, а не частью например something.sh, который отробатывает в ExecStart...


IMHO systemd-escape сделана как helper, чтобы писать динамические systemd-скрипты (т.е. не руками, а "машинным" способом).

sebres
+1

А чего тут подробнее — Tcl.


Ну а реализация конкретно этого http-server'a — собственная, асинхронная, на tpool-потоках, используя один пул listener/auth/supplier и второй пул workers, между ними асинхронный tcl reflected channel…
Реализаций коих штук двадцать на просторах (и не думаю что моя быстрее). Так же как думаю, что и tcl нисколько не быстрее erlang (просто elixir, хмм..., ну да ладно не хочется холиварить)...


Если совсем лень что-то делать (а тикль юзать или пробовать хочется), да и нужно еще быстрее — nginx + tcl по fastcgi (с некоторой обвязкой) порвет на таких хэлловордских задачах все вышеперечисленное, как тузик грелку.


Я его так и юзаю обычно, http-server на чистом тикле нужен когда тащить nginx тяжело или низя (embedded).


Писать мне лично на тикле удобнее чем на erlang, нодах, рюстах и сях вместе взятых (даже питон думаю не сравним, я про удобство и лаконичность)… Но я немного предвзят, ибо уже сто лет как в TCT (разраб в tcl core team), т.е. я его делаю (и если что-то не нравится переделываю сам;).
Но это не node.js, порог вхождения много-много выше (как минимум при "сборке" сервера)...

sebres
+2
статически скомпилированная программа просто обязана быть быстрее виртуальной машины с интерпретатором

Оно как бы да, но это смотря а) как скомпилированна и б) с каким интерпретатором сравнивать...


Вот вам для сравнения на чистом тикле (tcl, threaded, full-async), jit-интерпретатор в quad-code (если что;)
Ответ запроса чуть побольчее в размере, но не критично (ну headers у меня там многовато, лень править да и throughput тут важнее запрос/сек.)...


$ wrk -t10 -c100 -d10s http://172.18.105.109:80/app/empty.htm
Running 10s test @ http://172.18.105.109:80/app/empty.htm
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    15.00ms    8.18ms 145.16ms   95.58%
    Req/Sec   702.82    197.54     6.07k    96.68%
  69539 requests in 10.10s, 24.34MB read
Requests/sec:   6885.13
Transfer/sec:      2.41MB

Для сравнения то-же (подогнал по размеру) на Elixir (результаты немного лучше чем у вас, я про Latency и ко):


$ wrk -t10 -c100 -d10s http://172.18.105.109:8085/test-elixir
Running 10s test @ http://172.18.105.109:8085/test-elixir
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    33.86ms   30.49ms 281.11ms   82.70%
    Req/Sec   376.13    283.00     5.25k    77.16%
  36967 requests in 10.10s, 12.94MB read
Requests/sec:   3660.63
Transfer/sec:      1.28MB

Причем на tcl 2 из 4-х cpu спят, справляется практически 2-мя потоками 30-40% usage (чтобы загрузить на все 100% надо wrk -t100 юзать).


на Elixir же — все 4-е ядра под 100% busy и контекст-свич кернел-таймом погоняет.


Так-что реализация тоже важна (я не думаю, что tcl "шустрее" elixir)...


Ну и не компиляторами едиными…
П.С. Go не держу, так что сравнить не можу...

sebres
0

Я могу конечно ошибаться, но думается мне почему-то, что это ASLR (и-или DEP).
Если на машинках, где обоих можно выключить, баг не воспроизводится — оно говорит за-то...


Ну и если да, решения два (кроме как не юзать винду):


  • не использовать абсолютных указателей (только относительные, не думаю что вариант для mingw)
  • или бороться как я например тут для nginx делал, т.е. грубо говоря переалоцировать base, пока не выравняем блок у всех caller по одному адресу (good luck with its implementation;).

Ну или тот-же воркараунд на секции .text (MEM_WRITE как сделал Jason Bell), хотя не сукьюрно оно как-то.

sebres
+2
Для расшифровывания файлов действуйте в соответствии с одним из следующих сценариев

Ну да, в этом конкретном "детском" случае — возможно что-то и получится.
(Хотя гораздо проще тут было бы настроить "прокси" через роутинг к другому серверу, который вернет 1 по заданному адресу)


Однако в основной своей массе — шифровальщики:


  • либо используют асимметричное шифрование, где для расшифровки нужен другой ключ (т.е. вызов URL как в примере вернет не 0/1, а ключик для расшифровки).
  • либо портят все насмерть (т.е. вовсе не предусмотрено восстановление, даже так сказать по факту оплаты)

Ну и попробуйте подобрать даже 512-байтный ключ какой-нибудь эллиптической кривой (не обязательно стандартной кстати), встретимся через сотню лет (сколько там х-тилионов MIPS-лет нужно).


Тут только или свезло (как в вашем случае)… или (правильно настроенный) бэкап спасает…
Ну или 101 способ предотвратить запуск подобной нехорошей софтины (например тот же SRP и ко, если винда).

sebres
+2

because it's the bug of mingw, вернее ее реализация вокруг mark_section_writable.
Поэтому и не собираются, ибо нефиг плодить воркараунды.
Т.е. баг делегирован дальше, имхо абсолютно правилно, см. MinGW-w64 — for 32 and 64 bit Windows / Bugs / #537 pseudo_reloc fails to mark pages writable

sebres
+1

Вот только не надо про вероятности, интуитивное восприятие и т.п.


Вы кстати не поняли этот парадокс — он говорит как раз про обратное, что совпадения более вероятны, чем интуитивно воспринимается (ибо например для 23-х людей — на самом деле сравниваем 253 возможные пары).
И закроем тему интуитивного восприятия на этом. Расскажите про "день рожденья" кому-нибудь другому (когда поймете).


Теперь по теме: лично видел два одинаковых UUID, созданных на двух разных хостах в одном (правда большом и сильно нагруженном пуле) кластера.
И то было в industries API 80-го уровня. Я бы вам даже имя сказал, но низя (связан подписью о не разглашении)…
Однако с тех пор там та конкретная реализация UUID-api (рандомная кстати, ибо v4) — под строжайшим запретом (бьют по рукам если что).
А так-то да — теоретически невероятно...


Раз уж слово вероятность упало, попробуйте оценить разницу вероятностей:
1) что два каких-то "случайных" 128-ми битных числа будут равны;
2) например в сравнении с вероятностью, что два случайных 52-битных числа + цикличный инкремент (8 бит) про процесс, созданных в течении тех же десяти миллисекунд (48 бит), с одинаковым хэшем (20 бит) взятым от fqdn + thread-id — в результате тоже будут одинаковы;


Вам сразу вопрос: тут фактор времени или количества чисел вообще в выборке важен или нет? Т.е. вопрос два числа из скольких...


Поэтому, сделаем тут некоторые допущения — уточнения условий задачи:


  • одно-поточно реально создать максимально 1000 ключей за одну миллисекунду (только вот что с ними делать с такой-то скоростью, ну да пусть)
  • имеем 256 потоков на машинке
  • имеем ну пусть будет 100 машин в кластере
  • все это добро работает десятилетия.

И не забываем что:
Все это абсолютно не градиентно в первом случае, но чисто для оценки порядка:
(1000 * 1000000 * 256 * 100) — уже 2 в 45-й — и это прошу заметить в секунду.
И крайне важно во втором.

sebres
0
технически исключено

Ну оно к тому стремится… Просто цель-то у него — "глобально уникальный", а не "случайный" т.е. менее зависим от тех же начальный и текущий сид, энтропии и т.п.
Если у вас там даже хэш от uuid хоста замешан будет оно уже менее зависимо от "случайностей"…
Я про то, что законы Мерфи еще никто не отменял — "если есть вероятность того, что какая-нибудь неприятность может случиться, ...." (я про коллизию, как бы мизерна не была вероятность последней).


Да я и не спорю: то просто замечание было про между прочим (ибо режет глаз). В любом случае придумывать собственную реализацию guid, да еще и триггером обернуть имхо как-то не комильфо (о чем и поведал, выразив свое мнение, с которым совсем не обязательно нужно быть согласным).


П.С. Вот в качестве примера: возьмем nginx-cache-модуль — раньше ключи там не сравнивали (т.е. тупо считалось, что т.к. вероятность коллизии хэша никакая, то достаточно сравнить хэш и все).
И всем известный персонаж спорил с пеной у рта, что оно достаточно, и не нужно это, про всякие "дни рождения" рассказывал и т.д.
Вот там я действительно спорил и настаивал, потому что во первых, хэш — это хэш — он там для скорости а не для крипто-стойкости, во вторых это очень просто и доп. сравнение стоит гроши. А в третьих я их (коллизии) там лично встречал (на очень большом и длинном кэш), причем доказуемо (хорошо еще что на тест-стенде, а не в продакшн).
При том что частью ключа кэша может быть например user-id и nginx тогда при возникновении той "невозможной" коллизии покажет к примеру приватную информацию другому пользователю.
И побоку тогда, что коллизии маловероятны — в корпоративном секторе вы за такое как минимум с работы вылетаете.
Подробнее тут и в мэйл-архивах nginx можно поискать.
Фикс то пустяковый, но нужно же сперва поспорить… Вероятности, это такое дело — их нужно уметь готовить.
Все хотел про то статью тиснуть, да некогда — пусть побудет комментом.

sebres
0

Ну да SQLiteCustomFunction с рефлектом… А чему он хак-ом стал вдруг? Т.е. вы считаете trigger (который вообщето совсем для других целей придуман) менее хакиш вэй. Ну тады ОК.

sebres
+1
Если используется аппаратный источник энтропии

Не используется там никакие источники энтропии — ибо GUID по определению криптографически нестоек.


Каким же образом это «исключено»? :) Вы сами себе противоречите.

Вы возможно слово "часть" пропустили в предложении "значительная часть которого действительно является псевдослучайной последовательностью".
Во всех известных мне реализациях оного, там еще замешивают pid, tid, mac, clicks и тому подобное.


Если бы вы внимательно читали, но заметили бы, что это невозможно на Android

Если вы чего-то не умеете (не можете) — это еще не значит, что оно не возможно.
И собственная сборка SQLite для этого абсолютно не нужна.

sebres
0

Ну делать-то я положим тоже так делаю (когда оно оправдано)…
А вы при случае на execution plan гляньте.
Вот простейший случай — без group by и т.д. (тупо слить из первой все, присутствующие и во второй таблице):


CREATE TABLE records (id BLOB PRIMARY KEY, data CHARACTER)
CREATE TABLE subrecords (subid BLOB, ...)

EXPLAIN QUERY PLAN 
  select * from records where id in (
    select subid from subrecords
  )

0 0 0 SEARCH TABLE records USING INDEX sqlite_autoindex_records_1 (id=?) (~25 rows)
0 0 0 EXECUTE LIST SUBQUERY 1
1 0 0 SCAN TABLE subrecords (~1000000 rows)

CREATE TABLE records2 (id INTEGER, id2 INTEGER, data CHARACTER, PRIMARY KEY (id, id2))}
CREATE TABLE subrecords2 (subid INTEGER, subid2 INTEGER, ...)}

EXPLAIN QUERY PLAN
  select * from records2 
  inner join (select subid, subid2 from subrecords2) sub
  on sub.subid = id and sub.subid2 = id2

0 0 1 SCAN TABLE subrecords2 (~1000000 rows)
0 1 0 SEARCH TABLE records2 USING INDEX sqlite_autoindex_records2_1 (id=? AND id2=?) (~1 rows)

Вопрос: почему и когда второй вариант может стать сильно медленнее (а главное когда это будет очень-очень критично). (Подсказка — N x M + concurrency).

sebres
+1
GUID это случайное "число"

GUID это уникальный ID, значительная часть которого действительно является псевдослучайной последовательностью (но он однозначно не является случайным).
Иначе вы теоретически могли бы сгенерировать 2-а одинаковых GUID на двух разных устройствах (что на самом деле технически исключено).


Про триггер: sqlite легко расширяется собственными функциями практически на любом языке программирования, т.е. триггер не нужен, достаточно добавить default (expr), вот пример на TCL:


% db function UUID {uuid -binary}
% db eval {CREATE TABLE records (id BLOB DEFAULT (UUID()) PRIMARY KEY, data CHARACTER)}
% db eval {insert into records (data) values ('test')}
% db eval {select * from records}
?º¢?Né3?↑?ÿX¥??÷ test

Ну и чтоб два раз не ходить, отвечу всем вышекомментировавшим про составной комби-PK по двум ключам:


  • сложнее делать выборку по ID, например если join нежелателен (или невозможен) типа подзапроса.
    Попробуйте переписать с составным ID:

select * from records where id in (select rec_id from subrecords where ... group by ...)

  • будет не сильно но медленнее (как минимум если ID перерастут signed int32), вот ниже замеры для наглядности:

-- blob primary --
CREATE TABLE records (id BLOB PRIMARY KEY, data CHARACTER)
...
insert into records values (x'9bbaa28c4ee9b394189aff58a58f85f7', 'test')
insert into records values (x'bf8bdf314779cb74caac36844b60bd85', 'test')
--
select 1 from records where id = x'bf8bdf314779cb74caac36844b60bd85' limit 1
-- 1.061206 µs/# 9151569 # 942323 #/sec 9711.703 nett-ms

-- composite primary --
CREATE TABLE records2 (id INTEGER, id2 INTEGER, data CHARACTER, PRIMARY KEY (id, v1))
...
insert into records2 values (2147483647, 2147483647, 'test')
insert into records2 values (2147483648, 2147483648, 'test')

select 1 from records2 where id = 2147483647 and id2 = 2147483647 limit 1
-- 1.068456 µs/# 9091251 # 935929 #/sec 9713.603 nett-ms

select 1 from records2 where id = 2147483648 and id2 = 2147483648 limit 1
-- 1.111840 µs/# 8746288 # 899410 #/sec 9724.472 nett-ms

Если что измерял prepared, на in-memory базе, чисто время исполнения запроса.

sebres
–1

Пользуюсь сто лет уже статическими генераторами (т.е. ни запоминать ни записывать не нужно от слова вовсе).
Не сочтите за рекламу к примеру вот мой самописный плагин под лиса

Комментарий из публикации, перенесённой в черновики.
Комментарий из публикации, перенесённой в черновики.
sebres
0

Не нужны тут "два хэша".
Во первых, в гит хэш для коммита берется от содержимого + мета-информации (как-то: parent-commit, меседж, автор, сабмитер, время и т.д.). Т.е. генерация по принципу описанному гуглем здесь априори не работает.
Во вторых, кроме хэш коммита в гит важен также и хэш предка (parent-commit).
Ну и last but not least — создать два коммита с одинаковым хэш-значением в одной ветке гит в принципе не возможно, т.е. оно не ломает гит-репозитарий (от слова совсем). Единственное что возможно это переписать его амендом (или push --force в remote). Однако при fetch/pull вы получите новую ветку на том коммите.

sebres
0

Вам понятие "риторический вопрос" знакомо? Или это тонкий троллинг такой?

sebres
+1
Дублирование, резервирование, перекрытие защиту функционала – это залог успеха в современной быстро развивающейся среде в области информационной безопасности.

Ну да и по два антивируса на воркстейшн (а нередко и на сервере, чего уж греха таить) — это уже реальность (в корпоративном секторе).
Только вот панацея ли это?

sebres
0

У меня где-то валялся "бизоний" питоний парсер, он тоже делает код гораздо мельче, к тому же еще и быстрее, но к сожалению (в свое время) кроме всякой мелочи еще и с сохранением того кода в бинарник были проблемы, так и не допилил, может раскопать снова...

sebres
+1
скриптов на питоне, которые быстро прогоняют через себя сотни мегабайт логов или скл данных

Не путайте, ибо в контексте статьи и патчей, важно сколько те скрипты через себя (питоньих) исходников или jit (eval и иже с ними) "прогоняют".

sebres
0

Глупости не говорите: универсальное решение тут может быть только одно, в маппере чистить сегмент (нулями) как минимум за пределы реального перетащенного блока до размера сегмента банки, и как максимум по выделению и перед перетаскиванием блоков), что есть 1. геморрой, 2. вымывает кэша, 3. нереально "ускоряет" контекст-свич туды-сюды, ну и все сопутствующее безобразие в придачу сверху (сброс TLB, глобальных дескрипторов и т.д. и т.п.).
Ну или экзотика типа той же CBA (capability-based адресация), что тоже нереально весело, т.к. нужно будет переписать все, начиная от компиляторов и заканчивая ядром ОС и гипервизоров…
И последствия сего — бинарная (не)совместимость такого софта к примеру, тоже имеют место.


Одно вот только (что бы значит чуть сбавить градус истерии) — как применить на практике подобную "уязвимость" не ясно даже самим "первооткрывателям"… Ну и сколько звезд на небе для этого должны сойтись, история по видимому умалчивает...

sebres
–1

кстати, все бы изменилось, если бы первый выбор что-то менял, например вылет или выигрыш игрока, неравнозначность козлов А и Б, и т.д.

sebres
0
не может открыть ту дверь, которую выбрал игрок.

вы таки не поняли или я не понятно объяснил: что меняет выбранная дверь, или вернее какого козла ведущий откроет — первого или второго? т.е. первоначальный выбор не изменяет ничего, дверь с козлом будет открыта все равно, второй выбор (ткнуить снова в ту же дверь или в другую) ничего не меняет… убрав одного из козлов, это ведущий изменил условия задачи, сравняв вероятности машины для обеих оставшихся дверей, вне зависимости от "клейма" предыдущего выбора.


"ваша" математика понятна и в случае команды игроков и многократных повторов, без обмана — все так, что не отменяет всего выше описанного для каждого конкретного игрока...

sebres
+1
отказаться от подсказки...

а теперь представим, что первый раз вы не выбирали дверь… ведущий же все равно откроет дверь с козлом. Т.е. что изменилось — вы тыкаете в какую-то дверь (вероятность выбора правильной в этом случае один к двум), как на это влияет выбрана она была до этого или нет?


нет про частотный анализ и мат ожидание не нужно, это понятно как раз, вы ответьте на прямо поставленный вопрос...


ПС Если, что вопрос не мой, задаёт профессор хановерского университета… я его втянул в дискуссию

sebres
–1

Вооот! Искал этот комментарий (и дождался от человека, по его словам ничего не понимающего в "вероятностях" ;).


На самом деле спорящие стороны обе частично правы, ибо дилема происходит из-за неполного (вернее куцего что-ли) определения условий задачи… И голуби тут не совсем как-бы причём...


Если рассматривать вероятности угадывания при смене двери и без, при как минимум 3-х повторах (т.е. строго говоря соблюдая необходимое правило для оценки вероятности — массовый характер, желательно бесконечно долго), тогда — да все как написано — дверь нужно менять.


Если рассматривать вероятность угадывания один единственный конкретный раз (исключая условие "массовый характер" и предыдущие "опыты" других людей), то вероятности (нет уже нельзя говорить про вероятности, мат-ожидания и иже с ними), скорее необходимости что-ли менять дверь — как таковой — нет. Ибо равновероятно, что во втором туре именно в этот (важный для вас) раз — вы получите машину. Т.е. в этом конкретном туре она равна 1/2 (независимо от смены двери). И это кстати также видно на той же картинке из википедии — из 6-и человек 3-м досталась машина и 3-м — коза. Просто люди обращают внимание только на нижний левый угол (когда дверь меняли). Но… в том то и дело, что в одном единственном конкретном случае абсолютно не важно менялась дверь или нет, ибо изначально равновероятно она могла быть уже выбрана верно.


Комбинаторика наряду с теорией вероятностей, очень строгая наука, где для точного анализа, условия задачи должны быть строго оговорены. Многие кстати путают вернее иногда неверно связывают частотные и вероятностные характеристики (например количество равновероятных комбинаций и вероятности их выпадения в зависимости от различных условий).


  1. В качестве примера чуть поменяем условия (исключая необходимое условие бесконечности проведения опытов): Это шоу происходит один единственный раз (от слова совсем). Поможет ли играющему смена двери выиграть машину, по сравнению с тем как если бы вы ее не меняли? Ответ — нет.
  2. Другой пример: Ежедневное шоу. Насколько быстрее у компании, осуществляющей "бесплатную" раздачу машин, закончатся деньги, если каждый участник всегда будет менять дверь (по сравнению с тем как если бы ее всегда не меняли)? Ответ — в два раза быстрее (2/3 в сравнении к 1/3).

Ну и возвращаясь к голубям, учитывая что делая это раз за разом "смена двери" действительно повышает шансы добраться до корма, делается вывод — нужно менять дверь. Что не отменяет тот факт, что в единственном конкретном случае (а человек участвует в шоу ровно один раз), это абсолютно не важно (если не ставить целью разорить фирму, проводящую шоу).


Поэтому многие именитые математики и сделали такие заявления, т. к. подходя к задаче комбинаторно, они рассматривали единственное действие, т.е. выигрыш конкретного участника, а не общий игровой фонд всех участников за год, с целью разорения фирмы (т. е. при многократно повторяемых шоу).

sebres
+2

"Back up" — разделяемый глагол (not obligatory), поэтому и так и так можно…
Однако, исходя из частоты употребления англоязычной публикой я бы сказал написанное рядом звучит "лучше"...


Хотя про ваш вариант некоторые немецкоговорящие товарищи сказали бы, что возможно это "denglisch наоборот" ;)

sebres
0
на свеже поставленных ОС и фоксе офф-лайн, т.е. с гарантией, что не сядет троян?

Т.е. другими словами, вы знаете что у вас кейлоггер сидит и живете с этим? Т.е. случайное, до времени незамеченное, заражение — это одно, но это ж не норма...


Ну тогда вводите секрет как-нибудь "гарантированно" секьюрно (по частям, с копи-пастой, драг-дропом с яндекс клавиатуры и т.п.), т.е. максимально сложно — обфусцировано (один раз же)...

sebres
0

секретная фраза вводится один раз (запоминается в профиле), вытащить её оттуда сродни вытаскиванию пароля из поля формы, даже хуже ибо расширения в фоксе подписываются (т.е. неизменяемы). Максимум что может быть украдено кейлоггером — это нестойкий, не замешанный, пароль.
От keepass это отличается тем что пароли не хранятся нигде (имхо это моветон), они "вычисляются* алгоритмически

sebres
0

Да не сочтёт хабрасообщество за рекламу и звиняюсь за небольшой оффтоп (ибо тема, точнее подход, не совсем про-то, но с кейлоггерами, включая скрин-троянов и т.п. нечисть, справляется на ура, плюс запоминать пароли не надо) — сделал как-то расширение для ffox-а — пользуйтесь на здоровье... Вдруг кому пригодится.

sebres
+1
но всё может «исчезнуть» в один момент.

Нифига не может, ибо git в отличии от тех-же svn, cvs и т.д. — распределённая система управления версиями.
Т.е. репы останутся у меня, у Васи, Пети и еще сотен других… Причем после перезалива (без ребейса истории), они синхронизируются идеально, от слова совсем… даже через десять лет.


Край, что бывает нужно поправить — это незакоммиченые модульные remote-ссылки...

sebres
0

Что мне абсолютно не нравится в новой морде гитхаба, это отсутствие в табе activity (по новому overview) истории действий (комментов, движений, сливания и удаления веток и т.п.).
Т.е. поменяли вид user overview, теперь там подробнейшая contribution activity (т.е. видно коммиты, PR), но в упор нет истории, как оно было.


В результате:


  • стало абсолютно не реально найти что-то в своих комментах, типа "блин, позавчера же отвечал, подробный коммент на ту же тему, issue не помню";
  • на той неделе коллега удалил ветку, блин как же ее звали (хорошо если в reflog еще уши торчат)...
  • невозможно посмотреть на историю активности пользователя, например чтобы оценить адекватность (к примеру его support-agility) или компетентность человека (при отборе кандидатов на работу) и т.д.
  • и т.д. и т.п.

Ну переработали они ту страничку, ладно, но зачем же совсем выпиливать готовый и работающий функционал...

sebres
0
Добавлять задачи из одного репозитория в проекты/доску другого там и там нельзя...

Чо это? Можно давно, — называется гиперссылка :)


Это ж веб-приложение, в любом месте github пишем короткую markdown ссыль типа sebres/fail2ban#2, под которой вложится реальная ссыль на PR, issue и т.п. в репо fail2ban юзера sebres под номером 2. Точно так же вставлятся комменты, ветки и коммиты со выбраной строчкой и т.д. и т.п.


Вот честно, ниразу не скучал за JIRA и прочие на гитхабе...

sebres
0

Вы тогда с терминологией сперва разберитесь, что есть нейронная сеть (у которой строгое определение есть между прочим)… а потом уже лезьте холливарить, смущая других людей, и отвлекая автора от серьезной работы...


А придумывать не нужно совсем, ибо


Может ли компьютер с помощью технологии нейросетей ответить на вопрос, заданный текстом, и не запрограммированный инженерами? Может...

НЕТ. И еще раз нет, и еще долго не сможет.
Вы сейчас только что, чуть не всех секретарей, референтов и т.д. и т.п. на пенсию отправили...