В традиционном понимании, свободное ПО—это такое, при использовании которого пользователь обладает правами на 1) запуск, 2) изучение, 3) копирование и 4) изменение.
Да, теоретически современные дистрибутивы Линукса обладают этими качествами.
Но на практике современный пользователь никогда не пользуется этими своими правами. И для этого есть вполне естественное ограничение: огромная сложность всего.
Огромная сложность системы, по сути, сводит на нет все идеологические преимущества от свободного ПО. И сложность во всём: начиная от простейших утилит типа cat'а.
В результате во многих современных дистрибутивах не то что исходных кодов нет (их сейчас почти нигде нет), но нет даже заголовочных файлов для библиотек. Действительно, зачем пользователям что-то компилировать?
Так что и получается, что Linux вроде бы свободен, а толку с этого... Только бесплатность.
Толк в том, что Линукс более гибок и может очень быстро изменятся, в отличии от других ОС.
Цитата: hurufu от декабря 12, 2011, 01:35
Толк в том, что Линукс более гибок и может очень быстро изменятся, в отличии от других ОС.
Вот только что ехал и слушал лекцию (http://polit.ru/article/2011/07/13/bazykin/) о том, что ВИЧ более гибок и может очень быстро изменяться, в отличии от других вирусов. Поэтому с ним так сложно бороться.
;D
Не преувеличивайте огромную сложность.
Цитата: amdfНе преувеличивайте огромную сложность.
Я и не преувеличиваю.
Более того, даже простые вещи типа команд, запускаемых при запуске, ухитряются усложнить до максимума. И всё ради «дружелюбности».
Никто ничего усложнить не пытается.
Не спорю, специальной цели усложнить что-либо не ставится. Но от этого оно проще не становится.
:fp:
Строго говоря, современный линукс недостаточно юниксвеен. Теоретически, должно быть: «Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.» На практике, пользователю приходится иметь дело с многофункциональными монстрами с графическим интерфейсом — соответственно, традиционный механизм перенаправления потоков ввода-вывода для этих случаев бесполезен, а какого-либо общепринятого стандарта для взаимодействия между собой нескольких графических приложений я пока не заметил.
Цитата: Python от декабря 15, 2011, 01:16
Write programs to handle text streams, because that is a universal interface.
Всегда бесило!
Всё конвертировать в текст, потом обратно — это уродство, потеря производительности и, иногда, причина глюков.
Цитата: Python от декабря 15, 2011, 01:16
Строго говоря, современный линукс недостаточно юниксвеен.
+1
Цитата: Python от декабря 15, 2011, 01:16а какого-либо общепринятого стандарта для взаимодействия между собой нескольких графических приложений я пока не заметил.
dbus?
Цитата: TeilnehmerВсегда бесило!
Всё конвертировать в текст, потом обратно — это уродство, потеря производительности и, иногда, причина глюков.
Как показывает практика, ничего лучше не придумали. :donno:
Цитата: Teilnehmerуродство
А по-моему это элегантно.
Цитата: Teilnehmerпотеря производительности
Предварительная оптимизация есть корень всех зол же.
Цитата: Teilnehmerпричина глюков.
Глюки при работе с текстом легче устранять, чем при работе с другими форматами, так как текст может прочитать человек.
Цитата: Demetrius от декабря 15, 2011, 11:06
Как показывает практика, ничего лучше не придумали.
Так надо придумать.
Цитата: Demetrius от декабря 15, 2011, 11:06
Предварительная оптимизация есть корень всех зол же.
Когда массив double'ов передаётся как массив double'ов — это не «предварительная оптимизация», это вообще ещё не оптимизация.
А вот когда его приходится сперва превратить в комма-сепарейтед список из десятичных записей вида -4.189406564584124654E+104, а потом всё это проделать обратно, и при этом в разных локалях будет разный символ для отделения целой части от дробной, и где-нибудь он совпадёт с разделителем чисел в списке — вот это, конечно, очень элегантно.
На мой взгляд, у текстовых файлов есть такие проблемы:
1) Они последовательны. Чтобы взять что-то из середины большого файла, нужно читать его с начала и по порядку.
2) Они заставляют программы выполнять лишние преобразования данные→текст→данные. Парсинг текста — иногда сложная задача. И хорошо ещё, когда такие преобразования гарантированно однозначны, а так бывает не всегда.
3) Текст занимает больше места.
Обычно в защиту текстовых файлов говорят, что их может читать и править человек. Но во-первых, в подавляющем большинстве случаев это не требуется. А во-вторых, стандартизированные не-текстовые файлы тоже может править человек, если вместо «Блокнота» использовать программу для редактирования таких файлов, входящую в стандартную комплектацию ОС.
Осталось только придумать хороший стандарт бинарных файлов.
Линукс проще в использовании.
И что толку, что линукс кто-то не может освоить? Линуксу это никак не мешает существовать.
Цитата: Тайльнемер от декабря 15, 2011, 06:29
Всегда бесило!
Всё конвертировать в текст, потом обратно — это уродство, потеря производительности и, иногда, причина глюков.
Абсолютно согласна.
Цитата: maristo от декабря 15, 2011, 11:49
Линукс проще в использовании.
ЩИТО?
То, что Windows делается парой кликов, в Линуксе требует значительных усилий.
Даже такая элементарная вещь, как настройка VPN. С раскладками опять же там хуже.
Цитата: amdf от декабря 15, 2011, 12:44
И что толку, что линукс кто-то не может освоить? Линуксу это никак не мешает существовать.
...среди полутора процентов пользователей. Что какбэ намекает :)
Цитата: Dana от декабря 15, 2011, 13:05
То, что Windows делается парой кликов, в Линуксе требует значительных усилий.
Например? Допустим нужно настроить сочетание клавиш для максимизации окна. Действия в виндоусе?
Цитата: Dana от декабря 15, 2011, 13:05
Даже такая элементарная вещь, как настройка VPN. С раскладками опять же там хуже.
Чем хуже?
Цитата: RawonaM от декабря 15, 2011, 13:17
Цитата: Dana от декабря 15, 2011, 13:05То, что Windows делается парой кликов, в Линуксе требует значительных усилий.
Например? Допустим нужно настроить сочетание клавиш для максимизации окна. Действия в виндоусе?
8-) В фоновый AHK-скрипт добавляем строчку
#F1::WinMaximize, A ; Win + F1 maximize active window
AutoHotkey — средство от всех изжог. :green:
Цитата: RawonaM от декабря 15, 2011, 13:17
Чем хуже?
Сделать customную раскладку с мертвыми клавишами очень сложно в Линуксе.
Да кому интересны какие-то там пользователи, если линукс работает на серверах.
Цитата: Dana от декабря 15, 2011, 14:33
Цитата: RawonaM от декабря 15, 2011, 13:17
Чем хуже?
Сделать customную раскладку с мертвыми клавишами очень сложно в Линуксе.
Сложно не сделать, а портировать с винды. Просто мертвые клавиши и compose-последовательности настраиваются отдельно от собственно раскладки, некоторые действия с клавиатурой невозможно реализовать идентичным способом (хотя возможно). Хотя, в общем, графическая среда (управление раскладками — часть ее настроек) юникс-подобных систем достаточно неюниксвейна.
ЦитироватьКогда массив double'ов передаётся как массив double'ов — это не «предварительная оптимизация», это вообще ещё не оптимизация.
При условии, что внутренний формат чисел с плавающей точкой один и тот же в разных программах. Ну и массив — Java и C эти структуры реализовывают несколько по-разному, а некоторые языки вообще не имеют типизированных массивов.
ЦитироватьОбычно в защиту текстовых файлов говорят, что их может читать и править человек. Но во-первых, в подавляющем большинстве случаев это не требуется. А во-вторых, стандартизированные не-текстовые файлы тоже может править человек, если вместо «Блокнота» использовать программу для редактирования таких файлов, входящую в стандартную комплектацию ОС.
Чтение человеком нужно, в первую очередь, на стадии отладки сценария. Вместо человека вполне можно посадить программу, делающую все необходимые преобразования и передающую результат еще кому-то. Преимущество текстовых файлов в том, что они изначально структурированы, благодаря чему облегчается написание кода для их обработки. В двоичном файле смещение на байт влево-вправо может привести к фактической потере всех данных после него. И да, двоичных форматов множество, к единому стандарту они не сводятся, а даже если и сведутся, не приведет ли это в дальнейшем к такой же потере гибкости, что и при использовании текста?
Цитата: amdf от декабря 15, 2011, 14:35
Да кому интересны какие-то там пользователи, если линукс работает на серверах.
вы сравниваете зеленое с горячим. Серверная система должна быть удобна как серверная, а та, которую используют пользователи - удобна для пользователей.
Цитироватьк такой же потере гибкости произвдительности
Исправление. По гибкости и простоте трансформаций текстовые форматы явно лучше двоичных.
Цитата: Python от декабря 15, 2011, 18:48
При условии, что внутренний формат чисел с плавающей точкой один и тот же в разных программах.
Да, возможно, на экзотических компах понадобится перевод (не думаю, что он будет сложнее преобразования из текста), но на большинстве «обычных» компов это стандартно IEEE-754.
Цитата: Python от декабря 15, 2011, 18:48
Ну и массив — Java и C эти структуры реализовывают несколько по-разному, а некоторые языки вообще не имеют типизированных массивов.
Считывание из файла в массив и из массива в файл в текстовом случае всё-равно трудоёмче.
Цитата: Python от декабря 15, 2011, 18:48
Преимущество текстовых файлов в том, что они изначально структурированы
В смысле? Это же просто набор символов.
Цитата: Python от декабря 15, 2011, 18:48
благодаря чему облегчается написание кода для их обработки
Не понял.
Цитата: Python от декабря 15, 2011, 18:48
И да, двоичных форматов множество, к единому стандарту они не сводятся
А текстовые? Разве с текстовыми не такая же ситуация?
Цитата: Python от декабря 15, 2011, 18:48
а даже если и сведутся, не приведет ли это в дальнейшем к такой же потере гибкости произвдительности, что и при использовании текста
До такого убожества, как с тестовыми файлами, стандартизация бинарных файлов явно не доведёт.
Всегда останется возможность произвольного доступа по смещению для массивов элементов одинаковой длины; хранения индекса для произвольного доступа к массивам элементов переменной длины; считывание и запись данных без лишних преобразований. А такие вещи как структурированность, безопасность типов и т. п. можно тоже при желании реализовать, ещё эффективнее, чем в тексте.
Цитата: rlode от декабря 15, 2011, 19:17
Цитата: amdf от декабря 15, 2011, 14:35
Да кому интересны какие-то там пользователи, если линукс работает на серверах.
вы сравниваете зеленое с горячим. Серверная система должна быть удобна как серверная, а та, которую используют пользователи - удобна для пользователей.
Никто никому ничего не должен, в особенность когда что-то бесплатно.
Цитата: Python от декабря 15, 2011, 19:21
По гибкости и простоте трансформаций текстовые форматы явно лучше двоичных.
По-моему, это стереотип.
ЦитироватьВ смысле? Это же просто набор символов.
Среди которых есть пробелы и окончания строк. Процедура текстового ввода обрабатывает блоки символов, разделенные «пустым пространством» — при двоичном же вводе значение имеет информация о количестве байт, которую можно получить лишь из документации (получается, текстовый формат, в некоторой степени, самодокументируемый). Также текст более удобен для представления данных произвольного размера.
Цитата: Python от декабря 15, 2011, 19:55
Также текст более удобен для представления данных произвольного размера.
Странное утверждение.
Цитата: Тайльнемер от декабря 15, 2011, 11:40
Осталось только придумать хороший стандарт бинарных файлов.
Такой формат есть — это raw.
ЦитироватьС раскладками опять же там хуже.
В Гноме и КДЕ эсперантские раскладки и локализации идут сразу в дистрибутиве, даже флажок вам выведут в трей. В винде как всегда только костыли, а о локализации и речи нету.
Сделать кастомную раскладку в линухе раз плюнуть.
По поводу кликов. Мышеводы не нужны. Елозить виндоманипулятором сложо и нудно. Я уже не говорюо том, что в винде опять же нужны костыли, чтобы настроить что-то не вынесенное в гуёвые настройки. А это уже решают мудрые виндодизайнеры.
Цитата: Drundia от декабря 16, 2011, 06:14
Такой формат есть — это raw.
Что за raw? В который фотографии фотографируют или какой-то другой?
Цитата: Тайльнемер от декабря 16, 2011, 07:43
Что за raw? В который фотографии фотографируют или какой-то другой?
Другой. Просто бинарные данные. ;D
Для фотографий фотошоп, кстати, умеет его. Но, так как заголовка никакого нет, надо фотошопу вручную говорить размеры.
Цитата: maristoПо поводу кликов. Мышеводы не нужны. Елозить виндоманипулятором сложо и нудно.
−1. Мышь плоха для ввода команд, а для прямого назначения (выделение точек и кусков чего-то) очень удобна.
Цитата: maristoЯ уже не говорюо том, что в винде опять же нужны костыли, чтобы настроить что-то не вынесенное в гуёвые настройки. А это уже решают мудрые виндодизайнеры.
Это да... У них мания в каждой новой версии всё переделывать.
Цитата: Demetrius от Другой. Просто бинарные данные.
Добавь сюда: http://open-file.ru/types/raw.
А то там только картинки и аудио.
А я ничего не говорил про расширение. ;D
Более того, обычно raw data хранят с раширением bin, а там оно как раз перечислено.
Цитата: Тайльнемер от декабря 16, 2011, 03:54
Цитата: Python от декабря 15, 2011, 19:55
Также текст более удобен для представления данных произвольного размера.
Странное утверждение.
Сочему странное? Впрочем, смотря какая разновидность двоичных форматов берется для сравнения — текст ведь тоже лишь надстройка над двоичным кодом. Идея в том, что текст не требует предварительно знать размер хранимых данных, их окончание обычно определяется явно заданной меткой (пробелом или символом новой строки, закрывающим тэгом XML, концом файла и т.п.) — двоичный файл, рассчитанный на произвольный доступ, должен каким-то образом определять размеры: либо он должен состоять из записей фиксированной длины, либо перед началом каждого блока должен указываться его размер, либо все размеры и смещения блоков должны храниться где-то во внешней таблице. Первый вариант для данных произвольного размера неудобен, вторые два требуют предварительного вычисления размеров в процессе записи, что делает вывод более сложным (а если блок данных достаточно большой, его, вероятно, еще нужно где-то предварительно хранить, прежде чем добавить в файл).