Модератор: Модераторы разделов
Вах, какая новость!
user@localhost
$ dd if=/dev/zero of=very-big-file bs=1 count=1 seek=1T
1+0 records in
1+0 records out
1 byte (1 B) copied, 0,000753443 s, 1,3 kB/s
$ stat very-big-file
File: `very-big-file'
Size: 1099511627777 Blocks: 32 IO Block: 4096 regular file
Device: fe04h/65028d Inode: 3498010 Links: 1
...
Бла-бла-бла. Узкое место производительности для grep — диск. Я естественно, не призываю реализовывать поиск по шаблону в SQL через вызов grep, но мы и ведем разговор несколько о другом.
watashiwa_daredeska писал(а): ↑11.11.2009 13:35Стандарты обмена дают очень даже много. Проблема-то как раз в том, что и в Windows можно написать program1 file | program2, только вот:
1. Инструментов в самой Windows ~0. Но можно поставить сторонние Cygwin, MSYS, ...
2. Хорошо, есть инструменты, но обрабатывать ими нечего, потому что «стандарта обмена данными» в Windows для этого не существует. В Unix стандартом является текст, и этот стандарт по возможности соблюдают. В Windows этот стандарт не соблюдают, как правило, даже тогда, когда можно бы.
3. В отличие от Unix, оконные приложения в Windows — это совсем совершенно другие приложения, чем консольные. Им по-умолчанию даже stdin, stdout, stderr не дают, даже если запускать из «командной строки».
Я, честно говоря, уже потерял нить: что за «программа записи файла в нужном формате»? Это первое. Второе, программа du подходит потому, что принимает на стандартный вход и выдает на стандартный вывод текст. Не рисует пискели на экране, которые можно обрабатывать только как пиксели, а принимает и выдает текст, с которым можно работать как с текстом, а не с пикселями, со всеми вытекающими. Почему там какая-то программа не подходит... Ну, опишите эту программу, посмотрим.
Если набор программ написан для использования в стиле Unix, то мало полезного от использования их в стиле Windows. Можно, конечно, сделать find ..., а потом глядя на список файлов запускать вручную для каждого sed, но это неразумно, очень мягко выражаясь.
Можно, но так удобнее. Доказательство любой теоремы можно свести к основам — аксиомам, но этого не делают, используют ранее доказанные теоремы. Однако, доказанная теорема не теряет при этом возможности быть использованной при доказательстве очередной теоремы.
С внешней точки зрения — ничем. С моей точки зрения — тем, что я этот скрипт могу поправить, дополнить новыми эвристиками и т.п. Этот скрипт — моя копилка знаний, сделанная для меня, я не делал в нем многих вещей, которые обычно делают при написании программ для общего пользования: --help, --version, --copyright, и прочее, и прочее. Он лаконичен и мне понятен.
Вывод — ничем. Даже объемом вывода не отличается. Цветностью — слегка: можно текст через фильтр пропустить и раскрасить по желанию, современные терминалы поддерживают 256 цветов — этого более чем достаточно для раскраски логов.
Читать не умею, писать не умею, компьютер вижу первый раз в жизни. Какого фига мне тогда это всё подсунули? :)
Опять двадцать пять. Ну не делают это при живой очереди. При живой очереди — ограниченный интерфейс, оптимизированный под узкий круг задач. Как кассовый аппарат. Ну, не считает кассирша на кассовом аппарате рентабельность магазина, доходность различных видов товара и прочую аналитику. Ей надо полторы кнопки и 10 цифр. И на БД ей глубоко начхать, она и слов таких может не знать.Voral писал(а): ↑11.11.2009 13:51Рядом стоит живая очередь клиентов...
Основная ваша работа - работа с клиентами, работа с базой только инструмент.
Да даже если знаете язык запросов я вам буду искренне аплодировать если вы составите запрос с набором параметров быстрее, чем я в продуманном гуевом фильтре.
YUKLA писал(а): ↑11.11.2009 12:52SysInfo рекурсивно считает объем файлов и поддиректорий от выбранной директории + вычисляет суммарный "шлак" (хвосты нераспределенных секторов). Обрабатывая при этом симлинки, не переходя по ним, но вычисляя их реальный размер на диске и "шлак", игнорирует точки монтирования и виртуальные файловые системы.
Непонятно. Что Вы на самом деле считаете?
пытаетесь сравнивать тёплое с мягким
watashiwa_daredeska писал(а): ↑11.11.2009 14:30Почему там какая-то программа не подходит... Ну, опишите эту программу, посмотрим.
watashiwa_daredeska писал(а): ↑11.11.2009 14:30Если набор программ написан для использования в стиле Unix, то мало полезного от использования их в стиле Windows.
watashiwa_daredeska писал(а): ↑11.11.2009 14:30С внешней точки зрения — ничем. С моей точки зрения — тем, что я этот скрипт могу поправить, дополнить новыми эвристиками и т.п. Этот скрипт — моя копилка знаний, сделанная для меня, я не делал в нем многих вещей, которые обычно делают при написании программ для общего пользования: --help, --version, --copyright, и прочее, и прочее. Он лаконичен и мне понятен.
watashiwa_daredeska писал(а): ↑11.11.2009 14:30Вывод — ничем. Даже объемом вывода не отличается. Цветностью — слегка: можно текст через фильтр пропустить и раскрасить по желанию, современные терминалы поддерживают 256 цветов — этого более чем достаточно для раскраски логов.
watashiwa_daredeska писал(а): ↑11.11.2009 14:30Отличается сутью. Этот самый less не имеет никакого отношения к самой программе.
watashiwa_daredeska писал(а): ↑11.11.2009 14:30Читать не умею, писать не умею, компьютер вижу первый раз в жизни. Какого фига мне тогда это всё подсунули?
watashiwa_daredeska писал(а): ↑11.11.2009 14:30Опять двадцать пять. Ну не делают это при живой очереди.
Да я тут вообще тренирую слепой метод печати для русского языка
YUKLA писал(а): ↑11.11.2009 11:341.
17 лет практики в сетях 1500+ вас устроит? Вы, пожалуйста, детский сад кончайте.
2.
И почитайте то, что вам предлагает профессионал.
3.
Простите, но вы еще в школу ходили, когда я первый стоечный сервер разворачивал.
ЗЫ: Честное слово - ожидал большего профессионализма для данного форума.
Зачем нужен аудит? Ради аудита? Вы хоть это понимаете?! Доп. расходы? Да любой мало-мальски грамотный руководитель на такие вот "непредвиденные расходы" всегда закладывается. Вы что, собрались искоренить воровство? 
Да еще и в компаниях 1500+??? Чудак вы! Или напишите в двух строках (коротко) что вы предлагаете КОНКРЕТНО.Гм, игра слов уже запрещена законодательно? Крайне сомневаюсь, что такой матерый юниксоид и писатель, как alv, мог что-то напутать в заголовке. Разве что преднамеренно. :)
Кому как. Мне, например, проще tar c dir | bzip2 -c9 >dir.tar.bz2, чем помнить ключик tar, который отвечает за сжатие gz или bz2, да к тому же есть не во всех версиях tar. Точно также, как мне удобнее grep pattern file | less, чем less +\&pattern file (для второго мне даже в man пришлось заглянуть).
Этот скрипт написан мной. Не дядей Васей. Для изменения параметров или добавления новой эвристики в аналогичную программу на C одной правкой make Вы не обойдетесь, придется править исходник на C. Если программа написана не Вами, то чтобы внести изменения и не порушить всю программу, Вам придется разобраться, как она устроена. Мне в моём собственном скрипте разобраться проще.
Самообразование — это копилка знаний в голове. Я же голову как раз разгружаю, при этом оставляя себе возможность этими знаниями пользоваться в своих целях.
Простите, что-то упустил. Какая вторая?
Я где-то писал про каждый байт? Это мой скрипт. Методики расчета оптимальных битрейтов я выискивал по интернету и корректировал для себя, я выработал эвристику, которая могла изменить размер картинки для повышения качества изображения при заданном битрейте, я подобрал разные параметры кодирования для разных типов видео: фильм, мультфильм. И т.д. Это не имеет никакого отношения к системе — чисто прикладные расчеты. Мои собственные расчеты. При чем тут «каждый байт моей системы»?
Не понял, куда может укладываться отображение?
Если вы имеете в виду графический pager, то да. Графическая программа, конечно, может быть юниксвэй, но тогда ее графическая часть к собственно юниксвэю отношения имеет мало. Как, например, gnuplot.
Дык. В том то и дело.
watashiwa_daredeska писал(а): ↑11.11.2009 18:56Кому как. Мне, например, проще tar c dir | bzip2 -c9 >dir.tar.bz2, чем помнить ключик tar, который отвечает за сжатие gz или bz2, да к тому же
watashiwa_daredeska писал(а): ↑11.11.2009 18:56Этот скрипт написан мной. Не дядей Васей. Для изменения параметров или добавления новой эвристики в аналогичную программу на C одной правкой make Вы не обойдетесь, придется править исходник на C.
watashiwa_daredeska писал(а): ↑11.11.2009 18:56Если программа написана не Вами, то чтобы внести изменения и не порушить всю программу, Вам придется разобраться, как она устроена. Мне в моём собственном скрипте разобраться проще.
watashiwa_daredeska писал(а): ↑11.11.2009 18:56Мои собственные расчеты. При чем тут «каждый байт моей системы»?
А Вы заставляете их использовать его на рабочем месте? Когда к ним стоит живая очередь?
Вы прикидываетесь или на самом деле такой? В сто двадцать пятый раз повторяю: юниксвэй нужен при большом разнообразии задач, которое трудно заранее предсказать и «подстелить соломку». Ваши клиенты решают нетривиальные и непредсказуемые вычислительные задачи пред лицом живой очереди?
Возможно. Я и не утверждал обратного. Я лишь говорил, что мне удобно пользоваться консольными инструментами. Просто потому, что я часто получаю из БД не готовый результат, а лишь заготовку, которую надо еще обточить каким-нибудь скриптиком. Ибо в этом случае рутину на себя берут эти самые скриптики.
Ок. Вот и славно.
Да не считаю я так. Вы в который раз меня превратно поняли. Я говорил о том, что unix-way можно _использовать_ в том числе и для неких целей самообразования. Т.е. не самому unix-way учиться (зачем? принципы весьма просты, их за пол-часа можно выучить), а использовать его как _инструмент_ для решения разного класса задач -- и самообразовательных в том числе. Например, задачу сбора в сети и упорядочивания справочной информации любой нужной тематики. Так доступно?
Не могу. Но это на самом деле проще и логичнее, чем помнить ключики. Как тут верно заметил, по-моему t.t, дело не в запоминании, а в понимании. Понимание — проще. Кроме того, этот способ соответствует «Rule of Clarity: Clarity is better than cleverness». Эта строка более понятна, чем всякие -j, -y, -z (или что там за какое сжатие у GNU tar отвечает?). Абсолютно не составляет труда подставить вместо tar какой-нибудь find | cpio, а вместо gzip или bzip2 какой-нибудь 7z или еще что.
Быстро. Как Вы понимаете, я знал, что это возможно, поэтому мне не пришлось читать этот ман, только заглянуть и найти поиском нужное место. Я никогда не утверждал, что помню все маны наизусть. Наоборот, я всегда утверждал, что постоянно заглядываю в маны, благо это быстро и удобно.
Не буду Вас разубеждать, а то ещё придётся побыть для Вас преподавателем по предмету Shell Scripting. Фиг с Вами, можете считать, что реализовать ( echo 0; find /bin /sbin /usr/bin /usr/sbin -type f | while read f; do b=$(basename $f); ( man $b | wc -l ) 2>/dev/null; echo +; done; echo p ) | dc на C быстрее и проще. На пару с YUKLA.
Я бы использовал ее. До тех пор, пока бы мне не понадобилось поменять/добавить методы расчета. А дальше всё зависит от гибкости программы: либо я легко могу в ней найти, где это зарыто и настроить (причем, не пересобирая, ибо поддерживать собственный форк чужой программы мне лень, разве что она сравнима по простоте с моим собственным скриптом), либо я пишу свой скрипт
Как я говорил, отображение информации вообще, как правило — финальная стадия процесса обработки. Ну, или контрольная, как спидометр.
Ядро вообще не юниксвэй.
Я предполагаю, что цепочка логического вывода в этом случае очень похожа на тот анекдот про чапаева: «не куришь — значит пи...ас».
watashiwa_daredeska писал(а): ↑11.11.2009 19:22А Вы заставляете их использовать его на рабочем месте? Когда к ним стоит живая очередь?
watashiwa_daredeska писал(а): ↑11.11.2009 19:22Ваши клиенты решают нетривиальные и непредсказуемые вычислительные задачи пред лицом живой очереди?
watashiwa_daredeska писал(а): ↑11.11.2009 19:52Но это на самом деле проще и логичнее, чем помнить ключики.
watashiwa_daredeska писал(а): ↑11.11.2009 19:52Быстро. Как Вы понимаете, я знал, что это возможно, поэтому мне не пришлось читать этот ман, только заглянуть и найти поиском нужное место
watashiwa_daredeska писал(а): ↑11.11.2009 19:52Не буду Вас разубеждать, а то ещё придётся побыть для Вас преподавателем по предмету Shell Scripting. Фиг с Вами, можете считать, что реализовать ( echo 0; find /bin /sbin /usr/bin /usr/sbin -type f | while read f; do b=$(basename $f); ( man $b | wc -l ) 2>/dev/null; echo +; done; echo p ) | dc на C быстрее и проще.
watashiwa_daredeska писал(а): ↑11.11.2009 19:52Как я говорил, отображение информации вообще, как правило — финальная стадия процесса обработки. Ну, или контрольная, как спидометр.
Unix-way -- это подход к программированию... Думаю, авторы Unix очень бы удивились, что возникают такие сентенции. Unix-way -- это способ _не программировать_.
Философия UNIX — это набор культурных норм и философских подходов к разработке программного обеспечения
Всё правильно. Набор подходов к разработке ПО, направленный на то, чтобы человек, работающий с полученным набором ПО мог решать _любые_ задачи -- в том числе и _не предусмотренные_ авторами системы _без необходимости_ программировать самому.Voral писал(а): ↑11.11.2009 21:13Хм. Да?
А можно конкретную ссылку. Видимо я так и не нашел ответа на вопрос, что такое Unix way. Хотя все принципы что здесь приводили видел. Например
в викиФилософия UNIX — это набор культурных норм и философских подходов к разработке программного обеспечения
Все ссылки по UNIX way именно на философию UNIX. Если это различные понятия ткните меня в ссылку.
Unix-way -- это подход к программированию...
t.t писал(а): ↑11.11.2009 22:07Себя программистом не считаю. Программировать умею, но не люблю. В частности, за то и люблю unix-way, что он предоставляет мне возможность решать свои задачи, _не программируя_: в том числе и "нестандартные; в том числе и такие, о каких я раньше и сам подозревать не мог.