Три основные проблемы Linux на десктопе

Разговоры обо всём
Ответить
Аватара пользователя
vasilich
Сообщения: 696
Зарегистрирован: 03 окт 2012, 14:04
Темы: 498
Статус: Не в сети

Три основные проблемы Linux на десктопе

Сообщение vasilich » 05 ноя 2012, 02:23

Чуть ли не каждый год различные СМИ и веб-ресурсы продолжают говорить, что соответствующий год является "годом Linux на десктопе". Но при этом доля пользователей ОС на основе Linux так и не выходит за пределы одного-двух процентов. У этого есть несколько причин, некоторые из которых относятся в том числе к маркетингу или ситуациям, находящимся вне контроля собственно разработчиков ОС (например, нехватка стороннего ПО). Здесь я попробую привести несколько проблем, которые вполне могут быть исправлены самими разработчиками ядра, дистрибутивов и СПО:

1. Крайне низкая степень обратной (и не только) совместимости.

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

Программа вышла, ей люди пользуются, и всё вроде бы нормально -- пока не проходит несколько месяцев, не выходит новая версия поддерживаемого вами дистрибутива, и какая-то из множества используемых библиотек либо меняет свой ABI, либо исчезает вообще. Даже если вести себя ответственно и тратить своё время на доработку программы под новые версии библиотек, то возникает новая проблема: новые версии программ откажутся работать на старых дистрибутивах!

На эту проблему не очень сильно обращают внимания разработчики свободного ПО, в частности потому, что его нетрудно пересобрать в случае изменения ABI, а мэйнтейнеры дистрибутивов как-нибудь да разберутся с версиями библиотек (обычно, использованием более старой версии программы на дистрах со старыми библиотеками). А вот проприетарным разработчикам приходится из-за этого применять самые разные "костыли": класть самые важные библиотеки в набор самой программы (как, кстати, поступает немало СПО для Windows); линковать библиотеки в сам исполняемый файл, и так далее.

Как это можно решить: тут стоит взглянуть на опыт Microsoft. Который, в свою очередь, говорит три вещи:
1. Не ломать API (и ABI) библиотек в обновлениях и новых релизах;
2. В случае необходимости добавления новой функциональности написать новую библиотеку (или ограничиться добавлением новых методов с суффикском вроде Ex);
3. _Всегда_ поставлять старые библиотеки в составе (или репозиториях) ОС.

Благодаря чему в семёрке спокойно работает игра "Реверси" из выпущенной более 20 лет назад Windows 2.0, а софт, написанный на машине с Windows 7, вполне может работать и на Windows XP.

Конечно, у этого подхода есть и недостатки: будучи завязанными на обратной совместимости, значительно сложнее делать крупные изменения, затрагивающие в том числе старый код. Зато разработчики проприетарного ПО могут отдохнуть и вместо постоянной доработки своего софта под новые ОС заняться разработкой новых версий с новыми функциями и новым интерфейсом (обязательно новым интерфейсом!).

2: Отсутствие единого SDK и IDE.

В то время, как разработчики под Windows дружно используют никем не превзойдённую MS Visual Studio (которая имеет бесплатную Express-версию), а разработчики под макось сидят в также бесплатно распространяемом Xcode, ничего эквивалентного в мире свободного ПО, к сожалению, нет.

Тут, конечно, стоит сказать: я знаю, что есть множество различных IDE разной степени паршивости (и некоторые из них даже очень неплохие) для разработки под линуксы, но до уровня MSVS или Xcode не доходит ни одна из них.

Из личного опыта я могу назвать самой успешной IDE для C++ лишь Qt Creator. Но он, как нетрудно догадаться из названия, ориентирован в первую очередь на разработку для Qt -- что, учитывая тот факт, что в самом популярной ОС на основе Linux на данный момент используется GTK, не совсем хорошо для начинающих разработчиков. И да, в Qt Creator можно писать и не зависящий от Qt софт -- только смысла в этом слишком мало. Встроенный отладчик, например, работает только с QString и ни с какой другой реализацией строк -- даже со стандартным сишным char* (с чем справляется лежащий в основе gdb!)

Если говорить про более-менее универсальные IDE, то тут, скорее всего, большинство назовёт Eclipse. К сожалению, я им не пользовался, но если верить знакомым линуксоидам (и виндузятникам), то он оказывается крайне медленной в работе программой, умудряющейся тормозить на компьютерах с двухъядерными процессорами и гигабайтами оперативной памяти на борту, которая при этом всё равно не доходит до MSVS по уровню функциональности.

3. Слишком большая любовь разработчиков к использованию интерпретируемых ЯП.

Если взглянуть на всё разнообразие софта для Windows (через PeID, например), то нетрудно будет заметить, что подавляющее большинство его написано на C, C++ или одном из языков .NET. Некоторые более старые программы ещё могут быть написаны на Delphi или Visual Basic, но тут почти всё разнообразие языков кончается. С MacOS ситуация ещё лучше -- почти весь софт написан на Objective-C и больше ни на чём.

А вот среди свободных ОС даже входящий в состав системы софт не гнушается использовать такие языки, как Python, Perl или даже Ruby. Причём весь этот софт с его интерпретаторами расходует НАМНОГО больше ресурсов по сравнению с тем, будь он же написан на одном из более стандартных языков программирования.

Нет, я, конечно же, понимаю, что писать на этих языках проще и быстрее. Только проблема в том, что если вы пишете софт, который должен быть использован на повседневной основе, он не должен быть написан "просто и быстро". Лично меня уже давно достали мультимедиа-проигрыватели и IM-клиенты, которые поедают десятки мегабайт оперативной памяти даже тогда, когда ничего не проигрывают или не подключены к сети.

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

Раньше разработчики как-то умудрялись делать жутко красивые рабочие среды, которые могли работать без композитного менеджера вообще (KDE 3 и разработанные для него движки тем Qt/KWin -- яркий тому пример. Взгляните на Domino, например.). И они успешно обходили тогда последнюю Windows XP на тех же машинах.

Несмотря на то, что я был всегда ярым поклонником среды Unity, пользоваться ей в Ubuntu 12.10 я просто не смог. Она жутчайше тормозила даже при полном отсутствии нагрузки со стороны софта. Когда же я попробовал "ночную сборку" среды Elementary, я только наоборот, удивился -- она работала с великолепной скоростью, при этом поддерживая все красивые эффекты и сражаясь почти на одном уровне с Mac OS X!

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

http://liberatum.ru/blog/24798

Гуру,скажите свое мнение!

Серый
Сообщения: 844
Зарегистрирован: 27 сен 2012, 19:20
Темы: 102
Статус: Не в сети

Re: Три основные проблемы Linux на десктопе

Сообщение Серый » 05 ноя 2012, 19:37

Ну, я вам так скажу. Гуру я себя не считаю, но на твой вопрос Василич отвечу. Первая проблема Линукса это то что он из коробки просто ужасен, я про внешний вид. Не буду тут разводить рекламу, но только убунта из коробки выглядит более менее и то она далека от совершенства. Так вот пока линукс из коробки не станет красивым дальше он не продвинется, ИМХО. Всё остальное тоже важно, но красота я считаю в первую очередь. Ведь встречают то по одёжке.

Аватара пользователя
ZEN
Администратор
Сообщения: 1359
Зарегистрирован: 27 сен 2012, 18:23
Темы: 208
Откуда: Украина, Одесса
Статус: Не в сети

Re: Три основные проблемы Linux на десктопе

Сообщение ZEN » 05 ноя 2012, 20:06

vasilich писал(а):1. Крайне низкая степень обратной (и не только) совместимости. ... Вы написали очередной релиз, выпустили его и хотите приступить к написанию следующей версии, ожидая выпустить её через пару-тройку лет.
Как человек хоть немного связанный с программированием скажу, что этот пункт бред.
vasilich писал(а):Как это можно решить: тут стоит взглянуть на опыт Microsoft.
Вот тут я советую не смотреть на опыт майкрософт. Чего только стоит поднятие виртуальной машины в Windows 7 ради того, что бы запускать приложения от ХР. А уж разного вида DLL-Hell должен только больше отпугивать разработчиков от Windows.
vasilich писал(а):Благодаря чему в семёрке спокойно работает игра "Реверси" из выпущенной более 20 лет назад Windows 2.0, а софт, написанный на машине с Windows 7, вполне может работать и на Windows XP.
Не правда. Тупо пиар майкрософта.
vasilich писал(а):2: Отсутствие единого SDK и IDE.
Borland Builder, Microsoft Visual Studio и многие другие заточенные только под винду - это в среде Windows единая IDE. То же касается и SDK. Особенно вспоминается обещание майкрософта в 98-м, что MFC будет кроссплатформенным. Где?

vasilich писал(а):3. Слишком большая любовь разработчиков к использованию интерпретируемых ЯП.

Если взглянуть на всё разнообразие софта для Windows (через PeID, например), то нетрудно будет заметить, что подавляющее большинство его написано на C, C++ или одном из языков .NET. Некоторые более старые программы ещё могут быть написаны на Delphi или Visual Basic, но тут почти всё разнообразие языков кончается. С MacOS ситуация ещё лучше -- почти весь софт написан на Objective-C и больше ни на чём.
Стоит заметить ущербный cmd windows. И создание расширения через программу PowerShell. А так что вранье, что VisualBasic мерт. На его основе до сих пор успешно с флешек попадают в систему вирусы.

В общем, на мой взгляд статья не верная и вводит читателя в заблуждение. Автору статьи я бы посоветовал пользоваться kolibri OS, где нет SDK и фреймворков. Где все пишется только на ассемблере и нет готовых библиотек построения интерфейса.
бог создал труд и обезьяну
чтоб получился человек
а вот пингвина он не трогал
тот сразу вышел хорошо

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей