потому что в пределах одного дивайса wifi не нужен.
а автономные модули (то есть, без прибора, с интерфейсом на планшете, телефоне, ноутбуке, ...) не хотят покупать. поэтому не делаем.
само-собой, никто не мешает прописать в inittab всё, что угодно, сохранив механизм переключения runlevel'ов. мне кажется, что в большинстве современных применений оно не особенно нужно. single, multi-user и halt вполне достаточно.
а так — да, можно сказать, что если rc-скрипт не использовать, разница на глаз будет незаметна. но идеология чуть другая.
и исполняемый файл runit-init где-то в шесть раз меньше, чем init ;)
ну, не все программы пишутся под заказчика. а то, что хочет заказчик может быть реализовано разными способами.
к примеру, делаем мы прибор, а в нём энное количество функций. если платформа прибора *nix-based, то софт прибора ни в коем случае не будет одной программой. это всегда довольно сложная система, которая состоит из некоторого количества компонентов, работа которых по отдельности заказчика совершенно не волнует. а так, конечно, процесс разработки на заказчика завязан. но на верхнем уровне. а советы для обычных программистов. чтобы не забывали и не усложняли лишний раз.
насчёт 38 лезвий — тоже верно. правда, это ближе к области согласования спецификаций, ТЗ и пр.
Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.
именно так! правда, для этого у нас (уверен, что не только у нас) есть правила ведения проекта, где наличие сопровождающей документации обозначено как обязательная часть и структурировано по типам: README, ChangeLog, комментарии в коде, wiki и пр. впрочем, пункт 9 это подразумевает. как бы :)
у нас — шесть. до этого лень. принцип больше применим к автоматизации рутинных действий. второй раз не означает, что рутинные действия начались. третий — повод задуматься, но четвёртый-пятый идут на автомате. зато шестой — вот оно наше всё!
Ага, а любую музыку желательно начинать с записи ее нот на стане.
:) не думаю. музыка — она в душе. а код — это текст и, прежде, чем его писать, много чего нужно сделать. а тест иногда помогает понять что и, может быть, не сделать зря. впрочем, вы понимаете, что я имею в виду, судя по приведённой аббревиатуре.
насчёт обратного эффекта — согласен. в нашем календарике есть даже отмазочный антипаттерн «сделано ровно то, о чём просили». правда, некоторые продолжают часто делать лишнюю работу вместо того, чтобы вместо остановиться и подумать. и тут полезно вспомнить принцип номер три.
ну да, в ipaqе был PXA250 сначала, но мы свой дивайс на 270-м рискнули делать, потому что он не был снят с производства, несмотря на то, что интел продал это направление Marvell'у.
это всё в пределах одного прибора. в нём два модуля, подключаемых по usb к управляющей плате. wifi здесь не совсем к месту.
а автономные модули (то есть, без прибора, с интерфейсом на планшете, телефоне, ноутбуке, ...) не хотят покупать. поэтому не делаем.
а так — да, можно сказать, что если rc-скрипт не использовать, разница на глаз будет незаметна. но идеология чуть другая.
и исполняемый файл runit-init где-то в шесть раз меньше, чем init ;)
к примеру, делаем мы прибор, а в нём энное количество функций. если платформа прибора *nix-based, то софт прибора ни в коем случае не будет одной программой. это всегда довольно сложная система, которая состоит из некоторого количества компонентов, работа которых по отдельности заказчика совершенно не волнует. а так, конечно, процесс разработки на заказчика завязан. но на верхнем уровне. а советы для обычных программистов. чтобы не забывали и не усложняли лишний раз.
насчёт 38 лезвий — тоже верно. правда, это ближе к области согласования спецификаций, ТЗ и пр.
про «квартет и» — допишу сейчас.
именно так! правда, для этого у нас (уверен, что не только у нас) есть правила ведения проекта, где наличие сопровождающей документации обозначено как обязательная часть и структурировано по типам: README, ChangeLog, комментарии в коде, wiki и пр. впрочем, пункт 9 это подразумевает. как бы :)
:) не думаю. музыка — она в душе. а код — это текст и, прежде, чем его писать, много чего нужно сделать. а тест иногда помогает понять что и, может быть, не сделать зря. впрочем, вы понимаете, что я имею в виду, судя по приведённой аббревиатуре.
насчёт обратного эффекта — согласен. в нашем календарике есть даже отмазочный антипаттерн «сделано ровно то, о чём просили». правда, некоторые продолжают часто делать лишнюю работу вместо того, чтобы вместо остановиться и подумать. и тут полезно вспомнить принцип номер три.