LINUX.ORG.RU

linux - os for programmers!


2

0

Все более или менее конкретно, никакого флейма! Я много сидел и сижу под виндой, я знаю эту систему. Полгода назад установил linux, поначалу очень разочаровался в ней (но сносить, кажется, не хотел). Сейчас я доволен linux, но работаю (именно работаю) в нем не очень много, в основном так, ковыряюсь (хотя занятие это время отымает очень, иногда ночи напролет сижу :) Также нормально отношусь и к Win. Она если и падает, то хоть core-дампы размером 20Мб по всей файловой системе не раскидывает. (Кстати, GNOME у RedHat 6.1 постояно падает. Как его вылечить? Linuxconf тоже... ) Хотя core для разработчика это хорошо - если уметь им пользоваться. Да, насчет win - хорошая все-таки, единообразная система, даже программы от разных производителей. Очень быстрый, хотя и простой и не очень настраиваемый интерфейс (для прорисовки 3d- border эффектов, закраски и перетаскивания окон, короче при рисовании, активно используются аппаратный 2D ускоритель видеокарты (знаю, ковырялся, Ж-) ), чего в X-ах, по моему, нет... По этому они и выглядят немного медленнее... Еще эта ориентация на сеть :( X - сложная система, с множеством составных частей... И все это работает через различные протоколы над TCP/IP... Но мне, на локальной машине, этого не нужно! Это тормоза! ...Что, XFree4.0 - намного лучше по производительности/архитектуре? ... Хотя может быть я в чем-то не прав. Есть здесь спецы по архитектуре X-ов?) Че-то в X не то с курсором мыши - почему он дергается, когда система сильно загружена? Курсор мыши (в смысле процедуры его обслуживания) - самая привилегированная часть GUI. Мышь должна двигаться без всяких дерганий в любой ситуации! Под виндами даже при полном крахе мышь чаще всего остается живой! Как этого добиться (в смысле отсутствия дерганья) в linux? Registry - хорошая штука... Пользователю нет необходимости часто в нем копаться самому (в крайнем случае есть куча shareware и freeware утилиты, знающих, где что в реестре лежит, и для их использования не надо рыться в HEX последовательностях). Программам же наоборот - HEX числа понятнее, не нужно разбирать текстовые конфигурационные файлы, использовать парсеры. В итоге инициализация программы проходит быстрее (сколько тысяч строк всяких скриптов просматривается в linux при syslevel 5 до полной загрузки?) Да, современные настольные компы делают сотни миллионов операций в секунду, однако загрузка Win95 занимает у меня 8 секунд, а RedHat Linux 6.1 + KDE - 45 (за минусом таймаута при опросе CD-ка и наборе пароля). ... Ладно, не спорю, надо сравнивать с WinNT/Win2000, все-таки под 95-ыми виндами нет инициализации всяких сетевых служб и серверов, но даже KDE грузится секунд 12... Хотя че-там секунды считать плюс-минус десяток - не страшно. У линукса загрузка красивая, всякие системные сообщения выдаются, [ ОК ] зелененькие - мне лично нравится. Не то что тупая полоска под winnt или переливы палитры у 9евяти-иксовых. Я знаю людей, работающих админами BSD (уважающих эту систему), но использующих в качестве рабочих станций Windows NT ("FreeBSD (а подавно Linux) еще далеко до использования в качестве рабочей станции") Я же отношусь к тем, кто имеет дело с linux, потому что "в нем что-то есть" (а таких по опросу www.nevod.ru большинство!) Мне кое-чего в lin не хватает. Особенно нормальных file manager, image viewer и редактора (Естественно, мои идеалы: DISCo comm + FAR (в зависимости от обстоятельств), ACDSee и что-нибудь от Borland - уважаю BC3.1, BP7.0, BCB и дельфи). Мне нравится полуночный командер. Особенно когда запускаю его как: mc -C normal=brightcyan. Хорошее впечатление осталось от XNC, ELEMFM, но у в них еще многое не доделано (Хотя версия X Northern Captain - 4.2.1) Но после FAR с его Ctrl-ENTER, Ctrl-Shift-Insert, Alt-<-/->, Alt-N, F8 и Shift-F8 в редакторе и вьювере (перекодировка), F6 (переключение между Edit/View), а также Ctrl-TAB и F12... Если честно, меня достают дабл-ескейпы, ескейп-икс-и... Какой все-таки аналог NC-шного Alt-клавиша в mc (для поиска файла в текущем каталоге)? Иногда у меня получалось, а как - не пойму :( А как раскрывать меню истории у элемента ввода (значки [^] в конце строки)? Идея: написать свой файловый менеджер, собирающий все хорошее FAR, MC, DISCo comm, etc. Есть еще любители DN-а, Windows Comm, Explorer-а - их тоже не обидеть. Хорошая конфигурялка, но для любителей и возможность ручками .cfg поправить... Как, а? Видел много гляделок, хорошие: GQview, KuickShow, xnview (распространяется без исходников :(, некоторые другие... Самое прикольное, что у одних есть (или хорошо сделано) что-то одно, у других - другое. А как бы объединить все плюсы? Мне не хватает нормальных FullScreen, Shrink, Zoom, Browsing, File Info, SlideShow... По-моему, камень преткновения заключается в использовании тормозных библиотек, типа libjpeg, libtiff, etc. (я ошибаюсь?) Редакторов тоже куча. Xemacs/emacs - очень мощный редактор, но уж очень не похож старый добрый BC 3.1, к которому я привык. У меня нет желания изучать просто огромное количество комбинаций горячих клавиш. А так, в общем, ничего. Первое, на что я смотрю, оценивая редактор - возможность курсора выходить за конец строки. Под linux я знаю только один такой редактор - kwrite из kde. Следующее - наличие Undo, Redo (причем посимвольных, а не поблочных), лучше безграничных, их горячие клавиши (Минус kwrite - не работает Alt-BS как Undo, а Redo - Ctrl- Y). Также смотрю возможность работы с буфером обмена по Ctrl-INS, Shift-INS, в крайнем случае, по Ctrl-C,Ctrl-X. Очень не многие редакторы позволяют настроить горячие клавиши без правки исходников, а правкой заняться времени не хватает. Другой плюс - это наличие у редактора контекстного меню (по правой кнопке мыши) с пунктами Copy, Paste. (Средней кнопки у моей мыши нет). Так что пока что использую kwrite. Кстати, у mc-редактора горячая клавиша Undo - Ctrl-U, а F9 вызывает меню, в котором есть кое-какие настройки. Идея: может организовать несколько проектов по написанию софта, делающего повседневную жизнь в linux-е более приятной, более напоминающей хорошие стороны Windows (кто знает, тот поймет)? Кому- нибудь, кроме меня это нужно? Есть хорошие идеи, есть желание, нужны помощники (одному не справиться)! (... этакий город Солнца ...) По-моему, полезны были бы утилиты слежения за изменением в файловой системе, за изменением файлов вообще, и конкретно файлов настройки, история изменений - программы типа filemon, regmon. Есть уже что-нибудь подобное? Reverse Enginiring tools - необходимы как никогда!!! Куча исходников - необходимы специальные визуальные средства для их исследования, (like Source Navigator от Cygnus), специальные службы поиска в исходниках определений, вызовов, программы построения иерархий классов. Готов подключиться к проекту по созданию чего-либо подобного (SN хоть и хорош, но дорог и кое-чего там нет) ****** Ну, а теперь, для тех, кто еще с нами, на ваш суд некоторые мои мысли (сразу предупрежу, в основном, критические) по поводу linux/unix. Переносимость - бич производительности, многому софту нужно оптимизация на asm (которую без проблем потери совместимости используют многие программисты, пишущие коммерческое ПО под win). Например GIMP не хуже Photoshopa, но тормознее (не используется MMX, а MMX - это хорошее ускорение для мультимедийных преобразований). Хотя я встречал несколько проектов, в которых используется ассемблер, чаще всего под x86 (кстати, мне синтаксис nasm нравится больше, чем gas), но также и под другие цели, под PowerPC, например! Часто используются идеология программирования на C - намного более глючная и чреватая сложностями разработки, чем C++. (Ну кто будет утверждать, что ему не приходилось вылавливать непонятные глюки в C программах, возникающие из-за преобразования типов или отсутствия проверки диапазонов. По-моему, на C нельзя писать нормальные программы, не копаясь в ассемблерном коде, сгенереном компилятором). longjmp/setjmp, например - плохой стиль - доставляет сложности и автору (хотя он сам их не замечает), но в особенности и тому, кто пытается в таких программах разобраться. Необходима стандартизация всего и вся - слишком много разного, несоответствий: расположение файлов конфигурации, инсталляций, всяких там MIME ... Многое в программах сделано через одно место - необходимо доводить до кондиции Особенно много глюков в интерфейсе: мигание всего окна при прорисовке только одной его части, заметные лишние перерисовки, наезды одних элементов на другие (например у меня в диалоге Open у KDE 1.1.2 в правом верхнем углу кнопка наполовину скрыта границей окна), расчет на фиксированный размер окна - увеличиваешь его размер, а все элементы как были собраны в каком-то углу, так там и сидят (linuxconf, например) ... Вот и остается полоской прокрутки пользоваться, хотя места на экране - <-ВО->! Вопрос дня (и не пинайте меня ногами, как вы наверное знаете, от вредных привычек сложно избавиться... ладно, шутка... ) итак: как сделать вызов меню Пуск/KDE/GNOME или как оно там называется в KDE/GMONE/WM клавишей с симпатичным, разодранным на конце в клочья (видимо поклонниками) флагом, а? ... Ой, я убегаю ... А? что? бить не будете? ... Нет, серьезно, я настроил клаву в X как pc105, но при нажатии клавиши Start в проге настройки kbd шорткатов KDE вместо нее появляется какая-то META. А сама Start не работает. Хотя, я уверен, если покопаться в файлах xkb, все получится, вот только некогда. Так, далее. TTY - прошлый век (в прямом и переносном смысле). Полезна только при настройке. Что плохого в интуитивно понятном и приятном интерфейсе (что проще и быстрее - расставлять кнопки в Delphi или ручками задавать все координаты, представляя окошко в голове; или, набирая текст, менять шрифт, размер, атрибуты, парой нажатий на кнопки) (кстати, word - очень удобная штука, если уметь им пользоваться - мощный, хотя и basic, язык, куча фич). Насчет документации - по win для программеров есть книги: Метт Питрек, Чарльз Петзолд, Хелен Кастер, Джеффри Рихтер, Эндри Шульман, серия братьев Фроловых, по-моему, не плохая... Вот, специально достал с книжной полки: Алексей Коберниченко "Недокументированные возможности Windows NT" (в смысле, для программистов). Это, так, капля в море действительно хороших книг. Для linux - LDP, linuxdoc.sourceforge.net? Где книги по GTK, Qt, X-ам (расставил в алфовитном порядке)? О системном программировании? Того, что есть на LDP мне мало! Все книги, которые я видел по lin - этакие пути к linux, нафиг не нужные тому, кто решил все-таки потратить себя на linux (ну хоть в какой-нибудь бы написали о hdparm, которая включает DMA - а то ведь случайно вычитал на linuxfocus)... Хотя я вру... Иногда попадались полезные советы... Но все равно картина для меня сложилась не очень лицеприятная... Уж больно авторы восхваляют linux... не для простых юзеров эта система, вернее ее установка (которая чаще всего и описывается), ее должен установить и около стоять человек, знающий премудрости этого дела, знающий shell, а так, разобраться с работой в lin ничего сложного, по моему, нет. Идея: собирать всякие советы (только не очень уж глупые и очевидные, до которых можно докопаться, хорошенько почитав howto, man, etc), единообразно их оформлять... Может быть написать книгу о программировании, в том числе GUI для linux? Кстати man - тоже древность! Хачу графический браузер по справочным файлам, с возможностью геперпереходов между документами. Есть такой для man? Пора уже давно переконвертить все в другой формат, с возможностью использовать картинки (например, html), написать нормальную централизованную help-службу и забыть про этот о<от<тс<ст<то<ой<й. Слишком много атавизмов в linux - каналы (ана...) - почему это до сих пор используется (во всяких там системных, инициализационных скриптах)? Блин, ну не нравится мне все это. Формат архивов tar.gz и tar.bz2. Кто это придумал? Для того, чтобы просмотреть список файлов, необходимо полностью распаковать верхний архив (gz или bz2), а уже потом извлекать список файлов из tar. Это нормально? Можно ли добавлять к таким архивам информацию для восстановления как в rar и imp, позволяющую восстанавливать архив при его порче? (например, не прочиталось у вас несколько секторов на дискете - каждый по 512 байт! - не беда. Если они далеко друг от друга, rar часто может полностью восстановить этот архив!) Еще мне не нравится эта куча /usr/bin. mc даже тормозит, когда заходишь туда. Я предпочитаю раздельное хранение файлов разных программ, но совместное хранение файлов одной программы! Идея: virtual file structure - в каталоге /posix например все как сейчас в /, а в корне лежит /program, в котором есть подкаталоги kde, gnome, X, mc и др. Что-то в этом, по-моему, есть... А да, еще, специальная служба поиска исполнимых файлов, а не этот $PATH (у меня там 3 раза повторяется /usr/bin, в результате, похоже, 3-раза перебираются файлы в этом каталоге - как избавиться, я, ей богу, не знаю, знаю что это появляется после вызова gdm - в консоли такого чуда нет). Я использую xmms как muzic player. Поставил real time prior. Система не глючит, как обещалось, но иногда все-таки происходят прерывания в проигрывании. Почему? Специально запускал Process Meneger - загрузка процессора несколько процентов, свободной памяти (не занятой не под что) куча, и все равно, иногда звук пропадает. Похоже из-за обращения к диску... Кстати, кто-нибудь занимался замерами производительности/ эффективности систем памяти/кеша/диска? Есть ли какие-нибудь программы тесты/ускорители? Я встречал linux powertweak. Кто-нибудь что-нибудь писал свое? (Вот она, ваша лучшая поточность линукса - на P133, помнится, под win95 winamp (с нормальным приоритетом) почти никогда не сбивался (только если дискету пишешь - все-таки через BIOS - или ошибки при чтении), можешь как бешенный переключаться между задачами, в том числе досовскими - ни запиночки тебе; блин, а здесь - юзаешь freebirth, дернешь мышью - на тебе, заикание, rebirth так не глючил!) Кстати xmms (вернее mikmod как plugin) плохо играет модули it. Не поддерживаются какие-то команды новых версий формата. В итоге некоторые треки от Unreal или его продолжений играют как-то глюкаво. При этом у xmms отключается ползунок положения в файле. Есть ли нормальный (без указанных "особенностей") mod player? Пытался собрать одну из недавних версий freeamp. MP3 он у меня так и не заиграл - выпадал с core-дампом :( sh - полное глюкалово. Чтобы разбираться в программах, написанных на sh, необходимо выучить наизусть, чтоб от зубов отскакивало, весь его синтаксис и многие параметры некоторых команд. Но шелл - сердце unix/linux, важнее kernel, без него никуда. Shell - это то, что отпугивает начинающего линуксиста первым делом. Если в С еще можно, че-то понять не углубляясь, то shell... Да, слава богу, разбираться в скриптах приходится не очень часто, в RedHat более или менее все настроено... Короче, идея: делать sh более доступным для неподготовленного пользователя. Необходим интерактивный отладчик sh (может уже есть?), вьювер с продвинутой визуализацией синтаксиса, раскрытием использования переменных, раскрытием вызовов (убирать всякие экранирующие символы, ...) и многое другое... Опять же shell - это тормоза. Может компилятор (скорее виртуальная машина, как в яве)? Или perl? Насчет отладчиков вообще. Я видел ddd. Интерфейс у него поганый, хотя идея супер - отображение данных в необходимом пользователю виде. Например можно построить 3-х мерный график, или отобразить список действительно как последовательность элементов, связанных стрелками, с динамическим обновлением в процессе отладки программы! Какие еще есть оболочки для gdb? Чтоб также интерактивно как в Delphi, или, на худой конец, как в SoftICE? Пытался поставить xfstt (Сервер шрифтов ttf). Почему-то высота символов определяется неправильно - над и под символом слишком большое пустое пространство - как от этого избавиться? ... Да, но это было потом, а пока я его поставил (из rpm). GDM перестал загружаться, все время изменяя режим экрана с графики на текст и обратно. В итоге Ctrl-Alt-F1, Alt-F1 для переключения в консольный режим не работают, Ctrl-Alt-BS не работает, остается только Ctrl-Alt-Del. Что делать, если system run level 5? Многие ли пользователи знают об возможности lilo задать параметры загрузки? Короче в ситуации, когда что-то портится в настройках и при инициализации система падает, сбрасываем комп (Ctrl-Alt-Del), останавливаем lilo (Tab), пишем: linux single или linux init=/bin/sh и после инициализации ядра видим приглашение shell (можно приступать к ковырянию в файлах настройки). Этот же прием можно использовать, чтобы залезть в чужую систему (По крайней мере по умолчанию в RedHat никакой защиты не стоит. Конечно, это можно исправить, потратив какое-то время на разборки с хаутами, скриптами и е-тэ-цами). Так вот, насчет xfstt. Похоже он вставал на 7100 порт, замещая собой xfs, стандартный сервер шрифтов, в итоге X-ы не могли найти фонт fixed и выпадали. Необходимо указать ему через параметры командной строки встать на 7101 порт. Так вот, кто дочитал, насчет hdparm. Если у вас современная машина (ну не 4-ка скажем, хотя бы Пень на интеловском чипсете), есть такая команда: hdparm -u 1 -c 3 -d 1 -m 16 /dev/hda (еще параметр -X66, если UDMA33, как UDMA66 я не знаю). Включает нормальную работу с дисками. Теперь при вызове hdparm -t /dev/hda у меня показывает 18Mb/сек. Результат на лицо и нагрузка на проц при выполнении дисковых опреаций меньше. Вот еще один бич RedHat - по умолчанию многие параметры стоят по минимуму, в расчете на самое старое и глюкавое железо. Кто-нибудь еще чего-нибудь этакое знает? Буду(ем) признательн(ы)! Кстати все равно, дисковая система работает как-то медленно. Как говорится, проведем эксперимент. Вызов команды copy под win95 на файл pak0.pak от halflife размером 295796K занимает 52 сек (с раздела на раздел). Вызов cp под linux : 1) ext2 -> ext2 - 55 сек (головки почти не двигаются по поверхности диска) 2) с vfat -> vfat - 225 сек !!! - условия, те же, что и в windows 3) с vfat -> ext2 - 65 сек. Ну, что тут посоветуете/поясните? Пробовал vmware 2.0. Очень здорово. Даже звук работает, winamp почти не тормозит (ладно тормозит, и сильно, даже слушать не возможно, ведь эмулируется SB16 - блин, не могли, что-ли драйвер написать, как для экрана написали?). Умудрился настроить виртуальную sambу, теперь есть доступ из винды к разделам fat не напрямую, что опасно, а через сеть, что, правда, немного медленее. Правда с русскими именами беда, а так все класно. Можно работать в ворде или билдере. SysInfo из Norton Utilites показывет производительность больше, чем под виндами :)). Кстати, необходимо поставить в виртуальной винде специальный драйвер экрана и vmware tools (они прилагаются). Теперь работает буфер обмена между виртуальной виндой и linux! А также мышь переходит из экрана виндовс на экран linux-a и обратно. Так что, если ресурсы позволяют, есть желание/необходимость - попробуйте! ****** В общем, тому, кто связался с linux, нужны терпение, везение и драйвер руки.sys (руки.o, по нашему). И для людей, не обделенных природой, lin является серьезной альтернативой винды, даже в качестве десктопа. Машина чувствует человека - у меня и linux (после некоторых настроек) и win95 osr2 (2 года не переставлял и не собираюсь) /ie3.01(нет инета дома :( /Off2000/NU/Quarterdeck Cleansweep Uninstaller/Half Life and Opposing Force/ работают нормально. Заключение: человек, поставивший linux дома, не может не быть программистом. Слишком многого нет или, если есть, то недоделано. Таковы реалии бесплатного софта: пишу под себя, хотите - меняйте, не хотите - не пользуйте. Хотя настраиваемости и свободы выбора у lin безусловно больше, чем у win. P.P.S. Загляните на www.freshmeat.net, www.linuxberg.com, sourceforge.net Номера версий большинства программ < 1.0, но сколько их! Все только начинается ...

anonymous

На счет скорости Х. И согдасен и не согласен. Я бы сказал, что Linux+X у меня грузятся и работают не медленнее, чем Win98 (iC-375A,RAM128M, i740). На счет излишне тяжелой клиент-серверной архитектуры - вынужден согласиться. Хорошо бы, чтобы была спецверсия Х для рабочих станций. Еще я бы приветствовал библиотеку виджетов совместимую с Win API или Macintosh Toolbox. Не хватает общей графической системы для единообразного вывода на любой графическое устройство О GDB и разработке вобще. Есть xxgdb. Он не мощнее gdb, но все-таки визуальный.Вроде бы есть (или только разрабатывается) Delphi и BCB под Linux. Я не любитель продуктов Borland, но за это я их зауважал. Вообще, документации по программированию полно. Правда, англоязычной. И на счет libtiff и libjpeg. На самом деле почти все программы на всех платформах, работающие с tiff и jpeg так или иначе используют эти библиотеки. Проблема скорости не в них. После декодирования изображение надо запихруть в используемые на данной платформе структуры, а в случае х86 еще и поменять порядок байтов e.g. на Mac зачитка jpg происходит быстрее, чем в виндах даже если Mac в двое слабее.

anonymous
()

В свое время юзал 2 отличных вещи под MS-DOS, полноценного аналога ни под мастдаем, ни под Linux'ом не нашел. Это Dos Navigator в качестве файл-менеджера и Multy Editor в качестве программистского редактора (не пинайте меня приверженцы emacs, ну как-то слишком непривычен он для меня оказался. Не "интуитивно понятный" у него интерфейс) Вот их мне здорово нехватает. И программирую я под консолью, поэтому использую либо mcedit, либо le. Правда когда-то всречал wpe (тогда он был очень сырой), но сейчас его нигде не нашел.

anonymous
()

Читаю прямо и узнаю себя где-то с пол-года назад. Дело не в программах, кто бы ты ни был, anonymous. Дело в человеке. Как говорил один хороший линуксоид - "посадить человека на линукс - это значит вынуть ему два полушария мозга, поменять местами и засунуть обратно". Тут везде, куда не посмотри - другие идеологии, другие подходы. И, постепенно, познав их, начинаешь понимать, что подходы-то эти весьма эффективны и даже намного эффективнее традиционных. Это относится и к средам разработке (я о emacs :)), и к коммандеру (сам наблюдал человека-линуксоида, которого по работе заставили сесть на NT'ю, так он первым делом собрал под НТей mc и emacs и заявил, что FAR'ами и редакторами типа MSVC'шного он пользоваться не будет), и вообще почти ко всему. Ответы на почти все заданные вопросы я более-менее знаю, но из-за нехватки времени, тут их писать не буду. Если будут какие-то конкретно нужные позарез вопросы - пиши на e-mail, спрашивай.

GreyCat ★★
()

Извини за грубость, но это все полный бред. Слишком много безаппеляционных
заявлений. Просто твой кругозор (пока?) ограничен лишь узким классом задач,
с которыми тебе до сих пор приходилось иметь дело. Попав в необычную среду
ты пытаешься все в ней перестроить, так, чтобы тебе было удобно, и это правильно,
только вот понятия об удобстве привиты (между прочим, насильно) средой Windows
и теми средствами, которые ты там использовал. Там --- все было жестко завязано,
здесь --- нет. И это часто сбивает с толку.
Вообще, прежде чем самому начинать рулить системой, хоть даже на
домашнем компьютере, очень хорошо поработать пользователем на хорошо
администрируемой машине, чтобы понять, как это все должно работать ``правильно''.
У людей, которые постоянно общаются с разнообразными Юниксами, что очень широко
распространено в научно-образовательных кругах, трудностей с ``удобствами'' нет
никаких. Более того, иных решений (кроме Юникс-систем) здесь нет и никогда не было.
К слову, о пресловутом hdparm. Я, когда в первый раз собирал ядро Линукс, то
предварительно прочитал все, имеющее отношение к моей системе из каталога
Documentation ядра. Ядро я собрал с первого раза и оно запустилось и долго работало,
поскольку я собрал его правильно. Второй раз собирая ядро, я уже читал исходники.
О hdparm я там прочитал (по-моему, в ide.c) и сразу его использовал. Никаких
проблем.
Кстати, если после инсталляции дистрибутива неправильно включить hdparm, то
можно никогда не дождаться загрузки системы. Придется запускать bash вместо init,
искать, где твой инсталлятор вставил вызовт hdparm, мочить его, материть авторов
дистрибутива... Поэтому нормальные дистрибутивы не включают hdparm автоматически.

DronK
()

А вот ещё - модная смотрелка графики, как заказывали - gtksee. А вместо emacs можно gvim использовать - он подсвечивает всё, что только можно и ещё можно кнопки для компиляции и менюшки прикручивать...

Shadow ★★★★★
()

Я не хочу никого обидеть, однако, согласен GreyCat потносительно другой идеологии. В Unix многое другое. Представьте себе дерево, которое, обрубили в молодости и теперь оно растет кустиками. Это я про Ms :). Программисту нужно учиться пользоватесь ресурсами системы, а не желать для себя комфорта менюшек и хайлайтинга. Если они есть, конечно не плохо, но необхожимости в них нет. Другое дело пользователь, его нужно защитить от самого себя, и от других таких же специалистов в своих предметных областях. Если очень охота - нарисуй (модифицируй) любой редактор под себя - исходников больше чем сможешь прочитать за год, но за это не заплатят. Только нужно помнить, что дешевые программы - плохие программы. В unix важно, что бы жило ядро, а не какая-то графическая подсистема. если живо ядро, то X можно убить и перезапустить. В тестах на файловую систему у меня все наоборот: ext2 несколько быстрее. А вот попробуй создать в одном каталоге 40000 Файлов. ext2 легко держит, что в прочем никого не удивительно. А вот ntfs у меня упал, что, тоже впрочем, ничего не доказывает. X должны быть сетевыми. Можно играть в doom на Sun-е (ручками и глазками), а исполняться он будет на linux. И это не требует усилий. Тоже справедливо для любой нормальной иксовой программы. Что касается переноса графического API от Win32, то это не бред, а некомпентентность. Примитивы X позволяют создавать произвольные объекты, например с четыремя стандартными рамочками и тремя заголовками, ведущими себя как рамочки и заголовки. Потому что чистые X - очень низкий уровень. По-этому и возможна такая большая семья хорошо совместимых десктопов и менеджеров окон. О компиляторах, говорить не буду - до сих пор не понимаю тех, кто любит паскаль. Что касается литературы, то согласен - популярной мало. Man'ы и info читать тяжело, исходники еще тяжелее. Ну никто не обещал рая на земле. Однако литература стала появляться, в том числе популярная для программситов. Но man's и *.с все-таки лучше...

hawk
()

Зря ты недолюбливаешь man, хорошая ведь вещь. Да с русской документацией проблемы, но разбираясь в буржуйских доках хоть немного выучил english 8-) Ты слишком много наваял, и правильного и неправильного, что отвечать тебе непонятно на что. PS: а вот, Xfree4.0 действительно быстрее работают, и TTF рисовать уже умеют без второстепенного сервера, хотя падают в нетскейпе иногда на русских кодировках.

anonymous
()

Ага уже все знают как сделать чтобы нетскапа и гнома не падала?:))

anonymous
()

Нетскапа - своп большой сделай! Он тогда реже падать будет. Опять же, последняя версия - надёжней.
У меня своп - 250 мб.
Если совсем плохо - выруби яву и ява-скрипт.
Хотя, у меня и флэш, и адоб, и рилплеер - и ничего...
GNOME - это проблемы Imlib. Отключи MIT-shared - перестанет падать... А вообще, у меня после экспериментов с цифирками и так не падает...

Shadow ★★★★★
()

Столько всего сказано, что не знаю с чего начать. Я то же к Win нормально отношусь, но "единообразие" там какое-то :-0 GUI, например. Почти каждая программа танет за собой свою GUI библиотеку. Кнопочки в Outlook Express 5.0 делаются совсем не так, как в Internet Explorer 5.0, и совершенно по-другому, чем в Office. Выглядит то всё одинаково, но если запустить WindowsBlind (программа, которая скиннирует Windows), сразу видно, что сшито белыми нитками. Кнопочки в IE скиннируются, потому что стандартные, а в MSOE нет, потому что свои. У Photoshop целиком все widgets нестандартные, хотя прикидываются таковыми. Про программы от Visual Basic и говорить не хочется - там только вызов библиотеки vbrun<version>.dll и мусор, который этой библиотеке передаётся. Верный способ проверить программу под Windows на нормальность - запустить её в Linux через Wine, а запустить там продукты от Microsoft нереально. Чтобы GNOME не падал нужно в настройках Imlib > Rendering отключить MTH shared memory. Дистрибутивы Linux медленные и большие оттого, что обеспечивают двоичную совместимость, то есть запускаются на любом 32-разрядном Intel процессоре. Какого MMX ждать от RedHat, который оптимизирован под i386? От такой заботы о совместимости получается нечто монструозное, забивающее диски, память, и процессор - но хотел бы я видеть человека, запускающего GIMP, или того хуже XMMS на i386. По-моему, ничего хорошего от таких дистрибутивов не дождёшься - самому нужно компилировать. GCC 2.95.2 + PGCC 2.95.3 export CFLAGS="-06 -march=pentiumpro -mmx -funroll-all-loops -mstack-align-right" - получаешь GIMP c MMX и Photoshop's rest in peace. Лучшего всего Linux/GNU целиком так воссоздать from scratch - тогда он вполне может запуститься за сакраментальные 8 секунд. Если потом для всех исполняемых файлов ELF (*, *.la, *.a, *.so , *.o) запустить команду strip --strip-debug, то их размер уменьшится раза в три. > Хачу графический браузер по справочным файлам, с возможностью геперпереходов между документами. Есть такая малоизвестная вещь :-) GNOME Help Browser (c GTK+ interface, если не догадался ;-) На первой странице ссылка Man Pages - так они все с содержанием красивые, дивными стилями отформатированные, гиперссылками связанные, гиперссылки - чудо дивное - синие, да ещё подчёркнутые... Распаковывать архивы чтобы список файлов посмотреть - никому даром не нужно. В полунощном командоре, например их можно как dir смотреть и всё, что хочешь, с файлами внутри делать. Есть ещё KZip. А с консоли - набираешь tar It *.tar.bz2 или tar zt *.tar.gz работает как ls, если добавить v будет как ls -l. Если заглянуть в ненавистный man (через не хочу), можно было бы это узнать. Если не нравится ext2fs перейди на ReiserFS, которая быстрее, свободное место на диске экономит и журналируемая (при сбое fsck запускать не нужно она сама восстановиться) Насчёт /program et caetera - можешь дать эту идею в http://www.pathname.com/fhs (там разрабатывается стандартное дерево каталогов для Unix) - хотя вряд ли они поймут :-<. Но если сильно хочется, возьми исходные тексты X, KDE, mc и т. д. и сделай что-нибудь вроде ./configure --prefix=/program/<name> make make install Почему бы базовые программы RedHat не поместить в каталог /linux, вместо /lib /linux/system32, а вместо /home/<user> - /linux/users/personal_data/my_documents и всё будет MustDi... то есть я хотел сказать замечательно. Предупреждение: чтобы запустить программу, придётся её полное путевое имя указывать (/program/mc-4.5/mc), или все /program/<name> в $PATH запихивать. Что в этом по-моему есть... Возможность входа с linux init=/bin/bash никак нельзя использовать, чтобы навредить чужой системе. Во-первых, входишь с минимальными правами и большинство файлов недоступно даже для чтения, зайди /sbin увидишь, что количество яайлов там подозрительно уменьшилось, во-вторых, диск монтируется только read-only. А если входить с linux single, нужен пароль для root, что в наше время теневых паролей проблема. Чтобы звук в XMMS не прерывался, можно изменить приоритет командой nice, но лучше в настройках выбрать другой output plugin. У меня например, стоит ALSA (Advanced Linux Sound Architecture, замена OSS http://www.alsaproject.org) и проблем со звуком никаких, даже на Pentium 120. А то, что разработчики XFree86 выбрали приоритетом не непрерывность движения мыши, - может и к лучшему. Надеюсь я чем-нибудь помог и ни в чём не ошибся ;-) P. S. вот есть ли бы Windoze так нумеровались как программы на freshmeat, а? Вот и дождались наконец версии 0.0002, как-никак "новый стандарт надёжности".

shankara
()

Такими темпами сейчас вся дискуссия опять во флейм перейдет... Но все-таки попытаюсь вставить пару слов... Полностью согласен с shankara по поводу маздая - M$ уже давно сама запуталась в своих "стандартах", сама же их объявляет и тут же нарушает. Есть "стандартное" меню - так нет же, надо нарисовать в MSOE свое, чтобы оно выглядело круче, фиг с ним, что половина функциональности клавиатуры пропадает (кто из маздайщиков клавиатурой пользуется...) Примеров много. Насчет оптимизации с помощью PGCC и прочих продвинутостей - по-первых, тот же RH выпускает 2 версии дистрибутива: для i386 (для всех) и для i686 (для избранных со вторыми пнями). У меня P2 нет, поэтому я себе поставил 7-й мандрейк, он под i586 соптимизен. Насчет 386-х - XMMS, вернее его энжин - mpg123 вполне сносно идет на трешке с некоторыми ухудшениями звука. Насчет манов в GUI - тот же kdehelp умеет все показывать - и маны, и инфы и все с гиперссылками и т.п. Насчет номеров версий - тоже согласен, выпускать версии 0.x - это по-крайней мере честно. Ты говоришь этим юзеру, что честно признаешь, что программа может иметь кое-где глюки, не обладает полной задуманной функциональностью и т.д. и т.п. В маздае все выпускают сразу же 1.0 (хорошо, еще, если бет повыпускают) и потом уже на ходу все чинят. Да там в общем и о нормальном девелопменте речи не идет - CVS там никто не юзает, нормальные библиотеки и т.п. - тоже, о портабельности даже речи нет...

GreyCat ★★
()

Для меня линукс как библия 1) Источник знаний и истины 2) Всеобщедоступный 3) Требующий веры,терпения и понимания

anonymous
()

Спасибо, GreyCat, что нашел время в чём-то со мной согласиться ;-) "RedHat для избранных" всего лишь маркетинговый ход, что вообще RedHat свойственно - взять хотя бы for Oracle 8 за 1500$. Сделан он тем же GCC, правда с флагом -march=i686. Какой от этого толк не знаю, но в документации к GCC ясно сказано, что ничего выше i486 не поддерживается. К тому же, насколько я понял оптимизирован только 6.1 и это нечто вроде бета-версии. Насчёт Мандраки согласен, но вот цитата с сайта PGCC - "Mandrake-Linux is also built with PGCC, but does not aim at the poweruser as much the others". А фраза, которую я встретил на каждой страничке сайта Мандраки - "на 99% совместим с RedHat" - меня убила. Если это GNU/Linux, то binary из любого дистрибутива можно запустить на любом другом. Если же дистрибутив совместим с другим на меньшее, чем 98% (на уровне исходных текстов, я хочу сказать) - это уже не GNU/Linux, а, скажем, FreeBSD ;-). И как они только считали процент совместимости?... И что самое ужасное: все дистрибутивы компилированы с вторым уровнем оптимизации (у PGCC их шесть). 8-<

shankara
()

Пусть на меня ворчат приверженцы слаквари и Debian, но Mandrake 7.0 работает намного быстрее, компиляция базовых программ под пень даёт свои плоды. И ещё - своп одна из основных факторов производительности, поэтому разместите его на быстром диске и желательно в начале диска.

crazyalex
()

Все на самом деле очень просто. Дело в том, что возможности PGCC, EGCS и тому подобных компиляторов на высоких уровнях оптимизации являются экспериментальными. То есть их мало кто отлаживал и вообще мало кто пользуется. Это именно _экспериментальные_ уровни, они как правило генерят код с ошибками, причем часто со скрытими и не проступающими сразу. Я помню, что когда писал еще игрушку свою под дос/djgpp, поставил в PGCC -O6 - у меня тогда при запуске бинарника вылетел не только бинарник, но и RHIDE, MS-DOS Prompt и потом вылетела 95-ая винда с чем-то типа kernel32.dll... Поэтому в обычных дистрибутивах, будь по мандрейк или редхат, ими и не пользуются. От линукса ждут в первую очередь стабильности - а какая же тут стабильность, если система будет накрываться по паре раз в день из-за ошибок компилятора? Так что для этого есть спецдистрибьюшены, типа Stampede Linux, Turbo Linux и всякие прочие. Stampede я когда-то давно видел, помню точно, что накрывались проги там довольно часто и беспричинно (хотя ядро работало железно). Видимый прирост производительности - небольшой есть, но я не думаю, что такая нестабильность его окупает. Так что мандрейк7 скомпилен с некой позиции золотой середины - с одной стороны - и не падает сильно, с другой - и не совсем уж под чистую трешку... P.S. Времени мне не жалко, проблема в том, что у меня в интернете время довольно-таки ограничено...

GreyCat ★★
()

1) Не нравятся корки - не кидай их. man bash на предмет ulimit.
2) X-сервер на многих карточках весьма неплохо использует аппаратное 2D-ускорение.
3) На локальной машине X-протокол не поверх TCP/IP работает.
4) Кроме того, если кому-то надо шустро бегать в ущерб сетевой прозрачности - то есть на это DGA.
5) Единственно Верный Редактор Всех Времен И Народов - XEmacs. Аминь.
6) x86 sucks, MMX sucks. Аминь.
7) ASM sucks. Аминь.
8) C/C++ sucks. Аминь.
9) Книги по X - есть такое издательство, O'Reilly зовется.
10) По системному программированию - читай Робачевского, он крут.
11) Читалка документации - pinfo. Рулит до форевы.
12) Опция -mmx у PGCC - верный способ получить глючный код из абсолютно безглючных сырцов.
13) Все, надоело... Дальше сам разбирайся.

vsl
()

14. Если разобьешь /usr/bin на programs/... , то придется либо работать только с десктопом и набросать на него иконки запускаемых программ, либо добавить в PATH все bin каталоги программ. Первый путь не позволяет тебе использовать коммандную строку, а второй явно тяжелее, чем держать все в /usr/bin. А набирать в консоли полный путь бинарика при запуске (при этом подумай какой при такой системе этот путь будет....) .... увольте.
не vsl.

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

Посмотри на stow. Он ставит в $KUDATO/programname, а в prefix, куда пакет должен был бы стаивться навешивает симлинков.

vsl
()

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

GreyCat ★★
()

Что плохого в интуитивно понятном и приятном интерфейсе (что проще и быстрее - расставлять кнопки в Delphi или ручками задавать все координаты, представляя окошко в голове; или, набирая текст, менять шрифт, размер, атрибуты, парой нажатий на кнопки) Нельзя в Delphi "парой нажатий" расставить координаты ! Несмотря на все Anchors если у тебя программа не с одной (двумя) кнопками, а есть десяток-другой компонент пересчёт для разных разрешений\размеров всё рвно придётся делать ручками хочешь ты того или нет.

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

Типа, гражданин хороший не слышал про layout managers. Известная беда всех виндузных гуелабателей - не знают прогрессивных технологий. А потом при ресайзе все на дерьмо исходит.

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

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

vsl
()

Тогда чем это принципиально будет отличаться от RPMок редхата, если ставить - через утилиту, а не ручками, стирать - тоже. Только извращений куда больше. Так что юзеру - RPM в лапы. Я, например, когда знаю, что в пакете точно копаться не буду и он меня никак не интересует (хотя таких пакетов мало, на вскидку назову только xmms) - с чистой совестью качаю RPM и не мучаю свой процессор и хард лишние 15 минут конфигурением и сборкой. Насчет layout managers - это да :) После них в Delphi - просто ад, с их кривыми панельками и align'ами... А тут - и тебе ресайз, как нужно, с разными stretch'ами у разных элементов, нелинейным расширением и тому подобными вещами :)

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

А далеко не для всех софтинок RPM найти можно. Правда, я предпочитаю не stow для такого дела юзать, а installwatch - его в RPM перегнать элементарно, и spec писать не нужно. Практически весь гнутый софт давно уже в достаточной мере plug'n'play, любой юзарь может выучить волшебную последовательность './configure; make; su; make install'

vsl
()

Согласен, хотя я помню кто-то жутко извратный метод предлагал в виде програмки, которая делает автоматом configure;make;make install, потом у make install'а перехватывает все попытки инсталлить файлы, формирует из такой радости полноценную RPMку и потом уже ее ставит корректно через rpm -i. А насчет установки полностью ручками - это тоже весьма неплохой вариант. По крайней мере все, что ставишь ручками - ставится в /usr/local, где скопится, ну, максимум штук 20-30 программ, которые ты так поставишь. Обшарив все небольшое дерево /usr/local ты можешь честно все, относящееся к программе стереть и точно знать, что нигде больше ничего не осталось.

GreyCat ★★
()

Вижу, хороший для unix comunity человек пропадает. Короче, ответы на вопросы:
1)Чтобы не создавались дампы, вставь 'ulimit -c 0' в ~/.bash_profile
2) Использование библиотеки для чтения конфигов (как встроена в gnome-libs -  gnome_config_*) также легко, как и чтение реестра в винде, и для админов удобнее.
3) В mc  вместо ctrl-enter alt-enter в xterm, ctrl-enter в консоли. Во встроенном редакторе mc на косоли ctrl-shift-{ins,arrow} работают. Аналог alt-клавишы - ctrl-s .История ввода - ctrl-h. Насчет улучшения - уже много русских его улучшают, да вот патчи, суки, не интегрируют.
4) юзай gtksee. Можно xzgv
5) Купи другую мышь с 3 кнопками - не пожалеешь. Ср. кнопку можно использовать для быстрой прокрутки (скроллбар перемотается туда, где щелкнули, а не на страницу).
6) SourceNavigator уже под GPL - смотри новости на этом сайте
7) Перекомпиляй софт, тормозящий у тебя, с оптимизацией под твой камень и может быть без отладочных возможностей.
8) Насчет флага вместо Пуск - бери исходники и смотри. Благо, они доступны.
9) Книги по gtk - www.gtk.org/rdp (ну или с корня начни). По QT есть маны и наверно много книг тоже.
10) Linux есть unix, поэтому ищи сначала книгу про юникс (а те со словом "linux" в названии - скорее просто лажа, если рядом нет слова kernel).
11) winamp у меня на celeron525/75fsb заикается когда я в фаре текст редактирую под виндой (ничего больше не запущено)!
12) Всяких плееров для mod должно быть дохрена - см. freshmeat.net
...) В целом - надо просто свыкнуться с мыслью, что привычные в винде
   вещи - не единственный возможный (а далеко не оптимальный) способ
   для выполнения каких-либо действий. Винда и ее софт отучает пользователя
   думать. В целом, лучше принять положение вещей в юниксе как данное
   (лучше не задумываться, почему оно сделано именно так) на первых порах,
   чтобы пропитаться духом unix, а потом реабилитировать свое
   "программистское Я". Еще следует помнить, что unix-системы и софт
   не гоняться за производительностью в некритичных местах - и на первое
   место ставится гибкость/интероперабельность/взаимозаменяемость/модульность.
   Удачи в мире unix.

hvv
()

если вас что то не устраивает в линухе - возьмите исходник и исправьте. :)

anonymous
()

Ребята как делать динамические библиотеки под Линух кто-нибудь этим занимался? Andrew moonship@yahoo.com

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

Настоятельно рекомендую не делать динамические библиотеки ПОД ЛИНУХ, а взять libtool. Читай info на него и проникайся.

vsl
()

Ну всетаки почему и как делать динамические библиотеки?

Andrew
moonship@yahoo.com

anonymous
()

Для начала man gcc на предмет опции shared. Дальше --- по вкусу и характеру поставленной задачи

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

Слушай, я тебе уже сказал, как их ПРАВИЛЬНО делать: возьми libtool. Потому как если ты сам будешь иметь секс с опциями gcc, то ни на какой другой платформе потом твое поделие не заработает, да и под линухом ты имеешь все шансы пройтись по множеству граблей. Так что не умничай, а пользую правильные софтины.

vsl
()

Да не слушай ты эти "настоятельные рекомендации". Сборка dll'ек это не изучение лиспа. За несколько минут научишься собирать dll'ки под linux, поймешь что к чему, а потом и на libtool перейдешь (потому, как собирать их надо конечно же в libtool). info gcc, GCC-HOWTO, ELF-HOWTO, info libtool.

anonymous
()

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

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

Вот именно. Все надо делать проще, и без особой нужды не копаться в потрохах.
Как ты думаешь, что проще и понятнее:
$(LIBTOOL) --mode=link $(CC) -o libtratata.la tratata0.lo tratata1.lo -rpath ... -version-info ...
(и потом так же просто можно сказать --mode=install, сработает это на любой платформе, соберет и статическую и динамическую библиотеку, если попросишь, и прочая, и прочая)
или же:
все сырцы не забыть собрать с -fPIC (а то на грабли потом наступишь - мало не покажется, и поди разберись, где PIC забыл...)
gcc -shared tratata0.o tratata1.o -Wl,-soname -Wl,libtratata.so -o libtratata.so
(и потом иметь секс с прописыванием правильного LD_LIBRARY_PATH, путаницу с версиями динамического бинарника, писать свою процедуру инсталляции... ужас!)

vsl
()

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

DronK
()

ОК сделал Динамическую Либу. Вроде пашет. Спасибо всем. Andrew moonship@yahoo.com

anonymous
()

Господа! Обломы кругом! У меня Mandrake 6.0 от IPLabs. Я не программер.

Проблема - нету хорошего текстового редактора, описанного выше.

Причины таковы: mc работать не желает. При нажатии стрелок выдает в командную строку буквы, а потом вываливается в кордамп.

Vi и клоны, а также emacs тяжеловаты в изучении, мне нужно-то совсем немного. Убивать на них время не хочется.

И, наконец, kwrite работает с шрифтом, который при переключении клавы на русскую показывает кракозябры.

Пока работаю в kedit, в том числе и пишу скрипты на перле. Но это неудобно.

Как сделать, чтобы kwrite работал с каким-нибудь русским шрифтом, например, с курьером? Я заглянул в настройки - нет там опции изменить шрифт.



С уважением, LW.

anonymous
()

Попробуй пересобрать mc из исходников. Кроме того, почему бы не воспользоваться gVim? Это vi под X, там есть меню, при этом сохраняется возможность управления командами --- можно привыкать постепенно. Хотя лучше сразу начинать работать с vi правильно.

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