1. Куча / Говнокод #23441

    +1

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    http://www.vlang.ru/
    Описание нового языка программирования V.
    V является скриптовым, компилируемым в коды x86, языком со строгой типизацией и без ссылочной арифметики.
    V адаптирован для работы в CGI режиме с сервером Apache.
    Исходный код хранится в файле с расширением vsc. Компилятор в случае отсутствия ошибок создает файл с расширением v32, а также 2 служебных файла с расширениями vif и vsl.

    http://www.vlang.ru/
    Описание нового языка программирования V.
    V является скриптовым, компилируемым в коды x86, языком со строгой типизацией и без ссылочной арифметики.
    V адаптирован для работы в CGI режиме с сервером Apache.
    Исходный код хранится в файле с расширением vsc. Компилятор в случае отсутствия ошибок создает файл с расширением v32, а также 2 служебных файла с расширениями vif и vsl.

    Запостил: SemaReal, 22 Октября 2017

    Комментарии (119) RSS

    • http://www.vlang.ru/
      Описание нового языка программирования V.
      V является скриптовым, компилируемым в коды x86, языком со строгой типизацией и без ссылочной арифметики.
      V адаптирован для работы в CGI режиме с сервером Apache.
      Исходный код хранится в файле с расширением vsc. Компилятор в случае отсутствия ошибок создает файл с расширением v32, а также 2 служебных файла с расширениями vif и vsl.
      Ответить
    • Сайт охуенный. На V написан?
      Ответить
      • Похоже на то.

        Server:Apache/2.2.24 (FreeBSD) DAV/2 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_ssl/2.2.24 OpenSSL/0.9.8x

        FreeBSD + Apache + FastCGI в 2017 году.
        Автор языка мой кумир теперь.
        Ответить
        • nslookup vlang.ru
          Name:    vlang.ru
          Address:  77.241.28.30


          http://77.241.28.30/
          Ответить
          • веб-панелька стоит. Это для тех кто не умеет настраивать сервер через командную строку?

            Странно для человека, который разработал свой язык для CGI
            Ответить
            • Может быть, из коробки с виртуальным сервером поставлялось, а удалять лень?
              Ответить
              • С петушиным хостингом скорее, а удалять нельзя.
                > FreeBSD
                А ведь V же шиндошс-онли?
                Ответить
                • почему шиндуос онли? Потому что hyper-v?
                  Ответить
                  • Дык там конпелятор только в exe. Исходников его я не нашел.
                    И сорцы в UTF-16.
                    Ответить
                    • Компилятор под windows, а генерирует он ELF файлы? Ну или как иначе запустить CGI на FreeBSD?

                      Или он только для Apache на Windows? Ничего не понятно.
                      Ответить
                      • Да там, похоже, какой-то свой православный байт-код, я сильно не вникал. Запускается это говно через тот же comp.exe. В архиве кроме примеров и этого конпелятора ничего нет.
                        Ответить
          • https://stat.ripe.net/77.241.28.30

            Хостится в сети 77.241.28.0/23 (SALON2116-NET) фирмы OOO SALON 2116 Electronic Post Office.

            Зарегана KURSKTELECOMом

            http://salon2116.ru/

            Похоже что товарищ работает в этом салоне, и там же сервер поднял.

            Нихуя себе! Зачем им такая большая сеть?
            Ответить
        • # FreeBSD + Apache + FastCGI в 2017 году

          А что не так, поясните незнающему.
          Ответить
          • Apache не нужен, если только у тебя нет специально написанного под него модуля. Nginx рулит.

            FreeBSD не нужен вообще.
            Ответить
            • # Apache не нужен

              Почему же это? По моему, хорошая вещь (Apache + Nginx).

              # FreeBSD не нужен

              Никогда не видел его вживую, какая у него self-killer фича?
              Ответить
              • Nginx самодостаточен. Apache не нужен, за исключением тех случаев, когда нужно использовать бинарные модули Апача, аналогов которых нет для Nginx.
                Ответить
              • >>Apache + Nginx
                Зачем?

                >> какая у него self-killer фича?
                Отсутствие docker, отсутствие поддержки серьезных вендоров (в отличие от linux), исчезающе малое количество админов (все мигрировали на линукс), меньше база драйверов
                Ответить
                • На самом деле у меня есть подозрение, что связку Apache + Nginx, Apache + Lighttpd и т. п. используют по привычке.

                  Когда-то давным-давно из-за неповоротливости Апача в условиях хайлоада перед ним ставили лёгкий, но малофункциональный сервер.

                  Потом появились Nginx, Lighttpd, Cherokee, FastCGI, WSGI, SCGI, PCGI и ещё куча вореций. Потребность в Апаче и в его модулях снизилась, а привычка осталась.
                  Ответить
                  • ...а доктор ватсон без этого уже не мог (с)

                    Когда-то не было и nginx, и перед apache ставили squid в режиме reverse proxy:)

                    Мне кажется что в идеальном мире (С) надо запускать контейнер с приложением, а nginx ставить перед ним ради отдачи статики, безопасности, кеширования, реализации https итд.

                    Контейнер с приложением это gunicorn/python или tomcat/java итд.
                    Связь по unix domain sockets или tcp.

                    В более тяжелых случаях можно вбандлить все в сервер (mod_wsgi в apaсhe или какой-то там модуль на nginx), но потом питон отдельно от nginx или апаче не обновить, а джава вовсе в них не бандлится (правда там вроде есть нативный http листенер в томкате).
                    Ответить
              • > Никогда не видел его вживую, какая у него self-killer фича?

                google: FreeBSD jail

                Self-killer фича FreeBSD — это встроенная система виртуализации, позволяющая создавать VPS без сторонних средств.
                Ответить
                • у линуха тоже есть и chroot и cgroups и виртуализация ресурсов
                  только у линуха это выстрелило в docker, а jail так и остался джейлом
                  Ответить
                  • > cgroups

                    ты хотел сказать "lxc".

                    аналога jail'ам в линухах нет.

                    но в тему "BSD + Apache", вы в курсе что эту строчку можно ручками переписывать? у меня знакомые на ихнем M$IIS'е прописывали "Linux + Apache", и говорили что число атак падало до половины обычного.
                    Ответить
                    • > знакомые на ихнем M$IIS'е прописывали "Linux + Apache"

                      Овца в волчьей шкуре
                      Ответить
                      • скорее "как рыбе зонтик". но если помогает от скрипт кидди - которые не умеют фингерпринтингом пользоватся - то почему бы и нет. но от ботнетчиков это не спасет.

                        ЗЫ это было в тему что этой строчке доверять сильно не стоит.
                        Ответить
                    • lxc это виртуализация поверх namespaces и cgroups

                      а namespaces это тот же самый jail, не?
                      Ответить
                      • хез. я еще ни разу новые namespace'ы не трогал. в прошлом они изолировали только файловую систему. но вики теперь говорит что они и пиды и даже сети тоже изолируют, что для меня новость. из того что я знаю/видел, это очень сильно аналогично джэйлам.

                        вот тут пишут больше: https://news.ycombinator.com/item?id=13982620

                        в прошлом линуксоиды дружно кричали "VMы все равно секурнее" (ну это еще было до первых багов/дырок позволявших из виртуалки гипервайзор трогать) и у меня тогда просто сложилось впечатление что на аналоги джэйлов просто забили. почему и не интересовался.
                        Ответить
                        • Интересная возможность Docker
                          1. Наследуешь от какого-нибудь mysql:latest образ
                          2. Позиционируешь его как какой-нибудь "специально настроенный для Bitrix", и набираешь за счет нубья и стековерфлоуных копипастеров сотни звёздочек на Dockerhub, все ставят в проект superkontora/superBitrixMySqlBesplatno:latest
                          3. Выпускаешь обновление своего образа, в котором в Dockerfile курлом выкачиваешь любой посторонний код, собираешь его и вставляешь бекдор или просто отправляешь себе на почту таблицу users.
                          Ответить
                        • Ты что-ли проспал докер-революцию?

                          Сейчас все линуксоиды дружно дрочят на докер, а там namespaces и полное ограждение всех ресурсов: и процессов и сокетов итд.

                          Каждый как маленькая вирт машинка со своим init, но все на одном ядре.
                          Ответить
                          • > Ты что-ли проспал докер-революцию?

                            Да. Полностью. И меня это даже не напрягает.

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

                            С другой стороны, я там все равно ничего интересного не видел, поэтому сильно и не напрягало.
                            Ответить
                            • На VM был вагрант, который под капотом ставил виртуал бокс)

                              Docker это именно легкая виртуализайия (cgroups + namespaces).
                              Есть native docker под винду и мак, который конечно же ланчит виртуалку (на винде юзает hyper-v).

                              Это сейчас очень большой хайп. Люди делают image с nginx, image с redis и image с каким-нить gunicorn, и разхворачивают их где-нить в облаке где оркестрейшен делает 20 копий контейнера на разных серверах и все довольны.

                              Причем в каждом контейнере может быть вообще свой дистриб и своя либси и считается что это стабильно и хорошо.
                              Ответить
                              • шило на мыло. но привлекательность я понимаю.

                                с точки зрения безопастности это конечно мрак, т.к. увеличивается количество конфигураций софта. ну да админы всегда жалуются что им работы мало.
                                Ответить
                                • не совсем шило: работает-то оно быстрее, чем полноценный VM.

                                  Часть конфигурации ложится теперь на плечи девелопера: он должен составить Dockerfile, то-есть уметь поставить нужный софт под нужную ОС. Галерщики и юниоры, не умеющие man apt-get, плачут.

                                  На самом деле говна там тоже хватает. Например там проблема init.
                                  В никсах, как ты верно знаешь, если процесс завершился а его родитель дал дуба не успев waitpid, то процесс становится zombie, и его репарентит init и хоронит.

                                  Ну вот в докере заместо initа говноскрипт который написал какой-нить веб-программист когда собирал image, и конечно он не в курсе про эту проблему. В итоге в контейнере могут плодиться зомбаки
                                  Ответить
                                  • > не совсем шило: работает-то оно быстрее, чем полноценный VM.

                                    а. я мысль не раскрыл.

                                    докер это просто другой метод распространения софта.

                                    и как следствие заменяет в какой-то степени apt/yum (и launchpad).

                                    поэтому то у меня в голове сразу последствия для безопастности всплыли: одно из оснований централизированого серверного подхода apt/yum это раздача секурити апдейтов, и гарантии что эти апдейты с остальной системой совместимы.
                                    Ответить
                                    • Другой способ, не зависящий от окружения.

                                      Одному контейнеру нужен python3.6 а другому последний OpenSSL. А у тебя centos 7 и там нет ни того, ни другого. Что делать?
                                      Ставить левый реп? Не секурно!

                                      А с контейнерами это не проблема.

                                      Проблема с безопастностью внутри контейнера конечно есть: теперь программист отвечает за то, чтобы у него были запатченные либы. С другой стороны дыра в контейнере сломает конкретное приложение а не ос, но через приложение можно пол системы поломать.

                                      Думаю что админы должны настороженно воспринимать докер, примерно как если бы все программы статически линковали бы в себя все либы
                                      Ответить
                                      • > [...] примерно как если бы все программы статически линковали бы в себя все либы

                                        "history repeating itself" (c)

                                        > теперь программист отвечает

                                        лопата. смеятся здесь.
                                        Ответить
                                        • Ну так DevOps же. Программисты собирают сервера в докере, админы программируют виртуалки на teraform, смешались люди и кони, нет?
                                          Ответить
                                          • > смешались люди и кони, нет?

                                            нет. обычная повсеместная схема, где никто ни за что не отвечает.

                                            технологии нужные. когда хайп пройдет будет видно какая от них польза.
                                            Ответить
                              • Да заебали со своим докером. Пихают его даже туда, куда не надо.
                                Ответить
                • # Self-killer фича FreeBSD — это встроенная система виртуализации, позволяющая создавать VPS без сторонних средств.


                  Но что же в этом плохого?
                  Ответить
                  • Она хороша... тем, что она «из коробки». Бонусом является то, что все драйвера расшарены. Владелец виртуальной машины не может управлять драйверами.

                    Если нужен больший уровень изоляции, приходится использовать сторонний гипервизор (KVM, Xen) — в общем, как в Линуксе или в любой другой ОС.
                    Ответить
                  • Он перепутал killer и self kiling:)

                    Я могу сказать за что FreeBSD любили хостеры и провайдеры бСССР в 90-х (в нулевых уже любили по инерции)

                    1) Handbook. На вопрос "как включить foo?" фря отвечала главой книжки с примерами, а у большинства линуксовых дистров надо было читать шелскрипты и разбираться в писанине старого админа.

                    2) Base system. Пока линуксовые дистры были сборной солянкой из ядра, гну, и тысяч утилит собранных рукастенькими школьниками, у фри была base system которую писали и собирали именно под конкретную фрю. Неожиданностей там было меньше.

                    3) Порты: бздя умела поставить нужный софт с зависимостями, стянуть его с Интернета и собраться как нужно. Из линухов это умел только debian apt-get (yum не было у редхата тогда).

                    4) BSD была хорошо известна и понятна людям в унивреситетах (они видели bsd 4.3 всякие итд) а линукс для них была непонятная хуйня.

                    Но всё это стало не важно с появлением достаточно стабильных и документированных дистрибутивов linux, у которых появились хорошие системы для работы с пакетами, хендбуки итд.

                    Чисто для истории:
                    1) Как только фря релизнулась от нее отпочковалась группа товарищей во главе с Тео которая хотела портировать BSD на другие платформы. Так появилась NetBSD.
                    2) Тео послал нахуй пользователей, за что был выгнан и сделал свой проект. Так появилась OpenBSD.
                    3) В 2003 году чуваку не понравилась поддержка SMP в FreeBSd, он форканулся и сделал DragonFlyBSD.

                    Все эти системы существуют до сих пор.
                    Ответить
                    • > 4) BSD была хорошо известна и понятна людям в унивреситетах (они видели bsd 4.3 всякие итд) а линукс для них была непонятная хуйня.

                      это все еще остаётся фактором. линукс проник в систему образования - но большинство системщиков и сетевиков все равно сидят на бсд.

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

                      бсд начала гнатся за линухом, и там тоже читабельность/этц пошла в низ, но все равно все еще лучше чем на линухе.

                      ЗЫ
                      > 1) Handbook. На вопрос "как включить foo?" фря отвечала главой книжки с примерами, а у большинства линуксовых дистров надо было читать шелскрипты и разбираться в писанине старого админа.

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

                        тут прошлый админ так написал
                        там этак
                        тут на перле
                        там на баше

                        --а как работает foo?
                        --а посмотри по коду, я не помню уже

                        нет уж! лучше хендбук!
                        Ответить
                      • зы:

                        зато ебля со скриптами очень хорошо обучала

                        в слаке пока rc.* прочитаешь -- так вся загрузка как на ладони

                        а во фре можно было крутить rc.conf годами и не понимать что там под капотом
                        Ответить
                        • Что такое хендбук?
                          Ответить
                          • толстая, умная книжка в которой написано как канонiчно использовать ОС
                            Ответить
                            • Дай ссылку на хендбук по линуксу и по фре.
                              Ответить
                              • https://wiki.gentoo.org/wiki/Handbook:Main_Page
                                https://www.freebsd.org/doc/handbook/
                                Ответить
                                • еще одно популярное место:

                                  https://wiki.archlinux.org/index.php/General_recommendations

                                  в книгу никто не пытался делать, но сравнимо.
                                  Ответить
                              • RH handbook
                                https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/index

                                Freebsd handbook
                                https://www.freebsd.org/doc/handbook/
                                Ответить
                            • Да кому он нужен в 2к17, когда есть forum.ubuntu.ru
                              Ответить
                              • Мощный форумс какой
                                http://forum.ubuntu.ru/index.php?topic=232193.0
                                Ответить
              • > Почему же это? По моему, хорошая вещь (Apache + Nginx).

                Есть вещь еще лучше! Просто nginx, без Apache. Да даже если из этих двоих nginx вычеркнуть, то же будет лучше.
                Ответить
            • А отдельно апач почему хуёв?
              Ответить
              • «Надуманная» проблема C10k.
                Ответить
                • она и на самом деле от части надумана. редкий сервак - с пыхом -больше сотни сессий может поддержать. и к реализации httpd это отношения не имеет. даже на статической отдаче, может только сейчас до 10К соединений дошли. но потом - бам! - случился SSL, и все опять слегка в унитазе.
                  Ответить
                  • А потом случился SPDY, и из унитаза кто-то попал в субканализацию.
                    Ответить
                    • SPDY был буквально переименован в HTTP/2. так что мы все там будем.
                      Ответить
                  • При чем прихуярить его оказалось жизненно важно к каждой ссаной визитке и лендингу.
                    https://гермес-потолки.рф/ - хакерская группа Анонимус уже третий год пытается вычислить, у кого заказал натяжной потолок Валера из Краснодара.
                    Ответить
                    • Создатели недобраузера год назад сообщили, что их поделка будет помечать ужасным красным значком сайты, не использующие https:
                      https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

                      После чего владельцы сайтов кинулись подключать SSL, боясь потерять бо́льшую часть аудитории, доверяющую рекламе.

                      Зато когда (не)браузер показывает зелёный замочек, пользователь спокоен, даже если сайт на самом деле дырявый или фейковый.
                      Ответить
                    • там letsecnrypt же, а это нахалву
                      Ответить
                  • вы таки хотите сказать, что сервер тратит серьезные ресурсы на TLS?
                    Ответить
                    • во-первых, сервер тратит кучу ресурсов на само веб-приложение, к которому пользователь доступается.

                      во-вторых, TLS хэндшейк это как минимум 3 дополнительных сообщения между сервером и клиентом (вместе с TCP - минимум 6 сообщений для хэндшейка). не говоря уже о тормозах генерации ключей для сессии и самого шифрования. однозначно не ускоряет коммуникацию.
                      Ответить
                      • какую разницу несет количество сообщений в хендшейке для общего количества соединений, которые выдерживает сервер?
                        Ответить
                        • больше сообщений == дольше живет соединение == больше соединений надо держать в памяти == больше памяти расходуется/все слегка медленее работает.

                          ну и самое очевидное: больше пакетов == больше прерываний == еще медленее все работает. (на некоторых больших системах народ 1-2 кора проца выделяет чисто на обработку прерываний.)
                          Ответить
                          • Ребят, вы там спите хоть что ли время от времени и не пытайтесь из ничего выдуть слона.
                            Ответить
                            • слона? лол. ignorance is bliss.
                              Ответить
                              • Ты сейчас говоришь, что есть корреляция между количеством пакетов в соединении и тем, сколько соединений одновременно может держать сервак. Это примерно как говорить что если повозка в среднем проезжает 1200км, а не 1000, то на одной дороге может уместиться меньше таких повозок.
                                Ответить
                                • Сервак может прожевать ограничнное количество пакетов в секунду, так что связь есть.
                                  мимо проходил
                                  Ответить
                                  • Так эти шесть пакетов-то не прибавляются к тем остальным пакетам в секунду, что уже есть и не увеличивают bandwidth. Они просто удлиняют размер сессии. Не было бы хэндшейка - обменивались бы в этот момент времени теми пакетами, которые идут за хэндшейком.
                                    Ответить
                                • это как бы азы сетевых архитектур.

                                  правильная аналогия. в конце дороги стоит контрольный пункт. чем больше в конвое машин, тем меньше конвоев за день контрольный пункт может пропустить. (дорога == сеть, к.пункт == сервак, машина == пакет, конвой == соединение.)
                                  Ответить
                                  • мы говорим не про то, сколько конвоев целиком пройдет, а сколько полос на дороге прямо сейчас, привет
                                    Ответить
                                    • при чем тут пропускная способность?

                                      какая бы у тебя пропускная способность не была, задержки в узких местах все равно остаются. и ты от них никуда не денешься. дольше задержки - больше пакетов в полёте - больше ресурсов нужно что бы держать эти пакеты в полёте. где-то же они должны лежать.

                                      речь идет о том сколько пакетов может "въехать" и "выехать" на сервак. и сколько одновремменно может находится на серваке в полёте (до того как их приложение вычитало). на это все есть ограничения - и из-за техники, и из-за безопастности.

                                      привет.
                                      Ответить
                                      • > при чем тут пропускная способность?

                                        обсуждаем значит проблему С10К и влияние TLS на количество одновременно обрабатываемых соединений
                                        Ответить
                                        • привет.

                                          ... и при чем тут пропускная способность?

                                          ты вообще понимаешь что там под капотом происходит? от клиента до сервака, и назад до клиента?

                                          либо почитай про сети. или помедитируй над цитатой: "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." это тебе вся мудрость о сетях в одном предложении (corollary & orthogonal cases в качестве домашнего задания).
                                          Ответить
                          • Из-за TLS соединение живёт дольше. Из-за SPDY (HTTP/2) оно будет жить ещё дольше, потому что по SPDY за один запрос вместе со страницей могут отдаваться и все вложенные в неё картинки.

                            Из-за всего этого проблема количества соединений становится всё актуальнее. Следовательно, Апач не нужен, потому что он держит меньше соединений, чем nginx.
                            Ответить
                            • > Из-за всего этого проблема количества соединений становится всё актуальнее.

                              наоборот: теперь браузеру не надо открывать 4-8 соединений с сервером - он может обойтись только 1-2.

                              > Следовательно, Апач не нужен, потому что он держит меньше соединений, чем nginx.

                              давно этим не страдал. в те времена lighthttpd & nginx умели только базовый минимум фич, и буквально ничего кроме тупой отдачи не умели. basic авторизацию, права доступа или извраты с виртуальными хостами они не умели - не говоря уже о продвинутых фичах HTTP/1.1 или 1.2 (тот же geoip тогда вошёл в моду).

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

                              основная оптимизация у многих хвастливых серваков тех времен было глупое отключение по умолчанию (или принципиальное неумение вести) access.log (и всех остальных логов). попробуй что либо поразрабить или поддержать когда ты вообще не в курсе что клиент серваку посылает - и посылает ли вообще.
                              Ответить
                              • >>наоборот: теперь браузеру не надо открывать 4-8 соединений с сервером - он может обойтись только 1-2.


                                Привет, друзья! Я пишу вам из далёкого 1999го года. У нас тут изобрели новый протокол: HTTP 1.1.

                                Там есть заголовок Keep-Alive, который позволяет переиспользовать TCP сессию для всех запросов на странице, так что теперь браузер может держать N (порядка четырех) коннектов TCP и не делать хендшейк (syn, ack, syn-ack) на каждую ёбаную jpgшку.

                                Просто у нас всё равно надо слать GET (хоть и по тгому же соединению) а в спиди можно не слать.
                                Ответить
                                • Привет, друзья! Я пишу вам из далёкого 2005го года. У нас тут изобрели новую примочку: CDN!

                                  Каждая поибенька теперь лежит на своём выделенном серваке.

                                  ЗЫ про кип-алайв ты прав. но народ уже даже в 1999 - до цдн-ов - ресурсы по разным сервакам раскладывал. и в те времена даже в мозилле кип-алайв был отключен по умолчанию, потому что только апчиха его правильно и делала - и определить тип сервака бравзеру невозможно. IE в принципе кип-алайв не умел хез сколько лет.
                                  Ответить
                                  • А у нс в 2017-м уже не лежит, потому что все компилируют (ну окей, обфусцируют и аглифицируют) в один бандл. Так работает webpack, например.

                                    А вот с графикой у нас стало по-хуже: в вашем 2005-м все иконки лежали в спрайте (png или gif) и отображались позицинированием. И таблица цветов у них была общая.

                                    А у нас теперь в моде SVG (ибо вектор ресайзится) и вместо спрайта у нас 150 файлов. Хорошо что есть спиди
                                    Ответить
                                    • гигагерцы и гигабиты нам даны что бы их разбазаривать! ...иначе бы intel & amd остались бы без работы ;)
                                      Ответить
                                • С другой стороны, Keep-Alive приводит к большому количеству одновременно открытых соединений.
                                  Ответить
                                  • Keep-Alive --да
                                    Но . Это всё равно лучше, чем гонять хендшейк на каждую картину по 500 байт.

                                    Кроме того TCP может подстраивать размер окна чтобы оптимально (или не оптимально, в зависимости от алгоримта, которых там дофига разных) юзать пропускную способность. Так что долгая сессия, через которую переслали много данных, в целом более лучше чем 100 мелких сессий на 100 байт каждая.
                                    Ответить
                                    • не совсем. одна сессия лучше чем сто. но две-три сессии будут лучше чем одна, потому что можно параллелить. современные сети они не только широкие, но и длиные: задержки при передаче через одно соединения будут накапливатся. на 2-3 соединениях ты буквально эффект задержек на 2-3 делишь.
                                      Ответить
                    • Сервер тратит очень серьезные ресурсы на тлс. В опенссл каждая сессия жрет дестяки киллобайт памяти, а хендшейеки жрут цпу как не в себя.
                      Ответить
                    • Да, но есть нюансы.

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

                      По-други современные процы умеют много гитик (avx2, на пример): https://software.intel.com/en-us/articles/improving-openssl-performance (нужен свежий Openssl конечно, time to upgrade!!)

                      Во времена моей молодости TLS стоил так дорого, что люди покупали хардварные реализации на которых он терминировался, и даже всякие mail.ru не юзали его ровно по причине тяжеловесности.

                      А сейчас всем похуй. Конечно, если ты gmai. или facebook то эта нагрузка для тебя важна (у гугла кстати свои протоколы, которые умеет хром), но если у тебя 1000 человек в день то поверь: TLS не будет твоим ботлнеком.

                      И наконец стоит сказать что у многих сурезных облаков TLS реализован их собственными средствами (Amazon ALB, например) и тебе сугубо похуй какие он там ресурсы ест.
                      А амазон может его RSA хоть на ASIC реализовать, у них много ресурсов.


                      Короче, не стоит отказываться от TLS если только бенчмарки не сказали что на него тратится 80% CPU
                      Ответить
                      • глубоко не ковырял, но слышал что много больших сервисов пользуются elliptic curve потому что в разы быстрее.
                        Ответить
                        • ЕМНИП история была примерно такая: общий ключ можно вывести из RSA, но это не секурно. Лучше чтобы он был случайный и нигде не сохранялся.
                          Для этого заюзали диффи хельмана, и вот DH наэлиптических кривых оказался очень шустр.

                          Теперь все юзают ECDH: elliptic curves DH
                          Ответить
    • Importozameschenie
      Ответить
    • Ебать, вот это синтаксис! По сравнению с этим, крестовая метушня выглядит просто-таки идеально лаконичным кодом.
      Ответить
      • У меня только один вопрос - что такое "крестовая метушня"?
        Я согласен, что что угодно по сравнению с VLang будет идеально лаконичным кодом, просто интересно с чем у вас поднялась рука VLang сравнить?
        Ответить
        • Добрый вечер. Вы автор языка vlang?

          "Крестовая метушня" это метапрограммирование с помощью шаблонов на языке С++, воспетое еще Александреску
          Ответить
          • Еще констэкспры.
            Ответить
            • Констэкспры - ересь, которая пытается пошатнуть основы каноничной метушни.
              Ответить
              • template< T< Полностью, < поддерживаю >, "!" >, S< Метушня< без< "< < < > > >" >, "-", < ересь< ",", позорящая >, настоящее< Искусство, "!" > > > >
                Ответить
                • Только истинный Метух заметит в сообщении выше отсутствующую '>'.
                  Ответить
                  • Не считаю себя фальшивым метухом, но мой внутренний компилятор остановился уже на < поддерживаю > и строковых литералах.
                    Ответить
    • http://www.cyberforum.ru/other-lang/thread1402539.html
      Очевидно, у пациента серьёзные расстройства психики. До Мастера Вореций, коеечно, двлеко, но шизофазия из него вытекает прямо-таки потоком. Признаки шизофрении на лицо: навязчивые идеи, несвязное выражение мыслей, обращение и ссылки на несуществующих людей, полная неспособность воспринимать чужие высказывания. По мере прочтения его ответов создаётся впечатление, что разговаривает он сам с собой.
      Ну и его «код», конечно: такое мог написать только человек с полностью протёкшей крышей.
      Ответить
    • Какая красота:
      >>> Сообщение от __py__ 
      >>> А вообще новый язык изучают, чтобы научиться чему-то новому.
      всё новое - это хорошо распиаренное старое.
      
      Когда появился "реакт". Я таки вспомнил начало своего пути - там тоже были подобные трюки. А теперь вот у каждой
      обезъяны на это есть свой взгляд. Жрёт данный подход ресурсы, а профит есть только при минимальном использовании, но
      они ещё не нашли такой вывод. А в дальнейшем придут и разоблачат.
      Ответить
    • > Компилятор в случае отсутствия ошибок создает файл с расширением v32

      А в случае наличия ошибок удаляет исходные файлы?
      Ответить
      • В случае отсутствия ошибок в конпеляторе?
        Ответить
        • https://ghc.haskell.org/trac/ghc/ticket/5905
          Ответить
          • После подобного опыта я начал писать -o something в конце командной строки, а не перед исходниками.
            Ответить
          • ghc -o /*
            Ответить
            • Или так:
              ghc -o /dev/hda1

              P.S. Отправилось со второго раза. После первой попытки ГК выдал: «Application was halted».
              Ответить
              • hda? У тебя правда blkdev вместо libata в 2017 , или ты просто переименовал в udev?
                Ответить
                • Как пропатчить hda под blkdev вместо libata в 2017 через udev?
                  Ответить
                  • а давайте играть в технотрёп?

                    пропатчить hda можно файлом снифером с помощью пароля который хакеры введут в супер-мощную дискету силой три мегабайта в супер-современном нано-микрокомпьютере-вирусе
                    Ответить
                    • Я ваш орхитекторский трёп с бормандом про орхитектуры уже давно пролистываю.
                      Ответить
                      • Конно-железная, или попросту называемая конно-лошадиная дорога состоит из нутра, верхотуры и конно-железных правил. Нутро стоит пять копеек, верхотура три копейки, конно-железные же правила ничего. Первое дано человечеству для удобнейшего созерцания кондукторских нравов, вторая - для засматривания по утрам в декольтированные окна вторых этажей, третьи же для их исполнения. Правила эти суть следующие. Не конка для публики, а публика для конки. При входе кондуктора в вагон публика должна приятно улыбаться. Движение вперед, движение назад и абсолютный покой суть синонимы. Скорость равна отрицательной величине, изредка нулю и по большим праздникам двум вершкам в час. За схождение вагона с рельсов пассажир ничего не платит.
                        Ответить
                • У истинных гуру вообще /dev/ad0s1a
                  Ответить
          • I'm just learning Linux and I mistakenly passed the "rm" argument to bash instead of "ls". When combined with the "rf" argument (which I also mistakenly supplied, thinking of russian federation), this unlinks the file.
            Ответить

    Добавить комментарий