Странно, что автор сразу зарядил про lua, лично я подумал, а почему это не python или js. Оба два встраиваются довольно просто. А помимо этого имеют богатые библиотеки. Почти уверен, что тот же Js окажется по итогам и более производительным.
Прям всплакнулось, делал похожее на обычных виртуалках в в hyper-v и cygwin (X11 там гораздо функциональней, чем просто буфер обмена, а утилиты — портабельные, ну и opengl работает до определённой степени). Как раз по-моему ConEmu в качестве терминала и использовал, и он уже тогда вполне себе кушал всё что выдаёт ssh хост с tmux/vim. От похаканных шрифтов я по итогу отказался, глазки от этих углов в статус барах лично у меня болят(но это уже с gnu/linux на десктопе).
В узкой сработавшейся команде подобные вещи можно опускать, обычно это происходит постепенно. Главное знать границы где свои а где все остальные. Но вводить новичков будет сложнее а на галерах таки ротация имеет место быть.
Многие сообщества не просто так зовут токсичными, и, иногда это просто позитивный критерий при выборе сообщества, это значит что народ там не тратит время на обиняки.
Интересное чтиво. Самая безнадёга в том, что все там будем в том или ином виде, ибо без унификации всё равно производство не масштабируется, а вещи которые в нужный момент не масштабируются — помирают. И дело даже не в agile а в сути и цели роста любой активности.
Конкретно про индустрию разработки ПО у меня есть такая теория — погонщиками становится в основном кто? Правильно — разработчики, а разработчики привыкли реализовывать свои задачи как? Верно — с помощью программирования на детерменированном, формальном языке с предсказуемыми результатами. И если профессиональных управленцев ещё учат как минимум, что с людьми так не прокатывает, то вчерашний кодер — тащит успешный подход с разработкой DSL(таски и их формат, формат комментариев, прочие правила и ограничения), архитектуры (процессы) и программирует, только уже на тех инструментах, которые ему доступны(доски, митинги). Я вот думаю объекты в ООД проге чувствуют себя ничуть не лучше.
Имхо, тут слегка перепутанно тёплое с мягким, либо переводчик налажал.
Есть ООП — это парадигма программирования, она про интерфейсы в основном, про реализацию архитектуры и удобное/интуитивное API. Есть ООД(OOD) — объектно ориентированный дизайн, и вот это — да про архитектуру(всякие модели акторов и т.п.). Так вот, ничто не мешает упаковывать DOD в ООП API, это может упрощать как поддержку, так и тестирование. Но как совершенно верно заметил автор — эффективный код в наши дни пляшет именно от формата представления состояния ПО.
Жду когда истории типа DeX научатся хотя бы в 4к 60hz и станут побюджетнее. После этого для работы ноут точно перестанет существовать лично для меня а десктоп потеряет дисплей окончательно и будет максимум резервной заменой серверу. Имхо сиё со временем придёт практически для всех в отрасли, дольше всего наверное будут страдать дизайнеры, с другой стороны, время отклика и для них не слишком критично, и насколько я слышал в крупных конторах рендеры всё равно производят на серверах.
опыт создания тестового сервера для тестовых целей.
Тестировать непротестированным — это наше всё.
"Чувак, я не дал себе труда разобраться в том, что ты сделал, но ты явно пиаришь свою поделку тогда как я бы все сделал через tc-netem"
Скорее — чувак, тестировать скорость загрузки по http с помощью http сервера это слегка не точно… Хотя тут конечно всё сильно зависит от требуемой точности.
Вполне себе позиция. Только обсуждать ее мне вообще не интересно. Ну вот вообще.
Тем не менее, 90% обсуждения вокруг этого опуса произошло в выше приведённой ветке;) Ну по крайней мере пока не случился понедельник.
Показали бы как тот же результат получить без написания своего специализированного HTTP-сервера
Дык. Добавляем адрес к петле, шейпим траффик на заданный лимит по скорости на этом адресе, запускаем любой web сервер который умеет выдавать файл произвольного размера в директории /dev/ или в директории куда кинута символическая ссылка на /dev/zero. Вроде я ж с этого и начал?
Аргументации в чем? Если в том, что это "единственно правильный" подход, так её и не будет, поскольку у статьи не было цели показать, что подобные задачи нужно решать таким и только таким образом.
Хотя бы в том, что подход рабочий, как он был протестирован, какая погешность измерений, как точно удаётся выставить ограничение. Вот это всё. Заключение уровня я набросал тут поделку за час, не тестировал но вы мне верьте на слово, что это работает — ну такое себе, у меня симпатии не вызывает например.
Но вы, очевидно, увидели в статье что-то другое, то, о чем я вообще не писал.
Я увидел в статье сомнительный приём показанный широкой аудитории, часть которой свято верит в непогрешимость источника. Куча не очень опытных разработчиков думает, что если на хабре написанно — так обязательно нужно делать, чувак с хабра же так делает. Встречался с этим не раз.
Что еще раз говорит о вашем специфическом восприятии текста. Не нужно было тестировать поведение сервера. Ну вот вообще. Задача была в том, чтобы протестировать клиента.
Вы плохо следите за контекстом дискуссии. Я писал про тестирование вашей разработки. Это действительно интересный и полезный материал, гораздо более интересный, чем притянутое за уши приложение(гвозди, молотки, вот это всё).
Если вы знаете, как такой специализированный сервер собрать меньшими количествами усилий на tc-netem и Python, то напишите свою статью. Наверняка многие разработчики узнают что-то новое.
Согласен, критиковать проще чем создавать контент. Ну я как могу вношу посильный вклад.
Проблема ещё и в том, что в юзерспейсе, да ещё и на прикладном уровне — замер и ограничения по определению менее точные, а куча неопытных разработчиков может принять решение за эталонное и потом будет на собеседовании на серьёзных щщах вещать как это круто.
Ну я не услышал аргументации, а упоминание одного и того же инструмента раз 50 в одном коротеньком тексте слегка напоминает знаете ли… "Покупайте наших слонов, советские слоны самые лучшие слоны в мире".
каждый волен выбирать те инструменты, которые он знает и с помощью которых он может решить задачу быстро и качественно
До определённой степени, думаю. Если бы человечество следовало этому принципу безоговорочно, то каждое поколение изобретало бы колесо раз по 5.
Меня учили, что хорошая статья должна рассматривать альтернативы или указывать на их отсутвие в разделе "мотивация". Ну либо сразу предупреждать, что это из раздела "смотрите как я могу", например, тут проскакивали реализации игры "Жизнь" на CMake или что-то в таком духе.
Также — как разработчику сетевого приложения, крайне рекомендую освоить инструменты вида tshark, ip и tc. Я вот плохо представляю как без подобного тулкита протестировать а как поведёт себя сервер в случае сбоев на строне провайдера например. Вот про что я почитал бы на самом деле — это про методики тестирования и замеров производительности вашего решения(про сам сервер разумеется а не приложение из этой статьи).
Ну не в нём, так не в нём, чего флудить то. Проще сказать почему не взлетит, а ваше решение лучше, если вдруг вы обладаете каким-то тайным знанием, чем ограничение скорости http будет отличаться от такого же ограничения для tcp. На уровень ниже это работало вполне себе точно. Вполне себе допускаю, что велосипед оправдан и чего-то не учёл, однако — аргументации не наблюдается.
Вроде технический ресурс был, место дискуссии имелось, а теперь спрашиваешь у рекламодателя — а чем его решение лучше практически изкоробочных средств, а он только и может что сказать, что мол автор вопроса (то бишь я) ничего не понимаю. Позовите разработчика — может он пояснит?
Наверное, какие-то неудачники из разработчиков ядра linux и coreutils для gnu/linux, а так же — пара полных остолопов трудящихся над стандартной библиотекой пайтон.
Отдавать бесконечную статику разумеется. Например тот же /dev/random, да или даже /dev/zero, что бы cpu не насиловать почём зря.
Я не большой специалист в web технологиях(и пиаре своих поделок), но кажется, что даже:
python -m SimpleHTTPServer
вполне себе сдюжил бы.
Может конечно на прикладном уровне точнее, чем специально обученным инструментом, но вот вопрос — кто вашу наколенную поделку за час написанную протестировал?
tc qdisc add dev lo ingress
ip addr add 127.0.0.42 dev lo # ip for each server
tc filter add dev lo parent ffff: protocol ip u32 match ip src 127.0.0.42/32 flowid :1 police rate 1.0mbit
Дальше биндим любимый веб сервер на заданный адрес и развлекаемся. Так можно ещё и "плохое" соединение тестировать, в том числе и с заданным распределением потери пакетов.
Без быстрого и продуманного переключения окон/приложений/рабочих пространств — оно не годится для профессиональной деятельности большинства труженников IT. Даже если большая часть активности происходит в терминале, переключение на браузер, почту и мессенджер должно миниммизировать переключения контекста.
Ещё — не раскрыта тема терминальных сервисов. Можно ли систему как-то юзать удалённо?
Странно, что автор сразу зарядил про lua, лично я подумал, а почему это не python или js. Оба два встраиваются довольно просто. А помимо этого имеют богатые библиотеки. Почти уверен, что тот же Js окажется по итогам и более производительным.
Всё уже придумали за вас :)
Смотрим рекламу, и слушаем как жужжит куллер. Что только люди не сделают, что бы не ставить qBitorrent.
Прям всплакнулось, делал похожее на обычных виртуалках в в hyper-v и cygwin (X11 там гораздо функциональней, чем просто буфер обмена, а утилиты — портабельные, ну и opengl работает до определённой степени). Как раз по-моему ConEmu в качестве терминала и использовал, и он уже тогда вполне себе кушал всё что выдаёт ssh хост с tmux/vim. От похаканных шрифтов я по итогу отказался, глазки от этих углов в статус барах лично у меня болят(но это уже с gnu/linux на десктопе).
Отличный набор правил.
По-поводу "надоело", "не хочу" и т.п.:
В узкой сработавшейся команде подобные вещи можно опускать, обычно это происходит постепенно. Главное знать границы где свои а где все остальные. Но вводить новичков будет сложнее а на галерах таки ротация имеет место быть.
Многие сообщества не просто так зовут токсичными, и, иногда это просто позитивный критерий при выборе сообщества, это значит что народ там не тратит время на обиняки.
Интересное чтиво. Самая безнадёга в том, что все там будем в том или ином виде, ибо без унификации всё равно производство не масштабируется, а вещи которые в нужный момент не масштабируются — помирают. И дело даже не в agile а в сути и цели роста любой активности.
Конкретно про индустрию разработки ПО у меня есть такая теория — погонщиками становится в основном кто? Правильно — разработчики, а разработчики привыкли реализовывать свои задачи как? Верно — с помощью программирования на детерменированном, формальном языке с предсказуемыми результатами. И если профессиональных управленцев ещё учат как минимум, что с людьми так не прокатывает, то вчерашний кодер — тащит успешный подход с разработкой DSL(таски и их формат, формат комментариев, прочие правила и ограничения), архитектуры (процессы) и программирует, только уже на тех инструментах, которые ему доступны(доски, митинги). Я вот думаю объекты в ООД проге чувствуют себя ничуть не лучше.
Имхо, тут слегка перепутанно тёплое с мягким, либо переводчик налажал.
Есть ООП — это парадигма программирования, она про интерфейсы в основном, про реализацию архитектуры и удобное/интуитивное API. Есть ООД(OOD) — объектно ориентированный дизайн, и вот это — да про архитектуру(всякие модели акторов и т.п.). Так вот, ничто не мешает упаковывать DOD в ООП API, это может упрощать как поддержку, так и тестирование. Но как совершенно верно заметил автор — эффективный код в наши дни пляшет именно от формата представления состояния ПО.
[-|||-] конечно же, но — "Папка у тебя один, а в файловой системе — директории" ©.
Дабы два раза не ходить — пруфец.
Жду когда истории типа DeX научатся хотя бы в 4к 60hz и станут побюджетнее. После этого для работы ноут точно перестанет существовать лично для меня а десктоп потеряет дисплей окончательно и будет максимум резервной заменой серверу. Имхо сиё со временем придёт практически для всех в отрасли, дольше всего наверное будут страдать дизайнеры, с другой стороны, время отклика и для них не слишком критично, и насколько я слышал в крупных конторах рендеры всё равно производят на серверах.
Вот это, уже аргумент, я почти доволен.
Тестировать непротестированным — это наше всё.
Скорее — чувак, тестировать скорость загрузки по http с помощью http сервера это слегка не точно… Хотя тут конечно всё сильно зависит от требуемой точности.
Тем не менее, 90% обсуждения вокруг этого опуса произошло в выше приведённой ветке;) Ну по крайней мере пока не случился понедельник.
Дык. Добавляем адрес к петле, шейпим траффик на заданный лимит по скорости на этом адресе, запускаем любой web сервер который умеет выдавать файл произвольного размера в директории
/dev/или в директории куда кинута символическая ссылка на/dev/zero. Вроде я ж с этого и начал?Хотя бы в том, что подход рабочий, как он был протестирован, какая погешность измерений, как точно удаётся выставить ограничение. Вот это всё. Заключение уровня я набросал тут поделку за час, не тестировал но вы мне верьте на слово, что это работает — ну такое себе, у меня симпатии не вызывает например.
Я увидел в статье сомнительный приём показанный широкой аудитории, часть которой свято верит в непогрешимость источника. Куча не очень опытных разработчиков думает, что если на хабре написанно — так обязательно нужно делать, чувак с хабра же так делает. Встречался с этим не раз.
Вы плохо следите за контекстом дискуссии. Я писал про тестирование вашей разработки. Это действительно интересный и полезный материал, гораздо более интересный, чем притянутое за уши приложение(гвозди, молотки, вот это всё).
Согласен, критиковать проще чем создавать контент. Ну я как могу вношу посильный вклад.
Подумал ещё, и понял откуда всё же растёт моё недовольство вашим подходом.
Если у вас в руках молоток, то всё вокруг начинает казаться гвоздём. ©
Проблема ещё и в том, что в юзерспейсе, да ещё и на прикладном уровне — замер и ограничения по определению менее точные, а куча неопытных разработчиков может принять решение за эталонное и потом будет на собеседовании на серьёзных щщах вещать как это круто.
Ну я не услышал аргументации, а упоминание одного и того же инструмента раз 50 в одном коротеньком тексте слегка напоминает знаете ли… "Покупайте наших слонов, советские слоны самые лучшие слоны в мире".
До определённой степени, думаю. Если бы человечество следовало этому принципу безоговорочно, то каждое поколение изобретало бы колесо раз по 5.
Меня учили, что хорошая статья должна рассматривать альтернативы или указывать на их отсутвие в разделе "мотивация". Ну либо сразу предупреждать, что это из раздела "смотрите как я могу", например, тут проскакивали реализации игры "Жизнь" на CMake или что-то в таком духе.
Также — как разработчику сетевого приложения, крайне рекомендую освоить инструменты вида tshark, ip и tc. Я вот плохо представляю как без подобного тулкита протестировать а как поведёт себя сервер в случае сбоев на строне провайдера например. Вот про что я почитал бы на самом деле — это про методики тестирования и замеров производительности вашего решения(про сам сервер разумеется а не приложение из этой статьи).
Ну не в нём, так не в нём, чего флудить то. Проще сказать почему не взлетит, а ваше решение лучше, если вдруг вы обладаете каким-то тайным знанием, чем ограничение скорости http будет отличаться от такого же ограничения для tcp. На уровень ниже это работало вполне себе точно. Вполне себе допускаю, что велосипед оправдан и чего-то не учёл, однако — аргументации не наблюдается.
Вроде технический ресурс был, место дискуссии имелось, а теперь спрашиваешь у рекламодателя — а чем его решение лучше практически изкоробочных средств, а он только и может что сказать, что мол автор вопроса (то бишь я) ничего не понимаю. Позовите разработчика — может он пояснит?
С удовольствием расширю свой кругозор с помощью ваших пояснений.
Наверное, какие-то неудачники из разработчиков ядра linux и coreutils для gnu/linux, а так же — пара полных остолопов трудящихся над стандартной библиотекой пайтон.
Отдавать бесконечную статику разумеется. Например тот же
/dev/random, да или даже/dev/zero, что бы cpu не насиловать почём зря.Я не большой специалист в web технологиях(и пиаре своих поделок), но кажется, что даже:
вполне себе сдюжил бы.
Может конечно на прикладном уровне точнее, чем специально обученным инструментом, но вот вопрос — кто вашу наколенную поделку за час написанную протестировал?
Ну что-то в духе:
Дальше биндим любимый веб сервер на заданный адрес и развлекаемся. Так можно ещё и "плохое" соединение тестировать, в том числе и с заданным распределением потери пакетов.
Казалось бы, при чём тут
man 8 tc-netem?Я так понял — всё юзабилити мышевозное?
Без быстрого и продуманного переключения окон/приложений/рабочих пространств — оно не годится для профессиональной деятельности большинства труженников IT. Даже если большая часть активности происходит в терминале, переключение на браузер, почту и мессенджер должно миниммизировать переключения контекста.
Ещё — не раскрыта тема терминальных сервисов. Можно ли систему как-то юзать удалённо?