Посмотрел на календарь только что… 2019 же вроде, не?
curl http://my.site &> file
… можно, конечно, но только для тех случаев, когда речь идёт не о постоянном обслуживании. Примерно как соседского кота покормить на время отпуска. Суть в том, что вроде ни к чему об этом на хабр писать.
Вот это уже более справедливо.
Но как редкий, но меткий юзер ТВ скажу — не все каналы с этим перебарщивают. Хотя есть отдельные кадры, конечно, у которых это доходит до сумасшествия.
И Вы сообщаете в интернеты, какое Вы крутое киберсопротивление? Хвастаетесь своей прогрессивностью?
Есть как минимум одно преимущество ТВ даже для крутых харбрахикканов — сетка. Потому что в свободное время, когда зажигается желание посмотреть кино (лично у меня такое редко, но всё же) благодаря интернету можно потратить всё время, выделенное на просмотр фильма, только лишь на его выбор. Порой проще когда решают за тебя.
К слову о собеседованиях, реальной жизни и немасштабируемости на неё OSI — MPLS на каком уровне? Классический вопрос с наглядной демонстрацией неактуальности OSI.
Так, падажжите… профпригодность is questionable, говорите? То бишь такие вещи придумывают низкоквалифицированные идиоты, которых Вы можете так же тончайше и остроумнейше высмеять, как меня?
Bad practices — то, что ждёт рядового студента в будущем ежедневно. Если говорить о программировании, например, то переписывание легаси-кода — это то, за что с наибольшей вероятностью прошлый студент покупает хлеб. Быть знакомым с врагом заранее — неплохой вариант, вообще-то.
Не всегда покатит. Я не спец, но похожий на правду пример «непокатимости» могу привести.
Например, при изучении раздела загрузки ОС — задача на GRUB, нужно изменить ключи загрузки. Тяжело сформулировать конкретную задачу, но можно перекрыть возможность mkinitrd — закрыть простой путь. Да, конкретно в этой задаче содержимое статьи — вряд ли лучший инструмент, достаточно какого-нибудь SELinux, наверное. Но в общем в любом случае задача, в которой инструмент встанет, может всплыть.
Как минимум есть одно.
И на первый, и на второй вопрос ответ — учебный курс по администрированию / инфобезу / etc. Отрестриктить так, чтобы фиксить трабл не получилось с помощью service restart / shutdown now / других нетрушных методов (я надеюсь Вы поняли). А если речь идёт о курсе по инфобезу — то за обход защиты от плюсика в карму до автомата (в зависимости от глубины курса, доброты преподавателя, остальной аудитории).
Это, кстати, более опасный путь, чем вышеописанный в комментариях путь использования мессенджера в состоянии «кота Шрёдингера» — ничего не утверждаю, но на подумать: habr.com/post/181372
Автор знает толк, как грица. Хотя всегда думал, что во фронтенды не идут фрики.
Интересно бы получить ответ на то, почему постгрес медленнее отрабатывает.
И я учёл тот факт, что «полноценной работы с сокетами», например, у самого баша нет. Но при написании описанной мной OS полноценную работу с сокетами можно реализовать, скорее всего, внутри этой OS, как и полноценную поддержку оборудования. Или неполноценную поддержку виртуального оборудования, написанного на том же баше. А может и нельзя и я ничего не смыслю в информатике и вычислительной технике. :)
Всё так — Вы разделили понятия UNIX Tools, UNIX shell и bash. И по DSL всё так, споров 0. Хотя есть один — фор экземпл, если учитывать, что DSL — это не ЯП, то Erlang — это не ЯП. Однако та же вики, на которую Вы ссылаетесь, говорит о том, что Erlang — это ЯП. Взаимоисключающие параграфы? Технически, можно ли использовать Erlang абсолютно без OTP (повторюсь — абсолютно, а не в минимальной мало-мальской его сборке), тем самым отвязав его от термина DSL? Что-то мне подсказывает, что нет. В таком случае Erlang — это ЯП или не ЯП?
Суть в том, что на чистом баше (без использования UNIX Tools) можно написать машину Тьюринга. На нём же можно «распарсить», интерпретировать и выполнить код любого другого языка (конечно, в рамках совместимости с набором команд процессора, на котором это запущено). Это будет сложно, долго, мучительно, бессмысленно из-за скорости работы конечной поделки… но это будет. Возможно, имея что-то минимально-крошечно-юниксовое, способное только запускать баш, читать из /dev/stdin и писать в /dev/stdout и /dev/stderr, можно написать и запустить UNIX/Linux внутри этого на чистом баше. А может даже и Windows, если совсем сойти с ума.
Утрированно, по Вашей логике всё что угодно на баше может быть «не баш, а Си». По-крайней мере интерпретаторы баша, написанные не на Си, мне не встречались.
Таким же макаром какой-нибудь MATLAB — не язык программирования, что для кого-то потенциально звучит как оскорбление.
С учётом того, что в руках есть GCC + Make — можно всё замечательно «забиндить» в баш.
Офтопчег: миллиард раз поднималось, пора в миллиард первый.
Баш, конечно, это оболочка, но по какому критерию это не язык программирования? :) Хоть один аргумент.
Базовый барьер — полноту по Тьюрингу — баш вполне себе проходит.
Стоять на месте — хуже, чем двигаться в обратном направлении? Опять же, очень интересная позиция.
Проблема Вашей аналогии в том, что её и её последствия можно трактовать как «бегущий в обратную от искомой сторону научиться бегать», так и «бегущий в обратную от искомой сторону может убежать так далеко, что стоявший на месте идя пешком в искомую сторону всегда будет ближе к цели, чем развернувшийся бежавший в обратную».
Вы готовы ручаться за то, что сабж — это про «научиться бегать», а не про «стоявший на месте пешком обгонит»?
Весь мой месседж — не большее, чем ИМХО.
Соревновательный элемент хорош в зависимости от возраста.
В возрасте 0-15 он сделает только хуже. Для детей до полового созревания — пока нельзя переключиться на что-то поинтереснее рейтинга — моральными калеками станут все — те, кто будет в конце, в середине, около верхов и вверху. Более-менее способными к выживанию в среде после обучения будет средняк — ребята с конца и около верхов будут обижены на жизнь, ребята сверху словят звезду, средняк будет работать у станка лишённым мотивации к развитию. Оно и сейчас так, но менее взвешенно, потому что рейтинг «оценок в школе», всё же, не является главным — ещё важна социальная значимость и авторитет внутри класса. Со сменой приоритетов начнётся беда.
Естественно, ISPmanager, VestaCP… оно всё не для хайлоада, скорее. Но оно реализует, как минимум, удобный унифицированный аккаунтинг и менеджмент сервисами. И оно не должно мешать тюнить конфигурацию вручную когда это понадобится. Даже если и будет — это легко обойти воркараундом. А вот собирать дефолтный веб-сервер атомарными кусочками — не очень весёлое и не очень оправданное занятие, если он дефолтный. Суть в том, что и на дефолтном веб-сервере неожиданно может выпрыгнуть из-за кустов хайлоад.
1. Я тоже не против панелей управления веб-сервером. Хотя платить за неё деньги не стал бы (как в случае с ISPmgr, но VestaCP поставить очень даже можно — хуже не станет уж точно, и даже абстрагируясь от гуёв это удобно — Веста обладает удобным набором v-...-команд);
2. Господа edogs и Planet_Dust немного пояснили — можно наотключать кучу бай дефолт включенных модулей, перейти на event (читайте epoll) вместо prefork, оттюнить и отполировать Apache до состояния, слабо отличающегося от nginx… суть в том, что Ваша статья не полна с точки зрения теории, а значит не очень показательна для новичка — если ориентироваться на эти данные, то можно пойти по ложному посылу;
3. Я не обладаю для этого достаточной квалификацией, но могу предположить, что Я.Метрику можно подрубить к in-addr.arpa-домену, после чего прописать PTR-запись. А насчёт одежды и пиццы — поправимо, ибо я же сказал, цитата, «до релиза». Я могу быть неправ, ибо я понятия не имею о SEO, но неправым полностью я быть не могу — с этого всего можно словить бонусы;
4. «Критикуешь — предлагай», как грицца. А у меня нуль публикаций :) Так что мою критику можно отсечь с аргументом «спердобейся». Вы в любом случае молодец — даже если Вы написали не до конца правильно информирующую статью — Вас поправили в комментариях с информацией, актуальной на 2018 год. Как известно, у 99% статей комментарии интереснее и важнее самой статьи. Данная тематика на хабре почти исчезает, в любом случае читать Ваш труд — лучше, чем заниматься некропостингом, хоть и по содержанию самой статьи разница мала.
И вот так, легко и непринуждённо, автор прорекламировал свой интернет-магазин до релиза, бонусом подняв его рейтинг счётчиком посещений. Я.Метрика подрублена — всё хорошо! SEO выходит на новый уровень, гы.
Если этот год не будут спать, есть и как-либо отрываться от кода, при этом зная Pure C, Rust, архитектуру ОС и архитектуру ВМ и сетей и частное — отдельные конкретные реализации и воркараунды для железячных мест, где воркараунды нужны и почему на уровне способности "читать и писать без подсказок в 90% случаев и знать где быстро найти для остальных 10%" — то да, года будет достаточно. Утрированно, конечно, у каждого из этих тридцати своя нечеткая специализация, и 90% можно даже превратить в 70%, уух, задачу облегчили уже! Четкой специализации для команды в 30 человек не нужно, но понятие о всех остальных отраслях у них должно быть. Найдете 30 таковых по всему миру?
И даже если кто-то всерьёз скажет, состроив злобную гримасу и стукнув кулаком по столу, «срочно совершаем [ре|э]волюцию!» — ничего не произойдет. Это как с IPv6 — «… а воз и ныне там...»
Ой, вечно Вы со своей JVM влезете куда не следует. Безопасность на уровне, описанном в статье, нужно реализовывать через Rust, а не через Java. Любая жабоось будет серверным решением худшим, чем серверные решения мелкомягких — адекватного тюнинга в жизнь не добиться.
Статья формулирует проблему, которую не решить — переписать код ядра *nix. По человеко-часам это займёт приблизительно… лет 30, при том, что текущее ядро параллельно с этим не перестанет развиваться.
На самом деле таки вредный совет.
Харрис&Харрис, как бы её не позиционировали авторы, имеет не нулевой порог вхождения. Совсем. А для гуманитария это окажется полным адом из-за количества информации, которую придётся переваривать (пусть и язык не самый сложный).
Вам нужен «Код. Тайный язык информатики» Петцольда. По-моему, для полных нулей соотношение осиляемости Петцольда к осиляемости Харрис&Харрис примерно равно соотношению осиляемости Х&Х к «Архитектуре» Танненбаума.
Технически, null — это не состояние. Это — отсутствие сигнала. Вот тут описан пример того, как это реализуется в наших текущих двоичнологичных машинах — habr.com/post/431010 (возможно, не самый достоверный пример и автор мог ошибаться со своими расчётами, но то, что процесс обновления есть, и то, что он есть тот же самый null — неоспоримо). Превращаются ли от этого наши машины (или хотя бы частное — память наших машин) в троичнологичные? Сомнительно.
И троичная логика не лишается способности null. Превращается ли она от этого в четверичную? Сомнительно, опять же.
То, что в некоторых отдельных случаях некоторые отдельные инженеры используют null как состояние, которое имеет положительную нагрузку и смысл наравне с true и false не означает что null для этого придуман, полагаю.
Говоря языком статьи — «more compact» стоит между двоичной и троичной системами счисления. Вот почему: habr.com/post/427969
Плюс ко всему нужно кардинально перестраивать всё на уровне электронных компонентов, потому что изменится шаг и нужно более точно учиться разделять двойку, единицу и нуль уже в троичной системе и всё будет ещё сложнее в дальнейшем.
Вы сами запутались — я прямым текстом сказал, что Docker и контейнеризация — кривая технология, на что вы потребовали обоснования того, что Docker и контейнеризация — кривая технология приведя в пример ссылку того, когда она кривая тем самым доказывая мне то, что я и сам утверждаю. :)
А что мне технологически аргументировать? На соседей разделяется nf_conntrack, разделяется энтропия, разделяется etc…
С точки зрения Dev (побыстрее выкатить фичи и чтоб стабильно работало) — знаете, но внезапно (!) действительно разницы нет.
На моей машине всё работает. (с) Но ладно, да, с точки зрения Dev разницы никакой. Если только не… команда состоит не из 1,5 землекопа, а там начинается игра в футбол, которая зря потратит время всем: «это виноват Dev!» — «не, это Ops'ы косячат!»
Если Вы не чувствуете разницу между виртуализацией и контейнеризацией и для вас это всё на уровне «работает и нормально» — печально.
КМК пользователю это в первую очередь выгодно, выгоднее чем самим AWS — Ваше ПО наиболее изолированно, чем оно было бы изолированно, например, в Docker-контейнере, при этом Вы не платите за ВМ сполна, т.к. Вы кушаете меньше ресурсов хост-машины.