Требования ZFS к памяти — это свойство ZFS, а не ОС.
Кстати, мне вполне комфортно работается с ней на убогом ноутбуке с 4GB (против настоятельно рекомендуемого везде и всюду минимума в 8GB) — достаточно просто разумно ограничить vfs.zfs.arc.max, чтобы не жрал всю память под ARC.
Планирую эксперимент на совсем убогом EEE PC от Asus, в который больше 2GB не поставишь :)
Ага, только у 80% виденных мной инсталляций TrueNAS лишь эти “10% функционала” и используются :) Тут ведь какой нюанс — само название “Подключаемое по сети хранилище” довольно недвусмысленно говорит, что на самом деле это — сторадж — и есть 90% его функциональности. Это не качалка, не медиасервер, не платформа виртуализации, не почтовый сервер, не система видеонаблюдения, не <что там ещё можно взгромоздить на популярные NAS'ы>. Это хранилище. И в Windows-сети (особенно домашней) доступность по SMB и есть его самая главная и основная функция — быть “просто smb-сервером”.
Это подмена понятий, считаю. Я утверждаю, что в данной строке нет разыменовывания указателя. Вот этот самый indirection/dereference — это action, действие. Так именно действия здесь и нет, потому пример не годится в качестве демонстрации заблуждения “дереференс NULL всегда приводит к UB.”
Я близок к уверенности, что в жизни автора не было ничего, кроме x86 и Windows/Linux. А ещё автор явно имеет такое представление об UB, которое не совсем соответствует тому, как это определяет стандарт (и другие разновидности B). Это, прочем, свойственно очень многим.
Нельзя, поскольку усвоившим неверные сведения потом придётся переучиваться.
Возражение на чушь автора про “всегда UB” абсолютно справедливо. Но! В приведённом коде нет indirection operator. Семантически говоря. Это как раз один из моментов в С, с которым отцы недоработали — выражение *p имеет совершенно разную семантику в зависимости от контекста. Прежде всего — declaration vs. evaluation. А sizeof “работает” во время компиляции, а не исполнения, нет ни малейшей необходимости в разыменовывании, компилятору нужно лишь вывести тип операнда.
Отношение к стандарту у автора тоже доставляет. Но с учётом того, что ему (ей вообще-то) всего лишь 20 лет от роду, можно и простить это лёгкое невежество. Но поставить на вид, чтобы впредь неповадно было :)
Маленькая техническая не то, чтобы ошибка, но есть что-то некорректное в этом предложении:
ограничение 16-битной версии, умевшей работать лишь с 64 килобайтной ОЗУ, «научив» её использовать весь наличный объём оперативки: это очень помогло для работы с новыми советскими СМ-1420, где имелось уже целых 248 килобайт.
Дотошному читателю не может не броситься в глаза, что в одном случае упоминается вполне себе “в степени двойки” размер ОЗУ (64КБ), а во втором случае — 248КЬ — уже что-то не настолько кругло :) Только вот не было у младших (не по возрасту, а по функциональности) PDP-11, у таких же “младших” СМ-4, и у СМ-3 никакого “64 килобайтного ОЗУ”, равно как и у более продвинутых PDP-11/СМ-4 и СМ-1420 — 256 килобайтного. У них были такие адресные пространства, но верхние 8КБ оного — это особенность архитектуры UNIBUS (общая шина) — это регистры устройств, так как сам процессор никаких команд I/O не имел.
То есть абсолютно корректным было бы написать либо 56 в первом случае, либо 256 во втором. Только в случае 56/248 речь идёт действительно о размере ОЗУ, а в случае 64/256 — об адресном пространстве.
Забавно, что в этой статье прямо указывается о “совместимости” СМ-3/4/1420 с Digital Equipment Corp, но в разделе про СМ-1/2/М-6000 нет ни слова о такой же “совместимости” этих систем с Hewlett Packard. То ли автор не знал (что весьма сомнительно), то ли сознательно.
Куда интереснее вопрос, есть ли причины отказываться от утилиты, которая уже пятый десяток лет прекрасно делает от неё требуемое в любом юниксе, в пользу сугубо линуксового новодела, у которого вообще не было причин появляться, кроме Лёшиной одержимости и положивших с прибором мэйнтейнеров net-tools?
Не вижу ни малейшего повода для риторизмов :) Любой shell предназначен для запуска внешних программ, но никому не придёт в голову утверждать, что все shell'ы — эволюция sh. Или command.com
У PowerShell принципиально иная идея. Вот прям именно, что принципиально. Что возвращает юзеру или следующей программе в конвейере cmd.exe? Текст. Или мусор :) А что PowerShell? Вот то-то...
как “писать быстрые SQL-запросы”, согласно названию статьи. Ушёл с головой в индексацию не понимая, что “быстрый запрос” и “быстрое исполнение запроса” — это сильно разные сущности;
что он сам “понимает принципы работы баз данных”, ни разу не упомянув на такой “простыне”, например, “декартово произведение” — едва ли ни самый-самый базовый принцип в реляционных БД.
Я вряд ли смогу подсчитать, сколько раз меня в жизни звали “решить проблемку с SQL”, когда “ведущие специалисты” думали, что индексы решат им всё, и получали объёмы индексов, превышающие в несколько раз (!!!) объёмы собственно данных, со всеми вытекающими последствиями.
PowerShell вообще никак не является эволюцией CMD. Это принципиально другой инструмент, общего у них только то, что взаимодействие с ними осуществляется одинаковым образом.
Ну, справедливости терминологии ради, GEOM — это не класс, а целый фреймворк, и класс в нём — лишь одна из множества сущностей., которые тем или иным образом преобразует I/O запросы, и из которых можно выстраивать довольно затейливые иерархии.
Ну, почему ж только к кандидату претензия? Давайте посмотрим ещё и на вакансию, где компании, подвизающейся на охоте на воробьёв, требуется опытнейший снайпер из ПЗРК, в совершенстве владеющий «Стрелой-2М», «Blowpipe», «Stinger» и «Иглой-С» :)
Вообще статья больше похожа на восторженный писк неофита, чем на речи зрелого специалиста. А за 10 лет можно было уже и созреть. Расти пора, парень :)
Для начала предлагаю усвоить очень простую вещь: всякий программист — разработчик, но далеко не всякий разработчик — программист. Пример, чтобы понятнее было, о чём я: сын моего друга работает в модной геймдев-студии. Является ли он одним из разработчиков их игр? Да, безусловно, он имеет самое прямое отношение к созданию персонажей этих самых игр. Является ли он программистом? Нет, ничуть, ни на йоту — он никогда в жизни не написал ни строки кода, знать не знает, как это делается, он художник, он рисует персонажей этих игр. Рисует буквально — карандашами и фломастерами на бумаге. Даже оцифровка этих рисунков во всякие там спрайты, “вектора”, гифы и прочую цифру — вообще не его забота, для этого там есть другие разработчики, которые тоже, кстати, ни разу не программисты.
Короче, эти термины совершенно не взаимозаменяемы. Когда ты говоришь “программист”, более или менее (тоже есть нюансы) понятно, что ты имеешь в виду. Но когда ты говоришь “разработчик”, ты говоришь о сферическом коне в вакууме, который к коду может не иметь ни малейшего отношения.
Требования ZFS к памяти — это свойство ZFS, а не ОС.
Кстати, мне вполне комфортно работается с ней на убогом ноутбуке с 4GB (против настоятельно рекомендуемого везде и всюду минимума в 8GB) — достаточно просто разумно ограничить vfs.zfs.arc.max, чтобы не жрал всю память под ARC.
Планирую эксперимент на совсем убогом EEE PC от Asus, в который больше 2GB не поставишь :)
Ага, только у 80% виденных мной инсталляций TrueNAS лишь эти “10% функционала” и используются :) Тут ведь какой нюанс — само название “Подключаемое по сети хранилище” довольно недвусмысленно говорит, что на самом деле это — сторадж — и есть 90% его функциональности. Это не качалка, не медиасервер, не платформа виртуализации, не почтовый сервер, не система видеонаблюдения, не <что там ещё можно взгромоздить на популярные NAS'ы>. Это хранилище. И в Windows-сети (особенно домашней) доступность по SMB и есть его самая главная и основная функция — быть “просто smb-сервером”.
Это подмена понятий, считаю. Я утверждаю, что в данной строке нет разыменовывания указателя. Вот этот самый indirection/dereference — это action, действие. Так именно действия здесь и нет, потому пример не годится в качестве демонстрации заблуждения “дереференс NULL всегда приводит к UB.”
Я близок к уверенности, что в жизни автора не было ничего, кроме x86 и Windows/Linux. А ещё автор явно имеет такое представление об UB, которое не совсем соответствует тому, как это определяет стандарт (и другие разновидности B). Это, прочем, свойственно очень многим.
Пожалуй, категорически соглашусь. Надо пороть :)
Возражение на чушь автора про “всегда UB” абсолютно справедливо. Но! В приведённом коде нет indirection operator. Семантически говоря. Это как раз один из моментов в С, с которым отцы недоработали — выражение
*pимеет совершенно разную семантику в зависимости от контекста. Прежде всего — declaration vs. evaluation. А sizeof “работает” во время компиляции, а не исполнения, нет ни малейшей необходимости в разыменовывании, компилятору нужно лишь вывести тип операнда.Отношение к стандарту у автора тоже доставляет. Но с учётом того, что ему (ей вообще-то) всего лишь 20 лет от роду, можно и простить это лёгкое невежество. Но поставить на вид, чтобы впредь неповадно было :)
Маленькая техническая не то, чтобы ошибка, но есть что-то некорректное в этом предложении:
Дотошному читателю не может не броситься в глаза, что в одном случае упоминается вполне себе “в степени двойки” размер ОЗУ (64КБ), а во втором случае — 248КЬ — уже что-то не настолько кругло :) Только вот не было у младших (не по возрасту, а по функциональности) PDP-11, у таких же “младших” СМ-4, и у СМ-3 никакого “64 килобайтного ОЗУ”, равно как и у более продвинутых PDP-11/СМ-4 и СМ-1420 — 256 килобайтного. У них были такие адресные пространства, но верхние 8КБ оного — это особенность архитектуры UNIBUS (общая шина) — это регистры устройств, так как сам процессор никаких команд I/O не имел.
То есть абсолютно корректным было бы написать либо 56 в первом случае, либо 256 во втором. Только в случае 56/248 речь идёт действительно о размере ОЗУ, а в случае 64/256 — об адресном пространстве.
Забавно, что в этой статье прямо указывается о “совместимости” СМ-3/4/1420 с Digital Equipment Corp, но в разделе про СМ-1/2/М-6000 нет ни слова о такой же “совместимости” этих систем с Hewlett Packard. То ли автор не знал (что весьма сомнительно), то ли сознательно.
Куда интереснее вопрос, есть ли причины отказываться от утилиты, которая уже пятый десяток лет прекрасно делает от неё требуемое в любом юниксе, в пользу сугубо линуксового новодела, у которого вообще не было причин появляться, кроме Лёшиной одержимости и положивших с прибором мэйнтейнеров net-tools?
Оно не “указывает”, оно и есть оно. SSL — это просто наглядный пример неудачного нейминга.
Не вижу ни малейшего повода для риторизмов :) Любой shell предназначен для запуска внешних программ, но никому не придёт в голову утверждать, что все shell'ы — эволюция sh. Или command.com
У PowerShell принципиально иная идея. Вот прям именно, что принципиально. Что возвращает юзеру или следующей программе в конвейере cmd.exe? Текст. Или мусор :) А что PowerShell? Вот то-то...
Благодаря Эффекту Линди нам, заматерелым C-программистам, похоронить свой любимый язык не грозит. И вам не удастся :)
Это примерно такая же катастрофа, как и Dartmuth BASIC :)
Ещё как, хоть и изрядно мутировал :) JECL. Всё там же, на IBM mainframes.
Уже не загружается. Точнее, у некоторых ещё загружается, но оно уже около obsolete. Lua всё же куда удобнее.
Что-то “ведущий разработчик” не показал:
как “писать быстрые SQL-запросы”, согласно названию статьи. Ушёл с головой в индексацию не понимая, что “быстрый запрос” и “быстрое исполнение запроса” — это сильно разные сущности;
что он сам “понимает принципы работы баз данных”, ни разу не упомянув на такой “простыне”, например, “декартово произведение” — едва ли ни самый-самый базовый принцип в реляционных БД.
Я вряд ли смогу подсчитать, сколько раз меня в жизни звали “решить проблемку с SQL”, когда “ведущие специалисты” думали, что индексы решат им всё, и получали объёмы индексов, превышающие в несколько раз (!!!) объёмы собственно данных, со всеми вытекающими последствиями.
PowerShell вообще никак не является эволюцией CMD. Это принципиально другой инструмент, общего у них только то, что взаимодействие с ними осуществляется одинаковым образом.
Ну, справедливости терминологии ради, GEOM — это не класс, а целый фреймворк, и класс в нём — лишь одна из множества сущностей., которые тем или иным образом преобразует I/O запросы, и из которых можно выстраивать довольно затейливые иерархии.
Ну, почему ж только к кандидату претензия? Давайте посмотрим ещё и на вакансию, где компании, подвизающейся на охоте на воробьёв, требуется опытнейший снайпер из ПЗРК, в совершенстве владеющий «Стрелой-2М», «Blowpipe», «Stinger» и «Иглой-С» :)
Вообще статья больше похожа на восторженный писк неофита, чем на речи зрелого специалиста. А за 10 лет можно было уже и созреть. Расти пора, парень :)
Для начала предлагаю усвоить очень простую вещь: всякий программист — разработчик, но далеко не всякий разработчик — программист. Пример, чтобы понятнее было, о чём я: сын моего друга работает в модной геймдев-студии. Является ли он одним из разработчиков их игр? Да, безусловно, он имеет самое прямое отношение к созданию персонажей этих самых игр. Является ли он программистом? Нет, ничуть, ни на йоту — он никогда в жизни не написал ни строки кода, знать не знает, как это делается, он художник, он рисует персонажей этих игр. Рисует буквально — карандашами и фломастерами на бумаге. Даже оцифровка этих рисунков во всякие там спрайты, “вектора”, гифы и прочую цифру — вообще не его забота, для этого там есть другие разработчики, которые тоже, кстати, ни разу не программисты.
Короче, эти термины совершенно не взаимозаменяемы. Когда ты говоришь “программист”, более или менее (тоже есть нюансы) понятно, что ты имеешь в виду. Но когда ты говоришь “разработчик”, ты говоришь о сферическом коне в вакууме, который к коду может не иметь ни малейшего отношения.
А с КЭП если попробовать подавать заявление? Тут как бы сама необходимость какого-то там “подтверждения” отпадает...
Вступление статьи прямо кричит «Не та КДПВ! НЕ ТА!!!» :)
Вот эту надо было!