А теперь подумайте еще раз про то, что вы спросили… 70% от чего? (мы еще помним, что TTT монополист, правда?) Для математиков: 70% от трафика != 70% от новостей...
И потом:
сколько тех 70% просто потому, что если чел не пришел вовсе, то он и дальше не стал кликать
сколько по вышеупомянутой причине (ака точка входа — чел смотрит новости начиная с агрегатора и уходит к "конкуренту" издателя)
сколько упало по причине снижения рейтинга (честно-честно просто таким образом работает наш "секретный" алгоритм, который учитывает ленту новостей...)
сколько из тех 70% правда (сколько раздули и т. п.)
Это на вскидку, а если подумать то таких сколько...
Ну вы тут немного передергиваете (либо еще не совсем поняли, либо нарочно путаете теплое с мягким): в качестве контр-примера...
Другая аналогия: Телекомпания ТТТ — монополист. Размещая чужой контент в блоке новостей она лишает людей его изготовивших заработка. При этом она не хочет никому ничего отчислять и в случае обращения просто забывает про издателя от слова совсем (т.е. не размещая чужой контент, но и не упоминая его вовсе), при этом снова тем самым лишая людей заработка (а мы помним что ТТТ — монополист).
Вопрос: Как долго ТТТ сможет размещать чужой контент, когда все те люди его создающие пойдут по миру?
Другой вопрос: как при этом затронут интерес другой группы — потребителя (не лишает ли их монополист ТТТ тем самым возможности узнать про новость, чтобы прочитать/посмотреть ее где-нибудь у издателя), а в долгосрочной перспективе и новостей совсем?
Повторюсь, я вовсе не за "копирастию" (по крайней мере в текущем ее виде), но вот так однозначно делить на белых и пушистых (типа "аргументы издателей выглядят слабоватыми") я бы не стал.
Размещает новости целиком и без ссылки на источник?
А вот это уже хороший вопрос ибо где та граница, когда ссылка остается еще интересна. Если новость сама по себе — новость и выжимки google практически достаточно, то на ту ссыль нажмут единицы.
А там вовсе не про рекламу в прямом смысле — google используется потребителем как агрегатор новостей, и он действительно фактически монополист, т.е. избирательно "выбросив" кого-либо из выборки, он тем самым практически "исключает" издателя для огромной аудитории.
Т.е. понять можно обе стороны:
google понятно по какой причине (похожая на вашу позиция)
издателей же, по причине, что google размещает таки "чужие новости" и имеет с того (агрегации новостей) определенный профит, а люди создававшие эти новости как бы идут лесом (ибо потребитель далеко не всегда по ссылкам ходит).
Нисколько не поддерживая закон в том виде как оно есть, я все же могу понять аргументы обеих сторон. Т.е. проблема действительно есть, другое дело, что возможно решать ее нужно было не обязательно в суде и уж точно не таким "дурацким" законом (имхо).
Axel Springer не оставалось ничего другого, как разрешить Google ссылаться на тексты бесплатно.
Оно еще вовсе не закончилось — т.е. этот спор вышел на новый (юридический) уровень.
И как бы там не только Шпрингер, там еще с десяток-другой всяческих контор подвизались...
Т.е. если коротко, то:
Издатели утверждают, что google — фактически монополист, и поэтому обязан размещать (но и посему платить в соответствии с новым положением от 2013 в Leistungsschutzrecht).
В google настаивают на — либо бесплатно, либо не размещаем вовсе.
Ну вот не откажет, а через год-два "гения" собьет машиной, или он с Эвереста скувыркнётся, тем самым не "удержится". Как вам такая альтернатива?.. Оцените риски?
Тут как-бы стоит не про гениальность соискателя поговорить… Дело вот в чем: написать jvm-ный байт-код (а то и в с десяток других, включая питоний или нативный, ака asm например) смогут возможно многие, и из моего окружения в том числе, но при этом:
они сделают это без лишнего литья воды вокруг (я про собственный загрузчик и ко, что как минимум не имеет никакого прикладного значения в рамках поставленной задачи, т. е. не комильфо оно тут — вы же не будете писать ОС с дровами и шлюзами, если вас просят прочитать из channel)
постараются сначала или в процессе выяснить уровень "мальчика" Тима, чтобы разговор шел хотя бы на одном языке, тем самым...
не выставят человека полным нубом (ну или если хотите не покажут ему своего к нему "отношения")
будут вести разговор в продуктивном ключе (т. е. найдут возможность "блеснуть" так, чтобы собеседующий это хотя бы понял и проникся уровнем "гениальности")
покажут уровень "взрослости" собеседуемого (потому что, шутки-шутками, но вот-это сильно тянет на "я вчера сбежал с детского сада", уровня "кулхацкер" в абсолюте)
ну или как минимум уточнят рамочные условия, тем самым покажут ему что "из пушки по воробьям" для них знакомое словосочетание, а фирма не получит такого "все-на-свете-оптимизирующего" в ущерб читабельности, совместимости, безопасности (и еще с десяток ...-сти) того-самого "кода".
А так, да… как красивая история для бложика — возможно (т.е. написано-то и правда красиво, + понты, эго… все дела)…
Но как "реальная" история из жизни, — упаси боже от таких гениев-коллег.
может просто не надо писать баш-скрипты в systemd?
Т.е. я про то, почему это должно быть непременно частью something.service, а не частью например something.sh, который отробатывает в ExecStart...
IMHO systemd-escape сделана как helper, чтобы писать динамические systemd-скрипты (т.е. не руками, а "машинным" способом).
Ну а реализация конкретно этого 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, порог вхождения много-много выше (как минимум при "сборке" сервера)...
статически скомпилированная программа просто обязана быть быстрее виртуальной машины с интерпретатором
Оно как бы да, но это смотря а) как скомпилированна и б) с каким интерпретатором сравнивать...
Вот вам для сравнения на чистом тикле (tcl, threaded, full-async), jit-интерпретатор в quad-code (если что;)
Ответ запроса чуть побольчее в размере, но не критично (ну headers у меня там многовато, лень править да и throughput тут важнее запрос/сек.)...
Я могу конечно ошибаться, но думается мне почему-то, что это ASLR (и-или DEP).
Если на машинках, где обоих можно выключить, баг не воспроизводится — оно говорит за-то...
Ну и если да, решения два (кроме как не юзать винду):
не использовать абсолютных указателей (только относительные, не думаю что вариант для mingw)
или бороться как я например тут для nginx делал, т.е. грубо говоря переалоцировать base, пока не выравняем блок у всех caller по одному адресу (good luck with its implementation;).
Ну или тот-же воркараунд на секции .text (MEM_WRITE как сделал Jason Bell), хотя не сукьюрно оно как-то.
Для расшифровывания файлов действуйте в соответствии с одним из следующих сценариев
Ну да, в этом конкретном "детском" случае — возможно что-то и получится.
(Хотя гораздо проще тут было бы настроить "прокси" через роутинг к другому серверу, который вернет 1 по заданному адресу)
Однако в основной своей массе — шифровальщики:
либо используют асимметричное шифрование, где для расшифровки нужен другой ключ (т.е. вызов URL как в примере вернет не 0/1, а ключик для расшифровки).
либо портят все насмерть (т.е. вовсе не предусмотрено восстановление, даже так сказать по факту оплаты)
Ну и попробуйте подобрать даже 512-байтный ключ какой-нибудь эллиптической кривой (не обязательно стандартной кстати), встретимся через сотню лет (сколько там х-тилионов MIPS-лет нужно).
Тут только или свезло (как в вашем случае)… или (правильно настроенный) бэкап спасает…
Ну или 101 способ предотвратить запуск подобной нехорошей софтины (например тот же SRP и ко, если винда).
Вот только не надо про вероятности, интуитивное восприятие и т.п.
Вы кстати не поняли этот парадокс — он говорит как раз про обратное, что совпадения более вероятны, чем интуитивно воспринимается (ибо например для 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-й — и это прошу заметить в секунду.
И крайне важно во втором.
Не страшно… это для своих токма.
Unix epoch (also known as POSIX time or epoch time)
Уточните тип, пожалуйста...
Ну так он выпадает на 12-е (из-за високосности), официально то празднуется все равно 13-го числа, нет? Или он в России все-таки плавающий?
Ну так совпало. Пятница… повод...
Как вариант — разносить по разным доменам (суб-доменам)… + SOP + не юзать кросс-доменные куки ...
Побуду кэпом чуть-чуть...
c -"c++" -"cpp" -"c#" standard libraryНайдите там C++ и ко...
А теперь подумайте еще раз про то, что вы спросили… 70% от чего? (мы еще помним, что TTT монополист, правда?)
Для математиков:70% от трафика != 70% от новостей...И потом:
Это на вскидку, а если подумать то таких сколько...
Ну вы тут немного передергиваете (либо еще не совсем поняли, либо нарочно путаете теплое с мягким): в качестве контр-примера...
Другая аналогия: Телекомпания ТТТ — монополист. Размещая чужой контент в блоке новостей она лишает людей его изготовивших заработка. При этом она не хочет никому ничего отчислять и в случае обращения просто забывает про издателя от слова совсем (т.е. не размещая чужой контент, но и не упоминая его вовсе), при этом снова тем самым лишая людей заработка (а мы помним что ТТТ — монополист).
Вопрос: Как долго ТТТ сможет размещать чужой контент, когда все те люди его создающие пойдут по миру?
Другой вопрос: как при этом затронут интерес другой группы — потребителя (не лишает ли их монополист ТТТ тем самым возможности узнать про новость, чтобы прочитать/посмотреть ее где-нибудь у издателя), а в долгосрочной перспективе и новостей совсем?
Повторюсь, я вовсе не за "копирастию" (по крайней мере в текущем ее виде), но вот так однозначно делить на белых и пушистых (типа "аргументы издателей выглядят слабоватыми") я бы не стал.
А вот это уже хороший вопрос ибо где та граница, когда ссылка остается еще интересна. Если новость сама по себе — новость и выжимки google практически достаточно, то на ту ссыль нажмут единицы.
А там вовсе не про рекламу в прямом смысле — google используется потребителем как агрегатор новостей, и он действительно фактически монополист, т.е. избирательно "выбросив" кого-либо из выборки, он тем самым практически "исключает" издателя для огромной аудитории.
Т.е. понять можно обе стороны:
Нисколько не поддерживая закон в том виде как оно есть, я все же могу понять аргументы обеих сторон. Т.е. проблема действительно есть, другое дело, что возможно решать ее нужно было не обязательно в суде и уж точно не таким "дурацким" законом (имхо).
Оно еще вовсе не закончилось — т.е. этот спор вышел на новый (юридический) уровень.
И как бы там не только Шпрингер, там еще с десяток-другой всяческих контор подвизались...
Т.е. если коротко, то:
Как мне видится — это еще очень на долго...
Статья про это на немецком от марта 2016 — weiter auf Deutsch (и с выключенным адблокером).
Небольшая поправка:
Лимит для RAW = 2000 байт (если MAX_STRING_SIZE = STANDARD)
А это художественное произведение и есть...
Ну вот не откажет, а через год-два "гения" собьет машиной, или он с Эвереста скувыркнётся, тем самым не "удержится". Как вам такая альтернатива?.. Оцените риски?
Тут как-бы стоит не про гениальность соискателя поговорить… Дело вот в чем: написать jvm-ный байт-код (а то и в с десяток других, включая питоний или нативный, ака asm например) смогут возможно многие, и из моего окружения в том числе, но при этом:
А так, да… как красивая история для бложика — возможно (т.е. написано-то и правда красиво, + понты, эго… все дела)…
Но как "реальная" история из жизни, — упаси боже от таких гениев-коллег.
может просто не надо писать баш-скрипты в systemd?
Т.е. я про то, почему это должно быть непременно частью
something.service, а не частью напримерsomething.sh, который отробатывает в ExecStart...IMHO systemd-escape сделана как helper, чтобы писать динамические systemd-скрипты (т.е. не руками, а "машинным" способом).
А чего тут подробнее — 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, порог вхождения много-много выше (как минимум при "сборке" сервера)...
Оно как бы да, но это смотря а) как скомпилированна и б) с каким интерпретатором сравнивать...
Вот вам для сравнения на чистом тикле (tcl, threaded, full-async), jit-интерпретатор в quad-code (если что;)
Ответ запроса чуть побольчее в размере, но не критично (ну headers у меня там многовато, лень править да и throughput тут важнее запрос/сек.)...
Для сравнения то-же (подогнал по размеру) на Elixir (результаты немного лучше чем у вас, я про Latency и ко):
Причем на tcl 2 из 4-х cpu спят, справляется практически 2-мя потоками 30-40% usage (чтобы загрузить на все 100% надо
wrk -t100юзать).на Elixir же — все 4-е ядра под 100% busy и контекст-свич кернел-таймом погоняет.
Так-что реализация тоже важна (я не думаю, что tcl "шустрее" elixir)...
Ну и не компиляторами едиными…
П.С. Go не держу, так что сравнить не можу...
Я могу конечно ошибаться, но думается мне почему-то, что это ASLR (и-или DEP).
Если на машинках, где обоих можно выключить, баг не воспроизводится — оно говорит за-то...
Ну и если да, решения два (кроме как не юзать винду):
Ну или тот-же воркараунд на секции .text (MEM_WRITE как сделал Jason Bell), хотя не сукьюрно оно как-то.
Ну да, в этом конкретном "детском" случае — возможно что-то и получится.
(Хотя гораздо проще тут было бы настроить "прокси" через роутинг к другому серверу, который вернет 1 по заданному адресу)
Однако в основной своей массе — шифровальщики:
Ну и попробуйте подобрать даже 512-байтный ключ какой-нибудь эллиптической кривой (не обязательно стандартной кстати), встретимся через сотню лет (сколько там х-тилионов MIPS-лет нужно).
Тут только или свезло (как в вашем случае)… или (правильно настроенный) бэкап спасает…
Ну или 101 способ предотвратить запуск подобной нехорошей софтины (например тот же SRP и ко, если винда).
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
Вот только не надо про вероятности, интуитивное восприятие и т.п.
Вы кстати не поняли этот парадокс — он говорит как раз про обратное, что совпадения более вероятны, чем интуитивно воспринимается (ибо например для 23-х людей — на самом деле сравниваем 253 возможные пары).
И закроем тему интуитивного восприятия на этом. Расскажите про "день рожденья" кому-нибудь другому (когда поймете).
Теперь по теме: лично видел два одинаковых UUID, созданных на двух разных хостах в одном (правда большом и сильно нагруженном пуле) кластера.
И то было в industries API 80-го уровня. Я бы вам даже имя сказал, но низя (связан подписью о не разглашении)…
Однако с тех пор там та конкретная реализация UUID-api (рандомная кстати, ибо v4) — под строжайшим запретом (бьют по рукам если что).
А так-то да — теоретически невероятно...
Раз уж слово вероятность упало, попробуйте оценить разницу вероятностей:
1) что два каких-то "случайных" 128-ми битных числа будут равны;
2) например в сравнении с вероятностью, что два случайных 52-битных числа + цикличный инкремент (8 бит) про процесс, созданных в течении тех же десяти миллисекунд (48 бит), с одинаковым хэшем (20 бит) взятым от fqdn + thread-id — в результате тоже будут одинаковы;
Вам сразу вопрос: тут фактор времени или количества чисел вообще в выборке важен или нет? Т.е. вопрос два числа из скольких...
Поэтому, сделаем тут некоторые допущения — уточнения условий задачи:
И не забываем что:
Все это абсолютно не градиентно в первом случае, но чисто для оценки порядка:
(1000 * 1000000 * 256 * 100)— уже 2 в 45-й — и это прошу заметить в секунду.И крайне важно во втором.