LINUX.ORG.RU

Каким мог-бы быть Linux или пожелания разработчикам


0

0

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

Использовать для программ правило "Куда скопировал - там и работает", например скопировали программу в домашнюю директорию пользователя, оттуда и запускаем.

Использовать правило "Одна программа - один файл", поясню на примере. Допустим у нас есть программа "Text Editor" которая расположена так: /root/Text Editor. По-сути "Text Editor" это директория (которая выглядит для пользователя как исполняемый файл программы), внутри которой содержатся исполняемые файлы, конфигурационные файлы, документация:

читать далее - http://www.tik.ru/linux/75.html

Очень странные пожелания.

kitov ★★★
()

> Использовать для программ правило "Куда скопировал - там и работает", например скопировали программу в домашнюю директорию пользователя, оттуда и запускаем.

каждая программа должна представлять собой один виртуальный диск, который куда-нибудь union-маунтится

dilmah ★★★★★
()

Что, вендузятко, не асилил UNIX Way? А ну марш обратно на венду и уткнись.

anonymous
()

Исполняемые файлы ищет система(whereis startx) и необходимость в знании путей imho возникает редко. К тому-же в RPM/deb/... написано какие файлы он содержит(и их пути).

Проги в виде одного файла(как-раз твое предложение): http://klik.atekon.de/

YesSSS ★★★
()

приколисты, блин...

Pi ★★★★★
()

Мои пожелания:

лимиты памяти для пользователей, suspend процессов(т.е. возможность сохранить состояние процессов на диске, с возможностью возобновления),unswappable memory(чтобы у таких процессов как консоль, иксы ,не свопировалась память.Но не вся, а до опр. предела. т.е. разрешено 100mb unswappable, если прога потребляет больше, разрешать свопирование.)

xnix ★★
()

Мсье всю жизнь провел за Маком? :)

Gharik
()

starkit - приложения именно такие и есть :) одна программа - один файл, внутри которого tk,vfs,metabase..

причём всё это многоплатформенно, то есть если есть editor.kit то он и под win и под linux и под hp всё един..

MKuznetsov ★★★★★
()

вообще - прикольно. выкинуть нафиг весь IPC, MM, FS. глядишь и не так много останется с собой тягать доп либ. Правда это путь назад а не вперед.

sf ★★★
()

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

Превед, семидесятые!

anonymous
()

> Программа должна содержать все необходимые библиотеки внутри себя

Каждой программе свой libc? Не смешно.

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

> Каждой программе свой libc? Не смешно.

продвигаясь дальше - каждой программе свой кернел ! надо же задействовать виртуализацию в процессоре.. каждой машине - шустрый CD/DVD changer и отдельную кнопку на клаве - загрузить следующий в стеке диск :)

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

> продвигаясь дальше - каждой программе свой кернел ! надо же задействовать виртуализацию в процессоре.. каждой машине - шустрый CD/DVD changer и отдельную кнопку на клаве - загрузить следующий в стеке диск :)

я вижу еще дальше, каждой программе - отдельного юзера!

ale ★★
()

Дурачье. Просто слов нет.

Zulu ★★☆☆
()

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

Это противоречит самой концепции shared-libraries. Если размер этих либ небольшой - то static linking - это понятно, а если это LibC или X ?

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

>Эту идею надо людям, создающим filesystem hierarchy standart показать, однозначно.

ненада - они умрут от смеха - живот разорвется

alphex_kaanoken ★★★
()

ужасный способ пропиарить блог на tik.ru

anonymous
()

Че то такое вроде бы писали пионэры из РОДЛинукс...

klon
()

> при установке программ из RPM пакетов

man rpm

rpm -ql

> при компиляции

man checkinstall

man man - это пожелания разработчиков пользователю.

bugmaker ★★★★☆
()

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

Вообще умные люди придумали autotools, а в ней есть скрипт configure в параметрах которого есть BINDIR, MANDIR, DOCDIR и т.п., да еще есть понятие как makefile'ы с DISTDIR...

Данным пожеланием вы просто показали что еще очень мало работаете в linux :)

>Использовать для программ правило "Куда скопировал - там и работает", например скопировали программу в домашнюю директорию пользователя, оттуда и запускаем.

Вообще она и так запустится откуда угодно, главное что бы программа нашла все библиотеки которые хочет (или была статично с ними слинкована), ну некоторым программам может быть нужны будут какие-то конфиги... Но работать будут :) Опять же, при компиляции можно сказать ./configure --prefix=~

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

> Данным пожеланием вы просто показали что еще очень мало работаете в linux :)

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

> Мсье всю жизнь провел за Маком? :)

Нет, за Маком мне не довелось поработать, но если там формат программ такой, представлящий собой один файл - думаю это удобно. И при этом - программы занимают чудовищно много места на диске? Они работают медленнее программ на Linux? Думаю что нет.

Вопрос ко всем:

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

Я не пытаюсь ругать Linux почем зря, идея свободной ОС мне нравится иначе бы я здесь об этом не писал. Мне не понятна реакция сообщества на предложения - если я ошибаюсь в том, что пишу, можно ведь написать в чем именно моя ошибка и почему это невозможно сделать в принципе.

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

> обьясните почему практически все программы в Linux работают на порядок медленне аналогичных программ в других ОС?

конкретные примеры?

> в чем именно моя ошибка и почему это невозможно сделать в принципе

никто не говорил, что это невозможно _в_принципе_. а в чем ошибка - объяснили выше

friday ★★★
()

По сути этот "изобретатель" велосипедов "изобрел" JavaTM Archive (JAR) file format http://java.sun.com/docs/books/tutorial/deployment/jar/

Он запатентовать своё "изобретение" не пробовал? Его бы сразу спустили с небес на землю. Советчик ху9в. Нормальные люди уже давным давно так программы пакуют, непонятно, почему линуксоиды такие особенные?

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

> конкретные примеры?

GIMP / Photoshop - казалось-бы GIMP должен работать быстрее, но увы... на многих операциях GIMP проигрывает фотошопу по скорости, например при быстром рисовании кистью в GIMP`e видны характерные угловатости там, где должны быть плавные линии, особенно это видно при рисовании на планшете. Перенос окон, раскрытие меню тоже чуть притормаживает, впечатление что где-то "заедает", хоть и притормаживает меньше чем на секунду, но это заметно и неприятно.

Kwrite / UltraEdit - KWrite запускается порядка 3-4 секунд, что для текстововго редактора многовато.

Firefox / Opera - при примерно одинаковой функциональности Firefox заметно медленнее чем Opera

про OpenOffice наверное даже и не стоит писать...

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

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

>Я не пытаюсь ругать Linux почем зря, идея свободной ОС мне нравится иначе бы я здесь об этом не писал. Мне не понятна реакция сообщества на предложения - если я ошибаюсь в том, что пишу, можно ведь написать в чем именно моя ошибка и почему это невозможно сделать в принципе.

Посмотри, например, на программку gajim. Она занимает ~5 мегов. В зависимостях libc (11M), python (10M), libgtk (5M) и т.д. Если посчитать всё получится, думаю, мегов 50-100.

Что касается остального, распространение программ в виде таких комплектов резко увеличивает шанс заразиться какой-нибудь заразой. Как правило 95% софта ставится из репозитория дистрибутива и подписано клюём, это сильно уменьшает вероятность запустить что-нибудь не то.

Распределение файлов по директориям организовано (в правильных дистрах) очень разумно: вся документация, например, в /usr/share/doc/progname. Но если что-то забыл, что всегда можно сказать dpkg -L progname (в debian или ubuntu, для rh или gentoo слегка по-другому).

Рекомендую посмотреть на дистрибутив с dpkg и apt (debian или ubuntu).

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

> Распределение файлов по директориям организовано (в правильных дистрах) очень разумно: вся документация, например, в /usr/share/doc/progname. Но если что-то забыл, что всегда можно сказать dpkg -L progname (в debian или ubuntu, для rh или gentoo слегка по-другому).

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

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

Должна, и она есть. Рекомендую воспользоваться гуглем для ответа на твой справедливый в общем-то вопрос. Вообще, им стоит пользоваться всегда, прежде чем что-то "улучшать". :)

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

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

Тривиальный пример: как сохранить все настройки системы? Просто создать копию /etc. Как во встроенной системе (на которую не планируется ставить дополнительный софт) удалить всю документацию? Удалить /usr/share/doc.

А можно, например, монтировать раздел /usr по сети и иметь на всех машинах одинаковый набор программ и мало занятого места.

И т.д. и т.п.

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