Проблема 2000h (или как собрать GCC-ARM-embedded линкером большой проект)

Тема в первую очередь будет интересна пользователям среды Eclipse IDE/GNU ARM plugin/GCC ARM compiler под Windows.

Всякий уважающий себя эмбеддер рано или поздно вырастает из светодиодных моргалок, забрасывает авр-ки на полку, и пересаживается на более продвинутые чипы. С ростом возможностей микроконтроллера увеличивается и сложность встроенных программ. Мегабайты и Мегамипсы так и просят прикрутить к проекту графический ЖКИ, стек TCP/IP, файловую систему, а для полного счастья — конечно ещё и фриртоску.

И вот в один прекрасный момент проект перестаёт собираться. А виноват в этом может быть (ну конечно же, Билл Гейтс) лимит на длину командной строки в 8192 символа. Что же делать?

Давайте разбираться...

Утилиты из комплекта GNU ARM compiler имеют досоподобный интерфейс — все необходимые ключи и параметры передаются через командную строку. Самая длинная строка с параметрами в итоге достаётся линкеру. Она содержит список всех объектных файлов (в том числе пути их расположения), необходимых для сборки конечного hex-файла.

Так вот, если длина полученной строки с параметрами более 8191 символов, линкер начинает ругаться:



Он не может найти объектный файл, в имени которого почему-то отсутствует один смвол. В данном примере нет пробела между именами двух файлов.

Майкрософт утверждает, что командная строка должна быть не больше чем 8191 (либо 2047, в зависимости от ОС) символов. В моём случае линкеру передаётся 8613 буковок, в итоге попадаем под санкции и отдаём в виде налога 8192-ю букву.

Причём любопытно, что выпадает только каждый 8192-й символ, а вся остальная строка передаётся правильно. Ну а верхний лимит командной строки — 32768 байт (проверено), сверх этого передать ничего уже не получится.

Рассмотрим варианты решения проблемы.


1. Сократить длину пути и имени файлов
Бывает, что много файлов сходного назначения складывается в
папку1\папку2\ещё_одну_папку
При линковке к каждому объектному файлу добавляется указанный путь. Однозначно поможет перемещение, например, SPL из папки
мой_проект\Library\system\STM32F10x_StdPeriph_Driver\
в просто
мой_проект\spl\

В принципе на этом можно будет и остановиться, однако мы не ищем лёгких путей. Да и не хочется ломать устоявшиеся традиции и вытаскивать в корень проекта кучу отдельных папок SPL, CMSIS, newlib, FatFS, LwIP, STemWin, etc. Каша получится...

2. Использовать статические библиотеки
Создаём отдельный проект, в котором собираем массу исходников в одну my_lib.a библиотеку. Затем скармливаем её линкеру в базовом проекте. Длина проблемной командной строки кардинально сокращается. Если файлов слишком много, делаем несколько библиотек.

Отличный вариант. Побочным положительным эффектом будет сокращение времени компиляции основного проекта (т.к. куча файлов была ранее скомпилирована в my_lib.a). Но...

Довольно часто библиотечные модули (характерный пример — стек LwIP) имеют массу настроек в виде директив условной компиляции. Поэтому полученная библиотека будет актуальна только для конкретного проекта. Т.е. её нужно будет хранить, архивировать, сопровождать всегда совместно с базовым проектом.
А если одновременно в работе несколько проектов? Брр, неудобно…

3. Стать мастером make-файлостроительства
Если писать make-файл вручную, то проблему 2000h тоже можно легко обойти. Например, собрать проект в виде набора тех же статических библиотек, а потом объединить их в один выходной hex. При использовании ручного makefile открывается огромная масса других полезных возможностей. Однако…

Стать make-мастером — ой как не просто. И потом потребуется постоянно держать себя в форме. Иначе по прошествии пары-другой месяцев без тренировки приходится долго вспоминать, как же вся эта штука работает... Поэтому обычно предпочитаю использовать make-файл, автоматически создаваемый GNU ARM плагином.

upd: безусловно, если заниматься программированием серьёзно, познать make-утилиту всё равно придётся. И оно того стоит.

4. Передать строку параметров линкеру через отдельный файл
Говорят, ребята из Freescale (CodeWarrior) так и делают. Как это сделать в связке GNU make + GCC, не разобрался. Если таки можно — снова потребуется править makefile (возвращаемся к варианту №3).

upd: благодаря Gleserg , дополню этот пункт.

В автоматически создаваемом makefile есть три точки расширения
-include ../makefile.init
-include ../makefile.defs
-include ../makefile.targets
Они позволяют дополнить процесс сборки проекта своими фичами.

Как вариант, предлагается (см. оригинал) через файл makefile.defs подключить скрипт вида
$(shell rm ObjectList)
$(foreach obj, $(OBJS), $(shell echo $(obj) >> ObjectList))
$(shell echo $(USER_OBJS) >> ObjectList)
который и поместит список необходимых объектных файлов в файл ObjectList. Для передачи этого файла линкеру в параметрах проекта
Project properties -> C/C++ Build -> Settings -> закладка Tool Settings -> Cross ARM C++ Linker -> строка Command Line pattern
нужно заменить ${INPUTS} на @ObjectList. «Вуаля!», и проект собран.

5. Перейти на линукс
Говорят, там этой проблемы нет. В общем, на любителя...
хм, резонансная фраза получилась, больше сотни комментариев :)

6. Использовать костыль-корректор командной строки
А что, если сделать программу-прослойку, которая будет вызываться утилитой make, принимать и исправлять строку параметров, и запускать в свою очередь линкер? Сказано-сделано.
Собственно, этот вариант и послужил стимулом для написания данной заметки.
Программа вскоре научилась не только тупо вставлять указанный символ в указанном месте, а также исправлять ошибки в автоматическом режиме. Но (снова это «но»)…

7.
В очередной раз посетила мысль: ну неужели никто проблему 2000h так и не решил? И о, чудо! Гуглер наконец выдал свежее решение. Фтопку варианты 1..6. Нужно всего лишь взять пропатченные Build Tools.

цитата:
PS: Liviu, you probably read this, and I know you are using Mac OS, and you are not a fan of Windows environment for good reasons. On behalf of the Windows user community: THANK YOU, THANK YOU, THANK YOU!



Надеюсь, на этом вопрос можно считать закрытым. По крайней мере пока не доберёмся до следующей границы в 32к (в запасе имеем безлимитный метод №4).

Удачного вам гуглинга и кодинга!

Комментарии (177)

RSS свернуть / развернуть
5. Перейти на линукс
Говорят, там этой проблемы нет. В общем, на любителя...

звучит как оскорбление чувств верующих… мол, библию не читал, но осуждаю…
-1
Причем тут верующие то?) Вполне адекватный пункт — не все линуксом пользовались, и далеко не у всех есть желание и время пробовать.
+4
Извините, немножко GNU-сю для молодняка.

Проблемы возникают, когда люди смешивают разные парадигмы. Затронутая тема — пример такой проблемы.

Парадигма UNIX/Linux основана на том, что взаимодействие пользователя и программ осуществляется посредством «телетайпа». А парадигма Windows — на визуальном интерфейсе.

Что такое «телетайп»? Телетайп — это текстовый экран и клавиатура. И более ничего другого! Другие названия телетайпа — терминал, консоль. (Для нас пока их отличия друг от друга не важны!)
Причем, парадигма UNIX рассматривает телетайп и сам компьютер как два независимых (отдельных) устройства. Комп обычно называют «хостом». Согласно этому положению, телетайп может находится в любом месте. Примеры:

* на том же компе (ноутбук, настольный комп)
* на соседнем столе, в соседней комнате (локальная сеть, сервер + клиент)
* в другом городе, в другой стране
* в космосе (космическая станция), в атмосфере (дрон)

Ну и так далее. Важно понять, что хост находится в одном месте, а пульт управления — в другом. Между хостом и пультом управления имеется канал связи.

Следует заметить, что поскольку UNIX/Linux — это есть многозадачные многопользовательские ОС-и, то они допускают одновременное подключение к хосту сразу нескольких терминалов (пользователей).

Так вот, поскольку терминал — это текстовый экран и клавиатура, то это положение накладывает серьезное ограничение на способы взаимодействия пользователя и программы. Здесь нельзя, как Виндовсе указать мышкой или получить графическую картинку. Здесь допустимо только текстовое взаимодействие. Другими словами, интерфейс — ТЕКСТОВЫЙ. В связи с этим в UNIX развиты текстовые методы взаимодействия пользователя и программ.

Жизнь день ото дня становится всё сложнее и сложнее. И даже в сложном мире жить как-то надо. Поэтому в мире UNIX нет ничего удивительного в том, что посредством командной строки в программу приходится передавать много-килобайтные данные. Как-то давно я что-то компилировал, и я хорошо помню, что команда на компиляцию занимала целых два экрана! Да, тогда я удивлялся и негодовал — как такое вообще имеет право жить! Но прошло несколько лет, и я понял, что мои представления о «правильности» мирового устройства основаны на парадигме Виндовса. А UNIX — это совершенно другой мир.

Проблемы стали появляться, когда начали натягивать технологии из мира UNIX на парадигму Виндовс. Ну, совмещать несовместимое можно до поры-до времени, пока оно незначительно. Но потом начинаются проблемы, на подобие этой.

Скажу еще пару слов о парадигме Виндовс.

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

Windows, в отличие от UNIX, изначально разрабатывалась как КОММЕРЧЕСКАЯ Операционная система, назначение которой — продаваться на рынке, принося владельце бабло. Поэтому Виндовс разрабатывалась в прицеле не на специалистов, готовых изучать «компьютерную» науку, а на необученных широких народных масс, которым любое упоминание об учёбе наводит на тоску. Учиться мало-кто любит и хочет. И чтобы продажи операционки не встали колом, пользователь не должен испытывать негатив от её освоения. Всё должно быть просто и понятно, как велосипед — сел и поехал!

Понимание этого положения привело к пониманию того, что нужно делать. Нужно на экран вывести варианты и предоставить пользователю ткнуть пальцем и выбрать один из них. Учить, запоминать ничего не надо! Нужно только овладеть умением пользоваться мышкой. В пределе — даже не надо уметь читать — цветные картинки рулят!

Так вот, согласно парадигме Виндовс взаимодействие пользователя и программы должно происходить посредством выбора того, что отображено на экране — радиокнопки, чек-боксы, списки, менюшечки и так далее. Когда это всё графическое хозяйство будет настроено нужно нажать единственную кнопку «ОК» («Выполнить», «Откомпилировать», «Сделать мне приятно» ...)

Причем, заданные таким образом параметры уже находятся во власти программы. То есть на самом деле, если их перевести в текстовый эквивалент, их объем может быть очень большой. Мне сложно назвать какую-то цифру. Ну, предположим, — несколько мегабайт! И это не проблема!

Непроблема потому, что мы осуществляем взаимодействие (пользователь и программа) в своей родной среде. Если в Винде работать по-Виндовому, а в Линуксе — по Линуксовому, то проблем вообще не возникает! Проблемы возникают когда одну технологию напяливают на другую.

И в самом деле, когда в среде UNIX/Linux мы пытаемся что-то откомпилировать и набираем в консоли длинную команду, то компилятор (программа) еще не работает! Мы только-только готовим задание для работы. Поэтому среда должна нам обеспечить очень большие возможности для указания очень большого числа параметров. Но противоречия здесь нет! Это и есть парадигма UNIX.

Когда в Виндовой программе мы указываем очень большое количество параметров, то программа уже работает. Виндовая среда в этом взаимодействии не участвует. Поэтому всё взаимодействие (пользователя и программы) протекает внутри программы и под её контролем. Это парадигма Виндовс. И противоречия здесь так же нет!

Всё вроде бы хорошо, если оставаться в рамках выбранной технологии, то можно очень даже комфортно жить.

Однако, мир стал интернет-ориентированным. Это наложило отпечаток на технологии. Технологии UNIX изначально подразумевали, что хост и терминал — это два устройства, связанные между собой какими-то линиями связи. А вот Виндовс — это персональный компьютер, у которого процессорный блок, клавиатура и дисплей — это единое целое. И нельзя одно от другого дистанцировать.

Поэтому, UNIX/Linux легко допускает удаленное взаимодействие (пользователя и программ), а Виндовс — с определенными трудностями. Удаленное управление в UNIX/Linux находится под контролем самой операционной системы. Поэтому ЛЮБЫЕ (неграфические) программы в Линуксе уже сразу готовы к сетевым операциям. А вот в Виндовсе — не всё так просто! Если программа должна взаимодействовать с удаленным пользователем, то она сама должна решать эти сетевые проблемы. И если Виндовая программа не умеет работать удаленно, то — проблемы!

В среде UNIX/Linux — контроль взаимодействия между программой и пользователем осуществляется самой средой. Поэтому программе достаточно принимать данные из стандартного потока ввода, а результат работы выдавать в стандартный поток — и этого уже достаточно для любого взаимодействия между пользователем и программой — будь то взаимодействие локально (на том же самом компе (хосте)) или удаленно (управление космическим аппаратом, умным домом и т.д.).

Надеюсь, я не очень утомил вас своим рассказом. Я попытался объяснить, чем объясняется что настоящие специалисты выбирают тяжелое оружие, не смотря на его брутальность и отсутствие розовеньких бантиков. (Для тех, кто не понял — им нужно решать задачи, а не выглядеть красиво.)

(Хрена-се! Целая статья получилась. От-это я в ударе!)
+3
Что-то мне подсказывает, что ограничения винда унаследовала еще от дос. Которая, внезапно, не менее терминальная, чем юникс.
Да и вообще, подобные лимиты для винды не редкость. Например, чисто виндовый реестр имеет лимит размера ветви в 64кб, ЕМНИП.
и я хорошо помню, что команда на компиляцию занимала целых два экрана
Это всего 8кб, столько и винда прожует.
0
Два экрана могут быть разными, в зависимости от размера терминала :). Например у меня в Linux терминал где то 130 х 80, а это прилично больше 8к :), а уж если установить шрифт 8х8(правда мелковат) то вообще 170 х 96. Так что в текущей ситуации «экран» как единица измерения очень неоднозначен.
А если вспонить досовский экран то там было 80 х 25 симорлов и это значительно меньше 8к.
0
Да, я имел в виду 80х25. Только промахнулся с порядком, на самом деле два досовских экрана — это 4к.
Экран, конечно, можно сделать какой угодно (в винде в том числе), так что я взял единственную сколько-то стабильную цифру :D
0
1.
Вы ошибаетесь, ДОС — не терминальная среда!

Между терминалом (консолью) UNIX и так называемым «терминалом» DOS — принципиальная разница. У ДОС-а вообще нет понятия «терминал»! Понятие «терминал» — это порождение мира UNIX.

То, что в ДОС-е называется командной строкой — это не терминал, не консоль, не телетайп. Это просто страшная резиновая лодка черный-черный экран. И ничего больше! В ДОС-е клавиатура + экран — это не консоль! Это просто клавиатура и экран.

Вы не можете в ДОС-е вот так взять и просто выделить экран и клавиатуру, назвать это терминалом (консолью) и удалить их за 1000 км. Эта идея вообще работать не будет! Чтобы в ДОС-се можно было дистанционно работать, нужно установить специальный софт. И даже установка этого софта не будет отвечать критерию «удаленная консоль». Это будет что-то из серии два компа, соединённх сетью, причем, один из них эмулирует работу удалённого терминала.

Терминал — это совсем другое. Чтобы понять что это значит, нужно поработать с этим. Это то фундаментальное понятие, которое дается не через определение, а через чувство. Ну как объяснить слепому, что значит «голубое небо». Для этого он должен видеть!

Кроме того, ДОС не СЕТВАЯ операционная система.

2.
Про два экрана.

Экран терминала в среде UNIX — это не обязательно 25 строк по 80 символов. Размеры терминала вообще не определены! Потому как терминалом может являться принтер. Широкие принтеры позволяли печать в строке 136 символов в обычном режиме. И, если мне не изменяет память, то в режиме «конденсед» более 200 символов. Если печать осуществляется на бумажный рулон, то высота такого терминала равна бесконечности.

Поэтому, мне сложно сказать — сколько байт занимала та команда. Помню, что много.

И да! совсем нет никакой нужды набирать такие команды руками. Ну, разве что может быть один раз — первый раз. В UINX/Linux — всё есть текст и всё есть файл. Поэтому такие длинные команды сохраняются в виде файлов, в виде шаблонов, в виде истории команд. То есть всегда есть возможность воспроизвести не прибегая к повторному набору на клавиатуре. Поэтому те, кто хорошо знаком с UNIX/Linux, у тех не возникает паники при виде текстовой консоли — они просто знакомы с методами работы. А те, кто пришел из мира Виндовс — у них это всё вызывает благоговейный ужас.

Я никого не приглашаю в мир UNIX/Linux. Человек сам должен решать, где ему комфортнее. Но я утверждал и буду утверждать, что это не операционная система плохая, а ваши знания недостаточны для успешной работы с ней. За свою жизнь я успел очень глубоко покопаться и DOS, и Windows, и Linux. Так что в каких-то вопросах, мне кажется, что я разбираюсь.
0
ДОС поддерживал «те самые» терминалы. Была такая команда CTTY которая позволяла перенаправить потоки на терминал, например, подключенный на СОМ-порт. По умолчанию ввод/вывод связан с устройством «CON».

Но, для того чтобы это работало программы должны использовать стандартные средства ДОС для ввода/вывода. А многие (может даже большинство) программ этого не делало (писали напрямую в видеопамять, читали напрямую из порта клавиатуры и т. д.) и соответственно в этом режиме не работали. Но формально поддержка внешнего терминала в ДОС была, правда этим практически никто не пользовался.
0
Да и прозрачная работа с сетью была (SMB/NetBIOS) для тех, кому это так уж нужно.
-1
Где? В ДОСе? Да вы что? С каких пор? С какого года? Поддержка сети была включена в стандартный дистрибутив ДОСа? Неужели?
0
О, и у вас в чистом досе работает команда «net use»?
0
Я не знаю что такое «чистый дос». Всегда считал DOS конструктором, который в минимальном виде состоит из трёх файлов, в который можно просто скопировать всё необходимое и добавить в автоэкзек/конфиг то что нужно загружать. В т.ч. NET.EXE и прочее.
0
«Чистый дос» — это то, что фирма Microsoft включает на свои дискеты в комплект поставки MS-DOS.
Без любых других сторонних программ.
0
В т.ч. NET.EXE и прочее.
А он есть в стандартном комплекте поставки MS-DOS?
0
Не знаю. Может в определённых комплектах для каких-нибудь фирм и был. Какая разница, главное что сетевые компоненты для DOS существуют, а на каких дискетах они записаны — дело десятое.
0
Какая разница, главное что сетевые компоненты для DOS существуют, а на каких дискетах они записаны — дело десятое.
Круто. То есть при таком подходе можно сказать, что в ДОС входят средства разработки на С/С++, ведь не важно, что они ставятся с каких-то там других дискет. Я вас правильно понял?
0
Сетевые компоненты — системные, написанные специально для этой системы. А компилятор — просто прикладная программа.
0
Сетевые компоненты — системные, написанные специально для этой системы.
Применительно к досу это звучит весьма забавно, учитывая как там организовывается «системность» сети.
А компилятор — просто прикладная программа.
Ага. Написання под эту систему и собирающая программы под эту же систему. Не говоря уже о том, что компиляторы относятся к системному софту, а не к прикладному.
0
Не говоря уже о том, что компиляторы относятся к системному софту, а не к прикладному.
Помнится мне, в некоторых линуксах этот системный софт ручками доставлять приходилось. И это были не роутеры с ведрами, а десктопные дистрибутивы.
0
Это ничего не меняет. Просто по определению компиляторы относятся к системному програмному обеспечению.
0
Ну, в таком случае клиент сети также в обоих ОС относится к одному и тому же типу ПО, независимо от того, входит он в поставку или нет. Правда, в случае ДОСа он еще и вынужден реализовывать то, что в линуксе делает ядро/драйвер.
0
Речь не о типе (это, как раз понятно, что и там и там это системное ПО), а о том, входит оно в комплект или нет.
0
Не, ну дистрибутивы же разные бывают. В винде вон тоже сеть в комлекте, в фридосе в полном дистрибе софта на полный сидюк (голый фридос меж тем менее метра), а линукс, в принципе, варьируется от голого ядра (на те же ведра даже стандартные тулзы в лице busybox ставить приходится самому) и до всяких ынтерпрайзных дистрибутивов.
0
Не, ну дистрибутивы же разные бывают.
Угу. Но в досе (во всяком случае в классическом, от мс), сетевого клиента в комплекте нет. В линуксе же это вопрос выбора дистрибутива (ну или конфига сборки ядра и установки минимального комплекта утилит типа ifconfig-а).

P.S. линух в этом отношении хитрый зверь, поскольку собственно линух это только ядро, а все остальное это конкретный дистрибутив. даже собственного загрузчика у линуха нет, это все внешние программы.
0
P.S. линух в этом отношении хитрый зверь, поскольку собственно линух это только ядро, а все остальное это конкретный дистрибутив. даже собственного загрузчика у линуха нет, это все внешние программы.
Ага. Именно поэтому мне не нравятся сравнения линуха и винды по принципу «в линухе гимп из коробки, а под винду фотошоп отдельно продается!».
0
Ага. Именно поэтому мне не нравятся сравнения линуха и винды по принципу «в линухе гимп из коробки, а под винду фотошоп отдельно продается!».
Ну ничего ведь не мешает, скажем, сравнивать винду и убунту, верно?
0
Ну ничего ведь не мешает, скажем, сравнивать винду и убунту, верно?
Нет, но ведь в данной ветке это не уточняется.
Как не уточняется и дистрибутив винды. Вон, в ZverDVD фотошоп из коробки и бесплатно!)
0
Вон, в ZverDVD фотошоп из коробки и бесплатно!)
зверь, строго говоря, не дистрибутив, а пиратский сборник софта.

P.S. хотя вполне может стать дистрибутивом, если появится возможность заказать для него платную поддержку и фикс багов в компонентах.
0
Вот потому там и стоит смайлик.
0
даже собственного загрузчика у линуха нет
Ядро записывается с начального сектора диска и этого достаточно.
0
Ядро записывается с начального сектора диска и этого достаточно.
Хм, а разве эту фичу не убрали вот этим патчем? По-моему сейчас загрузить ядро без загрущика можно только через EFI Boot Stub
0
Возможно, это убрали.
Раньше можно было обойтись без загрузчика, записав ядро с самого начала дискеты.
0
а qbasic случайно не был на «тех самых дискетках»?
0
по крайней мере я был крайне рад его обнаружить, правда крайне кастрированную версию qbasic.exe вместоqb.exe
0
MS DOS 5.0 поставлялась на 10 (если точно помню) дискетах 3,5". Там было всё, что нужно для того, чтобы скомпоновать рабочий вариант.
0
Но сетевого клиента там не было. И net.exe в том числе.
0
Вот тут ничего не скажу за давностью событий. Скорее всего, так и есть. Для сети приходилось ставить отдельно драйвера и утилиты с проприетарных дисков.
0
Итого, там есть net.exe или нет?
-1
0
Я не знаю что такое «чистый дос»
Это да, никакие факты не могут повредить вере.
Всегда считал DOS конструктором, который в минимальном виде состоит из трёх файлов, в который можно просто скопировать всё необходимое и добавить в автоэкзек/конфиг то что нужно загружать. В т.ч. NET.EXE и прочее.
Вот только NET.EXE появляется только вместе с клиентом под (конкретную) сеть. Как вариант — вместе с установкой винды 3.11 (что, в принципе, тоже самое, только там клиент ставится как часть винды).
0
Ваш кролик писал (с)

>> Да и прозрачная работа с сетью была (SMB/NetBIOS) для тех, кому это так уж нужно.

А мы вообще о чём сейчас говорим?
0
Это я к тому, что
Кроме того, ДОС не СЕТЕВАЯ операционная система.
0
Вы или крестик снимите или трусы оденьте. Или была стандартная работа с сетью или дос не сетевая операционная система, одно из двух.

P.S. по поводу NetBIOS: штука для своего времени хорошая и весьма продвинутая, но крайне плохо совместимая со сколько-нибудь большими сетями.
0
Что значит «стандартная работа»? То, что в системе нельзя ничего сделать, не будучи подключенным к сети? В те времена это не было модно, т.к. предпочитали модульность и отсутствие лишних зависимостей. Но кому это было нужно, по всей видимости, могли взять сетевые компоненты и юзать их. В чём проблема?
0
Что значит «стандартная работа»?
Сетевой клиент, как минимум.
В те времена это не было модно, т.к. предпочитали модульность и отсутствие лишних зависимостей.
Модульность тут ни при чем. Линух, при желании, тоже вполне можно сконфигурировать без сети. Другой вопрос, что это никому нафиг не надо.
0
1.
Ну дак, и я о том же!

2.
>> Но формально поддержка внешнего терминала в ДОС была.
Ключевое слово «формально». Это был не настоящий терминал. Так, попытка попробовать поиграться во взрослые игры.
0
Это был не настоящий терминал. Так, попытка попробовать поиграться во взрослые игры.
Да почему не настоящий?

ДОС изначально поддерживал только внешний аппаратный терминал. 86-DOS разрабатывался для такой железяки как Seattle Computer Products (SCP). Эта железяка был классической для тех времен архитектуры «компьютер + аппаратный терминал». А уже потом MS купила 86-DOS, и прикрутили возможность работать с «локальной консолью».

Вообще ДОС много всего взял из СР/М а там многое было почерпнуто из UNIX. ДОС даже вполне можно отнести к концепции «все есть файл», вполне можно было делать такие вещи как
copy con com1
+1
На дак тогда с помощью этого терминала залогинтесь на соседний комп, и там выполните компиляцию проекта, а потом скопируйте объектник на третий комп, где запущен отладчик и пройдите десяток команд после main().

Предположительно, что второй комп — расположен в Канаде, а третий — это Raspberry-Pi, прикрученная к автокормилке куриц. (Недавно что-то подобное я читал на Хабре — про управление домашним хозяйством.)

Что-то я даже не могу себе представить такую Работу в ДОС-е. Точнее могу, но все программы, обеспечивающие сетевое взаимодействие нужно будет заранее установить. В Линуксе ничего этого делать не надо. Достаточно иметь сетевое подключение к интернету и учетную запись в системе. Даже не надо иметь заранее установленных программ. Всё можно проинсталлировать удалённо, не говоря уже о том, что можно запустить и остановить определенные процессы. А в виде высшего пилотажа даже переустановить систему, изменить ее конфигурацию, перезагрузить (согласно виндовому пристрастию перезагружать каждый раз!) систему и успешно залогиниться. Почувствуйте красоту мира UNIX/Linux!

Можно ли эти удаленные операции проделать в ДОС-е? Наверно можно, но какова будет цена за это?

Хотя мы о чём сейчас говорим? Наш разговор ушел в сторону — в направлении, что под ДОС-ом был текстовый экран и клавиатура, но это не было терминалом.
0
Не, ну это прелестно — сравнивать голый дос и полновесный дистрибутив GNU/Linux. Голый линукс, на секундочку, вообще одно ядро, с которым ты даже взаимодействовать не сможешь — оно без шелла.
А если сравнивать честно — то можно взять полный дистрибутив FreeDOS, там, полагаю, все требуемое обнаружится, а если и не обнаружится — можно доставить.
+1
А-а, так значит, в ДОС-е всё-таки нет полноценного терминала?
Или что? Мы о чем беседуем?
-2
Начни с определения вопросов «полноценный» и «терминал». Потому как если это означает «xterm+bash» то ответ «нет», а если это означает работу с аппаратным терминалом аля VT100 — то ответ «да». Причем даже в голом досе, так как в базовый комплект системы входят ядро и командная оболочка.
+3
мы начали с того, что в мире есть две парадигмы взаимодействия пользователя — UNIX-парадигма и парадигма Windows. Первая основана на формировании команд и данных в виде текста и передачи их программе, а вторая — на принципе «что вижу то и ткну мышкой». (Что не вижу, то недоступно.) И получение результатов работы программы в текстовом виде.

ДОС-овский «терминал» обладал внешне похожими признаками — тот же текстовый экран и клавиатура. Те же текстовые команды, и тот же текстовый вывод на экран. Но это не настоящий терминал. Этот терминал был сильно интегрирован с системой. Его нельзя было оторвать от системы и перенести в другое место.

Почему Вы видите только то, что на поверхности? Почему не хотите увидеть принципиальное отличие UNIX-терминала от того, что в ДОС-е называли консолью? Там же принципиальная разница! Хотя внешнее сходство — да, очень сильное.
0
Ну такой уж сильной принципиальной разницы там нет. Разве что досовский терминал подумбовее (в смысле ближе к dumb терминалу), юниксовый, как ни крути, по минимуму хотя бы vt100 реализовывал.
+1
мы начали с того, что в мире есть две парадигмы взаимодействия пользователя — UNIX-парадигма и парадигма Windows
Во первых, с этого начал ты. Я же считаю, что на сегодня есть два основных типа UI — CLI и GUI, а речь идет о особенностях реализации CLI в Windows и *nix.
Причем в обеих ОС реализованы оба с несколько разными подходами, так что в никсах CLI несколько удобнее, чем в винде.
Почему Вы видите только то, что на поверхности? Почему не хотите увидеть принципиальное отличие UNIX-терминала от того, что в ДОС-е называли консолью?
Потому что его нет. Это один и тот же CLI. Ну, это примерно как принципиальная разница между кнопочками Qt и кнопочками GTK.
Этот терминал был сильно интегрирован с системой. Его нельзя было оторвать от системы и перенести в другое место.
Вот не надо. UI реализуется оболочкой, и ее заменой или дополнением другим софтом сделать можно что угодно. Например, накатить на дос телнет и командовать ей по сети откуда угодно (в винде это уже из коробки).
0
>> накатить на дос телнет
А-а, понятно. Разговаривать далее уже неинтересно.

Потому что:
>> другим софтом сделать можно что угодно

Итак мы загнали тему разных подходов к взаимодействию пользователя и ПО в Виндовсе и в Юниксе в словесное болото.
0
Это потому, что подходы, в общем, идентичные. Разве что в юниксе больший упор на CLI и потому он более развит.
Ну и описанная тобой задача обычно в линуксе также реализуется сторонним софтом — SSH. По крайней мере, насколько я знаю (может быть, он уже и в шелл давно встроен — чего не знаю, того не знаю).
+1
До ssh уже были telnet, rsh, rcp.
0
Я знаю. Но не знаю, чем они реализуются, поэтому уточнил про ssh.
0
Например, накатить на дос телнет и командовать ей по сети откуда угодно (в винде это уже из коробки).
Как не было возможности зайти в ДОС по телнету, так и нет этой возможности и сейчас в Windows. Или я не прав, или это возможно?
0
Телнета нет, но ремут десктоп есть.
0
Вот, как раз хотел попытать сторонников виндовс (не вас):
с какого года появился RDP и удалённый вход в систему?
С какой версии винда стала реально многопользовательской системой?
0
Или я не прав, или это возможно?

Справедливости ради, телнет сервер был (а возможно и есть) на серверных версиях винды. Тип того (опция ниже телнет клиента):



Но толку от этого не было, сначала из-за скудности средств администрирования через CLI, потом появился PowerShall но было поздно.
0
Тогда уж вот это гораздо более в тему.

P.S. было время я там активно тусовался. и некоторая часть FAQ-а составлена из моих ответов :)
+1
Не, ну это прелестно — сравнивать голый дос и полновесный дистрибутив GNU/Linux.
 А давайте сравним почти голый линукс с полным досом.
 Инсталлятор Linux Redhat 3.03 (1996) запускается с дискет, с дву или трёх штук. С CD в то время компьютеры загружаться не умели или такая возможность только-только начала появляться. Уже с дискет был доступен конфигуратор сети, уже с дискет можно было продолжать инсталляцию по FTP или NFS. Возможно, были доступны протоколы HTTP и SMB, я не уверен за давностью лет. Можно было инсталлироваться по локальной сети или напрямую с серверов Redhat. Разумеется, с CD тоже.
 Последняя MS-DOS 6.22 (1994) своей сети не имела.

Теперь возьмём полновесный дистрибутив Windows.
 WFW 3.11 (1993) была сетевой системой, но с дискет не работала. Базировалась на предлежащей ДОС. Девяностопятка тоже.
 Инсталляторы WNT 3.51 (1995) и 4.0 (1996) тоже запускались с дискет. Возможности инсталляции по сети не было. Ну, только если вы с CD из-под доса запустите setup.exe, а в досе при этом будет поддержка сети. Тогда вы могли использовать сетевой комакт-диск на случай если NT не имела для него драйверов. Никакой возможности инсталляции с серверов microsoft не было.
можно взять полный дистрибутив FreeDOS
 Это не официальный MS-DOS. А так-то можно взять что угодно, а потом назвать ДОСом.
0
А давайте сравним почти голый линукс с полным досом.
Фигасе «почти голый». Но описанные возможности исталлятора впечатляют, да.
Никакой возможности инсталляции с серверов microsoft не было.
Возможно, это связано с тем, что винда коммерческая и M$ предпочитала торговать ей исключительно на дисках.
Это не официальный MS-DOS. А так-то можно взять что угодно, а потом назвать ДОСом.
Ну, по крайней мере это ориентирующийся на совместимость с MS-DOS клон и он запускает MS-DOS'овский софт. Да и в MS-DOS его софт вроде запускается.
И в любом случае некорректно сравнивать дистрибутив голой ОС с дистрибутивами линукса, которые полны стороннего софта.
0
На дак тогда с помощью этого терминала залогинтесь на соседний комп

я «логинился» ели так можно сказать о ДОС :) Вернее я управлял удаленно с аппаратного терминала машинами под DOS через сеть X25. PAD-s работали в прозрачном режиме, для того чтобы подключится к другому компу нужно было переконфигурировать «маршрутизацию» PAD.

То, что ДОС не умел пробрасывать терминал по TCP/IP не значит, что «терминал не настоящий». В том и идея, что терминал можно пробросить по любому транспорту, TELNET, SSH – это всего лишь частные случаи.
+1
Вы хотите сказать, что ДОС-машинка имела свою клавиатуру и экран и что там делала, а в это время Вы могли законнектиться к системе и выполнить каике-то системные команды типа скопировать с ХДД на флопп файл, запустить программу, отправить на принтер текст.

И работа в консолях этого компа определялась не конфигами и запуском дополнительных программам из AUTOEXEC.BAT и CONFIG.SYS, а уже была заложена в самой системе?

А потом, поработав удаленно, Вы могли разорвать соединение. Потом можно было подойти непосредственно к компу и открыть новую сессию работы уже с его локального дисплея и клавиатуры. И при смене консоли (терминала) не нужно было менять конфигурацию и перезагружать комп?

И эти средства перенаправления потоков ввода вывода уже были встроены в DOS?

И Вы могли послать сообщение с одного терминала на другой? (Аналог UNIX-овской консольной команды write)
0
Все эти претензии мне напоминают «да какой же это лазер, если он сталь не кромсает!» из обсуждения «лазер ли в лазерной указке»…
Различия безусловно есть, иначе не было бы доса и юникса, а был бы досникс. Но эти различия не являются принципиальными и зачастую относятся не к ОС, а к вопросам комплекта поставки.

И тем более в контексте статьи сетевой шелл ну совсем не к месту. В ней говорится исключительно про CLI и его ограничения в винде.
0
Оболочка как раз к месту!

Принципиальная разница между парадигмой CLI и парадигмой GUI (раз уж Вы упомянули эти термины) состоит в том, что когда мы хотим откомпилировать проект (ну, в частности — откомпилировать!), то согласно парадигме Виндовс мы должны с помощью оболочки запустить компилятор (или IDE) и на этом функции оболочки заканчиваются. Все остальные действия в том числе и взаимодействие компилятора (IDE) с пользователем происходит под управлением этого компилятора (IDE). И если компилятору нужно получить от пользователя огромный объем данных, он его получит. Но оболочка тут не причем. Оболочка стоит и ждет, когда компилятор (IDE) закончит работу.

В среде UNIX всё по другому. Среда (облочка) предоставляет средства для редактирования командной строки, в которой мы указываем как саму команду, так ее аргументы. И если пользователю нужно передать компилятору огромный объем данных, то UNIX-парадигма это тоже позволит сделать. Потому, что такая передача данных не противоречит парадигме UNIX.

Совсем другое дело, когда работа идет в среде Виндовс, а используются приемы работы UNIX.

Другими словами, если вы работа ведется в Виндовсе, то и нужно использовать преимущества Виндовс — сначала запускаем программу, а затем сама программа рулит процессом — что делать и как.

Если же работа ведется в UNIX/Linux, то опять же нужно пользоваться приемами, присущими UNIX/Linux — то есть готовим в оболочке сначала пакет информации (строку аргументов) (при этом компилятор еще не запущен) и только потом запускаем программу (компилятор).

Можно, конечно и наоборот. В Линуксе открыть окошки, взвести нужные флажки и топнуть на кнопочку «Compile», или в Виндовсе заготовить строку аргументов и «скормить» ее компилятору командной строки. И это будет работать. Но до поры до времени. То до какого-то разумного предела. После чего начинаются танцы с известными музыкальными инструментами. Михаил (автор этого топика) превысил этот предел. Вот и всё!

Свои посты (которые в самом начале топика) я писал для «молодняка». Почему на них отреагировали «бизоны», мне не совсем понятно. Впрочем, когда и где были разговоры на религиозные темы без срача!
0
Оболочка как раз к месту!
Я говорил про «сетевую оболочку». Не к месту упирание на то, что полноценный терминал должен быть сетевым.

В остальном — тут уже чуть ближе, действительно, в винде больше принято делать самостоятельные программы, а в никсах — цепочки склеенных пайпами утилит. Хотя 90-95% компиляторов под винду, даже тех, что отродясь к никсам отношения не имели, делаются как CLI-программы.

P.S. А вот любопытно мне, какие ограничения на длину командной строки у разных никсов. Должны же они были быть хотя бы у первых никсов.
0
Вы хотите сказать, что ДОС-машинка имела свою клавиатуру

ДОС стоял на банкомате. При старте выполнялась команда «CTTY com1». В банкомате стоял PAD, который пробрасывал com1 и com2 в пакетную сеть (com2 использовался для обмена данными с хостом банкоматов, com1 для терминала ). Я мог подключится, мог управлять софтом банкомата. Естественно, многозадачности там нет, но я мог остановить этот софт, что-то сделать в «чистом» ДОС штатными средствами, потом опять загустить клиент хоста банкоматов и т. д.

И эти средства перенаправления потоков ввода вывода уже были встроены в DOS?

Я же писал, они в ДОС были изначально, когда он даже не поддерживал локальную консоль.
0
Я просто помещю это сюда.

ДОС поддерживал «те самые» терминалы. Была такая команда CTTY которая позволяла перенаправить потоки на терминал, например, подключенный на СОМ-порт. По умолчанию ввод/вывод связан с устройством «CON».

Но, для того чтобы это работало программы должны использовать стандартные средства ДОС для ввода/вывода. А многие (может даже большинство) программ этого не делало (писали напрямую в видеопамять, читали напрямую из порта клавиатуры и т. д.) и соответственно в этом режиме не работали. Но формально поддержка внешнего терминала в ДОС была, правда этим практически никто не пользовался.

Возможно мы говорим об одном и том же, но разными словами.
0
Не, ну это опять претензия не к ОС и ее идеологии, а к софту под нее. Вон, ребята из селектела тоже долго удивлялись, как MC раскрашивает терминал, не поддерживающий раскраску (история по памяти, так что только примерная суть). Оказалось — лезет прямо в видеопамять. А в их эмуле терминала на виртуалке такой памяти нет и нишиша не работает. Вот тебе и линукс.
+2
для того чтобы это работало программы должны использовать стандартные средства ДОС для ввода/вивода

Все штатные утилиты ДОС, как и многие сторонние программы этот режим поддерживали. Безусловно, многие сторонние программы работали в обход ДОС (например через прямую запись в видеопамять). ДОС позволял работать через терминал, но не запрещал работать напрямую с железом.
+1
И эти средства перенаправления потоков ввода вывода уже были встроены в DOS?
Перенаправления потоков таки да, встроены в дос. Как и ключевой (для этой функциональности) системный вызов dup/dup2.
+2
TELNET, SSH – это всего лишь частные случаи.
Это протоколы прикладного уровня, а не транспортного уровня. Если противопоставлять TCP/IP, то NetBIOS и IPX/SPX, например. Если бы telnet работал, то он бы работал и через них.
0
Вы правы, но я под «транспортом» не имел ввиду конкретный уровень ISO OSI, просто так выразился.

Я к тому, что «терминал» не связан с конкретным прикладным протоколом или протоколом другого уровня. Древние аппаратные «труЪ» TTY работали, например, поверх чистого RS232 и сказать, что это были «не настоящие» терминалы нельзя. Скорее наоборот – то были терминалы, а сейчас люди называют терминалом программный эмулятор, зачастую не зная откуда берет начало эта история с TTY.
+2
Терминал — это совсем другое. Чтобы понять что это значит, нужно поработать с этим. Это то фундаментальное понятие, которое дается не через определение, а через чувство.
Не надо поэтизировать. Или мистифицировать. "Терминал" имеет вполне конкретное значение. Либо это символьный терминал (например VT100, VT220), либо это графический X(икс)-терминал.
Как мне кажется, под «терминалом» вы подразумеваете другое.
В POSIX-совместимых системах, таких, как UNIX и Linux, работа пользователя с терминалом осуществляется при помощи особой подсистемы, называемой TTY-абстракцией.
ru.wikipedia.org/wiki/TTY-абстракция
en.wikipedia.org/wiki/POSIX_terminal_interface
Но и в этом случае, при чём здесь «чувства»?
0
Спасибо за ссылки! Интересно почитать.

Вы как-то уж больно критически отнеслись. Только я хотел выделить разницу между тем «почитать как нужно управлять автомобилем» и «самому сесть за руль и пару годиков позажигать по дорогам России». Или изучить теоретический курс управления летательным аппаратом и полетать самому на лёгком самолете. Разница — огромная!

Так и по терминалу — можно почитать, и ничего не поняв, стать теоретиком. А можно практиковаться, сдабривая падения и шишки чтением вот таких ссылок, какие Вы привели.

Боюсь, что из меня плохой учитель, я не смогу объяснить почему ДОС-овский «терминал» — это не тот терминал, который UNIX-овский. Для этого нужно поработать пару лет под ДОС-ом, и под UNIX-ом.
0
Только я хотел выделить разницу между тем «почитать как нужно управлять автомобилем» и «самому сесть за руль и пару годиков позажигать по дорогам России».
Это разница между информацией и знанием. Знание приобретается через опыт.
0
Вы ошибаетесь, ДОС — не терминальная среда!
Возможно, я не очень хорошо знаю историю развития интерфейсов, но ноги и у командной строки DOS, и у командной строки *nix растут из примерно одного места, которое куда старше обоих систем.
Я, конечно, не буду спорить, что в никсах консоль куда более развитая и удобная. Нинай уж, почему ее не развивали в DOS, а насчет винды ответ вполне очевиден — там это по большей части костыль для обратной совместимости.
Ну и не надо про то, что дос не умеет терминал (в оригинальном значении этого слова). Оно не использовалось, оно не поддерживается программами, работающими в обход ОС, но терминал к ДОС подключить можно. Впрочем, речь не о нем, а о CLI.
Это будет что-то из серии два компа, соединённх сетью, причем, один из них эмулирует работу удалённого терминала.
В общем, оно так везде и было. Даже аппаратные терминалы вроде VT100 являлись специализированным компьютером. Сейчас — и вовсе два стандартных компа и соответствующий софт.
А те, кто пришел из мира Виндовс — у них это всё вызывает благоговейный ужас.
Да нифига. К тому же, в консоли винды многое из этого есть (а если поставить сторонний интерфейс консоли — то и вообще все).
И вариант 5 отметается в любом случае не из-за консоли (и так уже в ней работаем, сменить на более продвинутую — why not?), а из-за привязки к ОС прочего нужного пользователю софта (либо привычек и вкусов пользователя).
+1
Тащемта винда берёт начало от DOS и всё хорошее в ней оттуда. Скажем, чтобы установить программу fasm, я распаковываю fasm.zip в E:\prog\fasm, а хочу снести — жмякаю F8 и его нету. Некоторые проги, правда, любят срать своими данными в реестр и на системный диск, но для них у меня припасена утилитка reg2ini и в итоге они всё равно полностью поселяются в E:\prog. А в этих ваших юниксах всё связано со всем, любая мелочь размазывается по всей файловой системе, при этом тащит кучу зависимостей. Причём куда не плюнь, всё нужно качать из инета, т.е. болото зависимостей растягивается далеко за пределы машины.
Так что винда — это не только гламурные гуйнюшки…
0
любая мелочь размазывается по всей файловой системе, при этом тащит кучу зависимостей
При этом сносится в одно касание не оставляя хвостов.
Причём куда не плюнь, всё нужно качать из инета, т.е. болото зависимостей растягивается далеко за пределы машины.
Рабочий комп без инета практически бесполезен. Это можно признать и пользоваться всеми преимуществами, а можно изображать из себя старикана и ныть этому поводу на каждом углу. Каждый выбирает сам.
0
При этом сносится в одно касание не оставляя хвостов.
Ну, допустим, я устанавливаю debian-netinst в минимальной конфигурации. Затем пишу что-нибудь типа apt-get install kde. Что мне после этого сделать чтобы вернуть всё в точности как было?

Вообще, характерно, что в статьях линуксоиды обычно предлагают в тот-то конфиг вписать то-то, поставить то-то и то-то, скопипастить в терминал вот это, сделать make install и т.д. Но никогда не говорится как потом прибрать за собой. Закрадывается подозрение что не особо-то кого заботит что система напоминает содержимое помойного ведра…
0
Затем пишу что-нибудь типа apt-get install kde. Что мне после этого сделать чтобы вернуть всё в точности как было?
apt-get remove --purge & apt-get autoremove

Вообще, характерно
Это характерно если человек хочет чего-то необычного — «на лыжах и в гамаке». В этом случае он сам себе злобный буратино и папа карло в одном флаконе. Система этому не мешает.
Закрадывается подозрение что не особо-то кого заботит что система напоминает содержимое помойного ведра…
Да, это обычное состояние винды.
0
>> Ну, допустим, я устанавливаю debian-netinst в минимальной конфигурации. Затем пишу что-нибудь типа apt-get install kde. Что мне после этого сделать чтобы вернуть всё в точности как было?

А Вы отдаете себе отчет, что kde — это не просто какая-то мелкая программка, а целый комплекс? Что Вы обычно в Винде делаете, когда Вам нужно установить какое-нибудь мощное приложение, которое Вы еще не знаете, куда и чего оно может прописать и что оно может изменить в системе? Ну, допустим, Вы устанавливаете того Касперского или Eset. А потом Вы решили удалить это всё и привести систему к исходному виду?

Я уверен, что прежде чем начать установку сложного и незнакомого программного обеспечения Вы сделает слепок (back-up) системы. Так же поступайте и в Линуксе!

Если Вам сложно выполнять эти действия в Линуксе, ну это значит, что Вы еще не находитесь на том уровне, чтобы этим заниматься. Вас ведь не удивляет то, что какая-нибуль секретарь-Оленька не умеет устанавливать Skype на свою Винду. Вот, это и есть Ваш уровень в Линуксе. Просто у Вас мнение о себе строится на основе Виндовса, а Линукс — это не Виндовс, хотя внешне те же менюшки и кнопочки.

Перефразирую. «Вообще характерно, что в бухгалтерских статьях про 1С, не упоминаются проблемы управления памятью и сборкой мусора. Никогда не говорится как установить сетевое соединение или как потом прибрать за собой...»
В общем, подразумевается, что если вы уже владеете этими знаниями. Если нет, то видимо, следует почитать соответствующую литературу. Или оставить эту область деятельности. Ну, в общем, как-то так.

А претензии свои предъявлять можно только на основании заплаченной за продукт суммы. Иначе вас просто будут посылать. Сколько денег Вы заплатили за KDE? Вот на столько и высказывайте свои «фи»! А если продукт не нравится, и Вы в него не вкладывались, то Вам и терять нечего — оставьте его в покое! Вас ведь никто туда насильно не тащит. Вы всё делаете по своей доброй воле. Так к кому какие претензии?
0
>> А в этих ваших юниксах

Ах, какая прелесть! Оформлю-ка я это в рамочку и на стенку, на видное место.

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

А вот это как раз из той оперы, где поётся не про недостатки ОС-и, а про незнание инструмента. Со стороны очень забавно выглядит, когда человек, не знающий предмета, берется судить о нём.

>> куда не плюнь, всё нужно качать из инета,

А под Виндой Вы где обычно берете программы?

Вот, в Линуксе, я например, беру необходимый софт из репозиториев. Репозиторий — это такое здоровенное место-хранилище пакетов программ, где, можно сказать, находится 99% всех программ для вашего дистрибутива. Оставшийся 1% программ я отношу к частным репозиториям разработчиков. Так вот, прежде чем попасть программе в репозиторий и стать доступной, она проходт проверку на совместимость с другими программами, на совместимость с ядром. Ее исходные тексты просматриваются на предмет «закладок», вирусов и прочих вредоносных действий. Вот сколько я работаю в Линуксе, у меня еще ни разу не было прокола по причине, что я в Интеренете скачал зараженную прогу. Кредит доверия к репозиториям и к прогрпммам, в них размещщенным, — огромнейший! Во всяком случае, значительно больше, чем к Виндовым программам, которые тоже скачиваются из того же интернета.

А собственно, где сейчас этого интернета нет? К слову сказать, мне, да и многим другим людям, удобнее устанавливать новую версию Линукса не с CD/DVD или с флешки, а по сети. Старт, конечно происходит с флешки, но основная масса пакетов берется из интернета. Это быстро, удобно и всегда будет «накатана» последняя версия.

Как вы выразились «болото» — это не то, что вы думаете. Самое настоящее болото — это Реестр у Виндовса. Тут сам черт ногу сломит, не говоря уже о том, что полным полно всяких тайных закуточков, в которых принято размещать всякие секретные от пользователя данные. С ума сойти — делать секреты в квартире у пользователя! А то, что Вы называете болотом — так это болото на ваш неискушенный взгляд. На самом деле, если быть посвященным в технологии, то они уже не кажутся колдовством и магией.

Разница лишь в том, что Виндовс сознательно отвлекает пользователя от знания технологии бьет по рукам, когда он пытается залезть в них. А мире UNIX/Linux знания технологии сдерживаются лишь желанием самого пользователя знать. Что называется — почувствуйте разницу: в одном случае вам запрещают знать, а в другом — вы сами не хотите знать. Дак кто виноват в том, что вы не обладаете определёнными знаниями и вам кажется, что везде «болото»?
0
А под Виндой Вы где обычно берете программы?
А где угодно. Тем она и хороша, что программа — это всё ещё просто исполняемый файл, папочка с данными и инишика. Программа берётся где мне нравится, хоть из журнала дамп переписывай. Винда не принуждает меня выбирать программу из тех двух (ста, тысячи, неважно), которые есть в помойке в интернете под названием «репозиторий».

А собственно, где сейчас этого интернета нет?
Например, там, где он отвалился, потому что дворник перерубил лопатой кабель. И вообще, нахрен мне зависимости от каких-то левых контор и чуваков, которые могут обанкротиться или просто решить что мне пора переходить на новую «улучшенную» версию.
0
А где угодно. Тем она и хороша, что программа — это всё ещё просто исполняемый файл, папочка с данными и инишика. Программа берётся где мне нравится, хоть из журнала дамп переписывай.
Ну и в чем разница? Ровно так же можно поступить в линухе.
Винда не принуждает меня выбирать программу
Спасибо, поржал.
И вообще, нахрен мне зависимости от каких-то левых контор и чуваков, которые могут обанкротиться или просто решить что мне пора переходить на новую «улучшенную» версию.
Тогда я вообще не понимаю почему вы виндой пользуетесь. Вы в точности описали поведение винды.
0
>> А где угодно.
Вы не поверите, но в Линуксе точно так же! Я могу написать прогу и принести ее на работу на флешке. Я могу взять исходный текст программы в интернете (с сайта Хаккера, например, или подкачать проект с Гитбакета) и откомпилировать. Просто для этого дела у меня есть определённые знания, а у Вас их нет.

И я специально не затрагиваю тему вирусов, иначе мы вообще погрузимся в пучину рассуждений, почему в среде Линукса вирусы в принципе не могут жить.

Вы правильно сказали — «которые есть в помойке в интернете» Интернет — это большая помойка. Но репозитории — не относятся к мусорным свалкам. Репозитории — это скорее чистые родники. В репозиториях нет «проблемных» программ. И к стати, там всё упорядеченно. Нужно только уметь четко представлять что конкретно ты хочешь получить. Выбор пакетов программ в репозитории превышает 40 тысяч — это чрезвычайно много. Не так давно в интеренете стоял ор, что под Линуксом нет программ. Ага, нет!

Дворник порвал сетевой кабель. И что? Как Вы будете решать проблему под Виндой?
Так вот, в Линуксе я буду делать тоже самое. А собственно, почему я должен делать как-то иначе?
0
Я могу написать прогу и принести ее на работу на флешке. Я могу взять исходный текст программы в интернете (с сайта Хаккера, например, или подкачать проект с Гитбакета) и откомпилировать.
Если из моей винды выдернуть сетевой кабель, ничего ней не потеряет функциональности, кроме нескольких прикладных программ. Как я 10 лет назад таскал домой интернет на дискетах, так и можно будет дальше работать. Вообще, у меня давно есть желание всё что связано с сетью выкинуть в виртуалку (ибо оно как правило всё дырявое и тормозное, и нечего ему по хорошему делать в основной системе).
В этих ваших линухах без интернета отвалятся всякие репозитории и, возможно, куча другого хлама.

Просто для этого дела у меня есть определённые знания, а у Вас их нет.
Если мне это надо будет, посмотрю в гугле как это делать. Но мне пофиг — я, как пользователь, не собираюсь ничего компилировать. Это задача программиста. ЛЛео, кстати, хорошо написал на эту тему:
А я пользователь, я не хочу и не умею писать и компилировать софт! Не надо мне рассказывать, как это просто и здорово! Мне на хуй не уперлось читать тонны документаций и медитировать, что означает и как поступить если «ОШИБКА КОМПИЛЯЦИИ: установите библиотеку не ниже huiTamLib-2.4.0». При том, что в системе, разумеется, давно присутствует какая-нибудь «huiTamLib2-5.1»? Ее предлагается снести, чтобы отвалилось полсистемы или обновить до старой, чтоб полсистемы отвалилось?

Но репозитории — не относятся к мусорным свалкам. Репозитории — это скорее чистые родники.
По репозиториям валяется то, что туда решит засунуть мейнтейнер репозитория. Например, старьё двухлетней давности, которое считается стабильным (в то время как по факту текущая версия программы куда стабильней). Вообще, как можно говорить, что куча, куда свалено что попало в непонятно какой конфигурации, непонятно какой версии — не помойка?
0
Если из моей винды выдернуть сетевой кабель, ничего ней не потеряет функциональности, кроме нескольких прикладных программ.
Ну и? Ровно то же в линухе.
Если мне это надо будет, посмотрю в гугле как это делать.
Ага. Без интернета. Ну-ну.
в то время как по факту текущая версия программы куда стабильней
Ничего не мешает поставить текущую.
Вообще, как можно говорить, что куча, куда свалено что попало в непонятно какой конфигурации, непонятно какой версии — не помойка?
Это вы про свой комп?
0
Ничего не мешает поставить текущую.
Ну и нахрен эти репозитории нужны тогда? Даже в родном репозитории какого-нибудь nginx он лежит в рандомной конфигурации, которая совершенно не подходит в любом более-менее нестандартном случае (а под линухом это значит, что никаких тебе update и upgrade, компилируй его каждый день или как там он часто обновляется...)
0
Ну и нахрен эти репозитории нужны тогда?
Текущую поставить из репозитория, если вы не поняли.
Даже в родном репозитории какого-нибудь nginx он лежит в рандомной конфигурации, которая совершенно не подходит в любом более-менее нестандартном случае
Зная вас я не удивляюсь, что вам нужна настолько особая конфигурация, что софт надо из сорсов пересобирать. Кстати, на досуге задумайтесь над тем, что ни под дос, ни под винду у вас такой возможности нет вообще для подавляющего большинства программ.
(а под линухом это значит, что никаких тебе update и upgrade, компилируй его каждый день или как там он часто обновляется...)
Нет, не значит.
0
Кстати, на досуге задумайтесь над тем, что ни под дос, ни под винду у вас такой возможности нет вообще для подавляющего большинства программ.
Это уж смотря какой софт выбирать, у меня стоит немного самосбора и довольно много опенсорса. Под линуксом, кстати, такой фокус тоже далеко не со всем пройдет (другое дело, что обычно процент опенсорса там куда выше — от 90% в большинстве случаев).
0
Я живу на Урале. Здесь преимущественно дуют западные ветры. Но сегодня дует южный. А в дворе нашего дома, из-за уникального расположения дома и арки в нём арки для проезда, ветер почти всегда северный. Но в данный момент, из-за того, что в арке стоит пожарная машина, во дворе дома западный ветер. Но вот сейчас был порыв юго-восточного.

Так какое же направление имеет ветер?
0
К чему это?
Я говорю о том, что разница по этому вопросу между виндой и линуксом не так уж велика и зависит от предпочтений юзера. Я поклонник опенсорса, так что и в винде могу при желании пофиксить большинство программ самостоятельно. Прям как в линухе.
0
это к тому, что разница между Виндой и Линхом зависи от того на каком уровне мы их сравниваем.

На уровне главбуха Эллеаноры Павловны разницы никакой — и там там и сям, кнопочки менющечки, и принтер не печатает, мышка заедает. И клавишу «эскейт» ещё посмотрите!

На уровне секретаря-референта Леночки — системы немного разные. Где мой диск Цэ? И кудя я сейчас по вашему должна нажимать мышкой?

На уровне сисадмина Эдика, системы разные. Да нахрен мне эти заморочки с касперскими тормозами! Да и конфигурировать комп, который стоит как роутер, ну, который на Винде в 224-ой комнате, — иди, сам меняй ему таблицы!

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

А разработчик
0
Если ты внимательно изучишь дерево комментариев, то увидишь, что сравнение идет по одному вполне конкретному вопросу, и Леночки с Эдиками тут ни при чем.
0
Ну всё. Тупик. Каждый о своем.
0
Что характерно, отвечал я evsi и он меня отлично понял.
0
да. Всё правильно. Это я вмешался в ваш разговор и сломал нить рассуждения. Мои извинения.
0
(другое дело, что обычно процент опенсорса там куда выше — от 90% в большинстве случаев)
Гораздо больше. У меня, например, из не-опенсорса только игл.
0
Ну, эт все зависит от пользователя же. У геймера, например, из опенсорса будет только сама система, поверх которой крутятся проприетарные Steam и игры. А у приверженца открытых решений на винде закрытой опять же будет только система (я не фанатик, так что нахожусь где-то посередине и опенсорса с проприетарщиной у меня где-то поровну).
0
Когда я говорил:

>> Просто для этого дела у меня есть определённые знания, а у Вас их нет.

я имел ввиду, что у Вас нет ЛИНУКСОВЫХ знаний, про виндовые знания я ничего не говорил. Я уверен, что они у Вас есть. Но согласно Вашим претензиям к Линуксу, Ваш уровень уровень Линуксовых — только ЛИНУКСОВЫХ, не Виндовых!!! — знаний маловат.

>> Если мне это надо будет, посмотрю в гугле как это делать. Но мне пофиг — я, как пользователь, не собираюсь ничего компилировать. Это задача программиста. ЛЛео, кстати, хорошо написал на эту тему…

Ну, я еще раз повторю — Линукс для специалистов. Виндовс — для широких масс.

Определяйтесь уже: либо крестик, либо трусы. А то уже пальцы болят вам объяснять, где у Вас лежит проблема. Да и, в конце концов, что я — Ваш домашний доктор, чтобы лечить Вас? Добывайте знания сами!
0
А нужны ли мне эти знания? Пока я могу зайти на сайт автора программы, слить xxx.zip, распаковать его в E:\prog\xxx и пользоваться с удовольствием, у меня *вообще* никакого желания не возникает трахаться с репозиториями в которых валяется непонятно что, собирать что-то из сорцев (попутно ставя на комп гигабайты хлама, который потом толком не уберёшь...)
+1
а кто Вас заставляет это делать?
0
Агитаторы всякие )))))
0
Дак посылайте их лесом! И живите своим умом.
0
Дак посылайте их лесом! И живите своим умом.
Идите вы лесом! Мы сами как-нибудь разберемся, что на надо в каждом конкретном случае.

)))))
+2
а меня то за шо? (с)
Я что, агитирую за Линукс что ли? Я ведь русским по черному пишу — Каждый сам выбирает то, что ему удобнее.
0
Рефреном агитка так и сквозит )
0
А в этих ваших юниксах всё связано со всем, любая мелочь размазывается по всей файловой системе, при этом тащит кучу зависимостей.
Расскажите пожалуйста, с какого года в DOS и в windows появился менеджер пакетов, с каких пор появился стандартный для всех программ способ инсталляции и деинсталляции программ?
0
Для линкования большого количества файлов с gcc достаточно список с
путями файлов разделённых пробелами положить в отдельный файл, скажем,
list:

dir1/file1.o dir1/file2.o file3.o dir2/file4.o

Для линкования, в том месте, где в командной строке шёл список файлов,
вместо него вставляем @list

Было
arm-none-eabi-g++… dir1/file1.o dir1/file2.o file3.o dir2/file4.o…

Стало (где list — это название файла со списком файлов)
arm-none-eabi-g++… @list…
+4
Хорошо, попробуем. Только с составлением списка файлов остаются непонятки (через make-файл? снова возвращаемся к варианту №3).
0
Вот, нашёл:
community.freescale.com/thread/334455
отмечено как «Правильный ответ»

Шаг 1.
Воспользуемся тем, что автоматически генерируемый makefile при возможности подгружает makefile.defs из корня проекта.
Создадим в корне проекта свой makefile.defs со следующими тремя строчками:

$(shell rm ObjectList)
$(foreach obj, $(OBJS), $(shell echo $(obj) >> ObjectList))
$(shell echo $(USER_OBJS) >> ObjectList)

Данный скрипт стирает файл ObjectList и создаёт его заново заполняя списком object файлов, которые нам нужны при линковании.

Шаг 2.
Project properties -> C/C++ Build -> Settings -> Закладка Tool Settings -> Выбираем в списке Cross ARM C++ Linker
В поле «Command line pattern» заменяем $(INPUTS) на наш файл @ObjectList

Вроде работает
0
Спасибо, оно действительно работает. Только очень уж долго. Проект из 250 файлов сканирует 30 сек.
0
Быстрый вариант — после первого build'a, переименовать makefile.defs в _makefile.defs, чтобы его не видел makefile. Тогда ObjectList не будет пересоздаваться каждый раз. Обратно переименовывать только при добавлении в проект новых файлов. Неудобно, только, что в ручную.
0
Слегка поэксперементировал.

Добавил проверку, чтобы ObjectList собирался только, если он не существует

Makefile.defs:

ifeq ("$(wildcard ObjectList)","")
$(foreach obj, $(OBJS), $(shell echo $(obj) >> ObjectList))
$(shell echo $(USER_OBJS) >> ObjectList)
endif


Добавил собственный target myclean, который полностью копирует clean (скопировал из сгенерированного makefile'a) + стирает ObjectList
В корень проекта надо добавить Makefile.targets

myclean:
	-$(RM) ObjectList
	-$(RM) $(CC_DEPS)$(C++_DEPS)$(OBJS)$(C_UPPER_DEPS)$(CXX_DEPS)$(SECONDARY_FLASH)$(SECONDARY_SIZE)$(ASM_DEPS)$(S_UPPER_DEPS)$(C_DEPS)$(CPP_DEPS) Test.elf
	-@echo ' '


Project properties -> C/C++ Build -> Закладка Behaviour -> Значение поля «Clean» меняем с «clean» на «myclean».

Теперь после добавления файла в проект, достаточно сделать clean и ObjectList пересоберётся при следующем build'e.
0
А почему бы не сделать ObjectList зависимым от того файла, который определяет список файлов для компиляции/линковки? Тогда мейк его автоматически будет перегенерировать при изменении списка файлов.
0
Логично, но я не уверен, что в Eclipse этот список существует. В нём же не как у людей: он берёт все файлы из папки, можно только какие-то из них исключить (filter), в отличие от остальных IDE, где, действительно, каждый компилируемый файл надо добавлять в проект.
Хотя, поищу, вдруг есть где.
0
Кроме make есть и другие системы сборки, например, SCons, CMake, qmake, ant, maven и др. И многие из них имеют более приятный синтаксис билд-файлов и богатые возможности чем make.
Я SCons использую для своих проектов и maven на работе.
0
Но make такой привычный и прямой. Еще останавливает то, что для bare-metal компиляции не нужно проверять зависимости, делать конфигурирование, а это основное преимущество других систем сборки, и здесь оно теряется.
0
для bare-metal компиляции не нужно проверять зависимости
А если в проекте есть несколько различных типов устройств, использующие общие либы, модульные и интеграционные тесты, которые автоматически собираются и выполняются, загрузчик к которому для каждого из устройств подготавливается образ.
Совсем не нужны зависимости :)
0
Внутренние зависимости разгребать самому в любом случае. Я про возможности указать, что нам нужна libastral и получить правильные опции на куче поддерживаемых системой сборки платформ.
0
Внутренние зависимости разгребать самому в любом случае.
Совершенно не обязательно.
0
Как система сборки поймет чего я хочу? Где у меня тесты, где библиотеки, что от чего зависит и каким компилятором это собирать?
0
Вы не поверите, но очень много информации о зависимостях можно получить а) из общих соображений (например, *.с <-> *.o), б) скомпилировав исходники (gcc -M/-MM).

Многие системы сборки для других языков (maven, gradle, sbt, и так далее) могут сделать даже больше, включая поиск и загрузку библиотек с учетом версий (хотя зависимости от библиотек надо указывать, но вот где их брать это уже забота системы сборки), сборку сложных многомодульных приложений (автоматически учитывая зависимости между модулями), автоматический прогон тестов и еще кучу других вещей. Практически все они используют некую стандартизованную структуру директорий для решения этих задач. Как правило, возможность изменить структуру директорий есть (у того же maven-а, например), но этим никто не пользуется по ряду причин (во-первых, структура вполне удобна, во-вторых, унификация структуры проектов упрощает как разработку, так и сопровождение, вхождение новых сотрудников в проект и так далее). Замечу, что, помимо сборки как таковой, как правило все подобные инструменты предполагают (конфигурируемый, при необходимости) «жизненный цикл» артефакта (то есть бинарника, библиотеки, и так далее). Помимо компиляции и сборки сюда входят, например, компиляция и прогон юнит-тестов, генерация исходников, валидация состояния проекта, верификация собранного артефакта, прогон интеграционных тестов, загрузка артефактов в репозиторий, развертывание приложения.

Из сугубо С/С++ — ориентированных систем достаточно любопытно, на мой взгляд, выглядит SCons, хотя, возможно, те, кто такими проектами занимается профессионально, подскажут и другие инструменты.
0
А если в проекте есть несколько различных типов устройств
… то можно это разрулить в Makefile …

Нет, я Вас понимаю, и даже знаю кучу умных слов, которые актуальны для «энтерпрайз»: Dependency Injection, Mock-объекты … и прочие эти наши средства continuous integration :)

Но стоит ли говорить об этом, в контексте данного ресурса? Для большинства озвученных здесь задач средств классического make хватает с головой.
0
На хабре описывался какой-то эмбед-проект, авторов которого заколебал make и они написали свою систему сборки. На нем же О_о.
0
Но стоит ли говорить об этом, в контексте данного ресурса?
Это примерно из той же категории, что и «зачем радиолюбителям SMD компоненты?». То, что тут много любителей вовсе не повод не использовать современные средства. Программные в том числе.
0
То, что тут много любителей вовсе не повод не использовать современные средства.

Может и так, спорить не буду. Я использовал CMake в своих любительских проектах, но потом как-то незаметно для себя вернулся к make. Банально не было задач, на которых CMake бы мог мне реально помочь, а «make такой привычный» :)
0
Но make такой привычный и прямой.
Привычный — да. Прямой? Сильно не уверен. Со времен создания make прошло почти 40 лет, разработка софта с тех пор несколько изменилась и «прямизна» make нынче воспринимается как та самая простота, которая хуже воровства.
+1
ищите сами себе проблемы своими мэйками и подобной хренью
вот кусок моего рабочего .bat файла, хоть тыщу файлов на вход
arm-none-eabi-gcc -mcpu=cortex-m3 -Wall -mthumb -ffunction-sections -g3 -Os -c -I.\ *.c
arm-none-eabi-gcc -T"stm32f100rb.lsf" -Xlinker --gc-sections -Wl,-Map,superproga.map -mcpu=cortex-m3 -mthumb -g3 -o "superproga.elf" *.o
-1
ага, каждый раз все заново перекомпилировать, даже если просто поменялся коментарий.
0
я так и делаю и не жалею, времени это занимает мало
0
Это приемлемо пока весь код влезает на тетрадный лист мелким почерком.
0
Надо учитывать, что нотация *.o не избавляет от проблемы слишком длинной командной строки, так как ббрабатывается коммандным процессором и результат записывается в ту-же командную строку, с теми-же ограничениями на длину.
0
Ы? С чего бы? Cmd передает *.c в программу как есть, а та уже сама разбирается, что за дрянь ей скормили (многие плюются). Разве что gcc сам развернет *.c в километровую строку и передаст следующей вызываемой утилите.
0
Да, это я с bash-ем попутал, виндовая cmd так не делает.
0
Что за проект собираешь? Узнаю компоненты Cyclone TCP от ORYX. На каком железе используешь?
0
TE-STM32F107, по проекту ничего интересного не расскажу. Использую LwIP, в принципе хватает, для сравнения решил пощупать свежий стек CycloneTCP. И тут такая засада получилась. Ранее в другом проекте пришлось упаковать STemWin и SPL в отдельные библиотеки.
0
Стек очень вкусный, из коробки много чего умеет. Примеры использования очень наглядны, но стек еще не получил распространения. Впервые вижу использование его в этой статье, хоть только в качестве примера.
0
Юзаю макось и в ус не дую.
0
Аналогично!
0
Каждый уважающий себя эмбедер рано или поздно слезает с кустарщины на KEIL или в крайнем случае на IAR :)
Ваше время тоже придет.
0
Я прошёл через Keil (ещё под 51-й контроллер), затем пользовал IAR (AVR, AT91SAM7S). Честное слово, возвращаться назад не хочу. Кустарная Эклипса + GCC меня вполне устраивает.
0
Как раз сборка исключительно в IDE и есть кустарщина. В программировании этот этап был пройден еще в 90-х. Причем уже тогда это считалось кустарщиной.
0
В программировании этот этап был пройден еще в 90-х.
Ну, «пройденный этап» – это изменения в методологии разработки и в управлении жизненным циклом продукта. В программировании («алгоритмы + структуры данных», если верить Вирту) мало что поменялось :)

Просто вы смотрите на все с точки зрения управления проектом, через призму «энтерпрайз». Но нельзя «под оду гребенку» ровнять разработку в «энтерпрайз» и роботу над индивидуальными проектами уровня «just for fun».
+4
Нет, я имел в виду именно то, что написал — сборка в IDE это пройденный этап. Причем это касается даже мелких проектов «для себя». Кто хоть раз наступал на грабли «обновил IDE и программа не собирается/не работает» тот понимает о чем речь.
В программировании («алгоритмы + структуры данных», если верить Вирту) мало что поменялось :)
Поменялось очень многое. Точнее даже не поменялось, а сильно расширилось. Да, остались и алгоритмы и структуры данных (впрочем, это основа основ программирования, было бы странно, если бы они исчезли), но и то и другое многократно расширилось и усложнилось со времен Модулы 2.
Просто вы смотрите на все с точки зрения управления проектом, через призму «энтерпрайз».
Но-но, не надо меня обзывать ПМ-ом :) Я архитектор (уточню: пишущий архитектор) и смотрю на разработку, в первую очередь, с точки зрения эффективности работы отдельного программиста. Да, это сильно отдает «энтерпрайзом», но без этого даже в программировании «just for fun» очень легко скатиться в кустарщину. Если провести аналогию с электроникой, то любители, которые не стремятся идти в ногу со временем и не заинтересованные в своем развитии превращаются в кустарей.
0
Кто хоть раз наступал на грабли «обновил IDE и программа не собирается/не работает» тот понимает о чем речь.
Ну а кто наступал на грабли «обновил GNU-шные компиллеры или эклипс, и получил нерабочий бинарник к кучей глюков и проблемы при сборке» тот тоже поймет о чем речь :)

PS.Нормальные IDE обновляют только тогда, когда возникает в этом реальная насущная необходимость, а не просто так. Обычно основываясь на правиле «работает = нетрож!», ибо разработчик != бетатестер.
0
Ну а кто наступал на грабли «обновил GNU-шные компиллеры или эклипс, и получил нерабочий бинарник к кучей глюков и проблемы при сборке» тот тоже поймет о чем речь :)
Возможно. Если таковые найдутся.

PS.Нормальные IDE обновляют только тогда,
Тогда зачем вы обновляли еклипс? :) Это ж не кейл или иар какой-то, что бы его обновлять.

Обычно основываясь на правиле «работает = нетрож!», ибо разработчик != бетатестер
Проблемы со сборкой строго в IDE не ограничиваются тем, что я упомянул. Это только то, что лежит на поверхности.
0
Если таковые найдутся.
Да, вполне. Обновление AVR Toolchain сломало компиляцию AVRBOOT — оно теперь не лезет в маленький бутсектор (не помню, 512 или 1024 байт). Вроде как связано с изменениями в обработке inline'ов новой версией gcc.
0
Меня особенно возбуждает факт «обновление по глупости». Это я про себя!

(далее офф-топ. Можно не читать.)

Давным-давно, когда я сидел под Виндой и юзал пиратский IAR, раз в пол-года и в полном соответствие с парадигмой Винды топать мышкой по тому, что видишь, и только уже потом думать, что натворил, — я несколько раз подновлял прошивку программаторов. Особенно страдали от этого программаторы для MSP430.

Сидишь, лепишь проект, всё мысли только о том, как не упустить нить того, что хочется сделать и как это «красиво» сделать. Доводишь проект до какой-то логической точки. Естественно, торопишься. Успешно компилируешь, пытаешься залить код в таргет, на экран выскакивает окно с 2-3 строками какого-то сообщения и вопросом «заливать или не заливать?». Читать и вникать в суть — да ну его нахрен! Конечно, заливать! Топ мышкой по «ОК».

И только потом, когда вместо ожидаемых 10-20 секунд заливки время распечатывает уже вторую минуту начинаешь догадываться, что что-то пошло не так. Бля! Оказывается меня спрашивали «заливать ли новую версию в программатор». Ну и ладно! Не помешает. Дождемся окончания процесса.

Дождался. Программатор не видится вообще. Виндовая перезагрузка в стиле «если ничего не помогает — перезагрузись!» только подтверждает, что только-что на свет родился кирпич.

Всё, приплыли! Теперь надо останавливать основную работу и восстанавливать старую прошивку. Ладно, когда есть где ее взять. А сколько раз в начале этих «ритуалов» было, что прошивку негде взять! Приходилось бегать по людям и просить доверить мне их программатор, чтобы вынуть оттуда оригинал. Кто-то давал, а кто-то отмораживался типа «Работы полно. Звини, друх, не могу!» Эх, Винда-Винда! Покойся ты с миром!

Я понимаю, что основная проблема не в Винде, а во мне. Это ведь я, не читая сообщений, топаю по «ОК» и потом удивляюсь. Но скажите мне, почему под Линуксом за эти 7-8 лет мне ни разу ни одному программатору не удалось вот так по глупости снести башку. А я вам отвечу. Винда расслабляет внимание, а Линукс, наоборот, — дисциплинирует. Сколько раз при инсталляции программ под Виндой вы, не читая, топали по кнопке «Далее»? Почему Вы не читаете? Да потому, что нафиг оно не нужно!

«Вы хотите закончить работу?» — «ОК»
«Вы точно хотите закончить работу?» — «ОК»
«Вы в самом деле хотите закончить работу?» — «ОК»
— Уффф! Наконец-то вышли из программы!

Выйти из программы за три шага — просто гениально. Не менее гениально смотрится предоставить возможность подновить прошивку программатора во время программирования таргета.

Я не говорю, что Винда плохая. Я лишь говорю, что она не отвечает моим требованиям. Она относится ко мне не как к партнеру по бизнесу, которому можно и нужно доверять, а как к какому-то не очень обученному пользователю на расслабоне. Она заботиться о том, что в данный момент не иметт смысла, и более того — даже отвлекает. То есть Винда больше вредит работе, чем помогает. С моей точки зрения.

А добивает весь этот ансамбль неполноценностей то, что я за софт должен платить достаточно ощутимые бабки (то есть любое вложение денег в технологию провоцирует на дальнейшие платежи, ибо зачем платил, если меняешь платформу?), либо разрушай свою карму (пиратское отношение к софту неизбежно будет отражаться и на других сферах бытия). А вирусня! А тормоза Касперского! И повышенные требования к железу компа! Да ну его нафиг! Не моё это, не моё!

Поэтому у меня с Виндой нет взаимной любви.

Виндузятники! Вот он я — нападайте! Рвите в клочья!
0
0
Вроде как связано с изменениями в обработке inline'ов новой версией gcc.
Характерно. Кодогенерация во всех компиляторах из года в год становится всё более убога.
Скажем, новые версии M$VC даже тригонометрические функции FPU не хотят вставить интринсиками…
Можно ещё вспомнить libc-avr. В последней версии задепрекейтили все near-варианты функций работы с прогмемом, а то что предлагается взамен — это какой-то ужос. Достаточно сказать, что после загрузки четырёх константных байт адреса в регистры, тут же вставляется проверка значений в этих регистрах и какие-то условные действия. Позор.
0
Зачем тогда было обновлять?
0
Этот вопрос остается открытым.
0
Скажем, в начале 90-х обновление было необходимо в тех случаях, когда программа писалась на плюсах — с каждой новой версией улучшалась поддержка возможностей языка.
0
Да не плюсах так всегда, не только в 90-х. Отдельно разрабатывается стандарт, потом компиляторы постепенно (за несколько лет, постепенно добавляя поддержку новых фич) подтягиваются к полному соответствию этому стандарту, появляется новый стандарт.

В отличии, например, от C#, где MS выкатывает новую версию языка или фреймворка, и она по факту становиться стандартом (и одновременно эталонной реализацией нового стандарта). Кстати, а как в этом плане обстоят дела в современной Java?
0
Да не плюсах так всегда, не только в 90-х. Отдельно разрабатывается стандарт, потом компиляторы постепенно (за несколько лет, постепенно добавляя поддержку новых фич) подтягиваются к полному соответствию этому стандарту, появляется новый стандарт.
Ну, положим, сейчас ситуация сильно отличается. Во-первых, есть стандарт как таковой. Да, есть наметки на новый, но он пока в проекте. Имеющийся стандарт худо-бедно поддержан практически всеми, кто называет свой компилятор «С++». Можно гоняться за новыми фишками языка, а можно и не гоняться и писать сравнительно переносимо. Тогда ситуация была принципиально другой — стандарт в процессе обсуждения, каждый вендор пытается что-то запилить в язык свое, в надежде, что это потом пройдет через комитет. И с переменным успехом это у многих получается, поэтому попытки продолжаются. То, что не удалось пропихнуть через комитет — выпиливается из очередной версии. Все эти разброды и шатания продолжались вплоть до выхода официального стандарта.

Кстати, а как в этом плане обстоят дела в современной Java?
Все достаточно просто и прозрачно: реализации обратно совместимы, а что попадет в новую хоть и зависит от оракла, но предварительно проходит обсуждение и обкатку в подгруппах (так называемые JSR — Java Specification Request) по отдельным фишкам. Надо заметить, что процесс хоть и не очень быстрый, но весьма надежный, поэтому переход на новые версии дается практически безболезненно. Переходить или не переходить на новую версию — вопрос больше инфраструктурный. Поскольку о том, что попадет в язык более-менее известно заранее, то решение о том, на какую версию ориентироваться зачастую можно принять наперед, например я знаю проект, который писался под Java8 еще до официального релиза. Точно так же знаю немало проектов, которые в стадии «ленивой поддержки» и до сих пор используют Java6. Вобщем, какой-то особой гонки за версиями или еще чем-то таким нет.
0
Ну, положим, сейчас ситуация сильно отличается.

Не знаю почем вы считаете, что раньше было по-другому. Все тоже и было и есть (все что вы описали, в т. ч. попытки продавить в стандарт свои фичи ). Даже наоборот, ИМХО, самым «сложным» был переход на версию С++11 (ибо там было очень много нововведений, причем достаточно существенных).

Во-первых, есть стандарт как таковой.

Есть, но не все так просто. Вот сводная таблица (по состоянию на конец 2014, просто как пример). Некоторые компиляторы не до конца поддерживают С++11, и в то же время, у некоторых уже есть поддержка драфтов из C++17. С++14 в промежуточном состоянии.

Все достаточно просто и прозрачно: реализации обратно совместимы, а что попадет в новую хоть и зависит от оракла

Я правильно понял, что получается некий промежуточный вариант между С++ и С# (есть открытое обсуждение будущего стандарта, постепенная формализация стандарта, но Oracle может влиять на окончательное решение на правах «владельца»)?
0
Есть, но не все так просто. Вот сводная таблица (по состоянию на конец 2014, просто как пример). Некоторые компиляторы не до конца поддерживают С++11, и в то же время, у некоторых уже есть поддержка драфтов из C++17. С++14 в промежуточном состоянии.
Да, но С++11 худо-бедно (как я и писал выше) но поддерживается практически всеми.
Я правильно понял, что получается некий промежуточный вариант между С++ и С# (есть открытое обсуждение будущего стандарта, постепенная формализация стандарта, но Oracle может влиять на окончательное решение на правах «владельца»)?
Примерно так. Разве что влияние оракла сводится только к тому, когда определенная фича попадет в официальный релиз. Скажем, замыкания появились только в 8-ке, хотя все было готово еще когда готовилась к выходу 7-ка. Влияние оракла сильно смазывается наличием OpenJava, которая им не контролируется и спокойно может «уходить вперед». Помимо него есть еще еклипсовский компилятор (у него нет своих либ и рантайма), на котором зачастую обкатываются многие фишки задолго до появления официального релиза. Опыт приобретенный на этих версиях также идет на пользу — как правило в официальной версии новые фишки уже вполне работоспособны и не страдают «детскими болезнями». В целом все эти сообщества (опенсорсные реализации, JSR-комитеты и оракл) тесно переплетены. Идет постоянный обмен информацией как внутри них, так и между собой, а так же с разработчиками других языков и обычными разработчиками. Скажем, некоторые вещи, которые были добавлены в JVM семерки, самой Java не особо нужны, но зато очень полезны языкам с динамической типизацией типа Groovy, JRuby (Ruby на JVM), Jyton (Python на JVM), Rhino (JS на JVM) и других.
0
В отличии, например, от C#, где MS выкатывает новую версию языка или фреймворка, и она по факту становиться стандартом
Но результат-то тот же) Обновили Дельфи ради новых фич — старые проги сломались.
0
Да не, я не в плане обратной совместимости …

Просто в случае С++ есть открытое обсуждение, все заинтересованные стороны имеют доступ к черновику стандарта, могут заранее начинать постепенно реализовывать фичи в своих компиляторах … И эталоном является сам стандарт, а не конкретная его реализация.

В случае С# — решение принимает MS, стандартом становится очередная реализация от MS по факту релиза от MS. Другие (например, Mono) постоянно находятся в состоянии «догоняющего», вплоть до того, что вынуждены ради совместимости повторять ошибки, которые были допущены в реализации .NET от MS. Хотя, в свете последних событий, возможно что-то и изменится…

В Дельфи, насколько я понимаю, ситуация аналогичная, есть основной «майнтейнер», который диктует условия, остальные подстраиваются под него. Или я ошибаюсь?
0
В Дельфи, насколько я понимаю, ситуация аналогичная, есть основной «майнтейнер», который диктует условия, остальные подстраиваются под него.
Да там в общем и нету никаких «остальных». FPC разве что имеет режим совместимости — вроде до сих пор даже с седьмой не до конца совместимо.

Но все равно, результат схожий — нуна апгрейдиться для новых возможностей языка, да плюс то оптимизатор подпилят, то еще чего улучшат.
0
Кто хоть раз наступал на грабли «обновил IDE и программа не собирается/не работает» тот понимает о чем речь.
Я с таким пару раз сталкивался, но причина была не в IDE, а в обновившемся вместе с ней компиляторе.
+1
Я с таким пару раз сталкивался, но причина была не в IDE, а в обновившемся вместе с ней компиляторе.
Угу. Это еще один из пунктов. Предпочтительнее, все-таки, ситуация когда мухи отдельно, котлеты отдельно. IDE сам по себе, компилятор сам по себе. Это снимает множество проблем, в том числе ту, что ты упомянул.
0
Ну, то был Delphi. Зато мне нравится ее IDE и то, что там все аккуратно интегрировано и работает без вопросов, настроек и ковыряний.
+1
Но не всегда возможно осуществить такое разделение. Например, работа с STM8. Я бы с удовольствием прикрутил бы к какому-нибудь Codeblocks сторонний компилятор, линкер, прошивальщик и отладчик. Но увы, реальность диктует другие условия.
0
«обновил IDE и программа не собирается/не работает» тот понимает о чем речь.

Это как раз, не самая большая проблема (и она может возникнуть при обновлении любого компонента, не обязательно именно IDE, это может быть компилятор, система сборки, в плоть до обновления ОС). И, эта проблема обычно решается достаточно просто (в самом крайнем случае можно откатиться на старую версию)

Я согласен что вариант «билдить средствами IDE» имеет кучу недостатков: мы привязаны к конкретной IDE, не можем отделить от нее процесс сборки (например, перенести сборку на сервер для автоматизированного тестирования), встроенные в IDE средства управления сборкой достаточно упрощены по сравнению со специализированными решениями. Я согласен что специализированные средства управления сборкой лучше, чем средства IDE, а ещё лучше билд-сервера интегрированные с системой контроля версий.

Но я не согласен, что это все актуально для любительских проектов уровня «just for fun». Если человек будет расти в профессиональном плане и поймет, что ему нужна продвинутая система сборки – он ее освоит. Но это имеет смысл только на определенном этапе развития. Если с точки зрения проф. разработки ПО что-то выглядит «кустарщиной» — это не значит что оно не имеет право на существование (вспомните холивары вокруг arduino)

Но-но, не надо меня обзывать ПМ-ом :)
А за что вы так ПМ-ов не любите:) Они разные бывают…
+3
Если человек будет расти в профессиональном плане и поймет, что ему нужна продвинутая система сборки – он ее освоит. Но это имеет смысл только на определенном этапе развития.
+много
0
Если человек будет расти в профессиональном плане и поймет, что ему нужна продвинутая система сборки – он ее освоит.
Изначально мои возражения были против слов «рано или поздно… слезает с кустарщины на KEIL или… IAR».
0
Ок, тогда вопрос снимается. Я видимо неправильно понял вашу риторику.

Касательно фразы «рано или поздно… слезает с кустарщины на KEIL или… IAR» — я поддерживаю вашу позицию. Автор комментария сильно переоценивает «профессионализм» решений от «KEIL или… IAR» (хотя, по тому что я знаю, сами компиляторы там неплохи, но это не значит, что все остальное «кустарщина»… да и дело не только в компиляторе…)
0
А за что вы так ПМ-ов не любите:) Они разные бывают…
Я не говорил, что я их не люблю. Просто я не ПМ.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.