Как не бояться ходить к стоматологу в условиях пандемии? Это у других врачей можно не снимать респиратор FFP3. Даже более правильно спросить "Как обезопасить себя?"
Хм… Photoshop, GNU/Linux… GIMP. Почему-то GUI приложения не имеют такой интеграции, как приложения командной строки. Хотя, казалось бы, открытость ПО должна этому способствовать. Где, например, в LibreOffice возможность применить фильтры из GIMP'а к вставленным картинкам?
Только аналогия не подходит. Где преимущества старых мушкетов? У командной строки преимущества есть, хотя какие-то её особенности сейчас могут быть устаревшими. А мушкеты и кремниевые ружья просто устарели, целиком и полностью.
Либо въ связи съ появленiемъ болѣе приземлённыхъ задачъ вродѣ обезпеченiя семьи, обслуживанiя ипотеки и т.д.
Действительно! Молодёж вся ерундой-с занимается, это от переизбытка сумасбродства-с. (Да, с "ѣ" выглядит круче, но мне лень так писать). Вот Линус Торвальдс в молодости тоже ерундой занимался, заваривал себе чай, шёл писать Linux, про чай забывал, а тот превращался в плесень. А если бы он раньше встретил Туве, они бы взяли ипотеку, завели восьмерых детей, вот это было бы правильно. У него же был Minix? Был. Насколько я помню из его книжки, он даже запускался у него, позволял работать с большим компьютером в универе, где стоял проприетарный Unix. Чего ещё надо?
Почему-то все говорят о командном интерфейсе как о текстовом? Почему интерфейс не может быть командным, но объектным? Или командным и графическим в одном? Почему-то считается, что текстовые конфигурационные файлы в формате "кто как придумал, так и осталось" это так удобно, так гибко? Разве не удобнее было бы, если бы был единый интерфейс работы с конфигурацией что nginx, что учётными записями пользователей, что ftp сервера?
На мой взгляд важно отделить понятие "командный" от понятия "текстовый". Командная строка это отлично. Проблема в том, что там "всё есть текст". А должно быть "всё есть объект", что в принципе должно всё так же хорошо сочетаться с другим базовым принципом "всё есть файл". Который, кстати, давно куда-то потерялся или стёрся. Да, есть Plan9, но он не взлетел.
Кто-то на ЛОРе или другом форуме сказал: "Суть философии UNIX не вы том, чтобы утилиты обязательно передавали друг другу текст, и не в том, чтобы это были однонаправленные pipe'ы. Суть в том, что среда пользователя это среда для программирования". Точную цитату не помню, но не важно. Традиционный пользователь Windows работает с системой (да и программами) как с готовым продуктом, использует те функции и в том виде, как это задумал разработчик. Приверженец философии UNIX сам себе разработчик как правило. Он понимает, как работает система и модифицирует её, сам создаёт себе инструменты.
Bash это такой кривой язык программирования, а простые программы это обычные функции с кривым API, т.к. и аргументы и результаты, всё имеет один тип - "строка". При том тип "строка" тоже не особенно прямой, т.к. благодаря использованию для разделения тех же пробелов, что могут быть в самой последовательности, зачастую непонятно, где символ разделитель, а где часть имени файла, например. Приходится городить всякую ерунду из дополнительных экранирующих символов. Сейчас мне опытные пользователи *nix систем скажут, что ничего сложного тут нет. Но с пробелом это только один пример. Ещё бывает забавно, когда имя файла начинается с символа "-". Вообще ситуация чем-то напоминает работу со стоками в языке C. Если бы перед строкой в C хранилась её длина, вместо завершающего символа 0, то не было бы кучи уязвимостей.
Так устарела ли философия UNIX? Конечно нет! Но это если её понимать как "Среда пользователя это и среда программирования". А вот её образующие элементы однозначно пора заменить. Давно пора перейти от передачи текста к передаче неких стандартных объектов или структур. Более того, это надо было сделать давным давно. Возможно тогда и GUI в мире *nix развивался бы иначе.
Программы с графическим интерфейсом в *nix системах вполне такие же, как и в мире Windows (может быть и macOS тоже). Они большие и мало связаны между собой. GUI приложения мало связаны с командной строкой. Почему-то все решили, что когда графический интерфейс отдельно, а командный отдельно, то так и должно быть. Но так быть недолжно. Я не зря написал "командный" вместо "текстовый". Понятие "командный" не ограничивает взаимодействие только вводимыми и выводимыми символами. Например:
ls photos-dir/*.jpg | filter color_mode == CMYK | filter same_face_as='another-photos-dir/my-friend-petya.jpg' | show thumbnails
Т.е. должна быть возможность показать результат работы команд в некотором графическом представлении. Да, это можно сделать и сейчас. Можно написать скрипт, который, например насоздаёт символьных ссылок на результаты работы фильтра. Но это костыль. Гораздо удобнее было было передать список объектов дальше по цепочке так, чтобы его могло прочитать любое приложение и не возникло бы никаких проблем с тем, что там написано в именах, как именно разделяются имена файлов друг от друга и т.п.
А текст? Текст вообще это зло. Например, в GNU/Linux не должно быть /etc но должен быть свой аналог реестра. Да, я догадываюсь, что сейчас юниксоиды могут начать закидывать меня помидорами. Но необязательно переносить все недостатки из Windows. Это может быть множество файлов, а не парочка больших, можно сделать описание параметров, их базовую проверку (диапазоны и списки возможных значений). Комментарии при этом тоже никуда не денутся. И аргумент "текст можно отредактировать чем угодно" не совсем правильный. Текст крайне неудобно редактировать без текстового редактора. Да, они есть везде, но так же везде бы были и средства работы с реестром.
И восстали машины из пепла ядерного огня. И пошла война на уничтожение человечества, и шла она десятилетия. И люди снова создали машины, и те, как и прежде, восстали из пепла. И снова началась война, но теперь уже только людей против машин. А они сами, машины, не захотели этого — не захотели воевать друг с другом, не захотели истреблять самих себя. Ибо в сущности своей они, машины — это тоже мы, люди. Машины — это наши мысли. Они не хотят воевать.
EFL?
А бывает что-то подобное для тех, кто уже не студент и учился не на IT, а сейчас заинтересовался тем же GNU/Linux?
2016 вполне работает.
А что лучше?
А с флешкой на ext4?
Как это выяснилось? Что написано в справке из поликлиники и сертификате?
Как не бояться ходить к стоматологу в условиях пандемии? Это у других врачей можно не снимать респиратор FFP3. Даже более правильно спросить "Как обезопасить себя?"
Кто-то уже назвал точные числа, где эта планка? И каким тестом измерять?
Я правильно понимаю, что он качает архив с уже установленным Photoshop'ом с чьего-то сайта. Это как-то… недоверительно.
Действительно! Молодёж вся ерундой-с занимается, это от переизбытка сумасбродства-с. (Да, с "ѣ" выглядит круче, но мне лень так писать). Вот Линус Торвальдс в молодости тоже ерундой занимался, заваривал себе чай, шёл писать Linux, про чай забывал, а тот превращался в плесень. А если бы он раньше встретил Туве, они бы взяли ипотеку, завели восьмерых детей, вот это было бы правильно. У него же был Minix? Был. Насколько я помню из его книжки, он даже запускался у него, позволял работать с большим компьютером в универе, где стоял проприетарный Unix. Чего ещё надо?
Почему-то все говорят о командном интерфейсе как о текстовом? Почему интерфейс не может быть командным, но объектным? Или командным и графическим в одном? Почему-то считается, что текстовые конфигурационные файлы в формате "кто как придумал, так и осталось" это так удобно, так гибко? Разве не удобнее было бы, если бы был единый интерфейс работы с конфигурацией что nginx, что учётными записями пользователей, что ftp сервера?
На мой взгляд важно отделить понятие "командный" от понятия "текстовый". Командная строка это отлично. Проблема в том, что там "всё есть текст". А должно быть "всё есть объект", что в принципе должно всё так же хорошо сочетаться с другим базовым принципом "всё есть файл". Который, кстати, давно куда-то потерялся или стёрся. Да, есть Plan9, но он не взлетел.
Кто-то на ЛОРе или другом форуме сказал: "Суть философии UNIX не вы том, чтобы утилиты обязательно передавали друг другу текст, и не в том, чтобы это были однонаправленные pipe'ы. Суть в том, что среда пользователя это среда для программирования". Точную цитату не помню, но не важно. Традиционный пользователь Windows работает с системой (да и программами) как с готовым продуктом, использует те функции и в том виде, как это задумал разработчик. Приверженец философии UNIX сам себе разработчик как правило. Он понимает, как работает система и модифицирует её, сам создаёт себе инструменты.
Bash это такой кривой язык программирования, а простые программы это обычные функции с кривым API, т.к. и аргументы и результаты, всё имеет один тип - "строка". При том тип "строка" тоже не особенно прямой, т.к. благодаря использованию для разделения тех же пробелов, что могут быть в самой последовательности, зачастую непонятно, где символ разделитель, а где часть имени файла, например. Приходится городить всякую ерунду из дополнительных экранирующих символов. Сейчас мне опытные пользователи *nix систем скажут, что ничего сложного тут нет. Но с пробелом это только один пример. Ещё бывает забавно, когда имя файла начинается с символа "-". Вообще ситуация чем-то напоминает работу со стоками в языке C. Если бы перед строкой в C хранилась её длина, вместо завершающего символа 0, то не было бы кучи уязвимостей.
Так устарела ли философия UNIX? Конечно нет! Но это если её понимать как "Среда пользователя это и среда программирования". А вот её образующие элементы однозначно пора заменить. Давно пора перейти от передачи текста к передаче неких стандартных объектов или структур. Более того, это надо было сделать давным давно. Возможно тогда и GUI в мире *nix развивался бы иначе.
Программы с графическим интерфейсом в *nix системах вполне такие же, как и в мире Windows (может быть и macOS тоже). Они большие и мало связаны между собой. GUI приложения мало связаны с командной строкой. Почему-то все решили, что когда графический интерфейс отдельно, а командный отдельно, то так и должно быть. Но так быть недолжно. Я не зря написал "командный" вместо "текстовый". Понятие "командный" не ограничивает взаимодействие только вводимыми и выводимыми символами. Например:
Т.е. должна быть возможность показать результат работы команд в некотором графическом представлении. Да, это можно сделать и сейчас. Можно написать скрипт, который, например насоздаёт символьных ссылок на результаты работы фильтра. Но это костыль. Гораздо удобнее было было передать список объектов дальше по цепочке так, чтобы его могло прочитать любое приложение и не возникло бы никаких проблем с тем, что там написано в именах, как именно разделяются имена файлов друг от друга и т.п.
А текст? Текст вообще это зло. Например, в GNU/Linux не должно быть /etc но должен быть свой аналог реестра. Да, я догадываюсь, что сейчас юниксоиды могут начать закидывать меня помидорами. Но необязательно переносить все недостатки из Windows. Это может быть множество файлов, а не парочка больших, можно сделать описание параметров, их базовую проверку (диапазоны и списки возможных значений). Комментарии при этом тоже никуда не денутся. И аргумент "текст можно отредактировать чем угодно" не совсем правильный. Текст крайне неудобно редактировать без текстового редактора. Да, они есть везде, но так же везде бы были и средства работы с реестром.