LINUX.ORG.RU

Почему в свободных САПР не поддерживается формат DWG

 , , ,


0

3

В начале январе в разделе для нетехнических дискуссий ЛОР был задан очередной, двеститритысячипятисотый по счёту вопрос о поддержке в СПО проприетарного формата чертежей DWG.

Редакция проекта linuxgraphics.ru решила выяснить причины, по которым существующая библиотека LibreDWG не используется в таких активных проектах как LibreCAD и FreeCAD. Для этого были проинтервьюированы создатели библиотеки, авторы некоторых свободных САПР, соразработчик Open Assets Library, руководитель Blender Foundation и, наконец, представитель Free Software Foundation — правообладателя кода LibreDWG.

Исследование выявило несколько факторов, сформировавших существующее положение дел. Ключевыми авторы исследования считают два: неполнота спецификации на формат и лицензионная несовместимость библиотеки с ПО для конечных пользователей.

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

Обновление лицензии самих САПР до совместимости с GPLv3+ существенно осложнено ввиду использования унаследованного и третьестороннего кода, чья лицензия накладывает ограничения на лицензирование САПР.

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

Напомним, что поддержка DWG в свободном ПО была в 2008 году объявлена приоритетным проектом FSF. Несмотря на это, до сих пор FSF и Ричард Столлман высказывались категорически против релицензирования LibreDWG, тем самым препятствуя достижению поставленной ими же цели.

>>> Подробности

★★★★★

Проверено: JB ()

Ответ на: комментарий от baka-kun

baka-kun> Нет. Первое я могу взять на условиях GPLv2.

Второе тоже можешь взять на условиях GPLv2+, ежели выдерешь код, который под GPLv3+. И вообще лучше иди делай уроки.

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

1. Зато работает.

2. Хрена с два: на современных карточках можно что угодно считать. Разве что есть алгоритмы, физически не допускающие параллелизации - но их ни какой дурак на видеокарте считать не будет.

3. Очень даже заменишь.

4. Матлаб уже куду по полной юзает!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от baka-kun

baka-kun> Потому что FSF хочет сохранить за собой возможность влиять на условия использования и распространения всего кода под GPL в будущем.

Ути-пути! Диванный сторонник теорий заговора оказывается ты. FSF не имеет единоличного контроля над GPL-кодом. Заруби это себе на носу.

Quasar ★★★★★ ()
Ответ на: комментарий от shty

Автокад не ктулху, а креветка. Он просто кривой и неподъёмный, в то время как те же Pro/E, SolidWorks, CATIA и NX оказываются более эффективными.

Quasar ★★★★★ ()
Ответ на: комментарий от anonymous

Пока не будет разрулена проблема с лицензией, в этом нет никакого смысла. Иначе это работа в стол.

AP ★★★★★ ()
Ответ на: комментарий от Eddy_Em

Только не в случае с nVidia. Пока их карты - самые лучшие (естественно, только при использовании с блобом), а CUDA - наиболее успешно применяемая технология расчетов на GPU.

Нельзя быть наполовину беременным. Можно терпеть вендор-лок, но нельзя его иногда поддерживать, а иногда нет. Кстати, чисто по гигафлопсам AMD рвёт nvidia как тузик грелку. Пруф найти легко - любое сравнение чистой производительности на операциях с плавающей точкой.

И, совсем не понятно, зачем тебе куда в octave, если преимущество куды по твоим словам - в высокоуровневости? В октаве ты всё равно напишешь theta=pinv(X'*X)*X'*y, какая тебе разница, на куде это будет реализовано или на opencl? Если не считать того, что куда - это вендорлок сразу (вообще глупость для свободного проекта. Если б ты для matlab-a просил, я бы понял тебя).

ForwardToMars ()
Ответ на: комментарий от Quasar

Автокад не ктулху, а креветка

ктулху-криведко

те же Pro/E, SolidWorks, CATIA и NX оказываются более эффективными

в своей области применения - несомненно, но не как инструмент общего назначения, пока по крайней мере

shty ★★★★★ ()
Ответ на: комментарий от fat_angel

fat_angel> Фигассе мизерное улучшение — портирование с Qt3 на Qt4.

Хочешь сказать, они не морду, а весь код переписали? Тогда они могут себе позволить перелицензировать под GPLV2+

Quasar ★★★★★ ()
Ответ на: комментарий от ForwardToMars

В октаве ты всё равно напишешь theta=pinv(X'*X)*X'*y, какая тебе разница, на куде это будет реализовано или на opencl?

На куде считать быстрее будет. А вообще, конечно, без разницы: сейчас вообще все считается на CPU, что ну ооочень медленно!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от fat_angel

fat_angel> Идея превосходна. Но только пока не будет нормальной программы использующей этот формат по умолчанию, он будет оставаться никому не нужным, вроде IGES или STEP.

Так надо выбрать программу, которая будет этот формат поддерживать, и всячески её пиарить и дорабатывать. Организовать фонд - The Engeneer Foundation. Впаривать её в учебных заведениях и т.д.

Quasar ★★★★★ ()
Ответ на: комментарий от zamtmn

zamtmn> Ок, приду в нешарагу. Ваши варианты на что будем менять автокад?

BricsCAD. Несвободно, да. Но есть под линукс, несравненно дешевле и совместимо с автокадом.

Quasar ★★★★★ ()
Ответ на: комментарий от yurkis

yurkis> Не-не-не! Не надо подменять понятия. GPL как раз накладывает БОЛЬШИЕ ограничения (в том числе и) на разработчика.

Бздунам слово не давали ;) У них задач черчения нет.

Quasar ★★★★★ ()
Ответ на: комментарий от zamtmn

zamtmn> Выкладываю: Тормоз ваш либрекад. Открываю реальный чертеж из реального проекта - работать невозможно, любые зумирования\панаромирования вызывают секундные торможения. Не зависимо от количества объектов в кадре. Оптимизации в нем нет никакой

А QCAD пробовал?

Quasar ★★★★★ ()
Ответ на: комментарий от zamtmn

Охлолблин. Если выбирать между проприетарщиной - лучше сразу Компас взять. Да даже тот же T-Flex лучше автокада, если говорить об электронных кульманах. Почему ты это предпочтение автокаду отдаёшь, когда с СПО начинаешь сравнение?

Quasar ★★★★★ ()
Ответ на: комментарий от Eddy_Em

Eddy_Em> 1. Зато работает.

OpenCL работает ещё больше - не только на нвидии.

Eddy_Em> 2. Хрена с два: на современных карточках можно что угодно считать. Разве что есть алгоритмы, физически не допускающие параллелизации - но их ни какой дурак на видеокарте считать не будет.

Почему тогда кучу алгоритмов до сих пор не перенесли на видяхи, а продолжают считать на кластерах?

Eddy_Em> 3. Очень даже заменишь.

Автофиг. См. суперкомпьютеры.

Eddy_Em> 4. Матлаб уже куду по полной юзает!

Ну вот уже первый пакет. Неплохо, да.

Quasar ★★★★★ ()
Ответ на: комментарий от Eddy_Em

Eddy_Em> На куде считать быстрее будет.

У меня ноутбук с радеоном. Давай, посмотрим, как твоя хвалёная CUDA тут будет считать?

Quasar ★★★★★ ()
Ответ на: комментарий от Eddy_Em

Кстати. Я для тебя откопал статейку с замерами производительности. Nvidia Tesla простой видяхе от AMD сливает:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&amp...


Заметь - это не единичная задача. Те же биткоины тому подтверждение.

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

OpenCL работает ещё больше - не только на нвидии.

Можно названия хотя бы пары проектов, где использовался бы OpenCL, причем серьезно?

Почему тогда кучу алгоритмов до сих пор не перенесли на видяхи, а продолжают считать на кластерах?

Их считают на кластерах из видеокарт.

См. суперкомпьюте

Ну, ясен пень, что сотня тысяч ядер CPU попроизводительнее будет, чем сотня тысяч ядер GPU. Однако, если сравнивать стоимость, второе себе даже небольшая лаборатория может позволить, а первое - только суперинститут.

Ну вот уже первый пакет

Я вот периодически статейки почитываю, и как-то ни разу не встречал, чтобы данные обрабатывали с использованием OpenCL. Зато куду активно пользуют. И народ сам свои пакеты пишет с использованием именно куды.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Quasar

Если выбирать между проприетарщиной - лучше сразу Компас взять.

Интересно, если в этой стране все же появится зоопарк кадов, каким форматом станут пользоваться для обмена документацией? Додумаются ли использовать нечто более-менее открытое? Хоть тот же dxf?

fat_angel ★★★★★ ()
Ответ на: комментарий от Quasar

да, триалку. Теже тормоза. Этот же чертеж в автокаде и клонах летает, никаких торможений. Незнаю как сейчас, но пару лет назад ковырял исходники QCAD`а и не нашел там никаких оптимизаций для вывода примитивов типа разбиения пространства и упрощения мелких невидимых деталей. Без этих вещей программу нельзя называть CADом

zamtmn ()
Ответ на: комментарий от dogbert

Надо было вернуться в прошлое и заставить релизнуть libdwg под BSDL.

BDSM же

VeroLom ★★ ()
Ответ на: комментарий от Eddy_Em

На куде считать быстрее будет. А вообще, конечно, без разницы: сейчас вообще все считается на CPU, что ну ооочень медленно!

GPU - в любом случае хорошо. Так что поддерживать лучше всё-таки более свободный стандарт, а реализацию opencl nvidia для своих карт перепишет.

Можно названия хотя бы пары проектов, где использовался бы OpenCL, причем серьезно?

Jacket для matlab-а. Дело в том, что OpenCL моложе. И ему тяжелее поэтому - он входит на уже занятую территорию. Но он войдёт. Даже если сейчас ты используешь куду - хотя бы на словах стоит поддержать и opencl - по количеству проектов он подтянется скоро. Да и в любом случае вряд ли можно рассчитывать, что в свободных проектах будет появляться поддержка куды вместо opencl.

ForwardToMars ()
Ответ на: комментарий от ForwardToMars

Я начал было читать, как работать с OpenCL. Когда увидел, что этот динозавр собой представляет, плюнул и решил больше никогда такой глупости даже не думать.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

Я вот периодически статейки почитываю, и как-то ни разу не встречал, чтобы данные обрабатывали с использованием OpenCL. Зато куду активно пользуют. И народ сам свои пакеты пишет с использованием именно куды.

Дай пару ссылок. Без задних мыслей, просто интересны специализированные ресурсы именно по этой теме.

ForwardToMars ()
Ответ на: комментарий от ForwardToMars

Да, если я таки не заброшу свой велосипед, появится свободный проект с поддержкой куды :)

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от ForwardToMars

Сейчас не могу (я у родителей в гостях), можешь сделать поиск на adsabs.harvard.edu по opencl и по CUDA.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

Eddy_Em> Ну, ясен пень, что сотня тысяч ядер CPU попроизводительнее будет, чем сотня тысяч ядер GPU. Однако, если сравнивать стоимость, второе себе даже небольшая лаборатория может позволить, а первое - только суперинститут.

Так можно в «суперинститут"сходить серьёзно посчитать. А с видяхой всё равно только ускорение относительно простых расчётов будет.

Eddy_Em> Я вот периодически статейки почитываю, и как-то ни разу не встречал, чтобы данные обрабатывали с использованием OpenCL. Зато куду активно пользуют.

1. Инертность мозга
2. CUDA появилась раньше
3. Уже закупили железо

Вот и всё.

Quasar ★★★★★ ()
Ответ на: комментарий от Quasar

Да просто народ когда видит, как надо изголяться, чтобы OpenCL использовать, либо всего пару десятков строк кода написать на CUDA, ясен пень, идут по пути наименьшего сопротивления.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Quasar

Почему ты это предпочтение автокаду отдаёшь, когда с СПО начинаешь сравнение?

Потому что в каждой проектной организации с которой я сталкивался используют автокад (неважно законно или незаконно). T-Flex я не встречал не разу. Пару раз встречал компас на нескольких рабочих местах, при этом все остальные - автокад. Работал в одной, в момент попытки перевода с автокада на компас - руководство попыталось подешевле встать на лицензионные рельсы, ниче не вышло - проектировщики восприняли в штыки. Компасовские менеджеры буквально жили у нас, нахваливали, показывали. Была создана группа сидящяя только на компасе. Через 2 месяца по объективным результатам было решено покупать лицензионный автокад - благо тогда были скидки на старые версии.
Можно говорить что атокад хавает мозг... пользуется упоротоми непониматиками... но если отбросить проприетарную жопу - это очень качественный програмный продукт

zamtmn ()
Ответ на: комментарий от Jurik_Phys

По теме, самому пришлось однажды ставить хе-хе в пиратскую виртуалку, пиратский автокад, чтобы переконвертировать в dxf? (точно не помню) всего один файл, чего я с ходу так и не осилил. Зато осилил dwg2jpeg online, чего мне за глаза хватило.

Улыбнуло:)

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

Да, из-за этого винду приходится держать

HerrWeigel ★★★★ ()
Ответ на: комментарий от Eddy_Em

И вообще, я считаю, что в идеале у человека, использующего компьютер в работе, должно быть так: принимаем нового работника; выдаем ему компьютер с линуксом и только свободным софтом. Если ему что-то не нравится, он из своего кармана покупает софт, который ему хочется видеть на своем рабочем компьютере.

Так было бы очень здорово: во-первых, свободный софт быстрее бы развивался; во-вторых, все эти долбанные борзые компании, торгующие воздухом, поразорялись бы нафиг!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

Eddy_Em> Биткоины - никому не нужное говно. Пусть лучше посчитают что-нибудь нужное.

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

Quasar ★★★★★ ()
Ответ на: комментарий от Eddy_Em

CUDA будет считаться софтово, если вообще установится. OpenCL будет намного быстрее, ибо аппаратное ускорение ;) На нвидии - только чуть медленнее, чем CUDA, ибо обёртка там это над CUDA.

Quasar ★★★★★ ()
Ответ на: комментарий от zamtmn

Ну значит придётся разработчиков пинать. Но для студенческих курсовых оно определённо сойдёт.

Quasar ★★★★★ ()
Ответ на: комментарий от Eddy_Em

И что ты этим хотел сказать? Сам же попросил ровно _два_ проекта, и сам привёл огромный список на сайте пеарастов-маркетологов? Офигенный аргумент, да.

Quasar ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.